SR 26-2 for the Bank Chief Risk Officer: Model Scope, AI Boundaries and Runtime Evidence

What SR 26-2 is and what changed

On April 17, 2026 the Federal Reserve, OCC and FDIC issued the Revised Guidance on Model Risk Management as SR 26-2. It supersedes and replaces SR 11-7 from 2011 and SR 21-8, the 2021 statement on model risk management for BSA/AML systems. The OCC issued it as Bulletin 2026-13, and the FDIC rescinded FIL-22-2017 and FIL-27-2021 in connection with the release.

The guidance is expected to be most relevant to banking organizations with more than $30 billion in total assets, and most useful for models supporting significant business lines, operations, services and functions. The FDIC says it generally does not apply to models at banks with $30 billion or less in assets, to the extent they lack significant model risk exposure.

It does not set enforceable standards or prescriptive requirements, and non-compliance with the guidance alone will not result in supervisory criticism. It does emphasize a risk-based approach tailored to each bank's model risk profile, size and complexity. Practices that suit one bank may be ineffective at another. The guidance covers model risk and its management, model development and use, validation and monitoring, governance and controls, and vendor and other third-party products.

For the CRO, non-enforceability does not remove accountability. Each bank remains responsible for adopting practices that fit its own risks, and the rescission of SR 11-7 and SR 21-8 means the existing program should be compared against the revised text, including the BSA/AML system coverage SR 21-8 previously addressed.

Where generative and agentic AI sit

Many CROs expected the revised guidance to become the home for AI oversight. A May 1, 2026 speech by a Fed Governor points the other way. The speaker said the Fed, with the OCC and FDIC, amended the guidance to clarify that it does not apply to generative or agentic AI, and that supervisors had expanded the prior guidance beyond its original purpose.

The same speech says other risk-management and governance practices are expected to support generative and agentic AI adoption, that banks currently rely on existing risk-management frameworks for AI, and that the Fed is working to update and simplify its third-party risk-management guidance. Vendor-provided AI is likely to be affected by that work.

This changes the CRO's accountability map. SR 26-2 will not tell the bank who owns an agent that calls tools, which framework covers a generative assistant in customer or employee workflows, or what evidence must exist for either. The CRO has to define that ownership and evidence standard inside the bank's operational, compliance, third-party and governance frameworks, and record the basis for each classification in the inventory.

Where validation and periodic review leave evidence gaps

Model risk programs have traditionally organized around governance, validation, ongoing monitoring and documentation. These apply to models within SR 26-2 scope. The same structure is a useful test for AI that sits outside it. Pre-deployment validation and periodic review establish how a system was expected to behave. They do not by themselves record what the system was permitted to do, or what it did, in a specific live interaction. Whether examiners will ask for that level of record is a bank-level judgment, but supervisors may scrutinize AI in interactions, tool calls and agent actions, so the question is better answered before it is asked.

• Governance: Typical evidence: policies, committee minutes, named owners. Gap: no record that a policy was enforced on a given interaction.
• Validation: Typical evidence: pre-deployment testing and independent review. Gap: results describe test conditions, not live inputs, outputs or tool calls.
• Ongoing monitoring: Typical evidence: periodic performance and drift reviews. Gap: sampled or aggregated views can miss individual actions taken between reviews.
• Documentation: Typical evidence: development records, inventory entries, limitations. Gap: static documents do not show permitted versus actual behavior in operation.

What a runtime control layer does and does not address

Trussed is one example of a runtime control layer. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. That enforcement generates continuous, audit-ready evidence, so the record shows what the AI was allowed to do and what it did, enforced at runtime, not reviewed after the fact. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Its operating record includes 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic, and 100+ models under one policy plane. Insurance, a regulated financial sector, is where Trussed is deepest. A bank should evaluate it against its own requirements and ask any vendor for evidence of relevant experience.

The limits matter as much as the capabilities. A runtime layer does not replace governance ownership, model validation, inventory management, third-party oversight, or fair-lending, consumer-protection and AML compliance. It does not provide model lineage or dataset provenance. It addresses one question: whether the bank can show, at the level of a single interaction or tool call, what policy applied and what happened. Evidence of that kind supports the bank's own governance and examiner discussions. It does not make the bank compliant on its own.