Compliance Guide | Model Risk Management

    SR 26-2 Model Validation: What Changed for Bank Validators and for AI Scope

    As of November 2026, SR 26-2 (Revised Guidance on Model Risk Management) is the interagency guidance from the Federal Reserve, OCC and FDIC, issued April 17, 2026. It supersedes SR 11-7 and SR 21-8 and takes a risk-based approach tailored to each bank's model risk profile, size and complexity. Public statements indicate it applies to traditional models and basic AI applications, not generative or agentic AI. Validators should re-baseline the inventory, document materiality rationale, and treat runtime evidence for out-of-scope AI as internal governance practice.

    Validator actions and questions for model risk management leadership

    • Re-baseline the model inventory against the SR 26-2 definition and document how deterministic rule-based tools and AI systems were classified.
    • Replace references to SR 11-7, SR 21-8, FIL-22-2017 and FIL-27-2021 in policies, templates and BSA/AML procedures.
    • Document the materiality and risk-tiering rationale that sets validation rigor for each model.
    • Ask: how does our policy define independence and effective challenge, including for systems outside the model definition?
    • Ask: what governance, validation and monitoring standard applies to generative and agentic AI used in consequential decisions?
    • Ask: for third-party and AI-enabled models, what decision-level and production evidence can we retain and show an examiner?

    What SR 26-2 replaces and how it is framed

    The Federal Reserve, OCC and FDIC issued SR 26-2 on April 17, 2026. It supersedes and replaces SR 11-7, issued in April 2011, and SR 21-8, the April 2021 interagency statement on BSA/AML model risk management. The OCC issued the text as Bulletin 2026-13 and describes it as rescinding prior model risk management guidance. The FDIC is rescinding FIL-22-2017 and FIL-27-2021 in connection with the release.

    The agencies say the revision reflects about fifteen years of supervisory experience, industry feedback and advances in modeling practice. It clarifies principles and emphasizes a risk-based approach tailored to the banking organization. The guidance text also states that it does not set forth enforceable standards or prescriptive requirements.

    For a validator, the practical consequence is latitude paired with accountability for judgment. Where the guidance is principles-based, the bank decides scope and rigor, so the written rationale for those decisions becomes part of the validation record. Any internal policy, template or BSA/AML validation procedure that still cites SR 11-7 or SR 21-8 now points to superseded guidance and needs updating.

    The model definition and what it does to your inventory

    SR 26-2 defines a model as a complex quantitative method, system or approach that applies statistical, economic or financial theories to process input data into quantitative estimates. It excludes simple arithmetic calculations, such as spreadsheets, and deterministic rule-based processes and software that have no statistical, economic or financial theories underpinning their design or use.

    Inventory status is therefore scope-sensitive. A tool that falls outside the definition no longer sits inside the model validation program by default. That matters because inventory membership is what administers change control, documentation standards and performance evidence. Some industry commenters have argued that systems leaving the inventory also leave those controls, and the concern is reasonable even though it is a view, not a regulatory requirement.

    Re-baselining the inventory against the new definition is the first task. For each tool that moves out, record the reasoning, name an owner, and decide what change control and challenge it still receives. Silent removal is the gap to avoid.

    Validation scope, rigor and effective challenge

    The attachment states that validation evaluates whether models perform as expected, including their reliability and limitations. Its nature and rigor generally align with the model's approach, use and materiality, and validation generally occurs before a model's first use. Validation plans should therefore carry a documented materiality and risk-tiering rationale that explains why a given model received a given depth of testing.

    Effective challenge is defined as critical analysis by objective experts who evaluate model risk and effect appropriate changes throughout the model lifecycle, from development through ongoing monitoring. The guidance also describes assessing model risk individually and in aggregate, including shared assumptions, data or methodologies. In practice, that argues for tracking where several models depend on the same data source, vendor component or methodology, and for recording how those dependencies were considered.

    Vendor and third-party products remain within the guidance, including their validation. Validators should be clear about which outputs, version information and documentation the bank can obtain from a vendor, because those determine what can be evidenced later.

    Where AI sits: in scope, out of scope, and the gap between

    The brief for many validation teams assumes AI used in consequential decisions falls under the model risk framework. That is only partly true. On May 1, 2026, Federal Reserve Governor Bowman said the agencies amended the guidance to clarify that it does not apply to generative or agentic AI, and that it now applies narrowly to traditional models and basic AI applications. The OCC describes generative and agentic AI models as novel and rapidly evolving.

    Two consequences follow. First, a machine learning model that fits the definition and is not generative or agentic remains a validation subject, scaled to its materiality. Second, generative and agentic systems used in consequential decisions may have no SR 26-2 validation standard at all. They still need a documented owner, change control and a challenge process, set by internal policy and by whatever other supervisory expectations the bank determines apply.

    That gap is a governance decision for model risk management leadership, not something a validator should resolve alone. It should be recorded and approved so that the rationale is defensible when it is reviewed.

    Where runtime policy enforcement and execution evidence can help

    Pre-deployment validation describes how a system was expected to behave. It does not show what a system was permitted to do, or did, on a specific production interaction. For AI systems, particularly those outside SR 26-2, that distinction matters to anyone who must later explain a consequential decision.

    This section is an inference, not a requirement of SR 26-2. Where AI is in use, policy can be enforced in the execution path, so that each interaction or tool call is allowed, redacted, blocked or escalated for human approval, rather than reviewed after the fact. Enforcement of this kind produces audit-ready evidence of what the AI was allowed to do and what it did. Trussed provides this runtime control and evidence for individual interactions and tool calls. For out-of-scope generative and agentic AI, treat it as internal governance practice. For in-scope AI, confirm with model risk management what production monitoring evidence the bank will rely on.

    The limits are clear. Runtime enforcement does not replace validation or testing, and Trussed does not perform model validation, model lineage or dataset provenance. It supplies one evidence stream that a validator can reference alongside conceptual soundness review, outcomes analysis and ongoing performance monitoring.

    SR 26-2 at a glance for validators

    Supersedes

    SR 11-7 (2011) and SR 21-8 (2021, BSA/AML model risk)

    Approach

    Risk-based, tailored to model risk profile, size and complexity

    AI scope

    Traditional models and basic AI applications; generative and agentic AI reported as outside scope

    Validator focus

    Inventory definition, materiality rationale, effective challenge, evidence

    Map your AI evidence to examiner questions

    If your validation program includes AI in consequential decisions, discuss how enforcement in the execution path and audit-ready evidence can sit alongside your validation work.

    Talk to an Expert