Part I: Security Overview

1. Security model and service boundary

Fintant is building a managed-service delivery system for controlled back-office accounting production. It is not an autonomous accounting platform and does not give Fintant independent authority to post to ledgers, file tax returns, execute payments, release payroll, issue assurance opinions, or communicate with an accounting firm’s end client.

The security model is based on:

invitation-only access; accounting-firm-first tenancy; server-enforced role and organization authorization; least privilege and separation of duties; versioned records and governed audit history; source evidence, exceptions, and human review; separate Fintant quality assurance and accounting-firm approval; fail-closed provider and file states; data minimization and privacy-safe logging; and no live Client Financial Data until production release gates are satisfied.

2. Current production-readiness status

The application includes substantial security and workflow controls, but the repository and current environment are not approved for live Client Financial Data.

As of this draft, the following remain production release gates:

approved managed identity, authentication, invitation, recovery, and session configuration; approved production application, database, and backup region; approved private object storage; approved production file-security scanning and quarantine evidence; approved monitoring, on-call, alerting, and incident operation; approved retention, deletion, and backup-purge schedule; approved provider and subprocessor contracts, regions, transfer mechanisms, and client authorizations; tested production restore and incident exercises; completed legal, privacy, security, operations, accounting-quality, accessibility, and deployment approval; and client-specific data-region, offshore-access, AI, and provider restrictions.

Until these gates are satisfied, live or identifiable Client Financial Data must not be placed in production, development, test, demo, analytics, logs, screenshots, fixtures, or unapproved AI systems.

3. Identity, invitations, and sessions

The intended production design includes:

client access only by a controlled organization invitation; identity-provider authentication connected to Fintant’s local organization, membership, invitation, and role records; verified-email code authentication through the currently implemented WorkOS Magic Auth path, subject to production account, contract, configuration, recovery, and approval evidence; recovery and recent-authentication checks appropriate to the action and actually enabled in the approved production configuration; secure, HTTP-only session cookies with limited lifetime, SameSite protection, and Secure transmission in production; session revocation, expiry, and controlled replacement; and recorded acceptance of the applicable policy version.

A provider identity or successful authentication does not itself grant access. Fintant’s server-side organization, membership, role, status, invitation, and session records remain authoritative.

The currently implemented managed-provider contract uses WorkOS Magic Auth verified-email codes. Public signup, passwords, social OAuth, Enterprise SSO, passkeys, progressive passkey enrollment, TOTP, and multi-factor authentication are disabled or unapproved for the current release path. Production identity remains a release gate until the exact account, agreement, configuration, environment mapping, recovery process, owner approvals, and production-like journey evidence are complete.

4. Tenancy and authorization

Every protected object and action is designed to be scoped to an accounting-firm organization. Authorization must be enforced on the server and across:

pages and application programming interfaces; work queues and background jobs; files, versions, storage keys, and downloads; search, cache, and analytics references; questions, notifications, and exports; audit records and support tools; and Fintant operations access.

Client roles are separated into administrator, firm reviewer, contributor, and viewer responsibilities. Fintant roles are separated into platform administration, operations, preparer, quality assurance, and support or audit responsibilities.

End-client entities do not receive accounts in the default model. Fintant internal notes are restricted from client-facing pages, APIs, notifications, and exports.

5. Files and data lifecycle

The intended production file lifecycle includes:

authorization before an upload target is issued; private versioned storage; expected size, type, and content-hash validation; quarantine before availability; file-security scanning tied to the exact version and hash; fail-closed handling for malicious, unavailable, timed-out, stale, or mismatched results; short-lived and authorization-checked downloads; governed replacement through a new version rather than silent overwrite; explicit superseded, archived, deletion-scheduled, deleted, and legal-hold states; and recorded active-store, object-store, provider, de-identification, and backup-purge status.

A transfer confirmation does not mean a file is safe or available. Production object storage and production scanning are not yet approved, so this lifecycle must not be described as fully active until the provider, configuration, tests, monitoring, and release evidence are complete.

6. Application and API protections

Implemented or designed controls include:

cross-site request forgery protection; security response headers; strict request and response validation; bounded inputs, uploads, pagination, retries, and job behavior; rate limits and abuse protection; safe error messages; signed provider webhooks, authoritative follow-up checks, and replay deduplication; secrets kept out of browsers, source, URLs, logs, analytics, and audit records; safe correlation and result identifiers for support and monitoring; and fail-closed behavior when the provider, organization, permission, or state is not authoritative.

Security controls must be verified in the actual production deployment, not inferred from source-code presence.

7. Work integrity, versions, and approvals

Fintant’s workflow is designed to preserve:

source records and references; work scope, account, period, and entity; file and deliverable versions; model or workflow version where applicable; deterministic control results; confidence, missing-source, conflict, and exception states; preparer actions and Fintant quality-assurance decisions; separate client-firm review, rejection, acceptance, and approval; actor, time, organization, object, result, and safe change evidence; and downstream authorization boundaries.

Fintant quality assurance does not equal accounting-firm approval. No deliverable authorizes posting, filing, payment, payroll release, assurance, or end-client communication.

8. Encryption, secrets, and data minimization

The intended production standard includes:

encrypted transport for website, portal, provider, and administrative connections; encryption at rest in approved production application, database, object-storage, and backup systems; secret management with least privilege, rotation, separation, and no client-side exposure; named accounts and an approved strong-authentication method for privileged access; minimum necessary collection and transfer; no public or reusable file URLs; no financial file content, credentials, provider secrets, tax identifiers, account numbers, internal notes, or message bodies in ordinary audit, analytics, or application logs; and de-identification or aggregation only under contractual and technical controls that prevent reasonable re-identification.

Specific algorithms, key-management details, and provider attestations must be confirmed from the approved production environment before making a more specific public claim.

9. Providers, subprocessors, and cross-border access

Fintant reviews providers for purpose, data, contract, security, access, region, transfer mechanism, retention, deletion, incident handling, backup, tests, and evidence.

A provider used in code, test, or evaluation is not automatically approved for production. The Subprocessor Register distinguishes approved production subprocessors from providers under review and unselected capabilities.

Fintant may use authorized personnel in the United States, Canada, and Bangladesh only after the applicable contract, country, role, access, workforce, taxpayer, end-client, and client-authorization requirements are satisfied. Client-specific restrictions must fail closed.

10. Logging, monitoring, and support

The design supports:

governed audit records for material business and administrative actions; privacy-safe operational logs with correlation identifiers; provider delivery and callback evidence without raw secrets or sensitive content; worker health, job lease, retry, and failure evidence; controlled, time-limited support elevation; session revocation and incident containment; alerts for material control failures; and documented acknowledgement and escalation.

The production monitoring provider, on-call ownership, acknowledgement targets, and evidence remain release gates. A source-code alert or console message is not a production monitoring program.

11. Retention, deletion, legal holds, and backups

Fintant’s application model supports policy-driven retention, deletion requests, legal holds, active-store deletion, provider deletion, de-identification, and backup-purge tracking.

The production schedule must define:

record categories and owners; retention event and duration; client return or deletion instructions; legal, tax, insurance, dispute, security, and professional exceptions; active-system deletion timing; provider deletion; protected backup lifecycle and purge; legal-hold authority and release; and evidence of completion.

The existence of application fields or jobs does not establish legal approval or completed deletion. The schedule, providers, backup behavior, and evidence must be approved before live-data launch.

12. Personnel and contractor security

Before personnel receive access appropriate to their role, Fintant’s operating model requires:

identity and role verification; signed confidentiality, intellectual-property, privacy, and security duties; screening or background checks required by policy and law; security and financial-data training; named accounts, approved strong authentication, approved devices, and least privilege; no personal email, personal storage, public links, or unapproved local downloads; activity logging and periodic access review; incident-reporting and cooperation duties; and timely role change and offboarding.

These controls must be documented in the Workforce Security Policy and operating evidence before offshore or privileged live-data access.

13. AI and automated processing

Client Financial Data may be submitted to AI, optical character recognition, extraction, classification, or automation only after the provider, contract, region, retention, training settings, security, workflow, and client authorization are approved.

Approved processing must:

minimize input; prohibit use through personal or consumer accounts; prohibit general model training unless separately and lawfully authorized; retain source references, workflow or model version, confidence, and exceptions where applicable; use deterministic controls; require human review; and preserve the accounting firm’s final authority.

No AI-assisted output independently authorizes posting, filing, payment, payroll release, assurance, or external communication.

14. Assurance and truthful claims

Fintant does not claim SOC 2, ISO 27001, PCI DSS, penetration-test coverage, regulatory approval, or another independent certification unless the assessment is completed, current, scoped to the relevant service, and approved for publication.

Security documentation, questionnaires, test summaries, or client evidence may be provided under appropriate confidentiality. This public overview is not a substitute for a Client Agreement, Data Processing and Security Addendum, security addendum, or client-specific due diligence.

15. Security incidents

Report a suspected incident to security@fintant.ai. Do not include credentials, tax information, financial statements, source files, or other Client Financial Data in ordinary email.

Fintant’s incident process is intended to:

receive and triage the report; preserve evidence and establish an incident lead; contain and remediate the issue; determine affected systems, data, clients, jurisdictions, and providers; coordinate client, insurer, counsel, regulator, law-enforcement, and individual notice as applicable; recover and validate service; document decisions and corrective actions; and complete a post-incident review.

Notification duties and timing are governed by law and the applicable Client Agreement.

Part II: Responsible Disclosure Policy

16. Purpose

Fintant welcomes good-faith reports that help identify and correct security vulnerabilities. This Policy provides authorization only for research performed within the scope, rules, and reporting process below.

This is not a bug-bounty program. Fintant does not promise payment, public recognition, or a specific remediation result.

17. Authorized scope

Once this Policy is approved and published, authorized scope will include:

Fintant-owned production website and portal domains identified on Fintant’s published security page; and Fintant-owned production API endpoints used by those services.

The exact domains and API hosts must be inserted and verified before publication.

The following are out of scope unless Fintant gives separate written authorization:

development, test, staging, preview, demo, local, or internal environments; Fintant employee or contractor devices and accounts; third-party provider systems, including identity, email, scheduling, meetings, hosting, storage, scanning, monitoring, analytics, or AI services; client systems, accounting systems, bank systems, email tenants, and end-client systems; physical offices, facilities, networks, and personnel; denial-of-service, load, or destructive testing; and social engineering, phishing, pretexting, bribery, coercion, or physical intrusion.

If you are unsure whether a system is in scope, ask security@fintant.ai before testing.

18. Research rules

To remain within this Policy:

use only accounts and data you own or have explicit written permission to test; stop after confirming the minimum evidence needed to demonstrate the vulnerability; avoid accessing, downloading, retaining, altering, or deleting another person’s or organization’s data; do not establish persistence, move laterally, escalate beyond the minimum proof, or maintain unauthorized access; do not exploit a vulnerability for profit, leverage, publicity, competitive use, or any purpose beyond reporting; do not perform automated high-volume scanning, credential stuffing, password spraying, brute force, denial-of-service, resource exhaustion, or spam; do not upload malware or destructive payloads; do not disrupt service, corrupt data, alter accounting evidence, change approvals, or impair audit history; do not access provider secrets, production credentials, tax information, bank information, source documents, or financial records beyond the minimum unavoidable evidence; securely delete any inadvertently obtained Fintant data after Fintant confirms it is no longer needed; and keep the report and vulnerability confidential until Fintant authorizes disclosure or 90 days have passed after a complete report, whichever is later, unless law requires otherwise.

If your testing encounters Client Financial Data, credentials, internal notes, provider secrets, or another organization’s records, stop immediately and report the event.

19. How to report

Email security@fintant.ai with:

the affected domain, API, page, endpoint, parameter, or feature; the vulnerability type and potential impact; the date and time observed, including time zone; clear reproduction steps using non-sensitive evidence; relevant request and response details with credentials, tokens, cookies, personal information, and Client Financial Data removed; screenshots or proof-of-concept material only when necessary and safely redacted; whether any data was accessed and, if so, the minimum category and amount; actions already taken and whether the issue appears ongoing; and a safe way to contact you.

Do not send active credentials, session cookies, private keys, unredacted financial data, or malicious code by ordinary email. Ask for a secure transfer channel when needed.

20. Fintant’s response

For a complete, good-faith report, Fintant’s non-contractual operating targets are to:

acknowledge receipt within 5 business days; complete initial severity and scope triage within 10 business days; provide a status update at least every 15 business days while active, where practical; and coordinate a remediation and disclosure plan based on risk, complexity, provider dependence, and affected clients.

These are targets, not service levels or guarantees. Law, active exploitation, incident containment, third-party dependencies, or incomplete information may change the sequence.

Fintant may ask for clarification, validate the issue, combine duplicate reports, or determine that a report is informational, out of scope, accepted risk, or not reproducible.

21. Safe-harbor intent

When research is performed in good faith and complies with this Policy, Fintant intends to:

treat the research as authorized under this Policy; not initiate legal action against the researcher for accidental, good-faith violations promptly reported and corrected; and work with the researcher to understand and resolve the issue.

This authorization is limited. Fintant cannot authorize conduct on third-party or client systems, waive another party’s rights, bind law enforcement or regulators, or excuse conduct prohibited by applicable law. Extortion, threats, intentional privacy invasion, fraud, destructive action, public disclosure contrary to this Policy, or continued access after notice is not authorized.

If you are concerned whether proposed research is authorized, contact security@fintant.ai before proceeding.

22. Coordinated disclosure and recognition

Do not publicly disclose a vulnerability, affected system, client, data, proof of concept, or remediation detail until Fintant confirms that disclosure is safe and authorized.

Fintant may provide recognition at its discretion and only with the researcher’s consent. Fintant does not commit to a bounty or other compensation.

23. Changes and contact

Fintant may update this Policy as its systems and security program change. The version and effective date will be published, and material prior versions will be archived.

Security reports: security@fintant.ai Privacy questions: privacy@fintant.ai General support: support@fintant.ai Mail: Fintant Inc., 73-12 35th Avenue, Suite A45, Jackson Heights, NY 11372