Menu
On this page
- What do bank partners and enterprise buyers ask a fintech for?
- Which Trust Services categories does a fintech add to Security?
- How does an auditor test a ledger reconciliation under Processing Integrity?
- Which other fintech controls and vendors does the audit cover?
- Where do PCI DSS and the GLBA Safeguards Rule overlap with SOC 2?
- Does a fintech need SOC 1 as well as SOC 2?
- What does a SOC 2 audit cost a fintech company?
Bank partners and enterprise buyers often ask a fintech for a SOC 2 Type 2 report. Security is in nearly every report, Processing Integrity is added when the product moves, calculates or records money, and Availability when you promise payment or account uptime. The federal bank regulators' 2023 guidance tells banks they may review SOC reports as part of vendor due diligence, but it names no report type or category, so ask the bank which it will accept. A service that feeds your customers' financial statements may be asked for a SOC 1 as well.
What do bank partners and enterprise buyers ask a fintech for?
They ask for whatever their own vendor-risk process and contract call for, and that is often a SOC 2 Type 2. The Federal Reserve, FDIC and OCC finalized their Interagency Guidance on Third-Party Relationships: Risk Management on June 6, 2023. In due diligence, it says a bank “may consider reviewing System and Organization Control (SOC) reports” and whether their scope and results are relevant to the activity. In contracts, it suggests the bank specify which audit reports it is entitled to receive, and it names SOC reports and PCI compliance reports as examples. The guidance sets no required report, so the requirement reaches you through a questionnaire or a contract clause from the specific bank.
The agencies also published a due diligence guide for community banks working with fintech companies in 2021. It is voluntary, and it is a useful preview of what a small bank will ask you.
Before you scope, get four answers in writing from the bank or buyer: Type 1 or Type 2, which Trust Services categories, how long a period the Type 2 must cover, and whether they want your subservice organizations’ reports too. If you are weighing a Type 1 first, SOC 2 Type 1 vs Type 2 covers when a Type 1 is accepted.
Which Trust Services categories does a fintech add to Security?
A fintech adds Processing Integrity when its product moves, calculates or records money, Availability when it promises uptime for payments or account access, and Confidentiality or Privacy only when contracts or consumer data call for them.
| Category | Add it when | What the auditor tests against your commitment |
|---|---|---|
| Processing Integrity | The platform posts payments, calculates interest or fees, or keeps a ledger others rely on | Transactions are complete, valid, accurate, timely and authorized, and breaks against your bank are found and cleared |
| Availability | A contract or SLA promises payment or account-access uptime | Capacity monitoring, tested recovery, and the recovery objective you state |
| Confidentiality | You hold customers’ non-public business data under NDA, such as deal documents or credit files | Access, retention and disposal match what you agreed |
| Privacy | You collect personal data directly from consumers | Collection, use, retention and disposal match your privacy notice |
Each category you add brings its own criteria on top of the Common Criteria and widens testing, which is one reason scope moves a quote. The Trust Services Criteria guide lists every criterion.
How does an auditor test a ledger reconciliation under Processing Integrity?
The auditor picks days from the audit period, asks for the reconciliation, the breaks and the sign-off for each, and checks that the control ran as your policy says. The example below is illustrative; the thresholds and timing come from your own policy.
A common control for a payments or lending platform: each business day an automated job matches every ledger entry from the previous day to the settlement file from the sponsor bank or processor. Differences above a set threshold open tickets. A second person, who cannot post to the ledger, reviews the break report and signs it off within the time your policy sets. Breaks that stay open past the escalation window go to the controller.
The AICPA’s Processing Integrity criteria (TSP 100, 2017 criteria with revised points of focus 2022) are five. This one control touches each:
| Criterion | What the reconciliation shows |
|---|---|
| PI1.1 | You have defined what a matched transaction is and what the product promises, such as settlement timing |
| PI1.2 | The settlement file and ledger extract arrive complete: file receipt records, record counts and control totals, rejection of malformed files |
| PI1.3 | Processing errors are detected and corrected: the break queue, its tickets and its resolutions |
| PI1.4 | Output reaches the right recipients complete and accurate: reconciliation reports to finance, payout files, customer statements |
| PI1.5 | Inputs, in-process items and outputs are stored completely and accurately to your specifications: retained source files and results that cannot be edited |
For a Type 2, the auditor asks for these items:
- The system’s own list of every reconciliation run in the period, so the sample comes from a complete population. The auditor also tests that the report producing the list is complete and accurate.
- For each sampled day, the file receipt record with its control totals, the reconciliation output, and the break list.
- For each break in the sample, the ticket with its age, owner and resolution.
- The reviewer’s sign-off with a timestamp, and access records showing the reviewer cannot post ledger entries.
- The job schedule and failure log, including days the job did not run and what was done instead.
An exception the auditor would record here is a sign-off missing or past the policy window on a sampled day, a break open past escalation with no ticket note, or a failed job rerun by hand with no record. Exceptions go in the tests-of-controls section of the report; whether one changes the opinion depends on whether the criterion was still met overall. What a SOC 2 report contains shows where this section sits.
Which other fintech controls and vendors does the audit cover?
Three parts of the Common Criteria map closely to how a fintech’s money moves: who can touch ledger and payout systems, how code that moves money changes, and which vendors sit in the payment path.
Access (CC6.1 to CC6.3) is tested through the review of who can post ledger adjustments or approve payouts, and through separation between the person who requests a manual adjustment and the person who approves it. Change management (CC8.1) is tested through pull-request approvals, test results and deployment logs for the code that calculates fees, interest and balances, plus the record of any emergency change.
Vendor risk (CC9.2) matters more for a fintech than for most SaaS companies because the sponsor bank, card processor, KYC provider and cloud host all handle your customers’ money or data. Your report either carves those subservice organizations out, describing their controls without testing them, or includes them. A carve-out means you need each vendor’s own SOC report on hand and a list of what you rely on them for. Carve-out vs inclusive method explains the choice, and SOC 2 vendor management requirements covers the program behind CC9.2. A sponsor bank or processor that will not share a SOC report is better discovered at scoping than at fieldwork.
Tools that collect this evidence automatically are compared in SOC 2 compliance software for fintech.
Where do PCI DSS and the GLBA Safeguards Rule overlap with SOC 2?
Both overlap SOC 2 on access control, encryption, vulnerability management, vendor oversight and incident response evidence, and a SOC 2 report satisfies neither.
PCI DSS applies when you store, process or transmit cardholder data. The PCI Security Standards Council published v4.0.1 on June 11, 2024 as a limited revision with no new or deleted requirements, retired v4.0 on December 31, 2024, and kept March 31, 2025 as the date the requirements that were future-dated in v4.0 took effect. An assessment today is therefore against v4.0.1 with those requirements in force. The overlap is in network security controls (Requirement 1, CC6.6), access (Requirements 7 and 8, CC6.1 to CC6.3), vulnerability management and testing (Requirements 6 and 11, CC7.1) and logging (Requirement 10, CC7.2). The separate work is the cardholder data environment boundary, the validation document your acquirer or card brand accepts, and payment-page script controls, which v4.0.1 clarified in Requirement 6. SOC 2 vs PCI DSS for SaaS covers how to reuse evidence without assuming the two scopes match.
The FTC’s Safeguards Rule, issued under the Gramm-Leach-Bliley Act, applies to non-bank financial institutions under FTC jurisdiction; banks follow their own regulator’s standards. It requires a written information security program with a designated Qualified Individual, a written risk assessment, encryption in transit and at rest, multi-factor authentication, service-provider oversight, an incident response plan, and at least annual written reporting to the board. The FTC extended the compliance date for some of the 2021 amendments to June 9, 2023. A notification amendment took effect May 13, 2024: a covered institution must tell the FTC within 30 days of discovering an event involving unencrypted information of at least 500 consumers.
SOC 2 evidence helps with the risk assessment (CC3.2), access and encryption controls, vendor oversight (CC9.2) and incident response (CC7.3 to CC7.5). A SOC 2 report does not show that you named a Qualified Individual, reported to the board, ran the annual penetration test and six-month vulnerability scans the Rule requires when you lack continuous monitoring, or filed an FTC notice. Check with counsel whether the Rule or your bank’s regulator governs you.
Does a fintech need SOC 1 as well as SOC 2?
SOC 1 reports on controls relevant to your customers’ financial reporting, and SOC 2 reports on the Trust Services Criteria. A fintech whose output feeds customers’ financial statements, such as fees charged, payouts, balances or statements, may be asked for a SOC 1 by those customers’ auditors, while buyers asking about security want the SOC 2. Some fintechs are asked for both, and the reconciliation control above is the kind a SOC 1 would test too. SOC 1 vs SOC 2 sets out the test, and the SOC 1 report guide covers Type 1 or Type 2 and choosing a firm. 87 firms in our directory are on the SOC 1 auditors list.
What does a SOC 2 audit cost a fintech company?
The figures below are ballpark quotes firms sent fintech buyers through SOC2Auditors.org, before scoping.
In Q3 2026, firms quoted fintech companies a median $18,000 for a SOC 2 Type 2 audit through SOC2Auditors.org, in ballpark quotes before scoping.
Our quote data covers Type 2 audits only, so there is no observed Type 1 figure here. The audit cost guide compares Type 1 and Type 2.
Scope moves a quote. Adding Processing Integrity, auditing more than one legal entity, or running a SOC 1 alongside the SOC 2 each adds testing, so give every firm the same written scope before you compare numbers. Firms that work with fintech buyers are listed at SOC 2 auditors for fintech, and the quote process explains how the ballparks are collected.
More in Industry & Verticals