SOC 2 and what a bank partner actually reads

What the thing actually is

SOC 2 is an attestation engagement performed by an independent CPA firm against the AICPA's Trust Services Criteria. The criteria were published in 2017, with points of focus revised in 2022 to reflect how the threat landscape moved. There are five categories:

You choose which categories are in scope. That choice is the first thing a careful reader checks, because a report covering Security alone answers fewer questions than one covering Security, Availability and Confidentiality — and both are equally "SOC 2".

Type 1 and Type 2 are not grades

A Type 1 reports on the suitability of the design of controls at a point in time: are they in place, and would they meet the objectives if they worked. A Type 2 reports on operating effectiveness across a period — typically three to twelve months — by testing whether they actually did.

A bank partner generally wants a Type 2, because design without evidence of operation tells it little about the risk it is taking on. A Type 1 is a reasonable first report for a young company, and it is honest to present it as what it is: the starting point, with the observation window running.

Two practical consequences. The period has to be chosen before it starts, so the decision to pursue a Type 2 sits well ahead of the diligence it is meant to satisfy. And a report always ages — the gap between the end of the period and the day the bank reads it is covered by a bridge letter from management, which is management's representation rather than the auditor's opinion, and sophisticated readers treat it accordingly.

What a diligence team is looking for inside it

1. The scope. Which categories, which systems, which entity. A report scoped to a product you are not buying is not evidence about the one you are.
2. The period, and whether it covers the time the relationship will rely on.
3. The opinion. Whether it is unqualified, and if not, what was qualified.
4. The testing tables. This is where the substance is. Exceptions are recorded there with management's response, and a report with a clean opinion can still carry exceptions worth discussing.
5. The system description. Written by management, not the auditor. It defines what was examined, which means it also defines what was not.
6. Subservice treatment and the CUECs — below, and the part most often skipped.

This is also the checklist to apply to your own vendors' reports. See bank partnership due diligence for the wider file a sponsor bank will ask for; the SOC 2 is one exhibit in it, not a substitute for it.

Carve-outs and the controls the report hands back to you

Almost every fintech runs on infrastructure someone else operates. A SOC 2 handles those subservice organizations one of two ways. Under the carve-out method the report names the subservice organization but excludes its controls from the examination, disclosing instead the controls it is assumed to be operating, plus the service organization's own controls for monitoring them. Under the inclusive method the subservice organization's relevant controls are described and tested within the report.

Carve-out is far more common, and it means a report can be clean while a meaningful part of the stack was never in scope. The reader's job is to notice which method was used and what was carved out.

Then the part that matters to whoever reads the report: complementary user entity controls. CUECs are controls the user entity is expected to implement for the service organization's controls to provide reasonable assurance that its commitments are met. Both methods require them.

Read that from both directions, because it cuts both ways:

• Your report's CUECs are obligations you are placing on your customers. If a bank partner reads them and finds they assume it does things it does not do, the report's conclusions do not hold for that relationship.
• Your vendors' CUECs are obligations on you. Accepting a vendor's SOC 2 as comfort while ignoring the CUEC list is accepting a conclusion whose conditions you have not met.

What it is not

A SOC 2 is not PCI DSS — different scheme, different scope, different assessor, and a card-data environment needs its own treatment (PCI DSS for startups). It is not an anti-money-laundering program (BSA/AML), and it says nothing about licensing (money transmission). SOC 1 is a different report about controls relevant to financial reporting, and asking for the wrong one wastes a quarter.

And because it is an attestation rather than a certification, the accurate way to describe it is what it is: the categories in scope, Type 1 or Type 2, the period, and the auditor. Anyone describing a report as a certification is telling a reader who knows the difference something about how carefully the rest was read — see the compliance checklist for the rest of the posture.

This is general information, not legal, audit or security advice; scope and readiness decisions belong with your auditor and counsel.