SOC 2 for Fintech: What Banks Expect and How to Scope Your Report

Short answer: SOC 2 for fintech is a CPA's attestation report on the controls behind your platform, usually requested by partner banks, credit unions and enterprise customers during third-party due diligence. Most fintechs start with security, then add processing integrity, availability or confidentiality based on what they promise, and carve out sponsor banks and processors as subservice organizations.

Related guides:

• PCI DSS for fintech
• CRI Profile: a practical guide for vendors selling to US banks
• SOC 2 vs SOC 1

Key takeaways

• US bank regulators' 2023 third-party guidance names SOC reports as something a bank may consider in due diligence, which is why a fintech SOC 2 report shows up in bank questionnaires.
• Security is always in scope. Processing integrity is the category most fintechs debate, because it speaks to transaction accuracy.
• SOC 2 does not replace PCI DSS for card data, a SOC 1 for services that affect customers' financial statements, or the GLBA Safeguards Rule if you are a non-bank financial institution. It sits next to them.
• Sponsor banks, BaaS platforms and processors are usually carved out as subservice organizations, which you still monitor.
• Auditors tend to spend their time on change management for payment flows, reconciliation, segregation of duties, key management and vendor monitoring.

---

Why do banks ask fintech vendors for a SOC 2 report?

Because regulators hold banks accountable for risk their vendors and partners create, and a SOC 2 gives a bank independent evidence about your controls.

In June 2023 the Federal Reserve, FDIC and OCC issued the Interagency Guidance on Third-Party Relationships: Risk Management (the Fed circulated it as SR 23-4). It describes a relationship life cycle of planning, due diligence and third-party selection, contract negotiation, ongoing monitoring and termination, and states that its principles apply to all third-party relationships, "including those with fintech companies."

Three parts of the guidance explain the requests you receive:

1. Due diligence. Banks are told to assess a third party's information security program, and the guidance lists "System and Organization Control (SOC) reports" and independent conformity assessments or certifications as things a bank may consider when relevant and available.
2. Ongoing monitoring. Banks keep watching whether a third party can maintain the confidentiality, availability and integrity of the bank's systems and data. That is why banks ask for your new report every year.
3. Subcontractors. Banks look at how much you rely on subcontractors and how you oversee them, which your SOC 2 vendor management controls help answer.

The guidance applies to banks, not to you directly. But if your product depends on a bank partner, or your customers are banks, their obligations become your sales requirements. In our experience, credit unions ask for similar evidence.

Which Trust Services Criteria should a fintech add to security?

Add a category when it matches a commitment you make to customers, not because it sounds thorough. The AICPA defines SOC 2 as an examination of controls relevant to security, availability, processing integrity, confidentiality or privacy, using the 2017 Trust Services Criteria (with revised points of focus, 2022). Security is mandatory. The rest are optional.

Category	When a fintech usually adds it	What the bank or customer is really asking
Processing integrity	You move money, calculate balances, fees, interest or payouts, or generate statements	"Will the numbers your system produces be complete and accurate?"
Availability	You publish uptime commitments, or customers cannot transact when you are down	"What happens to our customers when your platform fails?"
Confidentiality	You hold customer financial data, contracts or bank partner data under NDA	"How do you protect and dispose of our confidential data?"
Privacy	You collect personal information directly from consumers	"How do you handle notice, consent, use and retention of personal data?"

A practical rule: if a bank partner's contract includes service levels, add availability. If your output feeds a ledger, a payout or a customer statement, consider processing integrity. It is harder to evidence, because you need input validation, processing checks and output review, so many teams add it in their second report.

How does SOC 2 fit with PCI DSS, SOC 1, GLBA and the CRI Profile?

Each answers a different question, so a fintech often needs more than one, and the overlap is in the controls, not the reports.

Framework	What triggers it	How it relates to SOC 2
PCI DSS	You store, process or transmit cardholder data, or could affect the security of the cardholder data environment	Mandatory through card brand and acquirer contracts. A SOC 2 does not satisfy it, but many security controls can be reused
SOC 1	Your service is likely relevant to customers' internal control over financial reporting, such as ledgers, payroll, billing or loan servicing	Written for customers' financial statement auditors. Some fintechs need both SOC 1 and SOC 2
GLBA Safeguards Rule	You are a financial institution under FTC jurisdiction (16 CFR Part 314)	A legal requirement, not a report. SOC 2 evidence can support it, but you still need the specific elements the Rule requires
CRI Profile	A bank sends you a questionnaire built on it	A financial sector framework built on the NIST Cybersecurity Framework. Your SOC 2 controls map into many of its statements

A few details worth knowing on GLBA. The FTC's business guidance on the Safeguards Rule lists covered businesses such as mortgage lenders, payday lenders, finance companies, account servicers, check cashers and wire transferors. The Rule requires elements including a qualified individual, a written risk assessment, encryption, multi-factor authentication, oversight of service providers and annual penetration testing. Since May 2024, a notification event affecting 500 or more consumers must be reported to the FTC no later than 30 days after discovery. A clean SOC 2 opinion does not prove you meet them.

How do you scope a fintech system around banks and processors?

Draw the boundary around what you operate, and treat the sponsor bank, BaaS platform, card processor and cloud provider as subservice organizations, usually under the carve-out method.

The PCAOB's interpretation of AS 2601 describes the two options. Under the carve-out method, the subservice organization's relevant controls are excluded from the description and from the scope of the service auditor's engagement. Under the inclusive method, they are included and tested. Inclusive reports need the other party's cooperation, which is hard to get from a bank or large processor.

A typical fintech boundary looks like this:

• In scope: your application and APIs, the ledger or transaction services you run, your admin tools, your cloud accounts, your CI/CD pipeline, your people and your policies.
• Carved out: the sponsor bank that holds funds, the BaaS platform that provides accounts or cards, the payment processor or network, KYC and identity verification vendors, and your cloud provider.
• Described, not tested: the controls you expect each carved-out party to run, such as the bank settling funds or the processor protecting card data.

Carving out is not ignoring. Your report should show how you monitor each carved-out party, such as reviewing its SOC report every year, tracking exceptions and mapping the user entity controls it assigns to you. A bank will check that its own role is described accurately, so share the draft description with it if you can.

Which controls do auditors look at hardest in a fintech?

Auditors focus on the controls where an error or a single person could move money or change balances without anyone noticing. In our experience, five areas attract the most testing and follow-up questions.

1. Change management on payment flows. Code that calculates amounts, routes payments or posts to the ledger should need peer review, passing tests and approval before release, with emergency fixes reviewed afterwards. Our guide to SOC 2 change management evidence covers what to keep.

2. Reconciliation. Regular reconciliation between your ledger, processor settlement files and bank statements, with named owners, evidence of each run and resolved breaks.

3. Segregation of duties. The engineer who deploys code should not also approve the change. The person who can adjust a customer balance should not also approve the adjustment. Where a small team cannot fully separate duties, document compensating controls such as logged admin actions reviewed by someone else.

4. Key and secrets management. Integration API keys, signing keys and encryption keys belong in a managed key store or secrets manager, with restricted access, rotation and logging.

5. Vendor monitoring. A register of carved-out and critical vendors, with annual reviews of their SOC reports, documented exceptions and a named owner. It mirrors what your bank partner does to you.

What is a sensible readiness sequence for a fintech SOC 2?

Start from the bank's requirements and your money flows, then build the controls and evidence before you book the audit window.

1. Map your money and data flows. Draw how funds, transactions and customer data move between you, the sponsor bank and processors. This becomes your system description's backbone.
2. Collect partner requirements. Check bank agreements and questionnaires for required reports, categories and notification terms.
3. Set the boundary and categories. Decide what is in scope, which parties are carved out, and which categories beyond security you need now versus later.
4. Run a gap assessment. Compare current controls against the criteria, giving extra attention to the five focus areas above.
5. Fix gaps and collect evidence. Write policies, add reconciliation sign-offs, tighten deploy approvals and move secrets into a vault.
6. Choose Type 1 or Type 2, then start the period. A Type 1 looks at design at a point in time. A Type 2 tests operation over a period, which is what banks generally ask for. See SOC 2 Type 1 vs Type 2 for the trade-offs.

How SecureSlate helps

SecureSlate helps fintech teams organize SOC 2 work for bank partners. SecureSlate does not issue SOC 2 reports; only an independent CPA firm can. Multi-framework control mapping lets you reuse one control set across SOC 2, PCI DSS and NIST CSF, and you can set up GLBA Safeguards Rule requirements or the CRI Profile as a custom framework. Agentless read-only cloud integrations and the device agent collect evidence, access reviews cover production and admin tools, and code security and secrets detection help find keys in repositories. Vendor risk management tracks your sponsor bank, BaaS platform and processors with their SOC reports and review dates, risk management records decisions on exceptions, and audit management keeps evidence ready for your CPA firm. When a bank sends a questionnaire, security questionnaire automation and the trust center help you answer and share documentation.

Start your free SecureSlate trial

FAQ

Is SOC 2 legally required for fintech companies?

No. SOC 2 is a voluntary attestation, not a law. It becomes a practical requirement when bank partners or enterprise customers make it a contract condition, often because of their own third-party risk obligations.

Do payments companies need both SOC 2 and PCI DSS?

Often, yes. PCI DSS applies if you store, process or transmit cardholder data or can affect its security, and it is enforced through card brand and acquirer contracts. SOC 2 for payments companies covers the wider platform and is what many banks and enterprise buyers ask for. Reuse controls across both, but expect two separate assessments.

When does a fintech need SOC 1 instead of SOC 2?

When your service is likely relevant to your customers' internal control over financial reporting, such as running their ledger, payroll, billing or loan servicing. Their financial statement auditors will want a SOC 1. Many fintechs in that position also keep a SOC 2 for security reviews.

Should our sponsor bank be included in our SOC 2?

Usually not. Sponsor banks and BaaS platforms are typically carved out as subservice organizations. Your report describes what they do and the controls you expect them to run, and shows how you monitor them.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.