Quick Take
- In April 2026, the Federal Reserve, OCC, and FDIC replaced SR 11-7 with SR 26-2, the first rewrite of US model risk guidance in 15 years.
- The core principles, development, validation, and governance, stayed the same. What changed is a shift toward risk-based tiering instead of one-size-fits-all rules.
- Generative and agentic AI models are explicitly left out of SR 26-2’s formal scope for now, which means institutions have to govern them on their own.
- Validating vendor or cross-institution AI models without direct access to the training data is one of the biggest practical gaps the guidance doesn’t solve.
Banks have used the same model risk playbook since 2011. That changed in April 2026, when the Federal Reserve, the OCC, and the FDIC issued SR 26-2, revised guidance that replaces SR 11-7 after fifteen years.
Model risk management is the discipline of identifying, measuring, and controlling the risk that a model produces wrong outputs or gets used in ways it wasn’t built for. For most of the last decade, that discipline has centered on three pillars: how a model is built, how it’s validated, and how it’s governed.
Those pillars haven’t disappeared. What’s changed is how strictly and uniformly they apply, and how the guidance treats the newest category of models: generative and agentic AI.
This article walks through what SR 11-7 originally required, what SR 26-2 changes, how machine learning and AI complicate model validation, and what to do when you can’t get direct access to the data a model was trained or tested on.
It’s written for risk, compliance, and AI governance teams who need a clear picture of where things stand.
What Is Model Risk Management?
Model risk management is the set of practices banks use to make sure a model does what it’s supposed to do, and that decisions based on its output don’t create problems down the line.
A central part of that work is model validation, the independent check that confirms a model performs as intended. In practice, model risk management covers everything from credit scoring models to fraud detection systems to the newer generation of AI tools banks are testing.
Why Model Risk Matters in Banking
Models sit behind decisions that used to require direct human judgment. Regulatory guidance is explicit that model risk can lead to financial loss, inaccurate financial reporting, and flawed decisions.
When a model is wrong, or right but misused, the damage doesn’t stay contained. A single mis-calibrated credit model can misprice risk across thousands of loans before anyone notices.
The Three Pillars: Development, Validation, Governance
Every version of the guidance, from 2011 to 2026, organizes model risk management around the same three areas.
● Development: how the model is built, including its assumptions, data, and testing before it goes live.
● Validation: independent review that checks whether the model actually works and stays reliable over time.
● Governance: the policies, inventory, and accountability structure that ties everything together.
These three pillars are the backbone the rest of this article refers back to.
What Actually Counts as a “Model” Under the Guidance
Not everything that runs a calculation is a model under this guidance. The regulation defines a model as a method that applies statistical, economic, or financial theory to turn input data into a quantitative estimate.
That excludes basic spreadsheets and simple rule-based systems with no underlying statistical theory. It matters because a machine learning tool that scores risk almost always falls inside this definition, while a static lookup table usually doesn’t.
What Did SR 11-7 Require?
SR 11-7 was issued jointly by the Federal Reserve and the OCC in April 2011. For fifteen years, it was the reference point nearly every bank built its model risk program around.
Model Development, Implementation, and Use
SR 11-7 expected banks to document why a model was built the way it was, test it before deployment, and understand its limitations well enough to avoid using it outside its intended purpose.
Development wasn’t treated as a purely technical step. The guidance placed real weight on the judgment behind a model’s design and the assumptions built into it.
Validation: Conceptual Soundness, Outcomes Analysis, Ongoing Monitoring
Validation under SR 11-7 rested on three techniques: checking whether the model’s design made logical sense (conceptual soundness), comparing model output to what actually happened (outcomes analysis), and watching performance over time (ongoing monitoring).
The guidance also introduced the idea of effective challenge: independent, technically competent people need the standing to question a model and force changes when something is off.
Governance, Policies, and Controls
On the governance side, SR 11-7 asked banks to keep a model inventory, assign clear roles, and separate the people who build a model from the people who validate it. That separation matters. Someone who spent months building a model isn’t the right person to judge it objectively.
Worth noting: Independent validation doesn’t have to mean a separate department. For smaller teams, it can mean a designated reviewer with real authority to send a model back for rework. The separation of responsibility matters more than the org chart.
How SR 11-7 Treated Vendor and Third-Party Models
SR 11-7 already recognized that banks don’t build every model themselves. It expected the same validation rigor for vendor and third-party models as for anything built in-house, even while acknowledging that banks often don’t get full access to a vendor’s underlying code or data.
That tension between validating fully and not being able to see inside the model existed well before AI made it worse. It’s a thread this article picks back up later.
Pro tip: If your bank uses a vendor model, ask for its validation reports, model certifications, and any relevant SOC reports upfront. Waiting until an exam to request them slows everything down.
What Changed: From SR 11-7 to SR 26-2
In April 2026, the Federal Reserve, OCC, and FDIC jointly issued SR 26-2, formally superseding SR 11-7 and SR 21-8 (the BSA/AML-specific model guidance from 2021).
A Risk-Based, Tiered Approach to Materiality
The biggest structural change is how SR 26-2 defines model risk magnitude. It breaks model risk down into four components: inherent risk, exposure, purpose, and use.
A model with low exposure and low business impact needs identification and monitoring. A model with high materiality needs the full weight of rigorous, ongoing oversight. SR 11-7 recognized this idea in principle. SR 26-2 makes it explicit and structured.
The $30 Billion Asset Threshold: Who’s In, Who’s Out
SR 26-2 is written to apply most directly to banking organizations with more than $30 billion in total assets. Institutions at or below that threshold typically rely on their own internal risk practices instead, unless their model use is unusually complex or extensive for their size. This is a real shift from SR 11-7, which didn’t draw an explicit asset line.
Effective Challenge Under the Revised Guidance
Effective challenge is still central, and SR 26-2 keeps the same definition SR 11-7 used. It still means critical analysis by objective experts who evaluate model risk and can effect change.
What Stayed the Same
It helps to be clear about what didn’t change. The three pillars are intact. Model inventories are still expected. Independent validation is still expected. Vendor models still need oversight. SR 26-2 is a recalibration of how much rigor applies where, not a replacement of the underlying philosophy.
Duality’s take: A risk-based framework is good news for validation teams stretched thin across hundreds of models, but it puts more weight on getting the materiality call right. If a model later contributes to a loss, the tiering decision will get scrutinized just as closely as the validation itself.
How Model Risk Management Applies to Machine Learning and AI Models
This is where SR 26-2 gets interesting, and where it leaves the most open questions.
Why Traditional Validation Struggles With Machine Learning
SR 11-7’s validation techniques were built for models with stable structure and parameters that don’t shift between review cycles. Machine learning models don’t always behave that way. A model that retrains on new data, or a vendor’s foundation model that updates quietly behind an API, can change its behavior without triggering a formal redevelopment event.
ValidMind, a model risk software company, has pointed to model drift and vendor opacity as two of the biggest gaps, noting that conceptual soundness checks and benchmarking still matter, but they weren’t designed to catch drift that happens silently between reviews.
The Generative and Agentic AI Carve-Out, and Why It’s Temporary
SR 26-2 explicitly excludes generative AI and agentic AI models from its formal scope, describing them as novel and rapidly evolving. That’s a notable choice. It means an LLM that drafts customer communications, or an agent that executes a multi-step workflow, currently sits outside the guidance that governs a traditional credit scoring model.
The agencies have signaled a forthcoming request for information specifically on AI and agentic model risk, so this carve-out looks like a placeholder rather than a permanent exemption.
Vendor and Foundation-Model Concentration Risk
Most banks don’t train their own foundation models. They consume them through a small number of vendors, which means a flaw or update in one provider’s model can ripple across some institutions at once. This is a different kind of risk than a single bank’s in-house model failing. It’s concentrated, harder to see coming, and largely sits outside any one institution’s direct control.
Quick check: If more than one critical process at your institution relies on the same foundation-model provider, that’s concentration risk hiding in plain sight. It’s worth mapping before an examiner does.
Governing What Falls Outside SR 26-2’s Scope
A generative or agentic system being outside SR 26-2’s formal scope doesn’t mean it’s ungoverned. It means the bank has to decide, on its own, what oversight looks like. Some institutions are filling that gap with frameworks like the NIST AI Risk Management Framework alongside their existing model risk program, rather than waiting for regulatory clarity that may still be a year or more away.
Heads up: SR 26-2 doesn’t just leave generative AI out of scope. It also rescinded SR 21-8, the 2021 guidance specific to BSA/AML models, folding those expectations back into the general risk-based framework instead of keeping a separate track for anti-money-laundering systems.
Validating Models You Can’t Fully See Into
Here is the practical problem that the guidance, in either version, doesn’t fully solve: how do you validate a model when you can’t see, move, or pool the data it was built or tested on?
Why Pooling Data for Validation Creates a New Risk
The instinct when validating a model trained on another organization’s data, or a partner bank’s data, is to request access to that data directly. That solves the validation problem and creates a new one. Centralizing sensitive data for the sake of testing a model introduces exactly the kind of exposure, compliance, and data sovereignty risk that regulated institutions are trying to avoid in the first place.
The Vendor Black-Box Problem
Vendor and foundation models make this harder still. A vendor rarely hands over its training data, and often won’t hand over the model’s internals either. Validators are left testing outputs without a clear view of what produced them, which is a weaker form of validation than the guidance was originally built around.
Privacy-Preserving Approaches to Model Validation
This is where privacy-enhancing technologies change what’s actually possible. Federated learning lets a model be trained or tested across multiple data sources without the raw data ever leaving its original location.
Secure multiparty computation lets several parties run a joint calculation, such as an outcomes analysis across pooled results, without any party seeing another’s underlying data.
Homomorphic encryption goes further, allowing computation directly on encrypted data, so a validator can run tests without ever decrypting the records involved.
For validators who need statistical assurance rather than raw access, differential privacy adds controlled noise so individual records can’t be reverse-engineered from aggregate results, and confidential computing protects data and computation while it’s actively being processed, using hardware-based secure environments.
Duality builds this kind of secure collaboration for exactly this problem. Instead of asking a vendor, a partner institution, or a regulator to hand over sensitive data before a model can be properly tested, Duality runs the evaluation inside a protected hardware environment. The validator gets the performance results, and the vendor and the bank don’t see each other’s model or data.
How This Plays Out in Practice
Picture a fraud detection model trained partly on data from several partner banks. None of them can legally or practically hand over their raw transaction data to a central validator.
With federated learning and secure computation, the model can still be tested against each institution’s data in place, and the results combined without anyone exposing their underlying records. The validation happens. Duality runs the evaluation inside a protected hardware environment, so the validator gets performance results without the vendor’s model or the bank’s data being exposed to the other party.
Building an AI-Ready Model Risk Management Program
Whether your institution falls squarely under SR 26-2 or is preparing for guidance that hasn’t landed yet, a few practical steps hold up regardless of where the rules end up.
Update the Model Inventory to Capture Shadow and Embedded AI
Many model inventories were built before AI got embedded into everyday software. A chatbot plugin, a summarization feature inside a case management tool, or a proof-of-concept that quietly made it to production can all slip past a manual registration process. Refreshing the model inventory specifically to catch embedded and shadow AI is worth doing before an examiner does it for you.
Tier by Materiality, Not Uniformly
SR 26-2 rewards institutions that can actually distinguish a low-materiality model from a high-materiality one, rather than applying the same checklist to everything. That takes real judgment about a model’s exposure and purpose, not just its mechanics.
Extend Monitoring Beyond Periodic Review Cycles
Periodic review made sense for models with stable behavior between check-ins. For models that adapt or retrain, monitoring needs to run closer to continuously, with clear thresholds for what counts as a material change that triggers full re-validation versus a minor one that doesn’t.
Assign Ownership for What’s Outside SR 26-2’s Formal Scope
Someone at the institution needs to own generative and agentic AI governance even though it sits outside the formal guidance. Leaving it unassigned because the regulation doesn’t cover it yet is the riskiest option on the table.
Our experts’ advice: Don’t wait for the AI-specific request for information to land before building internal governance for generative and agentic systems. By the time formal guidance arrives, institutions that already have a working internal framework will be adapting it. The ones without one will be building from scratch under supervisory pressure.
Where Model Risk Management Goes From Here
SR 26-2 doesn’t throw out fifteen years of model risk practice. It sharpens it, tying oversight more closely to actual risk instead of applying the same rules everywhere. The three pillars, development, validation, and governance, are still the foundation.
What’s genuinely new is the scale of the AI problem sitting on top of that foundation: models that change between review cycles, vendor systems nobody can fully inspect, and a generative AI carve-out that won’t last forever.
None of that gets solved by policy alone. Where you can’t access the data behind a model, whether it belongs to a vendor or a partner institution, the fix has to be technical. That’s exactly the gap privacy-enhancing technologies like federated learning and secure multiparty computation are built to close.
