SOC 2 by industry
SOC 2 for fintech: controls a partner bank can lean on.
In fintech, a missing control rarely stays theoretical: it shows up as a payment sent twice, a balance that does not reconcile or a bank partner asking hard questions. A SOC 2 report gives that bank, and your enterprise customers, an independent view of how money-moving systems are built, changed and checked. This guide covers what each reader looks for and how the scope is usually drawn.
Back to SOC 2 services01 · Who asks
Who asks fintech companies for a SOC 2 report
The buyer decides the scope and the weight of the report, so start with who is asking.
| Asked by | What they want to see |
|---|---|
| Sponsor or partner banks | Evidence for their own third-party risk review: change control, access to ledgers, incident handling and how you supervise your own vendors. |
| Enterprise customers using your payments or treasury product | A Type 2 report covering Processing Integrity, plus clarity on which reconciliations they must perform themselves. |
| Investors and acquirers in diligence | Whether controls exist on paper and in practice, and whether any exceptions point at money movement. |
| Card networks or processors you integrate with | Usually a separate standard (PCI DSS) for card data. A SOC 2 helps with everything around it. |
| The customer's financial statement auditor | Sometimes a SOC 1 instead, if your system feeds their general ledger. See the callout below. |
02 · What is in scope
What sits inside the system boundary
The report covers one system. In this sector the boundary usually takes in:
- The internal ledger
- The system of record for balances and transactions. Who can post manual adjustments is the first question.
- Payment orchestration
- The services that build, sign, send and track instructions to banks, card processors or payment rails.
- Reconciliation jobs
- The scheduled comparisons between your ledger, the bank's statement files and processor reports.
- Onboarding and identity checks
- Customer due-diligence flows and the third-party verification services they call.
- Keys and credentials to banking partners
- API keys, certificates and file-transfer credentials that can move money. Where they live and who can use them.
03 · Categories
Which Trust Services Categories matter here
Security is always in. The rest depend on what you promise customers.
| Category | Weight in this sector | Why |
|---|---|---|
| Security | Core | Always included. Privileged access to the ledger and to banking credentials is read line by line. |
| Processing Integrity | Common | When customers rely on you to move or record money completely and accurately, PI1.1 to PI1.5 describe exactly that promise. |
| Availability | Common | Payment windows and settlement cut-offs make downtime costly. Buyers expect tested recovery. |
| Confidentiality | Often | Account numbers, statements and business financials are confidential to customers even where they are not personal. |
| Privacy | Situational | Most likely for consumer-facing products that collect personal financial information directly from individuals. |
04 · Vendors in the report
The vendors that appear in your report
Each one is a subservice organization or a carve-out, and the report has to say which.
- Partner bank or payment processor
- Usually carved out. Their controls over settlement are outside your system, but your controls over the instructions you send them are inside.
- Identity verification and sanctions screening providers
- Carved-out subservice organizations. Your report names what you rely on them for and how you review their reports.
- Cloud and key management services
- Carved out, with CSOCs such as hardware-backed key storage stated in the description.
- Open-banking or account aggregation providers
- Often in the data flow. Treat them as subservice organizations if a control depends on their accuracy.
05 · Sector controls
Controls that this sector makes necessary
Examples only. Your own wording is what the auditor tests.
- S.1Manual ledger adjustments need two peopleAny posting outside the automated flow is raised by one person and approved by another, with a reason code.
- S.2Daily three-way reconciliationLedger, bank statement and processor report are compared each business day. Breaks are assigned and tracked to closure.
- S.3Payment instructions are idempotentEach instruction carries a unique key so a retry cannot send money twice. Tested on every release that touches payments.
- S.4Banking credentials sit in a managed vaultNo human can read the production keys. Rotation and access are logged.
- S.5Changes to money-moving code have an extra reviewerPull requests touching payments or ledger logic need a second approver from a named group.
- S.6Limits and velocity checksPer-account and per-day limits are configured, changes to them are approved, and breaches raise alerts.
- S.7Vendor reports reviewed against relianceEach year the partner bank's and processors' reports are read, and their CUECs mapped to your controls.
06 · Traps
Where companies in this sector slip
Predictable, and cheaper to fix before fieldwork.
- Choosing Processing Integrity without defining 'correct'. PI needs written processing specifications: what a complete, accurate and timely transaction means. Without them there is nothing to test against.
- Reconciliations done in a spreadsheet nobody keeps. The control may run every day, but if the file is overwritten there is no population to sample.
- Ops staff with standing write access to the ledger. Convenient for fixing breaks, and the first thing a reviewer flags. Route fixes through approved adjustments.
- Forgetting the batch file path. The SFTP job that sends payment files to the bank is part of the system. Its credentials, logs and failure alerts belong in scope.
- Assuming the bank's oversight replaces your own. Your partner reviews you, but the report still needs your monitoring of the vendors you rely on.
07 · Money-flow integrity
Following one payment through the controls
An illustrative transfer, and the control an auditor would test at each step.
| Step | What can go wrong | Example control tested |
|---|---|---|
| Customer submits a transfer | Unauthorised or tampered request | Strong authentication and signed requests (Security) |
| Limits and screening | Over-limit or prohibited payment passes | Automated checks with logged overrides (PI1.2, input) |
| Ledger records the debit | Wrong amount or duplicate posting | Idempotency keys and balance checks (PI1.3, processing) |
| Instruction sent to the partner bank | File lost, altered or sent twice | Signed files, delivery confirmation, failure alerts (PI1.3) |
| Bank confirms settlement | Status never returns | Unmatched-item aging report worked daily (PI1.4, output) |
| Daily reconciliation | Ledger and bank disagree | Three-way reconciliation with tracked breaks (PI1.4, PI1.5) |
Criteria references are indicative. Map each control to the criterion your auditor agrees it addresses during readiness.
08 · Evidence
Evidence to have ready
What an auditor will ask for, in the order they usually ask.
- Processing specifications for each payment type
- Reconciliation records for sampled days, with breaks and their resolution
- Manual ledger adjustments for the period, each with its approval
- Pull requests to payment code, showing the second reviewer
- Vault access logs and credential rotation records
- Limit-change approvals
- Your review of the partner bank's and processors' SOC reports
SOC 1 or SOC 2? Partner banks and customer auditors
If your system affects a customer's financial reporting, their auditor may ask for a SOC 1 (AT-C section 320) rather than, or as well as, a SOC 2. Separately, US banks are expected to manage risk from their fintech partners under interagency third-party risk management guidance; your SOC 2 supports their review but does not replace it. Card data brings PCI DSS, which a SOC 2 does not satisfy.
Sources: AICPA Trust Services Criteria (TSP section 100), Processing Integrity criteria PI1.1 to PI1.5; AICPA SSAE 18, AT-C section 320; Interagency Guidance on Third-Party Relationships: Risk Management (US federal banking agencies); PCI Security Standards Council, PCI DSS.
More about SOC 2 for fintech
Our partner bank sent a 200-question survey. Will a SOC 2 replace it?
It shortens it. It rarely replaces it.
Many answers can point at sections of the report. Questions about regulatory programs, such as anti-money-laundering procedures, sit outside the Trust Services Criteria, so the bank will still ask them directly.
Do we need Processing Integrity if we only display balances?
Probably not.
Processing Integrity fits when customers rely on you to process transactions correctly. A read-only view of data held at a bank makes accuracy of display a smaller commitment, usually covered within Security and Confidentiality. Decide based on what your contract promises.
Can reconciliations performed by our bank partner count as our control?
No. Theirs support yours.
A reconciliation the bank runs is their control, visible only through their report. Your report needs a reconciliation you perform, or a stated reliance on theirs as a complementary subservice organization control.
We hold no card numbers. Is PCI DSS still relevant?
Perhaps, for your integration.
If card data never touches your systems because a processor's hosted fields collect it, your PCI obligations are usually much smaller. The processor and your acquiring bank decide what validation you owe; a SOC 2 does not settle that question.
Scope your fintech SOC 2 around what buyers ask.
A readiness assessment turns this into your boundary, your categories and your gaps.