SR 26-2 left agentic AI out of scope. Here is what banks should do instead

On April 17, 2026, the Federal Reserve, OCC and FDIC replaced the model risk guidance that US banks had worked under since 2011. The Fed issued it as SR 26-2 and the OCC as Bulletin 2026-13. It supersedes SR 11-7 and SR 21-8, the 2021 interagency statement on model risk for systems supporting BSA/AML compliance (SR 26-2). The OCC rescinded its matching 2021 bulletin, and the FDIC rescinded its letters on both documents (OCC Bulletin 2026-13, FDIC).

A footnote in the new guidance puts generative and agentic AI models outside its scope, describing them as novel and rapidly evolving (guidance, footnote 3). For anyone running or buying an AI agent that triages transaction-monitoring alerts, that footnote is the most important line in the document.

What the new guidance does

The shape will be familiar to anyone who worked under SR 11-7, with a lighter touch:

• It is risk-based and expected to be most relevant to banking organizations with more than $30 billion in total assets, though it may apply to smaller ones with significant model risk (SR 26-2, OCC).
• It is not enforceable, and the agencies say non-compliance will not by itself draw supervisory criticism. Unsafe or unsound practices can still (guidance, section I).
• Validation has three parts: conceptual soundness, outcomes analysis against real-world results, and ongoing monitoring as data and conditions change. Effective challenge means critical review by people with the expertise, independence and standing to force a change (guidance, sections III and V).
• A model is a complex quantitative method that applies statistical, economic or financial theory to turn inputs into estimates. Deterministic rule-based processes without that kind of theory behind them are excluded from the definition (guidance).

Why “out of scope” is not “no expectations”

For tools the guidance does not cover, the footnote says the bank's own risk management and governance practices should guide the controls (guidance, footnote 3). The OCC added that the agencies plan a request for information on model risk management, including banks' use of generative and agentic AI (OCC Bulletin 2026-13).

Look at what that leaves for a typical AI triage tool. Its deterministic rules fall outside the definition of a model. Its language model falls outside the scope of the guidance. Neither half is covered, and the BSA/AML statement that used to connect monitoring systems to model risk management has been withdrawn. If your validation procedures cite SR 21-8, they now cite a rescinded document.

None of this takes the tool out of an examination. Examiners still assess the SAR process itself: adequate staff for identifying and evaluating suspicious activity, reviews completed in a reasonable time, and documented decisions (FFIEC manual). FinCEN's April 2026 proposal for AML/CFT programs would also have examiners consider whether a bank is employing innovative tools such as artificial intelligence, though as of this writing that is still a proposal (FinCEN fact sheet). The agent will be examined through the BSA program whether or not model risk guidance names it.

A control set for agentic triage

The practical answer is to borrow the structure of SR 26-2 anyway and adapt each part to what an agent actually does. An agent that triages alerts reads records, calls a model, writes claims and proposes a disposition. These nine controls cover that loop.

1. Bounded authority, enforced in code. Write down what the agent may never do, and make it impossible rather than discouraged. For alert triage the list should include the SAR filing decision, clearing a sanctions or watchlist match, contacting a customer, and changing its own thresholds. A sentence in a prompt is not a control.
2. Deterministic checks on both sides of the model. Rules that run before the model (route strong watchlist matches to L2, abstain on thin files) and after it (confidence floors, downgrades). Because these are not models under the new definition, document them as controls with owners and tests.
3. Grounded claims, checked mechanically. Every claim in a rationale should cite a record the agent was given, and code should verify each citation exists and each dollar figure traces to the cited records. A failure should send the alert to a person, never to the analyst as a confident recommendation.
4. Versioned runs. For every recommendation, record the model and provider, the prompt version, the policy version, the agent identity, the evidence it saw and the steps it took. Without this, outcomes analysis has nothing to stand on.
5. Shadow testing before anyone sees the output. This is the outcomes analysis. Run the agent on alerts your team has already decided, hide its recommendations, and compare by alert type. Look hardest at the cases where the agent would have closed and your analysts escalated.
6. Sampled QA in production. This is the ongoing monitoring. Draw a random sample of agent-assisted closes for a second reviewer and track agreement, override rates and override reasons by alert type.
7. Autonomy earned per alert type. Recommend-only is the default. Batch approval or auto-close for a given alert type should require a stated agreement rate on a stated number of QA reviews, plus written sign-off, and should drop back when agreement falls.
8. Human-only change control, and untrusted inputs treated as hostile. Policy changes come from named roles, get a version number and keep their before and after values. A new model or prompt reruns the shadow set. Memos and counterparty names are written by customers, so instruction-like text in them should lock the alert, not reach the model.
9. An exportable file, including vendor terms. Effective challenge needs a document: purpose, data lineage, method, controls, performance, limitations, change history and sign-off. It should also record what the model provider may do with the data. Anthropic's commercial terms say it may not train models on customer content from its services (Anthropic). OpenAI says API data is not used for training unless the customer opts in (OpenAI). Microsoft says Azure OpenAI prompts and completions are not available to OpenAI and are not used to train foundation models without permission (Microsoft).

What this means for alert triage

I built Assay around that list, so here is how it maps, including the parts that are not done.

• Bounded authority. Four actions have no code path: the SAR decision, clearing a watchlist match, contacting a customer, and changing its own policy.
• Deterministic checks. Six policy rules run around the model. Watchlist similarity at or above 0.88 forces L2. Fewer than 8 transactions makes the agent abstain. A close below 0.85 confidence becomes human review. Instruction-like text in a memo locks the alert before any model call.
• Grounded claims. Citations and dollar figures are validated against the evidence bundle before an analyst sees the recommendation.
• Versioned runs. Each run records the agent identity, provider, model, policy version and a hash of the prompt template, with the full trace.
• Shadow testing and QA. Autonomy level L0 is shadow mode. QA samples 10% of agent-assisted closes by default.
• Earned autonomy. Moving an alert type to auto-close requires an owner or admin to attest to 98% agreement on 2,000 QA-reviewed alerts and written approval, and the metrics screen shows each type's progress toward that bar. Today that gate is an attestation, not an automatic lock, and it does not yet step down on its own when agreement falls. Only owners and admins can change policy, and every change is versioned in a SHA-256 hash-chained audit log.
• The file. The model risk documentation export has 9 sections, from “Purpose and scope” to “Sign-off”, filled from live policy, run and QA statistics.

What does not exist yet: an independent validation, a SOC 2 report, and any production data run through it. A design partner's model risk team is the first effective challenge it will get, which is the point of the model risk page and the pilot.