What is model risk management?
A regulator asks who signed off on the model behind a lending decision. If the answer is a prompt nobody reviewed, the model itself is now the finding.
Model risk management
MRMSR 11-7
Model risk management (MRM) is the discipline of overseeing any model whose output feeds a decision. It covers who built the model, who checked it, how it gets watched after launch, and who owns it when something goes wrong. US banking regulators set this out in guidance known as SR 11-7.
SR 11-7 is joint guidance from the Federal Reserve and the Office of the Comptroller of the Currency, issued in 2011. It defines a model broadly: any method that turns data into a number used for a decision. Credit scoring, fraud checks and stress testing all count. So does a language model that scores a loan application or drafts a compliance memo.
The guidance rests on one idea. Every model is wrong sometimes, and the real danger is not the error rate. The danger is using a model beyond what it was built for, or trusting it past the point anyone checked. MRM is the set of controls that catches that early.
The three lines of defense
SR 11-7 splits ownership into three lines. The team that builds and uses the model owns it day to day. A separate validation team checks the model's assumptions and tests it against data the builders never touched. Internal audit checks that the first two lines did their jobs.
The separation is the point. A developer grading their own model is not validation, even if the number is honest. Independent review exists because the person who built something is rarely the one who spots where it breaks.
Banks now face the same question about the LLMs they are adding. Think of a chatbot answering account queries, or an agent drafting a suspicious-activity report. Regulators have not carved out an AI exception. If the output shapes a decision about a customer, MRM's usual questions apply. Someone owns it. A separate person checked it. Drift gets caught after launch, not ignored.
- 01First line: the team that built and runs the model, accountable for its use.
- 02Second line: independent validation, testing assumptions the builders did not check.
- 03Third line: audit, confirming the first two lines did their jobs on schedule.
- InventoryEvery model in use, logged with its owner.
- ValidateIndependent team tests before deployment.
- DeployDocumented scope: what the model may decide.
- MonitorPerformance tracked against a baseline.
- Re-validateTriggered by drift, not just a calendar date.
Skip inventory and nothing downstream has an owner to report to.
Common questions
01Does SR 11-7 apply to LLMs?
Yes, if the output feeds a decision about a customer or a regulatory filing. SR 11-7 defines a model by function, not by algorithm. A language model scoring risk or drafting a compliance document falls under the same guidance as a statistical credit model.
02Does MRM only apply to banks?
SR 11-7 is written for the banks and holding companies the Federal Reserve and OCC oversee. Insurers, fintechs and other lenders often follow the same rules by choice, or because a bank partner asks them to.
03What's the difference between validation and evals?
Evals are automated tests that score a model's output against known cases. Validation is the layer of oversight around that: a separate team, a written scope, and a record of who approved the result. A model can pass every eval and still fail validation if nobody independent reviewed it.
04How often does a model need re-validation?
SR 11-7 does not set a fixed calendar. It expects re-validation when the model's performance drifts, its inputs change, or its use case expands beyond what was originally approved. A model swapped out by a vendor without notice is a trigger even if nobody flagged it.
