Model Validation Requirements for AI Agents That Execute Transactions
On April 17, 2026, the Federal Reserve, the OCC, and the FDIC put out SR 26-2 and OCC Bulletin 2026-13, retiring SR 11-7 as the guiding word on model risk after fifteen years. Buried in the new text is a line that ought to keep model validation teams up at night: generative AI and agentic AI models are novel and rapidly evolving and, as such, sit outside the scope of this guidance entirely. So the regulation just written to replace the old rulebook opens by declining to cover the fastest-growing category of AI deployment in banking, and that leaves validation teams building their own framework from spare parts. This piece maps what those parts need to be.
Why agentic AI strains the SR 11-7 model definition in ways that matter for validation
Start with the definition itself. SR 11-7 defines a model broadly as any quantitative method, system, or approach that uses statistical, economic, financial, or mathematical techniques to produce estimates from input data. An AI agent that executes a wire transfer or approves a transaction fits that description on paper. But look closer at how it actually works, and the fit starts to come apart at the seams.
A traditional model takes a fixed set of inputs, runs them through deterministic logic, and spits out a single output. You can freeze that artifact and test it. An agent doesn't work that way. It reads context, calls outside tools, plans a chain of steps, sometimes loops back to check its own work, and can take an action nobody reviewed first. The "model" isn't a fixed thing anymore. It's a system of moving parts talking to each other.
That architecture creates validation problems with no clean precedent. What exactly is being validated: the language model, the layer that calls external tools, the logic that orchestrates the whole sequence, or all three stitched together? Ask ten validation leads and you'll likely get different answers. Outputs aren't even reliably repeatable: feed the same input twice and the agent can return two different answers, which makes standard backtesting a much blunter tool than it used to be. And unlike a credit score a loan officer can override before it does damage, a payment instruction from an agent can clear faster than traditional oversight processes are designed to catch.
Then there's the failure mode with genuinely no analog in the old world: prompt injection. Someone feeds the agent a crafted input designed to make it misbehave, and there's nothing in SR 11-7's original playbook that anticipates that. A vendor security review built for a SaaS platform that stores and serves static data can't catch it either, because an agent reasons over live customer data, generates novel responses on the fly, and takes real action in backend systems in real time. The Consumer Financial Protection Bureau has already flagged the consumer-harm side of this directly, warning that AI chatbots in financial services risk violating legal obligations and eroding trust. Per fin.ai's 2026 compliance guide, an agent that states the wrong fee or the wrong rate isn't a minor glitch. It's a potential UDAAP violation.
So validation has to be built around how agents actually break, not around the failure modes SR 11-7 was written fifteen years ago to catch.
The horizontal instruments every bank's validation program must anchor to
Two frameworks apply no matter what the agent does or which business line owns it.
The NIST AI Risk Management Framework gives the method: four functions, Govern, Map, Measure, Manage. ISO/IEC 42001 gives something NIST doesn't: an actual certification an outside auditor can sign off on, covering risk management, transparency, and responsible deployment. Put plainly, NIST tells you how to run the process; ISO/IEC 42001 proves to an external party that you ran it. Governance without something to test against is just policy sitting on a shelf.
Map that back to SR 11-7's three pillars, sound development, rigorous validation, effective governance, and the pieces line up cleanly enough. NIST's Govern and Map functions map to governance. Measure and Manage map to validation and ongoing monitoring. ISO/IEC 42001 wraps around both as the management system that holds it together.
Vendors bring their own alphabet soup, and validation teams need to know which letters actually matter. SOC 2 Type II, not the weaker Type I, covers a sustained audit period across security, availability, processing integrity, confidentiality, and privacy; treat it as the floor, not the ceiling. ISO 27001 covers a formal information security management system. AIUC-1, developed with input from Stanford, MIT, MITRE, and the Cloud Security Alliance, is newer and narrower: it's built specifically around how agents behave once they're live in production, and it requires adversarial testing every quarter. That last detail matters. A certification that only gets checked once, at launch, tells you nothing about whether the agent still behaves the same way six months later.
None of this happens in isolation from the rules already on the books. GLBA, PCI DSS, NYDFS Part 500 (whose 2023 amendments now name AI systems directly inside cybersecurity program requirements), and DORA, effective January 17, 2025, all apply at the same time and need to be mapped alongside these frameworks, not bolted on afterward. The Wolters Kluwer Banking Compliance AI Trend Report for Q1 2026 found that 28.4% of financial institutions named explainability and transparency among their most acute regulatory concerns. That number is a signal worth sitting with: explainability has to be designed into the framework from day one, not patched in after an examiner asks an uncomfortable question.
What a pre-deployment validation test suite for a transaction-executing agent must cover
Take SR 11-7's original validation components and each one needs a fresh, agent-specific translation before it's worth anything.
Policy fit means confirming the agent's actual logic reflects bank policy, that it denies a transaction for the right reason and flags suspicious activity the way BSA/AML rules require. That takes a documented map from policy to logic, not just watching the agent behave correctly a few times and calling it done. Backtesting against historical cases means running the agent across a real, representative dataset and counting correct decisions against false positives and false negatives, not settling for one headline accuracy number that hides where the risk actually sits.
Robustness checks are where agent validation starts to look genuinely different from anything SR 11-7 anticipated. Rephrase the same question five different ways and see if the answer changes for no good reason. If it does, that's a robustness failure unique to language-model systems, and it wouldn't show up in a traditional model at all. Adversarial testing takes it further: feed the agent prompt injections, garbled data, absurdly long inputs, and genuine edge cases, and map every way it breaks before it ever touches a live customer.
Research published in June 2026 by Thanh Luong Tuan and Abhijit Sanyal on arXiv pushes this into something more systematic, worth understanding in some detail. The idea is an Agent Operational Envelope: a formal certification of exactly what the agent is permitted to do, across permissions, domain constraints, safety properties, governance rules, and autonomy level, before it's ever handed production access. Paired with that is ontology-to-scenario generation, which builds test scenarios straight out of formal representations of actual regulatory text rather than out of someone's best guess at what a bad actor might try. In a controlled pilot spanning banking, fintech, insurance, and healthcare, this approach generated 1,800 test scenarios checked against 125 primary-source regulatory requirements. Ontology-grounded generation hit 48.3% regulatory coverage, against 33.1% for a persona-based baseline built the older way. Fifteen points doesn't sound dramatic until the coverage gap turns out to be a missed sanctions match.
That's not hypothetical. The same research describes a Tier-2 Vietnamese commercial bank running an AML screening agent through 27 customer-onboarding cases. It processed 27 cases correctly in shadow mode but produced two false negatives against the UN 1267 consolidated sanctions list, traced back to a misconfigured name-romanization rule. A simulation gate caught both before the agent ever reached production. Under Vietnam's AML Law, that miss would have been the bank's liability, not the vendor's, and that allocation of responsibility is exactly the same in most jurisdictions banks actually operate in.
That's the core of the hallucination risk specific to payment agents: if a model invents a plausible-sounding reason to wave through a suspicious transfer, the bank owns the consequence. Monitoring after the fact doesn't undo a cleared wire. So pre-deployment testing can't lean on the promise of catching it later; the fallback architecture itself needs testing before launch. If response quality drops, or the agent produces something out of bounds, does the system default to something conservative, or route the case to a human? That path needs to be tested directly, not assumed to work because it exists on a diagram somewhere.
Ongoing monitoring requirements once a transaction-executing agent is in production
Periodic review, the once-a-quarter model check that worked fine for a static credit model, doesn't hold up against an agent that can execute hundreds of transactions an hour. Monitoring has to run at the same tempo as the agent itself, which in practice means continuous, automated, and largely real-time.
Three things the monitoring layer has to catch. Model drift, where behavior quietly diverges from the validated baseline as underlying weights update or the data the agent sees in production shifts away from what it was tested on. Outlier behavior, transactions or decisions that fall outside the operational envelope the agent was certified against. And plain performance degradation: accuracy slipping, latency creeping up, false-positive rates drifting past the threshold set at validation. None of this is visible through a sample pulled once a month; it needs dashboards and alerts running continuously, because the alternative is finding out three weeks after the fact.
The three-lines-of-defense model still applies, it just needs updating for agent-specific mechanics. First line, the business itself, needs real-time transaction controls and approval thresholds built directly into the agent's architecture, not layered on as an afterthought. Second line, risk and compliance, owns independent validation that the agent is actually doing what it was designed to do against the compliance rules that govern it, including ongoing review of how well production behavior tracks the scenarios it was tested against. Third line, audit, needs a complete, tamper-evident trail of every action the agent took, every tool it called, and the reasoning behind each decision, producible on demand for an examiner without anyone having to reconstruct it from scattered logs after the fact.
One structural answer worth taking seriously here is neurosymbolic architecture: splitting the neural piece, the language model reading unstructured input and figuring out intent, from the symbolic piece, deterministic rule-based logic that actually executes the decision. The symbolic layer can't hallucinate a compliance pass, because it doesn't generate anything. It enforces a rule or it doesn't. Gartner's 2025 research predicts guardian agents, AI systems built specifically to monitor other AI agents, will capture 10 to 15% of the agentic AI market by 2030. Until that category actually matures, the load-bearing control has to come from architecture that inspects the tool call directly, not from a future product that doesn't fully exist yet.
None of this is optional paperwork. SOC 2 Type II, NYDFS Part 500, DORA, and the governance principles carried forward from SR 11-7 all require that every AI-driven action in a regulated environment be traceable, attributable, and reviewable. For an agent that executes payments, that means logging at the level of the individual tool call, not just the session. A session log tells you a conversation happened. It doesn't tell you which specific action moved money.
Know Your Agent: the identity and authorization layer validation frameworks must now include
Something new is walking through the bank's front door, and it doesn't fit any box that existed before. An AI agent checking a balance or moving funds on a customer's behalf isn't a customer. It isn't an employee. It isn't a system account in the way banks have always defined one. It's a fourth category nobody built controls for.
Leave that identity gap open and the regulatory exposure shows up fast, across several fronts at once. Reg E and Reg Z were written around the idea of a human authorizing a transaction; existing liability frameworks under Reg E and Reg Z were written around human authorization, leaving unclear how losses tied to a customer's AI agent acting autonomously would be allocated. BSA/AML obligations may require tying every single agent back to a verified human identity just to keep transaction monitoring functional, since a system built to flag abnormal human behavior can get genuinely confused by an agent making continuous, autonomous transfers around the clock. An IMF paper on the subject warns plainly that agents capable of executing payments expose real gaps in KYC and multifactor authentication, both of which were designed around an assumption of explicit human action at the moment of the transaction.
This isn't a distant, theoretical risk. The volume of autonomous agent activity in financial services is already substantial and growing rapidly. That shift is already underway. The identity gap sitting underneath it is a today problem.
Zor Gorelov, writing for American Banker in December 2025 with input from Klaros Group, laid out a framework worth internalizing here: Know Your Agent, or KYA, built on three pillars. Agent Identification and Validation establishes who owns an agent, where it came from, and what its identity actually is. Agent Due Diligence assesses the risk in how the agent behaves and what data it's allowed to touch. Ongoing Agent Monitoring keeps watching performance, compliance, and integrity after deployment, not just at launch.
Under that framework, every agent touching financial data or executing a transaction needs to clear four bars. Authenticated: identity, origin, and ownership all verified. Authorized: permissions and transaction limits spelled out clearly and consented to by the actual customer. Auditable: behavior and decision logic transparent enough to trace after the fact. Aligned: actions that hold up against regulatory, ethical, and fiduciary standards, not just technical ones.
Sumsub's approach, launched in January 2026, offers one workable pattern: every agent action is explicitly tied to authorization from a real, verified human. The agent can execute the action, but responsibility and authorization stay with the person, and that authorization link can be checked dynamically the moment risk actually shows up, rather than sitting as a one-time checkbox from onboarding. For validation teams, the lesson is straightforward: an agent's identity, its authorization boundaries, and the mechanism linking it back to a human aren't IT configuration settings buried in a settings panel. They're validation artifacts, and they need testing before deployment like everything else on this list.
How international regulatory frameworks are shaping the grammar banks will eventually be examined against
U.S. guidance carved agentic AI out of scope, but examiners don't build their expectations in a vacuum, and the rest of the world hasn't been nearly as quiet on this front.
The EU AI Act requires high-risk AI systems to meet a specific list of obligations: risk management, data quality, logging, documentation, information passed to deployers, human oversight, robustness, cybersecurity, accuracy. General-purpose AI obligations became applicable in August 2025, and transparency requirements follow in August 2026. Even where a specific banking agent doesn't get classified as high-risk under the Act's own terms, the vocabulary it establishes, traceability, human oversight, lifecycle documentation, is quickly becoming the shared language regulators reach for, including examiners in jurisdictions where no equivalent law exists yet.
DORA, effective since January 17, 2025, asks EU financial institutions to continuously monitor and control their ICT systems, holds management explicitly accountable, and requires logging, classifying, and reporting ICT-related incidents, including ones tied to AI. That operational resilience model is a reasonable preview of the standard transaction-executing agents will eventually be measured against, wherever they operate.
The Bank of Thailand's 2025 AI risk-management policy takes an even more direct line: human oversight is mandatory whenever AI handles a strategic function, and it names approval of deposits, withdrawals, and transfers specifically. Controls apply across the entire lifecycle of the data involved, not just at the moment a transaction clears.
Put these three together and a pattern starts to form, even without a single unified global standard behind it. Oversight, traceability, lifecycle accountability: these show up again and again, across jurisdictions that don't otherwise coordinate closely on financial regulation. For a validation team building a framework from spare parts because SR 26-2 left them without a rulebook, that recurring pattern is worth treating as more than coincidence. It's very possibly a preview of the exam questions still to come.
