SOC 2 Certification for AI Vendors in Banking

No SOC 2 report, no meeting. That's the wall vendors hit before they ever get near a demo call when they're selling AI tools into banks. A vendor-security guide from one compliance platform found that roughly 66% of B2B buyers now require a SOC 2 report before they'll even look at a vendor, and that number gets tighter once you narrow the lens to banking specifically.

Banks and fintech firms have required SOC 2 for years from anyone touching transaction data or account information. Community banks feel this pressure through vendor-management policies shaped directly by OCC Bulletin 2023-17, which pushed third-party risk oversight into sharper focus across the industry. So when an AI vendor shows up without a report in hand, that's not a paperwork gap. It's a reason to walk away, full stop.

But what does the SOC 2 badge actually tell a bank? It says an outside auditor looked at the vendor's security practices and operational habits and found them solid enough to write down. That's worth something real. It says nothing about whether the product itself works well, makes good decisions, or produces output a bank can trust. Those are separate questions, and a lot of vendor evaluations fall apart exactly where those two get confused.

SOC 2 audits: the five Trust Services Criteria and the two report types

SOC 2 comes from a national accounting standards body. It measures a vendor's data protection across five categories, the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Only Security is mandatory in every audit. The other four get picked by the vendor, based on whatever fits their business. So two companies can both wave around a "SOC 2 report" while being certified against entirely different sets of controls. A vendor could choose Security alone, skip the rest, and still call itself SOC 2 compliant. That gap is exactly where a lot of banks get fooled.

For a bank evaluating an AI vendor, Security and Availability are two criteria that deserve close attention. Security covers the basics: who can access what, how encryption works, how the vendor reacts when something breaks. Availability covers uptime, disaster recovery, and the vendor's SLAs actually holding up under pressure, which matters a lot once the AI tool sits inside a live customer workflow.

Confidentiality is the third one worth real scrutiny. It checks whether data marked sensitive actually stays that way, protected from anyone who shouldn't see it. For AI vendors, this is where a bank should look for a zero-training-data commitment: proof the vendor isn't quietly feeding a bank's customer data into models built for other clients. Any AI vendor touching financial data that left Confidentiality out of its audit scope owes the bank a direct answer as to why, and that conversation should happen before signing, not after.

Four things vendor-management teams should read inside the actual SOC 2 report

Sales decks lead with the badge. The substance sits buried in the report itself, and most of it never gets read because nobody on the vendor-management side knows where to look. Four things deserve real attention every time.

Start with the observation period, stated in the auditor's opinion on the first page: how long the vendor's controls were actually tested. A longer observation window generally reflects a more established program. A shorter window isn't automatically disqualifying, so long as the vendor is moving toward a full annual cycle. Check the gap between when that window closed and today, too. A report that ended eight months ago is telling a stale story.

Next, check which Trust Services Criteria actually made the cut. Confirm Confidentiality is in there as well as Security. If Confidentiality isn't in there, that's a question worth raising directly with the vendor before any contract gets signed.

Then look at exceptions, and how the vendor handled them. An exception in a SOC 2 report isn't automatically a red flag: audits exist to find gaps, not to produce spotless paperwork, and minor findings are not unusual. What matters is the response. Did the vendor trace the root cause, fix it, and show evidence the fix held? The real warning sign is a control failure that reappears in subsequent reports without evidence of resolution. That pattern says the vendor wrote the problem down and never actually solved it.

A bank that reads those four things learns more about a vendor's real discipline than any slide deck could ever offer.

Compliance gaps that AI systems introduce beyond SOC 2

SOC 2 rests on three assumptions, and AI agents break all three.

First, SOC 2 assumes controls can be written down and stay fixed until someone deliberately changes them. AI models don't behave that way. Outputs drift over time, and the same prompt can produce different answers on different days, with no "change" in the traditional change-management sense ever having occurred.

Second, SOC 2 assumes systems follow documented logic. AI systems show emergent behavior: outcomes nobody explicitly programmed, and nobody can fully predict through the change-review process SOC 2 audits are built around.

Third, SOC 2 assumes a human sits behind every access decision. Agentic AI systems make access decisions on their own, in real time, and static role-based access control has no way to inspect an agent's reasoning or enforce a policy that depends on context.

None of this makes SOC 2 a broken framework. It just means SOC 2 was never built to answer questions about model behavior, and any vendor who points to their SOC 2 report when asked about hallucination or bias has misunderstood the question. Training data poisoning, adversarial robustness, hallucination, emergent behavior: none of it sits inside the SOC 2 boundary.

Picture what that gap looks like inside actual bank operations. A model reviewing a wire transfer for money-laundering red flags invents a plausible-sounding reason to clear a transfer it should have escalated instead. That's a direct regulatory liability, sitting right there in the transaction log. SOC 2 has nothing to say about whether that model's reasoning held up, because checking reasoning was never part of the job.

Regulatory requirements beyond the SOC 2 badge in 2026

Regulators have started closing that gap themselves, piece by piece.

SR 26-2, issued jointly by the Federal Reserve, the OCC, and the FDIC in April 2026, replaces the long-standing SR 11-7 and reaffirms model risk management as its own discipline: model inventories, independent validation, ongoing monitoring, governance over third-party models. It scales by institution size and risk profile, with obligations increasing for larger and more complex institutions. That's a real expansion of what "model governance" means at scale.

The OCC's revised 2026 model risk guidance says outright that generative and agentic AI sit outside its scope, on the grounds that the technology moves too fast to pin down with fixed rules. So the most advanced AI systems banks are evaluating right now sit in a gray zone, untouched by SOC 2 and only half-covered by the guidance meant to govern models generally.

Treasury tried to fill that gap from the federal side. Its Financial Services AI Risk Management Framework, announced in February 2026, adapts the NIST AI Risk Management Framework specifically for banking. It carries a Risk and Control Matrix built around 230 control objectives, covering areas such as model development, validation, monitoring, third-party risk, and consumer protection. This is the document doing the work SOC 2 was never built to do.

Examiners are already asking sharper questions on the ground. The OCC's Spring 2025 Semiannual Risk Perspective flagged model risk tied to emerging technology, cybersecurity exposure, and compliance gaps by name. In practice, examiners want to know exactly which conversations an AI system handled, what it told a customer about a debt collection or a disclosure, and the bank must be able to defend that answer later if asked.

The layered certification stack that complements SOC 2 for AI banking vendors

SOC 2 is the floor, not the ceiling. Banks evaluating AI vendors should expect a stack of certifications on top of it, chosen based on what the vendor actually touches.

Any vendor involved in payment processing or handling card data will typically need PCI-DSS coverage. Any vendor processing data belonging to EU data subjects will generally face GDPR obligations. ISO 27001 rounds out the stack by approaching information security as a structured management system, complementing what SOC 2 covers through its audit process.

None of these certifications, alone or stacked together, answers a single question about how an AI model actually behaves. Together, though, they build a picture of a vendor that treats security and data handling as an organizational habit rather than a checkbox exercise.

Agentic AI and the governance stakes beyond static certification

This isn't a future-state conversation. Banking institutions are already using agentic AI in some form, through live deployments or active pilots, and adoption is spreading quickly across the industry.

What actually separates agentic AI from the automation banks have run for decades? Older automation followed fixed rules: if X, then Y, every time, no surprises. Agentic AI generates and executes code at runtime, shifts its behavior based on new data it encounters mid-task, makes access decisions on its own, and chains multiple actions together without a human signing off on each step. Stable controls, predictable logic, human-gated access: every one of SOC 2's underlying assumptions gets tested by that description, and every one comes up short.

Payments make this concrete fast. AI agents are already making authorization decisions in sub-second windows, shaping approval rates directly. At that speed, a human reviewing each decision before it fires isn't a preference issue, it's structurally impossible. So what's actually governing the decision? The architecture the vendor built around the agent becomes the control itself, whether anyone labeled it that way or not.

Zooming out further, the risk stops being about any single vendor. S&P Global has warned that automation stretching across institutions, linking trading, credit, and compliance systems through continuous data exchange, could amplify volatility if several agents respond to the same shock in correlated ways. No SOC 2 audit, run on one vendor in isolation, was ever built to catch that kind of system-wide behavior coming.

Questions bankers should ask AI vendors that SOC 2 alone cannot answer

A SOC 2 report answers infrastructure questions: who can reach the servers, how encryption works, what happens during an outage. It says nothing about how the model thinks or what happens the moment it's wrong. So what actually fills that gap?

On model behavior: ask how the vendor proves its model doesn't hallucinate in decisions that carry compliance weight, such as automated screening or approval workflows. Ask which architectural choices keep high-stakes decisions on deterministic, rule-based logic, and which get left to the model's own probabilistic judgment instead. Ask whether the vendor can produce independent validation of accuracy, something beyond its own internal testing dressed up as proof.

On audit trails, the questions get sharper still. Does the system log individual user attribution for every action an agent takes, or does everything run under one shared service account that blurs who actually did what? Can the vendor produce a full audit trail tied to one specific AI decision, on request, in a format examiners will accept without pushback? And does that log capture model version, confidence scores, the input data, and every human override along the way?

A vendor that answers these with specifics, not marketing language, is showing something no badge ever could: proof that someone inside the company actually sat down and mapped out what happens when the model gets it wrong. That mapping is worth more to a bank's risk posture than any certificate on the wall, SOC 2 included.