System Description

Owner	Classification	Version	Effective	Next review	Status
Sekhar Prakash	Internal	0.1	2026-08-27	2026-11-27	Draft

Purpose. The narrative description of the Finaisse system for audit — the working draft of Section III of a SOC 2 report.

Covers:

• Services
• System boundaries
• The five system components (infrastructure, software, people, procedures, data)
• Subservice organizations
• Complementary user-entity controls
• How controls over the system are organized

Companion to the Security Posture scoreboard; where it references controls or status it links rather than restates.

Internal draft — not the issued report

This is the internal working draft. The version in an issued SOC 2 report is finalised with the auditor and is present-tense about operating controls; this draft honestly marks controls not yet operating (🎯 Target) for planning.

1. Services & overview

Finaisse operates the Finaisse platform — a multi-tenant financial-operations SaaS.

• Covers: close management, reconciliation, invoicing, journal, and collections, with an AI agents layer (Finni).
• Customers: finance teams.
• Data processed: their financial records and related personal identifiers.

2. System boundaries

• In scope: the blitz backend microservices, blitz-ui frontend, and fin-infra infrastructure-as-code; the AI agents surface; staging (Railway, live) and production (AWS ap-south-1, in build).
• Out of scope (this phase): US/EU regions (driven by future customer residency needs); card-payment handling (no PAN in scope).

3. Principal service commitments & requirements

• Confidentiality, integrity, and availability of customer financial data.
• Tenant isolation — no customer can reach another's data, workload, or identity.
• Data residency in-region (Mumbai; India DPDP baseline).
• Controlled, traceable changes to production; recoverability.

4. System components

4.1 Infrastructure

• Staging — Railway: code-defined via TypeScript against Railway's API; operator access via GitHub SSO; backends private on .railway.internal.
• Public edge — Cloudflare: DDoS, CDN, TLS, and the admin portal behind Cloudflare Access.
• Production — AWS: Terraform/Terragrunt; ap-south-1; IaC-only with no manual console changes.

(Detail: Architecture — Infrastructure.)

4.2 Software

• Backend: Bun/TypeScript microservices (Elysia).
• Frontend: Vue 3 / Vuetify.
• .NET services: two — excelrw · bapiproxy.
• CI/CD: GitHub Actions to GHCR. Automated checks do not gate merges; the current CI control state is recorded in the Control Register. Change control is pull-request review plus branch protection.

(Detail: Architecture — Backend.)

4.3 People

Role	Responsibility	Holder
CEO	Management commitment	Kris
COO	Executive sponsor; people, privacy, ops	Payeli
Security & Infrastructure Owner	Owns the ISMS, security, cloud, infra	Sekhar
Engineering	Implements and evidences controls	All engineers

Access is least-privilege and role-based; see Access Control Policy.

4.4 Procedures

Procedures:

• Secure SDLC
• Change management
• Incident response
• Access provisioning/deprovisioning
• Backup/restore

Governed by the Policy Library; operated per Platform Operations and the Assessment & Evidence Cadence.

4.5 Data

• Classification: customer financial transactions, journals, reconciliations, and personal identifiers are Restricted (Data Classification Policy).
• Isolation: a dedicated database per customer.
• Encryption: in transit (TLS at the edge) and at rest (managed keys; 🎯 CMKs with the AWS build).
• LLM: identifiers sent to the LLM are tokenised (LLM PII Tokenization).

5. Subservice organizations (subprocessors)

The parties in the data path — with purpose, data category, location and DPA/assurance status for each — are maintained in the Subprocessor Register. That page is authoritative; this section deliberately does not restate the list, because a second copy drifts (it previously carried 7 entries against the register's 12, and domains.md a third list of 12 with different membership again).

Two exposures worth naming here for the reader of this narrative, both detailed in the register: LLM inference providers receive tokenised financial/PII data, and object storage (RustFS / S3) holds Restricted data at rest.

6. Complementary user-entity controls (CUECs)

Controls the customer is responsible for, which the system assumes:

• Manage their own users and role assignments within their tenant.
• Review and authorise approval-rule configuration used for straight-through posting.
• Reconcile postings to their general ledger.
• Protect their own credentials and access.

7. Control framework

• Organized into 20 security domains, mapped to SOC 2 (TSC), ISO 27001:2022, CIS v8, and OWASP.
• See: Control Register · Coverage.
• Current operating state: Security Posture.
• Certification roadmap: Framework & Cert Register.

Related

• → Security Posture
• → Security Domains
• → Control Register
• → ISMS Scope & Framework

Revision history

Version	Date	Author	Change
0.1	2026-08-27	Sekhar Prakash	Reframed the organisation overview into a SOC 2 System Description (five components, boundaries, subservice orgs, CUECs).

Finaisse Internal — Confidential. Not for external distribution.