SR 26-2 vs OSFI E-23: Model Risk Rules for US and Canadian Banking Groups

What SR 26-2 is, and what kind of document it is

SR 26-2, titled Revised Guidance on Model Risk Management, was issued by the Federal Reserve on April 17, 2026. The FDIC announced the same day that the agencies had issued revised model risk guidance. The guidance discusses the factors that influence model risk and the features of effective model development and use, model validation and monitoring, and governance and controls.

Its character matters for a cross-border comparison. SR 26-2 states that it sets no enforceable standards or prescriptive requirements, and that non-compliance with the guidance will not result in supervisory criticism. It recognizes that practices appropriately vary with each organization's risk profile and model usage, and that practices suited to one bank may be inappropriate for another with a different risk profile or model purpose. Each organization is responsible for adopting practices that are appropriate and effective for the risks it faces.

That framing means a US program is judged largely on the reasoning behind its choices. A group that also answers to OSFI Guideline E-23 in Canada should treat the two documents as separate supervisory expectations applied to one set of models, and should avoid describing SR 26-2 elements as legal obligations in internal policy.

Comparison by model risk domain

The table is organized by the domains a cross-border group has to evidence. The SR 26-2 column reflects what the guidance says. The second column describes the evidence a group should be able to produce for each domain, and it should be checked against the E-23 text for each Canadian entity.

• Scope and model definition: SR 26-2: the relevance of model risk depends on the nature, scale and use of models relative to business risks. The guidance may be useful for any type of model, and is expected to be most useful for models supporting significant business lines, operations, services and functions. Group evidence: one written definition of a model, an explicit scope decision for each system, and the reasoning behind borderline cases.
• Risk-based tiering and inventory: SR 26-2: the intensity of model risk management scales with risk profile, model usage and materiality. Group evidence: a single inventory with a tier for each model, the rationale for that tier, and the business function it supports, so the same record answers both supervisors.
• Development and validation: SR 26-2: describes features of effective model development and use, and of model validation. Group evidence: development documentation, validation results and the rationale for the level of rigor applied to each model.
• Ongoing monitoring: SR 26-2: validation and monitoring are treated together as a feature of effective practice. Group evidence: monitoring records for models in production, thresholds used, who reviews them and what actions followed.
• Governance and accountability: SR 26-2: governance and controls are a core domain, and each organization decides which practices fit its risks. Earlier interagency guidance adopted in 2017 made senior management responsible for effective challenge and internal audit responsible for verifying it. Group evidence: named owners, challenge records and escalation decisions.
• Third-party models and documentation: Supervisory guidance on third-party risk in general states that a bank cannot abrogate responsibility for effective risk management when it uses a third party. Group evidence: enough information about vendor models to explain and reproduce past decisions, and contract and review records for each provider.

Where AI and ML models in production change the picture

Whether an AI or ML system falls inside model risk management depends first on how a group defines a model and sets scope, and that decision should be written down and applied consistently in both jurisdictions. Because SR 26-2 scales to nature, scale and use, the practical question is how significant the business function is, not whether the technique is new.

Production AI systems raise operational questions that tiering and validation alone do not answer. Behavior can vary with inputs, a system may call tools or external services, and the underlying model is often supplied by a third party. For each such system, a group should be able to say what it was permitted to do, what it did in production, and who reviewed the results. Those answers feed ongoing monitoring, which SR 26-2 treats as part of effective practice, and they are the kind of material an examiner asks for when a model is already in use.

A vendor-supplied model does not move accountability. The bank remains responsible for effective risk management even when a provider performs the work, so the evidence has to exist inside the bank, not only at the provider.

Building one program instead of two

The common failure is a second, parallel program for the other jurisdiction. A more durable approach is to map the existing inventory, validation and monitoring artifacts to the three SR 26-2 domains first, then add the E-23 mapping for each domain and record where an expectation is stricter, differently worded or absent. Differences then become documented exceptions to one program, not a separate program.

The tradeoff is that a single program must be written to the more demanding expectation in each domain, which can raise the baseline for some US models. In return, the group maintains one inventory, one tiering method and one evidence trail. Where a US practice is a judgment call under non-enforceable guidance, record why that judgment was made. That record is more useful to an examiner than a policy that only states the practice exists.

For BSA and AML systems, the interagency statement says banks may apply some or all of the model risk management principles, commensurate with the nature and materiality of the risk. The same proportionate logic can be applied when deciding how much of the program reaches lower-tier models.

What runtime policy enforcement can and cannot support

Enforcing policy in the execution path of AI interactions and tool calls produces records of what a system was allowed to do and what happened: which actions were allowed, redacted, blocked, rate limited or escalated for human approval. Because enforcement happens at runtime, not through review after the fact, the resulting audit-ready evidence is generated as a byproduct of operation. For production AI systems, that evidence can be one input to ongoing monitoring and to examiner requests about live behavior. Trussed enforces policy at this level, scoped to individual interactions and tool calls.

The limits are important. Runtime enforcement does not replace model development documentation, independent validation or effective challenge, which SR 26-2 and earlier interagency guidance treat as distinct features of effective model risk management. It does not provide model lineage or validation, and it does not set a group's model definition, tiering or governance structure. Those remain with the bank's model risk function.

Trussed's production experience is in regulated sectors, with insurance as its deepest area. A group assessing this kind of evidence should evaluate whether the records map cleanly onto its own monitoring and governance processes.