Model Risk Management for Banks: SR 11-7 to the EU AI Act

What model risk management means in practice

Model risk management is the set of policies, people and controls a bank uses to make sure the models it relies on do what they're supposed to do, and that someone can prove it. That's the whole job. It sounds simple until you count how many models a mid-sized bank actually runs: credit scoring, fraud detection, AML transaction monitoring, stress testing, pricing, collections prioritization, and increasingly, generative AI copilots drafting suspicious activity reports.

The Federal Reserve's SR 11-7 Model Risk Management guidance, issued jointly with the OCC in 2011, defines a model broadly: any "quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates." That definition was written before anyone at the Fed was thinking about transformer models, but it covers them without needing an amendment. A large language model summarizing a loan file is a model. A gradient-boosted fraud classifier is a model. A spreadsheet with an embedded regression that decides collections priority is a model too, and yes, examiners have cited banks for exactly that.

Ownership usually sits with a second-line model risk management (MRM) function that reports independently of the business lines building the models. First line builds and uses the model. Second line validates it, challenges its assumptions and can force it out of production. Third line, internal audit, checks that the first two are actually doing their jobs. If your bank has one team doing all three, that's not a governance gap you can paper over, it's the finding an examiner writes up first.

The scope is bigger than credit and market risk models, which is where the discipline started. Modern MRM programs at banks now cover model governance for AI used in KYC/AML, fraud, and increasingly, the AI agents banks are starting to deploy for investigation and case management. Each new use case brings the same three questions: what's the model's intended use, what data trained it, and who signs off when it's wrong.

Why it matters now

Two things changed the urgency here: regulatory scope expanded, and the models got harder to explain.

On the regulatory side, the EU AI Act (Regulation (EU) 2024/1689) entered into force in August 2024 and its high-risk provisions apply from August 2026. Article 6 and Annex III classify credit scoring, and in many cases fraud and AML systems, as high-risk AI. High-risk status means a documented risk management system, a registered technical file, human oversight measures and post-market monitoring, none of which is optional once a system is in scope. We cover the applicability question in detail in our guide on EU AI Act requirements, because getting the classification wrong in either direction, treating a high-risk system as exempt or over-scoping a low-risk tool, both create real cost.

In the US, SR 11-7 hasn't been rewritten, but examiners have made clear they're applying it to AI and machine learning models with the same rigor as the legacy statistical models it was written for. The Fed's 2021 interagency Request for Information on AI use in financial services signaled that examiners expect existing MRM frameworks to stretch to cover AI, not that AI gets a pass because it's new. The Bank for International Settlements has also weighed in: its Financial Stability Institute published a 2023 paper (BIS FSI Insights No. 63) on the specific model risk challenges AI introduces, including the difficulty of validating models that update themselves in production.

Then there's loss data. The 2023 collapse of a mid-sized US regional bank's stress testing failures, documented in the Fed's own post-mortem on Silicon Valley Bank, wasn't caused by AI, but it hardened examiner attention on any model whose assumptions go untested for too long. Supervisors have been explicit that model risk failures compound: a model wrong about one thing quietly stays wrong about it until someone checks.

Examiner focus right now concentrates on three things: whether the model inventory is complete, whether validation is genuinely independent, and whether the bank can produce evidence beyond a policy document that a human reviewed and can override a high-stakes automated decision. Banks that pass exams cleanly tend to have all three built into daily operations, not assembled the week before the exam.

How it works

At a mechanical level, model risk management runs through five stages, and skipping any one of them is what generates findings.

1. Inventory and tiering. Every model gets logged: what it does, who owns it, what data feeds it, and a risk tier based on the impact of it being wrong. A credit denial model is high tier. An internal report-formatting tool is low tier. Tiering determines how often validation happens and how much documentation is required.

2. Development documentation. The team that builds a model has to document its intended use, its limitations, the data it was trained on and any known weaknesses. This isn't a formality; it's what the validation team works from, and vague documentation is a common reason validation gets bounced back to development.

3. Independent validation. A team with no role in building or approving the model tests it against three questions: does it work as intended (conceptual soundness), does the implementation match the design, and does ongoing performance hold up against expectations. SR 11-7 calls this out explicitly as a control that can't be self-performed. Our Model Validation glossary entry breaks down what validators actually check.

4. Ongoing monitoring. Models don't stay accurate forever. Model drift, where a model's real-world performance degrades because the data it sees no longer resembles its training data, is the main reason annual validation cycles are increasingly seen as insufficient on their own. A fraud model trained on 2023 attack patterns is already stale against 2026 fraud tactics; the only question is how stale, and whether anyone's watching for it in real time.

5. Escalation and remediation. When a model fails a check, drifts past its threshold, or produces an outcome a human overrides, that event needs to go somewhere: a committee, a risk owner, a remediation plan with a deadline.

Here's how the stages map to typical control ownership:

Where banks fall down most often is the gap between stages four and five: monitoring catches a problem, but there's no defined path for what happens next, so the finding sits unresolved until an examiner or auditor finds it first.

Where programs fail

Four failure patterns show up again and again in exam findings and post-mortems, and none of them are exotic.

Incomplete inventory. This is the most cited finding, full stop. A model built by a data science team outside the formal MRM process, a vendor tool with an embedded scoring model nobody flagged as a model, a spreadsheet regression a business analyst built to speed up collections calls. If it's not in the inventory, it's not being validated, monitored or tiered, and an examiner who finds it asks the obvious question: what else isn't in there?

Validation that isn't actually independent. Some banks have a validation function that reports to the same business head as the model developers, or a validator who reviews their own past work under a different hat. SR 11-7 requires organizational independence, and examiners test for it by asking who the validator's manager is and who approved their headcount.

Undetected bias and unexplained decisions. Algorithmic bias in a credit or underwriting model is both a fairness problem and a model risk problem, because a biased model is, by definition, not doing what it was validated to do. Black-box models that can't produce a reason code for an individual decision put a bank in a difficult spot under both fair lending law and the EU AI Act's explainability requirements. Programs that skip explainability testing at validation time tend to discover the problem only after a regulator or a plaintiff's attorney does.

Governance that exists on paper but not in practice. A bank can have a beautifully written AI governance framework and still fail an exam, because examiners ask for evidence, not policy. Can you show me the validation report for this specific model. Can you show me who reviewed this specific override. Can you show me the drift alert from March and what happened after. If the answer requires someone to reconstruct events from memory or a scattered email thread, the program isn't operating the way its own policy says it does. This is usually where AI compliance tooling earns its budget: not by replacing judgment, but by making sure the evidence trail exists automatically instead of retroactively.

What good looks like

A model risk program that passes exams cleanly and, more importantly, actually catches problems before they become losses, has a specific operating shape.

A living inventory, not a spreadsheet updated once a year. Every model has an owner, a risk tier, a last-validation date and a next-due date, and the list is reconciled against what's actually running in production rather than what was formally approved.

Validation that's proportionate to risk. High-tier models get full independent validation annually and at every material change. Low-tier models get lighter-touch review. Nobody's burning validator hours on a low-stakes internal reporting tool while a customer-facing credit model waits eighteen months for its next check.

Drift thresholds set in advance, with an owner assigned before the alert fires. Waiting until a model visibly breaks to decide who's responsible is how a two-week fix becomes a two-month one.

Documented override history. Every time a human overrides a model's recommendation, that's data. It tells you where the model is weak, and it's exactly the evidence an examiner or auditor wants to see that a human is genuinely in the loop rather than nominally involved.

A published policy that matches daily practice, using our free model risk management policy template as a starting point rather than reinventing the structure. The template matters less than the discipline of keeping the live policy and the live practice in sync as models change.

Metrics worth tracking monthly: percentage of inventory with current validation, number of models past their validation due date, drift alerts triggered versus resolved within SLA, and override rate by model. None of these are exotic. All of them are the first things an examiner asks for, which is exactly why they're worth having ready before anyone asks.

How AI and automation change model risk management

Automation is real here, but it's narrower than most vendor pitches suggest. What actually gets automated: monitoring, not judgment.

Drift detection, backtesting cadence, threshold breach alerts, and evidence collection are the parts that scale well with automation. A system can watch a fraud model's precision curve daily and flag when it dips below a set band. It can re-run backtests on a schedule instead of waiting for a human to remember. It can assemble the audit trail (data lineage, approval history, performance logs) into one package instead of an analyst spending three days pulling it together before an exam.

What doesn't get automated: the sign-off. Someone with the authority to own the outcome has to decide whether a model goes into production, whether a drift alert is a false positive or a real problem, and whether a model gets retired. That's not a compliance nicety, it's how the OCC's guidance on third-party and model risk expects accountability to work: a named executive owns the model, not a dashboard.

Full decision explanations matter more here than in most AI applications. If a model rejects a loan application or flags a transaction as suspicious, the compliance team needs the specific factors that drove that output, beyond a bare confidence score. This is where champion challenger testing earns its place: you don't just deploy a new model and hope, you run it in parallel against the incumbent and compare real decisions before cutting over. That comparison itself needs a human to interpret, especially when the challenger disagrees with the champion on edge cases.

Where this gets interesting is in inventory management. Most model risk programs still track model inventory in a spreadsheet that's out of date by the time anyone reads it. An automated inventory that pulls directly from model registries and deployment logs catches shadow models, the ones a data science team built and quietly put into production without registering them. We've seen banks find twenty or thirty untracked models this way in a first pass. That's not an automation nice-to-have, it's a control gap closing.

One more distinction worth making: automation can prepare a decision faster, but it can't absorb the liability for a wrong one. If a regulator asks who approved a model with a known bias issue, "the system flagged it and nobody objected" is not an answer that holds up. Read our guide on AI model governance for chief data officers for how to structure that ownership so it survives an exam.

How to evaluate a solution

Most model risk tooling gets pitched on dashboards. Dashboards are the easy part. What's hard, and what you should actually be testing for, is whether the tool holds up under an exam rather than under a demo.

Start with a basic question: can this tool produce, without manual assembly, the exact artifact an examiner would ask for? Model inventory as of a specific date. Validation history for a specific model. Evidence that a specific alert was reviewed and by whom. If the answer involves someone exporting three reports and stitching them together in Excel, that's not audit-ready, that's audit-adjacent.

Second question: does it integrate with where your models actually live? A tool that only watches models deployed through its own pipeline is useless for the shadow models sitting in a data scientist's notebook that somehow made it into a decision system. Coverage of your actual model inventory matters more than feature breadth on the models it does track.

Here's a comparison framework we use with clients evaluating vendors:

Ask for a reference client in your specific regulatory environment. A vendor that's only ever sold to a startup lender will not have thought through what SR 11-7 validation documentation needs to look like for a Federal Reserve exam. If you're building a policy from scratch rather than buying one, our free AI governance policy template for financial services is a reasonable starting point, and it's a useful yardstick for what a vendor's tool should be capable of producing.

Pricing structure is worth probing too, though we won't dictate what you should pay. Ask whether the cost model scales with your model count in a way that discourages registering every model, because a pricing structure that penalizes complete inventory is a pricing structure working against the point of the tool.

Regulatory and standards references

Model risk management isn't a vague best-practice area. It's governed by specific, named regulatory guidance, and examiners will cite chapter and verse.

SR 11-7 (Federal Reserve, 2011), jointly issued with the OCC as OCC Bulletin 2011-12, is still the foundational US framework. It defines model risk, requires independent validation, and puts ownership on a named senior executive, not a committee. Every US bank model risk program traces back to this document, even fifteen years on.

The EU AI Act changes the picture for any institution operating in the EU or serving EU customers. Credit scoring and certain fraud detection use cases fall under high-risk classification. Article 6 sets out the specific requirements and penalties for high-risk AI systems, including mandatory conformity assessments before deployment and ongoing monitoring obligations after. If you're not sure whether your model falls into scope, run it through the EU AI Act applicability checker rather than guessing.

The OCC's third-party risk guidance (Bulletin 2021-19) matters for any bank using vendor-built models, which is most of them. A model you didn't build is still a model you own for regulatory purposes. Outsourcing the build doesn't outsource the accountability.

NIST's AI Risk Management Framework (NIST AI 100-1, 2023) isn't binding on financial institutions the way SR 11-7 is, but examiners increasingly reference it as a shared vocabulary for govern, map, measure, and manage functions. Worth knowing even where it's not mandatory.

The Basel Committee's principles for the sound management of operational risk touch model risk indirectly through operational resilience expectations, and international banks should track how their home regulator has localized Basel guidance.

None of these frameworks agree on terminology, and none of them are optional if they apply to you. A program built to satisfy SR 11-7 alone will have gaps against EU AI Act documentation requirements, and vice versa. Map your control set against every framework that applies to your footprint, beyond the one you know best.

Next steps

If your models are largely US-regulated, start with SR 11-7 validation documentation and make sure your inventory is complete before anything else. An incomplete inventory undermines every other control you build on top of it.

If you have EU exposure, run your credit and fraud models through the applicability checker now, not after an examiner asks. High-risk classification changes your deployment timeline.

For governance structure and who should own what, the chief data officer guide goes deeper into the org design question this pillar only touched on. And if you're evaluating vendors against the checklist above, the glossary entry on champion challenger testing is worth a closer read before your first vendor call.