SR 26-2 model risk management guidance, issued on April 17, 2026 by the Federal Reserve, the OCC and the FDIC, replaced the framework US banks had followed since 2011. The Fed’s letter, SR 26-2, supersedes SR 11-7 and the 2021 interagency statement on models used for Bank Secrecy Act and anti-money laundering compliance. For anyone building or buying AI for a bank, the key point is scope: the guidance says which AI systems count as models, and it leaves generative and agentic AI out.
This explainer covers who the guidance is aimed at, how it defines a model, what it expects across the model lifecycle, and where AI products land.
What changed with SR 26-2
The revised guidance is a joint document of the three agencies. The Fed’s cover letter says it clarifies model risk management principles and emphasizes a risk-based approach tailored to a bank’s model risk profile and the size and complexity of its operations.
Three changes stand out:
- It is not a rulebook. The guidance says it “does not set forth enforceable standards or prescriptive requirements,” and that non-compliance with it will not result in supervisory criticism. A footnote adds that supervisory action may still follow from violations of law or unsafe or unsound practices that stem from poor management of model risk.
- It is aimed at larger banks. The agencies expect it to be most relevant to banking organizations with over $30 billion in total assets. Smaller banks are generally outside it, though it may still be relevant to those with significant model risk because of complex models or activities beyond traditional community banking.
- Older issuances are gone. The OCC’s April 17 release says it rescinded OCC Bulletin 2011-12, the 2021 BSA/AML model statement, OCC Bulletin 1997-24 on credit scoring models and the “Model Risk Management” booklet of the Comptroller’s Handbook.
What counts as a model
The guidance 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 such as spreadsheet calculations, and deterministic rule-based processes and software that have no statistical, economic or financial theory behind them.
That definition matters for product teams. A fraud rule that blocks any card transaction above a fixed amount in a new country is deterministic logic. A machine learning score that estimates the probability a transaction is fraudulent is a model.
Where AI models fit
Footnote 3 of the guidance draws the line. Generative AI and agentic AI models “are novel and rapidly evolving,” and “are not within the scope of this guidance.” The same footnote says the principles do apply to traditional statistical and quantitative models and to “non-generative, non-agentic AI models.”
In practice, that splits a bank’s AI portfolio in two:
- In scope: machine learning models that produce quantitative estimates, such as credit, fraud or loss forecasting models, judged by the definition above.
- Out of scope: large language model assistants and AI agents that take actions. The footnote does not leave them ungoverned: it says a bank’s risk management and governance practices should guide the controls for tools, processes or systems the document does not cover.
The OCC release adds that the three agencies plan to issue, in the near future, a request for information on model risk management that considers banks’ use of AI. Until that work produces something, teams shipping generative AI into banks are working from general governance expectations and other frameworks. Our guide to the NIST Generative AI Risk Profile covers one such framework, and our explainer on NYDFS AI cybersecurity guidance covers what New York’s regulator expects on the security side.
How model risk is sized
The guidance builds risk from four factors:
- Inherent risk: assumptions, complexity, input quality and data constraints.
- Exposure: how significant the output is to business decisions, often measurable by portfolio size.
- Purpose: models that help meet regulatory requirements or manage financial risk exposures are generally higher risk.
- Use: a sound model can still carry high risk if it is misapplied or misused.
Purpose and exposure together set a model’s materiality. A bank may treat some models as immaterial and limit its work to identifying them and watching for signs that they are becoming material. Higher-materiality models warrant more rigorous oversight. The guidance also asks banks to look at risk in aggregate, where several models share assumptions, data or methods.
What the lifecycle looks like
Development. Work starts with a clear statement of purpose. Testing can include out-of-sample and out-of-time tests, comparison with alternative methods and review of data quality, with rigor matched to complexity and materiality.
Use. Users need to understand a model’s limitations. Using a model beyond its intended purpose adds risk, so sound practice involves further analysis of the new use and a review of existing controls.
Validation. Validation generally comes before first use. When an urgent business need forces earlier use, the guidance points to closer attention to limitations, informing stakeholders and controls such as limits on use or closer monitoring. Validation covers conceptual soundness, where interpretability measures or benchmarking against other models may be more practical than theory for some models, and outcomes analysis, such as back-testing.
Monitoring. Ongoing monitoring checks whether the model still performs as expected as products, clients, data or markets change, with overlays, adjustment or redevelopment as possible responses.
Effective challenge. Throughout, the guidance expects critical review by people with the expertise, independence and standing to force changes.
Governance and vendor models
Banks are expected to have clear policies, defined roles that address conflicts of interest between development and validation, a model inventory detailed enough to support individual and aggregate risk management, and adequate documentation. Internal audit generally evaluates whether model risk management is effective rather than duplicating validation.
For vendors and other third parties, including suppliers of data, parameters or complete models, the principles still apply even when code or data is proprietary. The guidance expects banks to understand a vendor model’s conceptual soundness, design, development data and performance, to monitor whether it stays fit for purpose, and to document and evaluate any customization. A fintech selling a scoring model to a large bank should expect those questions.
This article explains supervisory guidance. It is not legal or compliance advice for any particular institution.
