Interagency AI Principles and Their Operational Gaps for Banks

SR 26-2 tells banks what to achieve with AI governance and leaves the how blank on purpose. That gap between what examiners expect and what banks actually run day to day is where most operational risk in AI deployments lives right now. The generative and agentic carveout in the rule functions as a governance vacuum, and banks are being examined against it whether the rulebook admits that or not.

The regulatory stack doesn't make this easier. SR 26-2 sits alongside OCC Bulletin 2025-26, OCC Bulletin 2026-13, FDIC FIL-15-2026, the 2023 interagency third-party risk management guidance, and CFPB chatbot guidance. Each one adds an expectation. None adds a playbook. Layer in California's January 2025 advisory applying existing consumer protection law to AI, Utah's 2024 AI Policy Act with per-violation penalties for undisclosed chatbots, and banks are working a patchwork that changes shape depending on which state they operate in. The American Bankers Association has already flagged the risk that conflicting state rules choke off innovation before it gets off the ground. That's a live concern, not a hypothetical one.

So where does the guidance go quiet, and what do banks need to build themselves to fill that silence rather than wait for the next bulletin to do it for them?

The GenAI carveout in SR 26-2 and what it actually means for agentic deployments

Start with the carveout, because it's the clearest example of principles-based guidance creating more questions than it answers. SR 26-2 puts generative and agentic AI systems outside its scope and tells institutions to apply "existing risk management and governance practices" instead. That sounds reasonable until you ask the obvious follow-up: which function inside the bank actually owns that?

Here's the problem. The carveout doesn't hand banks a parallel framework built for agentic systems. It hands them a gap. Generative and agentic tools are excluded from traditional MRM controls, and nothing built for this new territory replaced what got excluded, particularly for systems making customer-facing decisions or executing real financial actions on their own.

Trace the ownership question through each risk function and watch it dissolve every time. Model risk doesn't want it, because there's no single wrong output to validate against; the system's behavior shifts with context. Operational risk doesn't want it either, because there's no process break in the traditional sense; the system does what it was built to do. Conduct risk can't claim it because there's no human actor making the decision in the chain. Each function inspects its own layer, sees a clean result, and moves on. The governance gap survives precisely because no one owns it, and that's the part worth sitting with: this isn't three functions fighting over turf, it's three functions each correctly concluding the problem isn't theirs.

SR 26-2 replaces the old binary of model versus non-model with a three-tier structure: traditional models get full MRM rigor, non-model tools get general governance, and excluded innovations like GenAI and agentic AI get "general risk governance," full stop. That third tier has no prescribed content. It's a label without a manual.

Even the OCC seems to know it. Its press release accompanying SR 26-2 mentioned a forthcoming request for information on AI, including agentic systems, and that's a tell: if the guidance were complete, there'd be nothing left to ask about. Examiners aren't waiting for that RFI to close the loop, though; they're already asking banks how they govern what the rule doesn't cover. The carveout functions less like a reprieve and more like an invitation to get examined on governance that doesn't exist yet.

How hybrid AI architectures make the governance gap harder to close

Most banks aren't running a single AI model in isolation. They're running hybrid stacks, where an LLM or an agentic orchestrator feeds inputs into, or pulls outputs from, traditional statistical models that sit squarely inside SR 26-2's scope.

That creates a seam. The statistical model gets validated under full MRM rules. The agentic layer directing it, deciding when to call it, how to interpret the instruction, what to do with the output, does not. A validated model's output, in other words, might be the product of a process the bank can't fully reconstruct after the fact. Call it the reasoning layer problem: the moment an agentic system decides which model to invoke, or how to read an ambiguous instruction, or what action to take next, it sits outside every control boundary the bank has already built. That boundary isn't weak; it was never drawn.

Time makes this worse, not better. A model run in batch produces a snapshot: input, output, done. An agentic system managing a loan or a payment across its full lifecycle produces consequential outputs continuously. The exposure doesn't sit still; it compounds, action after action, for as long as the system stays live.

A related concern has been raised at the industry level: automation linking trading, credit, and compliance systems through continuous data exchange can amplify volatility when agents respond to shared signals in correlated ways. That's a systemic risk, not just an institutional one, and no single bank's governance program is built to catch it alone.

The architectural implication is easy to state and hard to execute. Governance can't be designed model by model anymore. It has to be designed across the orchestration layer itself, the connective tissue between systems, and that's exactly the layer current guidance doesn't describe.

What TPRM guidance requires when an AI vendor builds what the bank deploys

The 2023 interagency third-party risk management guidance, issued jointly by the Fed, OCC, and FDIC, is blunt about one thing: outsourcing a model to a vendor does not outsource the risk. The bank stays accountable for the vendor's controls, data handling, and failure modes, full stop.

This is where most existing programs are thinnest, and where the industry keeps getting the priority backwards. Banks tend to treat vendor AI due diligence as a variant of traditional IT vendor review, just with an extra questionnaire tab. Most TPRM programs weren't built with AI agents in mind when someone first drew them up, and stretching an old checklist over a new risk doesn't close the gap; it just hides it.

What does "responsible for the vendor's controls" actually require, operationally? The bank has to be able to audit what the vendor's model does, not take the vendor's word that an internal audit process exists somewhere. It has to know where the vendor's data lives, how often the model gets updated, and what the escalation path looks like when something fails. When an AI agent executes a transaction on the bank's own rails, the bank's compliance obligations attach to that action regardless of where the underlying intelligence came from.

For credit unions and community banks, this cuts deep. CUSO and vendor partnerships are often the only realistic path into agentic AI. That path doesn't shrink the compliance surface, though; it relocates it into a relationship the institution now has to actively manage rather than passively trust.

SOC 2 certification matters here, and it's the right baseline to ask for. But treating it as the finish line is the mistake: a SOC 2 report proves a control framework exists, not that the framework matches the bank's specific risk profile or regulatory obligations. TPRM guidance asks banks to calibrate risk management to their own size, complexity, and risk profile, so a large regional bank and a small community bank will land on different answers. The accountability principle doesn't flex either way.

Where audit trails break down in practice — and what complete auditability actually requires

SR 26-2, TPRM guidance, and BSA/AML frameworks all agree that AI-driven decisions need documentation. None of them specifies what an audit trail for an agentic system needs to contain. That silence is doing a lot of work, and it's the single most underrated gap in this entire rulebook.

Traditional audit trails log inputs, outputs, and a model version number. Fine for a credit score. Nowhere near enough for an agentic system that might take a few dozen intermediate steps, call multiple tools, and change course mid-task based on real-time context before landing on a final action.

Break the agentic audit trail problem into its parts, because each one fails differently, and most banks are only solving for the first.

Completeness comes first. Logging the final action tells you nothing about how the system got there; every intermediate reasoning step, every tool call, every branch the system considered and rejected needs to be captured, not just the outcome. Immutability matters just as much. A log that can be edited after the fact has limited compliance value; it functions as a suggestion rather than a record. The institutions ahead on this build immutable logging into the architecture itself, so the record can't be touched after the fact, even by someone with good intentions.

Timeliness is the third piece. Reconstructing what an agent did after the underlying system state has already changed amounts to guesswork dressed up as documentation. Real-time or near-real-time capture is what the audit trail actually needs. Interpretability closes the loop: a log a compliance officer or examiner can't read and follow carries little operational value, no matter how complete it is. The reasoning chain has to be expressed in a form a human can review, not buried in raw system state.

Payments make all four dimensions non-negotiable at once. An irreversible transaction can't be unwound, so the audit trail has to establish intent, authorization, and compliance at the moment of execution, not reconstructed afterward when it's too late to matter. Frameworks like the NIST AI RMF and ISO/IEC 42001, published December 2023 as the first certifiable AI management system standard, call for this kind of documentation and control. Translating that call into the actual architecture of an audit trail is left entirely to the institution.

Human-in-the-loop oversight in agentic systems — where it belongs and where it breaks down

Human oversight shows up as a requirement across SR 26-2, TPRM guidance, and consumer protection frameworks alike, for any material decision. None of them says where on the spectrum from full autonomy to full human control that oversight needs to sit for agentic AI specifically. That gap matters more than it looks, because most banks are quietly failing at oversight in a way that looks fine on paper and does nothing in production.

The failure mode has a name worth using: checkboxing. A bank designates a human review step that exists on paper and does nothing in practice, either because the volume of agent actions outpaces what any reviewer can meaningfully assess, or because the review happens after the action already executed and can't be undone anyway. If the reviewer's sign-off arrives after the payment clears, the sign-off isn't oversight; it's paperwork.

What does oversight that actually functions require? Thresholds for autonomous action versus escalation need to be set in advance, calibrated to transaction type, value, and risk profile, not applied as one blanket rule across every agent action a bank runs. Escalation channels need to move fast enough to matter, meaning before a payment clears or a decision reaches a customer, not after. Someone specific needs to own each class of escalation; agentic AI tends to flatten organizational hierarchies, which sounds efficient until an incident hits and nobody's sure which function was supposed to catch it. And the audit trail itself needs to record whether a human actually reviewed an action, who that person was, and what they approved or rejected, not just that a review step technically sits somewhere in the workflow diagram.

Industry reporting has consistently found only a small fraction of companies have a mature model for governing autonomous AI agents. Read plainly, human oversight for most deployments right now is aspirational: a policy statement more than an engineered control.

What separates the deployments that work is oversight built into the architecture from the start, not bolted on as a compliance layer once the system already exists, with configurable controls the institution can tighten or loosen as its risk appetite shifts and as examiner expectations evolve, which they will.

The community bank and credit union version of the same problem

Community and regional banks answer to the same examiner expectations under the April 2026 MRM guidance as the largest institutions in the country. The principles-based framing doesn't scale down just because the balance sheet is smaller, and pretending otherwise is the mistake to watch for here.

OCC Bulletin 2025-26 gives community banks some clarification, acknowledging their size and complexity differ from a global systemically important bank's. Clarification of what's expected isn't scaffolding for how to meet it, though, and that distinction matters more the smaller the compliance team gets.

Credit unions carry an extra dimension worth sitting with. A large share of the US adult population banks at a federally insured credit union, and agentic deployments have been moving from pilot projects into core operations, with governance lagging behind the pace of adoption. That's the pattern to watch: adoption outrunning the controls meant to contain it.

The most common entry points for credit union agentic AI, contact centers, underwriting support, fraud detection, also happen to be the highest-risk from a fair lending, privacy, and explainability standpoint. The governance gaps in those use cases aren't theoretical; they're exam-relevant the day the system goes live.

Vendor and CUSO partnerships are the practical route for most credit unions into this technology, and there's nothing wrong with that route on its own. But the TPRM framework is explicit: the institution's compliance obligations travel with the vendor relationship. Outsourcing the build doesn't outsource the governance gap; it just moves the gap somewhere the credit union now has to actively watch.

So what do smaller institutions actually need from a vendor that a large bank might build in-house? Configurable controls layered onto existing rails, audit trails an examiner can review without a dedicated AI compliance team translating them first, and infrastructure carrying SOC 2 certification the institution can point to under exam. Fiserv's May 2026 launch of agentOS, positioned as a governed layer for agentic AI spanning core, payments, and servicing platforms, is one example of vendor-built governance infrastructure showing up in the market to meet exactly that need. The question that still belongs to the institution, no matter which vendor it picks, is whether the bank can independently verify what its agents access, decide, and document. That verification can't be delegated away.

Payments and transfer execution as the highest-stakes operational gap

Agentic AI has moved past making recommendations. It's executing real financial transactions now, either at the transaction layer, acting on its own within defined parameters, or at the orchestration layer, managing a multi-step payment workflow end to end. This is the section where the governance gap stops being abstract and starts being measured in dollars that already left the building.

The ISO 20022 migration is what made this technically possible in the first place. Richer, structured, machine-readable payment data opens the door to real automation. It also means that when an agent makes a mistake, or takes an action it wasn't authorized to take, that error executes with the same institutional precision and speed as a correct one. The rails don't distinguish between the two.

Real-time payments strip out a safety net that batch processing used to provide: time to catch a mistake before it settles. ACI Worldwide's 2026 fraud trends analysis flagged bank transfers and instant payment rails as among the most exploited fraud channels precisely because they're high-velocity and hard to reverse once money moves.

For agentic payment execution specifically, four controls compound on top of each other, and skipping any one of them undermines the rest. Authorization has to be established and documented before execution happens, not reconstructed afterward when the transaction can no longer be unwound. Transaction limits need to flex by value, counterparty type, and payment rail, not sit as one uniform ceiling applied to every agent action regardless of context. The audit trail has to capture the full chain, instruction through execution, including whatever intermediate decisions the agent made about routing, timing, or which counterparty to use. And human escalation thresholds need to be set according to how irreversible the specific rail actually is; a same-day ACH transfer and an instant payment don't carry the same risk, and the controls shouldn't pretend they do.

Open banking adds one more layer of exposure worth naming. AI agents pulling multi-bank cash positions and automating liquidity decisions through APIs are operating across institutional boundaries, not just within one bank's walls. A failure there doesn't stay contained to the institution that made the mistake; it has consequences for whoever's on the other end of that API connection.

Banks deploying agentic payment execution without these four controls, authorization, configurability, auditability, calibrated escalation, are building the exact exposure the interagency principles exist to prevent. The guidance doesn't spell that out in so many words, but the consequence doesn't need it spelled out to be real.

What banks that are getting this right are actually doing operationally

The institutions ahead of this curve share one design instinct more than any specific tool or vendor: they treat governance as something built into the architecture from day one, addressed early rather than stapled on after the system already ships. That instinct, more than any single control, is what separates the banks that pass exams cleanly from the ones scrambling to explain a workflow diagram after the fact.

In practice, that shows up as layered controls rather than a single checkpoint: thresholds that vary by transaction type and risk instead of a blanket rule, audit logging that's immutable by design instead of by policy memo, escalation paths with a named owner for each category of decision so nobody's guessing who picks up the phone when something looks wrong, and vendor relationships where the bank keeps the ability to independently verify, not just certify, what the AI is doing on its behalf.

Regulation alone doesn't tell banks exactly how to build any of this. SR 26-2 and the guidance around it describe outcomes: safety, soundness, accountability, auditability. The architecture that gets a bank to those outcomes is still, for now, an engineering problem the institution has to solve on its own. That's the nature of principles-based regulation applied to a technology moving faster than any rulebook can track, rather than a failure of the guidance itself.

The banks closing that gap aren't waiting for the next bulletin to tell them how. They're building the how now, and testing it against exactly the questions examiners are already starting to ask.