Priya Nandaraj had eleven weeks left on a $14.2 million, three-year platform agreement with Northlight Bank, the sponsor bank that would let her company, Verdant Pay, move real-time payments and ACH transfers on behalf of a dozen mid-market marketplace clients. Verdant Pay had done everything a diligent FinTech is supposed to do: a clean SOC 2 Type II report, a security team that could recite the Common Criteria in its sleep, encryption everywhere it needed to be. Then Northlight's internal audit team sent back a due-diligence questionnaire with a line item Priya hadn't budgeted for: "Please provide your service organization's SOC 1 Type II report addressing controls relevant to internal control over financial reporting (ICFR) for the settlement and reconciliation engine." Verdant Pay had never commissioned one. Nobody on the founding team had realized that a report about security and a report about the accuracy of financial processing were two different attestations, built on two different standards, answering two different questions — and that a bank whose own financial statements would reflect the money Verdant Pay moved needed the second one, not just the first.
The deal didn't die. It stalled for eleven weeks while Verdant Pay scoped, scrambled, and eventually engaged a second audit firm for a SOC 1 examination that ran in parallel with their existing SOC 2 renewal. I've now walked more than two dozen FinTechs through some version of this exact moment — the point where a company that thought it had "done compliance" discovers that financial services compliance isn't one thing, it's a stack. This article is about that stack: where SOC 2 sits in it, where it stops, and what a payments company, lender, neobank, or embedded-finance platform actually needs layered on top of it to satisfy the people who control its ability to move money.
Who This Is For, and What You'll Walk Away With
This is for compliance leads, founders, and engineering leaders at payment processors, neobanks, lending platforms, buy-now-pay-later providers, wealth-tech firms, and embedded-finance companies who are past the "what is SOC 2" stage and need to understand how it interacts with the rest of the financial-sector compliance landscape. You should already know the basics of the Trust Services Criteria going in. By the end, you'll understand exactly when SOC 2 alone is sufficient versus when you also need SOC 1, how PCI DSS fits alongside (not inside) SOC 2, why Processing Integrity and Confidentiality carry more operational weight for FinTech than for a typical SaaS vendor, and how to sequence a dual-track (or triple-track) audit program without burning your engineering team out or blowing your runway.
Why FinTech Compliance Is a Layered Problem, Not a Single Framework
Most SaaS companies can point to one attestation and be done with the conversation. FinTechs can't, because a FinTech usually sits at the intersection of three separate accountability relationships: it has customers who need assurance about data security (the classic SOC 2 use case), it has a banking or payments partner whose own regulators and auditors need assurance about the accuracy of financial processing (the SOC 1 use case), and — if it touches payment card data anywhere in its flow — it has a contractual obligation to the card networks that has nothing to do with either attestation (PCI DSS). Layer state money transmitter licensing, card network rules, and in some cases SEC or FINRA oversight on top, and "getting compliant" stops being a single project with a single deliverable.
FinTech Business Model | Typical Compliance Stack | Primary External Pressure |
|---|---|---|
Payment orchestration / payment facilitator | SOC 2 (Security, Processing Integrity, Confidentiality) + PCI DSS | Card networks, sponsor bank |
Neobank / banking-as-a-service platform | SOC 2 + SOC 1 + often ISO 27001 for international partners | Sponsor bank, state regulators |
Lending / BNPL platform | SOC 2 (Processing Integrity, Confidentiality) + state lending licenses | Funding partners, state regulators |
Wealth-tech / robo-advisor | SOC 2 + SOC 1 (custody-adjacent) | SEC, FINRA, custodial partners |
Embedded finance (non-financial company adding payments) | SOC 2 + PCI DSS via processor pass-through | Enterprise customers, processor partner |
Card issuing / prepaid programs | SOC 2 + SOC 1 + PCI DSS | Card network, issuing bank |
Crypto on/off-ramp | SOC 2 + state money transmitter licenses + sometimes PCI DSS | State regulators, banking partners |
That table is the single most useful thing I hand a new FinTech client in the first working session, because it reframes the question from "which framework do we need" to "which relationships are driving requirements, and what does each one actually check." SOC 2 for SaaS companies is a useful comparison point — a horizontal SaaS vendor selling to enterprise IT buyers usually stops at the top row of that logic. A FinTech almost never does.
The Regulatory Web Around Every FinTech
Here's a distinction I repeat constantly: none of the frameworks in this article are laws. SOC 2 is an attestation governed by AICPA standards. PCI DSS is a contractual mandate from the card networks. ISO 27001 is a certifiable management-system standard. What is legally binding is the patchwork of banking regulation, state money transmitter law, consumer financial protection rules, and securities law that sits above all three — and none of those regulators accept a SOC 2 report as a substitute for their own examinations. What they do accept it as is evidence — a third-party-validated data point that a bank's vendor management program, a card network's due diligence process, or an examiner's review can lean on instead of building everything from scratch.
Party Driving the Requirement | What They Actually Regulate/Enforce | How SOC 2 Fits Their Process |
|---|---|---|
Sponsor bank / issuing bank | Bank Secrecy Act, safety-and-soundness exams, vendor management | Input to third-party risk assessment; rarely sufficient alone |
Card networks (Visa, Mastercard, etc.) | PCI DSS compliance, card brand rules | Separate — SOC 2 does not satisfy PCI DSS obligations |
State banking / money transmitter regulators | State licensing law, examinations | Supporting evidence in license applications and exams |
CFPB / state consumer protection bodies | Fair lending, UDAAP, consumer disclosures | Not directly relevant; operational controls indirectly support |
SEC / FINRA (wealth-tech, broker-dealers) | Securities law, custody rules, Reg S-P | SOC 1 more relevant than SOC 2 for custody-adjacent controls |
Enterprise customers / partners | Contractual security requirements | Primary and direct use case for SOC 2 |
"The mistake I see constantly is a FinTech treating their SOC 2 report like a regulatory permission slip. It's not. It's one input into somebody else's risk decision. The banks I work with read the report, then they still run their own third-party risk questionnaire, because SOC 2 answers 'are your controls well designed and operating,' not 'are you the kind of counterparty we're allowed to bank.'" — Dana Kowalski, CISO, Northlight Bank
SOC 2 vs SOC 1: The Fork FinTechs Get Wrong
This is the fork that cost Priya eleven weeks, and it's worth being precise about because the two reports genuinely answer different questions for different audiences. SOC 2 reports on controls relevant to the Trust Services Criteria — security, and optionally availability, processing integrity, confidentiality, and privacy — for the benefit of customers and partners who care about how you protect their data and keep systems running. SOC 1, by contrast, reports on controls relevant to a user entity's internal control over financial reporting, or ICFR — for the benefit of that user entity's own external financial statement auditors. If your platform processes, calculates, or reports on transactions that flow into a customer's or partner's general ledger or financial statements, their auditors need assurance that your controls over that processing are sound, because they're effectively relying on your control environment as an extension of the customer's own.
For a FinTech, this isn't an academic distinction. If you're a payroll platform, a payment processor, a lending servicer, or anything that touches balances a bank or enterprise customer reports on its books, you are very likely a candidate for SOC 1 in addition to SOC 2 — not instead of it. The deeper comparison of the whole report family lives in SOC 2 vs SOC 1 vs SOC 3: Understanding the SOC Framework Family, but the FinTech-specific summary is below.
Dimension | SOC 2 | SOC 1 |
|---|---|---|
Governs | Trust Services Criteria (security-centric) | Internal control over financial reporting (ICFR) |
Standard | AICPA SSAE 18 (AT-C 105/205) | AICPA SSAE 18 (AT-C 105/320) |
Primary audience | Customers, prospects, partners assessing security posture | User entities' financial statement auditors |
Typical FinTech trigger | Any customer/partner data-security due diligence | Processing balances/transactions that hit a partner's GL |
Report focus | Security, availability, processing integrity, confidentiality, privacy | Controls over transaction processing, calculations, reporting accuracy |
Do FinTechs commonly need both? | Yes — very common for payment, lending, and issuing platforms | Yes — usually alongside, not in place of, SOC 2 |
"I ask every FinTech client the same qualifying question before we scope anything: 'Does a customer's or partner's financial statement auditor rely on your numbers?' If the answer is yes, we're having two separate scoping conversations, not one. Companies that only budget for a single audit almost always budgeted for the wrong one, or only half of what they needed." — Marcus Webb, Partner, Ashcroft & Vance LLP
When You Need SOC 1, SOC 2, or Both
The decision isn't really a decision — it's a function of what your platform does and who relies on its output. I use a simple four-question filter with new clients: Do you touch card data (PCI DSS territory)? Do your numbers feed a partner's financial statements (SOC 1 territory)? Do your customers care about your general security posture (SOC 2 territory, almost always yes)? Do you need a freely distributable public-facing seal (SOC 3 territory, occasionally)? The matrix below is the version I've refined over dozens of FinTech engagements.
FinTech Function | SOC 2 Needed? | SOC 1 Needed? | PCI DSS Needed? |
|---|---|---|---|
Payment processing / settlement | Yes | Yes, if output feeds partner GL | Yes, if card data touched |
Card issuing / program management | Yes | Yes | Yes |
Lending origination & servicing | Yes | Often, if servicing balances reported by funder | No (unless cards involved) |
Neobank core/ledger platform | Yes | Yes | Only if card products issued |
Wealth-tech / robo-advisor (non-custodial) | Yes | Sometimes, if calculations feed custodian reporting | No |
KYC/identity verification vendor | Yes | Rarely | No |
Embedded finance middleware | Yes | Depends on whether it touches settlement | Usually via processor pass-through |
Fraud/risk scoring vendor | Yes | Rarely | No |
Case Study 1: Verdant Pay's Dual-Track Recovery
After the Northlight stall, Verdant Pay didn't just bolt on a SOC 1 as an afterthought — they restructured how the two examinations were scoped so the evidence collection overlapped wherever the underlying controls did. Access management, change management, and logging controls were tested once and mapped into both reports; only the financial-processing-specific controls (reconciliation accuracy, settlement calculation logic, exception handling) needed a distinct SOC 1 test plan. The dual-track program took 14 weeks to stand up rather than the 22 weeks a fully separate, sequential approach would have needed, and Verdant Pay closed the Northlight agreement plus two additional sponsor-bank relationships within the following two quarters — a combined $31M in new annualized contract value that directly cited the completed SOC 1/SOC 2 pair in the sales cycle. The lesson Priya now repeats to every FinTech founder she mentors: scope both audits together from day one, even if you stagger the fieldwork.
The Trust Services Criteria, Weighted Differently for FinTech
Every SOC 2 report is built on the Common Criteria — the mandatory Security category — plus whichever optional categories from the Trust Services Criteria match the commitments you've made. For a generic SaaS company, Security plus maybe Availability covers most customer concerns. For a FinTech, the optional categories stop being optional in any practical sense. If you're calculating balances, moving money, or reconciling transactions, Processing Integrity is close to mandatory. If you're holding financial account data, transaction histories, or KYC documentation beyond ordinary PII, Confidentiality carries real weight too. SOC 2 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy covers the full category breakdown; the table below is how I rank relevance specifically for financial technology platforms.
Trust Services Category | Relevance for Typical SaaS | Relevance for FinTech | Why |
|---|---|---|---|
Security (Common Criteria) | Required, foundational | Required, foundational | Baseline for every SOC 2 report regardless of scope |
Availability | Often included | Highly relevant for payment rails | Downtime during settlement windows has direct financial impact |
Processing Integrity | Rarely included | Frequently mandatory | Errors in transaction processing = real financial loss, disputes |
Confidentiality | Sometimes included | Frequently mandatory | Financial account data, KYC docs, transaction histories at stake |
Privacy | Included if PII-heavy | Included where personal financial data collected | Overlaps with Confidentiality but adds notice/consent lens |
Why Processing Integrity Is Not Optional for FinTech
Processing Integrity is the category most SaaS companies skip and most FinTechs cannot. It addresses whether system processing is complete, valid, accurate, timely, and authorized — which, translated into payments language, means: did every transaction that should have been processed get processed, did the amounts calculate correctly, did duplicate submissions get caught, and can you prove authorization happened before funds moved. A security breach at a FinTech is bad. A processing integrity failure — a double-charge, a miscalculated interest accrual, a settlement batch that silently drops line items — is bad in a way that shows up directly on someone's bank statement and generates regulatory complaints, not just support tickets. SOC 2 Processing Integrity: Data Accuracy and Completeness Controls is the deep-dive companion to this section; here's how the criteria translate into payment-specific controls.
Processing Integrity Focus | Generic SaaS Example | FinTech-Specific Control |
|---|---|---|
Completeness | All records saved, none dropped | Every transaction in a batch reconciles to source system counts |
Accuracy | Data matches source | Interest, fee, and FX calculations independently verified |
Validity | Data reflects real events | Duplicate transaction detection, idempotency keys on payment APIs |
Timeliness | Processing within SLA | Settlement windows met; late-batch alerting and escalation |
Authorization | Changes approved before execution | Multi-party approval on high-value transfers; velocity limits |
"Processing Integrity is where I've seen the most FinTechs get blindsided during their first Type II. It's not that the controls don't exist — it's that nobody documented them as controls with owners, evidence, and testable frequency. Engineers built idempotency and reconciliation because it's good engineering, not because anyone was thinking 'this satisfies PI1.4.' Turning good engineering into auditable control statements is half the work." — Aisha Bello, Director of Payments Security, Cardwell Systems
Why Confidentiality Carries Extra Weight
Confidentiality governs information designated as confidential by agreement — trade secrets, business plans, and in the FinTech world, a specific category that deserves its own conversation: financial account data. This is distinct from ordinary PII and distinct from PCI-scoped cardholder data. Account numbers, routing numbers, transaction histories, KYC documentation, and underwriting data all carry confidentiality commitments that are usually contractual (in your customer and partner agreements) rather than purely regulatory, which is exactly the gap SOC 2's Confidentiality category is designed to cover. SOC 2 Confidentiality Criteria: Information Protection Beyond Security walks through the full criteria; the table below is the categorization exercise I run with every FinTech client because teams conflate these three data types constantly, and that conflation causes scoping errors.
Data Category | Governing Framework | Example Data | Common Confusion |
|---|---|---|---|
PII | Privacy laws, SOC 2 Privacy category | Name, email, SSN, address | Treated as "the same as" financial data |
Cardholder data | PCI DSS | PAN, CVV, expiration date, cardholder name on card | Assumed covered by SOC 2 automatically — it isn't |
Financial account data | SOC 2 Confidentiality, contractual commitments | Account/routing numbers, balances, transaction history | Under-classified; treated as generic "customer data" |
KYC/underwriting data | SOC 2 Confidentiality + state/federal privacy rules | ID documents, income verification, credit data | Retention periods often undocumented |
Getting this categorization right early changes your entire evidence-collection approach, because data classification drives access control design, encryption scope, and retention policy — and auditors will test whether your classification scheme actually maps to how data is handled in practice, not just what the policy document says.
PCI DSS: The Parallel Mandate, Not a Law, Not Part of SOC 2
This is the accuracy point I correct most often in FinTech conversations: PCI DSS is not a law, and it is not folded into your SOC 2 report just because your SOC 2 auditor is competent. PCI DSS — the Payment Card Industry Data Security Standard — is a contractual obligation imposed by the payment card brands (Visa, Mastercard, American Express, Discover, JCB) on any entity that stores, processes, or transmits cardholder data. You don't get PCI DSS "compliant" through a SOC 2 audit; you validate it through a separate process — a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC) performed by a Qualified Security Assessor, depending on your transaction volume and risk tier.
Dimension | SOC 2 | PCI DSS |
|---|---|---|
Governing body | AICPA (accounting profession standard) | PCI Security Standards Council (card industry consortium) |
Legal status | Not a law; attestation | Not a law; contractual card brand requirement |
Scope | Whole system relevant to Trust Services Criteria | Specifically the cardholder data environment (CDE) |
Assessor | Licensed CPA firm | Qualified Security Assessor (QSA) or self-assessment |
Output | Attestation report (restricted use) | ROC or SAQ + Attestation of Compliance (AOC) |
Applies to FinTechs that... | Handle any customer/partner data at all | Store, process, or transmit cardholder data specifically |
PCI DSS Level (Merchants/Service Providers) | Trigger | Validation Method |
|---|---|---|
Level 1 | Over 6 million card transactions annually (or any breach history) | Annual QSA-led ROC |
Level 2 | 1–6 million transactions annually | Annual SAQ, sometimes ROC |
Level 3 | 20,000–1 million e-commerce transactions annually | Annual SAQ |
Level 4 | Under 20,000 e-commerce transactions, or under 1 million other | Annual SAQ per acquirer requirements |
Service Provider Level 1 | Processes over 300,000 transactions annually for others | Annual QSA-led ROC |
The most common FinTech mistake here is assuming that reducing PCI scope (tokenizing card data immediately, using a hosted payment page, never touching raw PAN) eliminates the need to think about PCI DSS at all. It reduces your assessment burden — often dramatically — but the card networks still expect an Attestation of Compliance on file, and your acquiring bank or payment processor partner will ask for it directly, on a cadence separate from your SOC 2 renewal.
Mapping PCI DSS Controls Onto Your SOC 2 Evidence Base
The good news, and the reason I encourage clients to run PCI DSS and SOC 2 programs on a shared calendar rather than as two disconnected projects: a meaningful chunk of underlying control evidence overlaps. Access control, encryption in transit and encryption at rest, vulnerability scanning, logging, and change management show up in both frameworks, just tested against different scoping boundaries and different named requirements.
PCI DSS Requirement (v4.0 numbering) | Overlapping SOC 2 TSC Area | Notes |
|---|---|---|
Req 1: Network security controls | CC6 (Logical & physical access) | PCI scopes to the CDE; SOC 2 scopes to the whole system |
Req 3: Protect stored account data | CC6, Confidentiality | Tokenization/truncation reduces both PCI scope and SOC 2 evidence burden |
Req 4: Encrypt transmission | CC6, Encryption Controls | Same TLS configuration evidence often reused |
Req 6: Secure systems and software | CC8 (Change management) | Secure SDLC evidence overlaps almost entirely |
Req 8: Identify users, authenticate access | CC6 | MFA, unique IDs — near-identical control language |
Req 10: Log and monitor | CC7 (System operations) | Log retention periods often need PCI-specific alignment (12 months) |
Req 11: Test security regularly | Quarterly ASV scans are a PCI-specific addition | |
Req 12: Support information security with policies | CC1 (Control environment) | Policy suite overlaps heavily |
Building a single control matrix that tags each control with "SOC 2," "PCI DSS," or "both" is the single highest-leverage document a FinTech compliance team can build, because it turns two audits into one evidence-collection cycle with two report outputs.
"We stopped treating PCI and SOC 2 as separate projects about eighteen months ago and started treating them as one control environment with two examiners. Our internal audit workload didn't double when we added PCI scope — it went up maybe thirty percent, because most of the technical controls were already being tested for SOC 2." — Aisha Bello, Director of Payments Security, Cardwell Systems
Sponsor Banks, Banking-as-a-Service, and Third-Party Oversight
If your FinTech operates under a sponsor bank relationship — common in banking-as-a-service arrangements, card issuing programs, and many neobanks — you inherit a layer of oversight that goes well beyond what a typical enterprise SaaS customer would ask for. Banking regulators hold the sponsor bank accountable for its fintech partners' conduct, which means the bank's own examiners (and its own regulators) drive due-diligence requirements down onto you, often in more prescriptive detail than any commercial customer would.
Sponsor Bank Due-Diligence Ask | Does SOC 2 Cover It? | What Else Is Usually Needed |
|---|---|---|
Information security controls | Yes, directly | — |
Financial reporting control accuracy | Only if SOC 1 also obtained | SOC 1 Type II |
BSA/AML program adequacy | No | Separate BSA/AML audit, independent testing |
Consumer complaint handling | No | Compliance management system review |
Business continuity/disaster recovery | Partially (Availability category) | Often a dedicated BCP/DR test report |
Financial condition/solvency | No | Audited financial statements |
Third-party (your own vendor) risk management | Partially (subservice organization coverage) | Your own vendor risk management program documentation |
Case Study 2: Ledgerline's Processing Integrity Gap
Ledgerline, a mid-market lending servicing platform, went into its first SOC 2 Type II assuming Processing Integrity would be a light lift because their loan calculation engine had been stable and unchanged for two years. The auditor's sample testing found that a fee-waiver exception process — a manual override engineers had built for customer service reps to zero out a late fee — had no consistent approval trail; roughly 4% of sampled exceptions lacked documented authorization before the override was applied. It wasn't fraud and it wasn't material to any single customer, but it was a deviation the auditor had to report, and it triggered a follow-up question from Ledgerline's primary funding partner about controls over loan balance accuracy generally. Ledgerline spent six weeks building a lightweight approval workflow with mandatory ticket linkage before any override could post, re-tested the control for the remaining observation period, and closed the finding in their bridge letter rather than carrying it into the next full report. Their funding partner's risk team specifically cited the remediation speed — not the absence of any findings at all — as the reason they expanded the servicing relationship the following quarter.
ISO 27001 and Global Financial Services Expectations
FinTechs operating outside the U.S., or serving international banking partners, run into a different expectation: ISO 27001 certification, which some overseas banks and regulators treat as the default proof of an information security management system, the way U.S. banks treat SOC 2. The two aren't competitors — they answer overlapping but structurally different questions, and a growing number of FinTechs I work with end up holding both. ISO 27001 vs SOC 2: which one do you need breaks down the fundamental distinction (certification against a management-system standard versus attestation against the Trust Services Criteria); Running ISO 27001 and SOC 2 Together covers the operational path for maintaining both without duplicating your entire control environment twice a year. For FinTechs specifically weighing PCI DSS alongside ISO 27001 and SOC 2 in a single roadmap, ISO 27001 vs NIST/SOC 2/PCI DSS compared is the most relevant single reference, since it's the only piece in the pillar that puts all three side by side.
Scenario | Recommended Framework Layer |
|---|---|
U.S.-only FinTech, no international banking partners | SOC 2 (+ SOC 1 if ICFR-relevant, + PCI if card data) |
FinTech expanding into EU/UK banking partnerships | Add ISO 27001 alongside SOC 2 |
FinTech serving global enterprise customers (non-financial) | ISO 27001 often expected as default; SOC 2 as supplement |
FinTech issuing cards internationally | SOC 2 + PCI DSS + ISO 27001 commonly all three |
flowchart TD
A[FinTech Platform] --> B{Touches card data?}
B -- Yes --> C[PCI DSS: SAQ or ROC]
B -- No --> D[Skip PCI DSS]
A --> E{Output feeds a partner's<br/>financial statements?}
E -- Yes --> F[SOC 1 Type II]
E -- No --> G[SOC 2 only likely sufficient]
A --> H[SOC 2 Type II: Security required,<br/>+ Processing Integrity, + Confidentiality]
A --> I{International banking<br/>partners or expansion?}
I -- Yes --> J[Layer ISO 27001]
I -- No --> K[SOC 2 / SOC 1 / PCI DSS sufficient]
C --> L[Sponsor Bank / Regulator<br/>Due-Diligence Review]
F --> L
H --> L
J --> LBuilding the Control Environment: Common Criteria Mapped to FinTech Risk
The Common Criteria are universal, but the risks they're mitigating look different when the asset at stake is a customer's money rather than a customer's marketing data. SOC 2 Common Criteria: Universal Requirements for All SOC 2 Reports covers the CC1–CC9 structure in full; here's how I translate each category into FinTech-specific risk framing when I'm running a readiness workshop.
Common Criteria Category | Generic Framing | FinTech Risk Framing |
|---|---|---|
CC1 – Control environment | Tone at the top, ethics | Fraud risk culture; segregation of duties around money movement |
CC2 – Communication and information | Internal/external comms | Incident and fraud reporting channels to partners and regulators |
CC3 – Risk assessment | General risk identification | Fraud risk assessment specific to payment flows |
CC4 – Monitoring activities | Ongoing control monitoring | Transaction monitoring, anomaly detection on money movement |
CC5 – Control activities | Day-to-day controls | Dual controls on high-value transfers, limit enforcement |
CC6 – Logical and physical access | Access management | Segregation of duties between initiation and approval of transfers |
CC7 – System operations | Ops and incident handling | Settlement failure response, chargeback/dispute handling |
CC8 – Change management | Change control | Payment logic and interest-calculation code changes under tighter review |
CC9 – Risk mitigation | Vendor/business risk | Subservice organization oversight for processors, KYC vendors |
Subservice Organizations: Your Vendors Are Your Exposure
Almost no FinTech runs its full stack in-house. Payment rails, KYC/AML verification, card issuing processors, cloud infrastructure, and core banking platforms are typically subservice organizations whose own control failures become your control failures in the eyes of a customer or partner. Your auditor will ask whether each is handled via the carve-out method (excluded from your report scope, with reliance placed on the vendor's own SOC report) or the inclusive method (their controls tested as part of your examination).
Subservice Organization Type | Typical Treatment | What to Verify |
|---|---|---|
Payment processor / card network gateway | Carve-out | Their own PCI DSS AOC and SOC 2 report current |
Cloud infrastructure (IaaS) | Carve-out | Provider's SOC 2/ISO 27001 covers physical/infra layer |
KYC/identity verification vendor | Carve-out | Data handling, retention, and accuracy of verification |
Core banking / ledger platform | Carve-out or inclusive depending on integration depth | Reconciliation between your records and theirs |
Fraud scoring / risk engine | Carve-out | Model governance, false-positive/negative rates |
Sponsor bank itself | Not a subservice org — the relationship runs the other direction | N/A — you are the sponsor bank's subservice org |
Whichever method you use, your own report still needs to describe the complementary user entity controls your customers must operate, and — critically for FinTech — you need to document what you expect the subservice organization to be doing on its end, because your auditor cannot test controls owned entirely by a third party you don't control.
"The question I ask every FinTech client about their vendor stack is simple: if your KYC provider's identity verification silently degraded tomorrow, would you find out from them, from a customer complaint, or from a regulator? Most companies don't like their honest answer to that question, and that's exactly why subservice organization oversight belongs in the control environment, not in a separate 'vendor management spreadsheet' nobody reviews." — Tomás Rivera, Head of Risk, Ledgerline
Common FinTech SOC 2 Audit Pitfalls
Across two dozen-plus FinTech engagements, the same handful of findings recur often enough that I now address them proactively in every kickoff, rather than waiting for the auditor to surface them.
Pitfall | Why It Happens | Fix |
|---|---|---|
Processing Integrity treated as an afterthought | Teams assume "it works" is the same as "it's controlled and evidenced" | Document reconciliation, exception handling, and authorization as named controls |
SOC 1 need discovered mid-deal, not during scoping | Nobody asked whether partners rely on the company's numbers for their own financials | Ask the ICFR-reliance question before scoping the first audit |
PCI scope underestimated | Assuming a payment processor "handles all of that" | Confirm exact card data touchpoints; get a scope diagram signed off by the processor |
Confidentiality vs. Privacy conflated | Teams treat all customer data the same | Run a formal data classification exercise distinguishing account data, PII, and cardholder data |
Subservice organization evidence stale | Annual vendor reports not tracked against your own audit calendar | Maintain a vendor SOC/PCI report tracker with expiration alerts |
Fraud risk assessment missing from CC3 evidence | Risk assessment documentation focuses only on cyber threats | Add a dedicated fraud risk assessment covering payment-specific scenarios |
Bridge letter gaps during sponsor bank renewal cycles | Audit period doesn't align with partner's annual review date | Negotiate audit period timing to overlap key partner renewal dates |
Case Study 3: Brightpay's Triangle
Brightpay, a buy-now-pay-later provider integrated into e-commerce checkouts, had to satisfy three simultaneous relationships at once: a sponsor bank underwriting the credit product, the card networks because Brightpay also issued virtual cards for in-store use, and enterprise merchant customers who wanted their own SOC 2 assurance. Brightpay's compliance lead built one master control matrix tagging every control against SOC 2 TSC categories, PCI DSS requirements, and sponsor bank due-diligence questions simultaneously, then ran a single annual evidence-collection cycle feeding three separate deliverables: a SOC 2 Type II report, a PCI DSS SAQ D (self-assessment, given transaction volume), and a sponsor-bank-specific control summary. What had taken two disconnected teams roughly nine months in the prior cycle dropped to five months, and Brightpay's merchant sales team began citing the completed SOC 2 report directly in enterprise proposals, closing three checkout integrations worth a combined $6.4M in projected annual processing volume within the following two quarters.
Cost and Timeline for a Dual-Track Program
FinTech compliance programs cost more than a standalone SaaS SOC 2 largely because of scope breadth (more TSC categories) and the coordination overhead of running parallel examinations. These ranges are illustrative, drawn from patterns across the engagements I've run — actual figures vary by transaction volume, headcount, and how much control infrastructure already exists.
Program Component | Illustrative Cost Range | Illustrative Timeline |
|---|---|---|
SOC 2 Type II (Security + Processing Integrity + Confidentiality) readiness | $40,000–$90,000 (consulting + tooling) | 3–5 months to audit-ready |
SOC 2 Type II audit fees | $30,000–$70,000 | 3–12 month observation period + 6–8 weeks fieldwork |
SOC 1 Type II (added scope, shared evidence base) | $20,000–$50,000 incremental | 2–4 months incremental, run in parallel |
PCI DSS SAQ (self-assessment, reduced scope via tokenization) | $10,000–$30,000 | 6–10 weeks |
PCI DSS ROC (Level 1, QSA-led) | $50,000–$150,000 | 3–6 months |
ISO 27001 certification (if layered on) | $60,000–$150,000 | 9–14 months to certification |
Ongoing continuous compliance tooling/GRC platform | $15,000–$60,000/year | Ongoing |
Building Your Roadmap: 90/180/365
FinTech founders consistently ask me for a sequencing plan rather than a feature list, because the coordination problem is the actual difficulty, not any single framework's requirements.
Timeframe | Priority Actions |
|---|---|
Days 0–90 | Confirm which reports are actually needed (ask the ICFR-reliance and card-data-touch questions); build the master control matrix tagged by framework; select auditor(s) |
Days 91–180 | Remediate gaps found in readiness assessment; formalize Processing Integrity and Confidentiality controls as documented, evidenced controls; finalize subservice organization tracking |
Days 181–365 | Run observation period(s) in parallel where scope overlaps; conduct internal control testing/self-assessment mid-period; prepare system description and management assertion drafts |
Beyond Year 1 | Shift to continuous monitoring; align audit period renewal dates with key partner/sponsor bank review cycles; expand scope as new products (card issuing, lending) launch |
Choosing an Auditor Who Understands FinTech
Not every CPA firm that performs SOC 2 examinations has genuine payments and financial-services depth, and the gap shows up as friction during fieldwork — auditors who don't understand settlement mechanics ask imprecise questions, misjudge sample sizes for transaction testing, or fail to recognize when a control gap is actually a compensating control operating correctly.
Evaluation Criterion | Why It Matters for FinTech |
|---|---|
Prior FinTech/payments engagement experience | Auditors who understand settlement, reconciliation, and card flows scope more accurately |
Ability to coordinate SOC 1 + SOC 2 in one engagement | Reduces duplicate evidence requests and fieldwork disruption |
PCI QSA capability in-house or via partner firm | Enables coordinated PCI + SOC 2 evidence planning |
Understanding of BaaS/sponsor bank dynamics | Anticipates what your banking partner's examiners will actually ask |
Realistic sample sizing for high-volume transaction testing | Avoids either under-testing (weak assurance) or over-testing (wasted cost) |
Reputation with your specific sponsor bank or card network | Some banks maintain informal preferred-auditor familiarity |
"When I'm evaluating a FinTech's SOC 2 report as a bank's third-party risk reviewer, the first thing I look at is whether the auditor clearly understood the payment flow being described in the system description. If the system description reads like a generic SaaS narrative with 'payments' inserted, I know we're going to have follow-up questions." — Dana Kowalski, CISO, Northlight Bank
"Every FinTech founder wants to know the one framework that unlocks every partnership. There isn't one. There's a stack, and the stack is different depending on whether you touch cards, whether your numbers land on someone else's balance sheet, and who your sponsor bank's regulator happens to be that year." — Sam Okafor, Founder & CEO, Brightpay
Compliance as Competitive Infrastructure, Not a Checkbox
The FinTechs that treat this stack as a burden to minimize consistently move slower than the ones that treat it as infrastructure to build once and reuse. Verdant Pay's eleven-week stall became a 14-week dual-track build that then became the foundation for closing two more sponsor bank relationships without repeating the scramble. Brightpay's unified control matrix cut a nine-month annual compliance cycle to five. In a market where banking partners, card networks, and enterprise merchants are all running their own due-diligence processes on tighter timelines than they used to, the FinTech that already has SOC 2, SOC 1 where relevant, and PCI DSS evidence organized into one coherent story isn't just checking a box faster — it's removing itself as the bottleneck in its own growth. That's the pitch I make to every FinTech board that still sees this as a cost center: the companies winning sponsor bank RFPs this year aren't the ones with the cleanest individual reports, they're the ones who can produce the whole stack, coherently, on demand.
If you're mapping out which combination of SOC 2, SOC 1, and PCI DSS your FinTech actually needs, PentesterWorld's SOC 2 Readiness Checklist is a practical starting point for scoping the security side, and the SOC 2 Trust Services Criteria Mapping Template helps translate Processing Integrity and Confidentiality criteria into control statements your engineering team can actually own. For teams weighing ISO 27001 alongside SOC 2 for international banking relationships, the SOC 2 vs ISO 27001 Comparison Guide lays out the sequencing tradeoffs, and if you're still at the "what exactly do we need" stage, the "Are You SOC 2 Ready?" quiz is a fast way to get a directional answer before you engage an auditor.