The Short Version
Model risk management is the discipline of inventorying, validating, monitoring and governing the models that drive business decisions. On 17 April 2026, SR 26-2 replaced SR 11-7 as US banking guidance, with a narrower model definition, a materiality-based approach and an explicit footnote placing generative and agentic AI outside its scope. Your evidence still has to exist.
- Who it reaches: banking organizations over $30 billion in assets most directly, and their vendors indirectly.
- What changed: risk tiering by materiality, a narrower definition of “model”, and a stated non-enforceable tone.
- Generative AI: outside this guidance, but the letter tells banks to govern it under their own risk practices.
- Effort: an inventory, lineage from data to model, and monitoring tied to each model’s materiality.
The Federal Reserve’s SR 26-2 carries the title “Revised Guidance on Model Risk Management”. It supersedes SR 11-7, issued 4 April 2011, and SR 21-8, issued 9 April 2021. It was issued jointly with OCC Bulletin 2026-13 and FDIC FIL-15-2026, so the three federal banking agencies now share one text.
The guidance itself, in the SR 26-2 attachment, says it is “expected to be most relevant to banking organizations with over $30 billion in total assets.” Smaller banks are generally excluded, though the agencies say it may still be relevant to one with significant model risk exposure or activities beyond traditional community banking.
Most mid-market readers of this article are not $30 billion banks. You are more likely a lender under that line, a fintech, or a software and data vendor selling into banks. For you, SR 26-2 arrives indirectly: as a questionnaire from a bank’s model risk team asking how your model was built, validated and monitored. The rest of this article is about answering that questionnaire with evidence instead of prose.
What Did SR 26-2 Change From SR 11-7?
The agencies describe the revision as an effort to clarify model risk management principles and to set a risk-based approach tailored to each organization’s model risk profile, size and complexity. Five changes in the attachment matter to anyone building or selling models.
| Topic | What SR 26-2 says | What it means for your evidence |
|---|---|---|
| Who it targets | Most relevant above $30 billion in total assets; generally excludes smaller banks | Large-bank customers will ask for evidence; smaller ones may ask for less |
| Definition of model | A complex quantitative method applying statistical, economic or financial theories; excludes simple spreadsheet arithmetic and deterministic rule-based processes | Classify each asset as model or non-model, and record why |
| Materiality | Model purpose plus model exposure determines materiality; immaterial models may only need identification and performance monitoring | Tier the inventory, then size validation and monitoring to the tier |
| Enforceability | Does not set enforceable standards; non-compliance will not result in supervisory criticism, though unsafe practices can still draw action | Expect fewer checkbox demands and more questions about judgment |
| Generative and agentic AI | Footnote 3: not within the scope of this guidance; governance for uncovered tools follows the bank’s own practices | Expect a separate, bank-specific control set for generative AI |
What did not change is the core lifecycle. Effective challenge, by experts with the independence and standing to force change, is still there. So are validation before first use, conceptual soundness review, outcomes analysis, ongoing monitoring, a model inventory and documentation. Vendor models are still covered: the attachment says the principles of model risk management “remain applicable” even when the vendor will not share code or data.
Does SR 26-2 Cover Generative AI?
No, and this is where a lot of online commentary goes wrong in both directions. Some summaries say the letter quietly covers everything. Others say generative AI is simply exempt from oversight. Neither reading matches the text.
Footnote 3 of the attachment reads: “Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance.” The same footnote continues that a bank’s own risk management and governance practices “should guide the determination of appropriate governance and controls” for tools the document does not cover, and that its principles apply to traditional statistical and quantitative models and “non-generative, non-agentic AI models.”
So a gradient-boosted credit model or a fraud classifier is squarely in scope. A large language model summarizing loan files is outside this guidance but not outside governance. A bank still has to decide how it controls that system, and its vendors should expect to be asked. The agencies have not told anyone to stop governing generative AI. They have declined to write the rules for it in this document.
For the generative side, many teams borrow structure from the voluntary NIST AI Risk Management Framework and its Generative AI Profile. Our AI governance framework shows how those controls sit on the same lakehouse evidence base as the rest of your models.
What Should a Model Inventory Contain Now?
The attachment calls a comprehensive inventory “common industry practice” and asks that it hold enough information to understand model risk at the individual and aggregate level. Aggregate is the word to notice. The guidance asks banks to consider interactions among models, including reliance on common assumptions, data or methods. You can only see that if the inventory knows which data each model consumed.
A workable inventory record carries: the model’s purpose and business owner, its classification as model or non-model with the reason, its materiality tier, its training and evaluation datasets, its version history, its validation status and date, its known limitations, and its monitoring thresholds. For a vendor, add which customer deployments run which version.
How Does a Lakehouse Produce Model Risk Evidence?
Model risk programs usually fail on evidence, not on policy. The policy says lineage is documented. The lineage lives in a Word file written at go-live and never touched again. A lakehouse fixes that by making the evidence a by-product of how models are built.
On Databricks, Models in Unity Catalog provides centralized access control, auditing, lineage and model discovery across workspaces, with versions, aliases and tags. When you train on a Unity Catalog table and log the input with MLflow, the model version records the upstream datasets it was trained and evaluated on. Separately, Unity Catalog lineage is captured automatically for queries, down to the column level, with gaps for column-level lineage through UDFs and path-referenced tables.
Put together, that gives you a chain a validator can walk: source system, bronze, silver, gold training table, model version, alias in production. Tag each registered model with its materiality tier and owner, and the inventory becomes a query rather than a spreadsheet. Store validation reports and monitoring results as governed tables keyed to model version, and the evidence of ongoing monitoring exists without anyone compiling it. Our data lineage guide covers where the automatic capture stops and what to document by hand.
What Warning Signs Say Fix the Model Process Before You Add AI?
New tooling layered on a broken process gives you faster, better-documented defects. These red flags compound, so they are listed in the order they usually cause damage. If you see the first two, stop and fix them before any AI model goes near production.
- Nobody can list the models in production. Without an inventory there is no materiality tiering, and without tiering every validation is either overdone or skipped.
- Training data cannot be reproduced. If the dataset behind a model version was a one-off extract to a laptop, conceptual soundness cannot be reviewed and outcomes cannot be explained.
- The developer is also the validator. The guidance names misaligned incentives between development and validation as a conflict to manage. Effective challenge needs someone with the standing to say no.
- Monitoring thresholds were never written down. Without an agreed performance range, drift is noticed by a customer or an examiner, not by you.
- Generative AI pilots sit outside every control. Being outside SR 26-2 does not mean being outside governance. Pilots without owners, logs or a risk decision are how projects stall later, a pattern we unpack in why AI pilots fail.
- Vendor models are accepted on the vendor’s word. The guidance expects banks to understand conceptual soundness, development data and performance of vendor products, and to monitor outcomes themselves.
The fix is the same each time, and it is a process fix before a platform fix: define the measure, collect a baseline, then automate. That is the Lean Six Sigma habit applied to model governance.
This article is general information, not legal advice; your counsel, model risk function or a qualified assessor makes the call on how this guidance applies to you. If you build or sell models into banks and need the inventory, lineage and monitoring evidence built on a lakehouse, see our work for financial services teams.
Frequently Asked Questions (FAQs)
Is SR 11-7 still in effect?
No. SR 26-2, dated 17 April 2026, supersedes SR 11-7 and SR 21-8. The OCC and FDIC issued matching guidance alongside it as OCC Bulletin 2026-13 and FDIC FIL-15-2026.
Does SR 26-2 apply to banks under $30 billion in assets?
The guidance says it is expected to be most relevant above $30 billion and that excluding smaller banks is generally consistent with tailored supervision. It adds that it may still be relevant to a smaller bank with significant model risk exposure or activities beyond traditional community banking.
Are generative AI models exempt from model risk management?
They are outside the scope of SR 26-2, per footnote 3 of its attachment, but not exempt from governance. The same footnote says a bank’s own risk management and governance practices should determine the controls for tools the guidance does not cover.
We are a fintech, not a bank. Does this affect us?
Usually indirectly. SR 26-2 is supervisory guidance for banking organizations, not a rule that binds every company. A bank customer that follows it will still apply its principles to vendor models, so expect questions on validation, data provenance and monitoring.
What is the minimum evidence for a material model?
An inventory entry with owner, purpose and tier; reproducible training data with lineage to the model version; a validation record covering conceptual soundness and outcomes analysis; and monitoring results against written thresholds. Size the depth of each to the model’s materiality.