What Is Model Risk Management (MRM)?

Model risk management (MRM) is the discipline of approving, controlling, and monitoring models as ongoing risk-bearing systems rather than as one-off analytical projects. It originated in banking, where a wrong model does not produce a wrong slide - it produces mispriced credit, understated capital, or a missed financial crime. MRM answers a specific set of questions about every model an organization relies on: who owns it, who independently challenged it, how material is it, how do we know it still works, and what happens when it stops working.

MRM matters far beyond banking now, because the thing being governed has changed. Organizations that used to run dozens of statistical models now run hundreds of models plus machine learning systems, and the regulatory ground has moved with them. In the United States, the Federal Reserve, OCC, and FDIC issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026, superseding the SR 11-7 guidance that had defined the field since 2011. In the United Kingdom, the PRA's SS1/23 has applied five model risk principles to all models informing business decisions since May 2024. Both push the same direction: proportionate, risk-based governance of models as a permanent operating discipline.

MRM Defined

Model risk is the potential for adverse consequences from decisions based on incorrect or misused model outputs. Note the two halves: a model can be wrong, and a model can be right and used wrongly. SR 26-2 makes this explicit - even a fundamentally sound model producing accurate outputs consistent with its design objective can carry high model risk if it is misapplied or misused. That is why MRM is a governance discipline and not a testing exercise. You cannot validate your way out of a model being pointed at the wrong decision.

MRM therefore covers the full arc of a model's working life:

• Identification and inventory - knowing which models exist, who owns each one, and what it is used for.
• Development and testing - sound design, documented assumptions, and testing proportionate to complexity.
• Independent validation - an objective assessment of whether the model performs as expected, and where its limits are.
• Ongoing monitoring - continuous evidence that performance has not degraded and that use has not drifted from intent.
• Governance and controls - policies, roles, and escalation paths that make all of the above repeatable.

The concept that ties them together in the supervisory guidance is effective challenge: critical analysis by objective experts with the expertise, independence, and organizational standing to actually force a change across the model lifecycle, from development through ongoing monitoring. A validation function that can write a finding but cannot make anyone act on it is not effective challenge.

What Counts as a Model

The scope question is where most MRM programs succeed or quietly fail, because an inventory that misses half the models governs nothing. SR 26-2 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 deliberately excludes simple arithmetic calculations such as those found in spreadsheets, along with deterministic rule-based processes.

Two boundaries are worth stating plainly, because both get argued about internally:

• A rule engine is not a model. Deterministic logic that always produces the same output for the same input has risks, but they are change-control and data-quality risks, not model risk. Governing it as a model dilutes attention.
• A vendor model is still your model. The UK's SS1/23 is explicit that its principles apply to models used to inform business decisions whether developed in-house or externally, including vendor models, and regardless of the technology used. Buying a model transfers the build, not the accountability.

The harder frontier is what to do with the systems that sit just outside the classical definition - large language models, retrieval pipelines, and agentic workflows. The answer in current guidance is unusually clear, and it is not the answer most vendors imply.

The Core Controls

Strip away jurisdictional differences and MRM comes down to four controls that reinforce each other. Miss one and the others degrade.

• The model inventory. A comprehensive record of models under development or in use, with owner, purpose, inputs, materiality, validation status, and dependencies. It is common industry practice precisely because nothing else in MRM works without it. The inventory is also where model risk becomes visible in aggregate - shared assumptions, shared data sources, and shared methodologies that could fail together.
• Documentation. Enough written record that a competent stranger can understand what the model does, what it assumes, and what it cannot do. Documentation is what makes continuity possible when the person who built the model leaves.
• Validation. An assessment of whether the model performs as expected, including its reliability and limitations, with rigor aligned to the model's approach, use, and materiality. Validation is not a one-time gate: performance deterioration over time is one of the things it exists to reveal.
• Ongoing monitoring. The mechanism that catches drift, changed conditions, and creeping misuse between validations, and that triggers adjustment, recalibration, or redevelopment when performance deviates meaningfully from expectations.

Materiality & Proportionality

The single most useful idea in modern MRM is that models are not governed equally. SR 26-2 frames this through model materiality, which combines two things: model exposure (how much is riding on it) and model purpose (what decision it drives). Models used to determine financial risk exposures are generally considered higher risk than models that are not. Together, exposure and purpose determine materiality, and materiality determines how much governance a model earns.

The practical consequences are worth spelling out, because this is where a program becomes affordable:

• Testing rigor is commensurate with complexity and materiality. For models with relatively less material impact, or in organizations with less complex operations, testing may legitimately be more limited in scope.
• Some models can be deemed immaterial. In those cases MRM may consist of identifying them and monitoring for the change in exposure or purpose that would pull them into scope. That is a defensible control, not a gap.
• Validation timing follows materiality too. The timing, nature, and frequency of validation activity flex with the model's approach, use, and materiality rather than following a fixed annual calendar for everything.

This is the same logic that AI risk tiering applies to AI use cases, and it is not a coincidence - AI tiering borrowed the idea from MRM. If your organization already runs an MRM materiality assessment, you have most of the machinery for tiering AI, and vice versa.

MRM vs AI Governance

This is the distinction that matters most in 2026, and it is easy to get backwards. MRM and AI governance are not competing frameworks, and neither is a rebrand of the other.

SR 26-2 draws the line explicitly: its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. Generative and agentic systems are outside what that guidance covers - though the guidance also notes that an organization's own risk management and governance practices should still guide how it controls tools and systems that fall outside the document. In other words, the newest US model risk guidance does not hand you a framework for your LLM assistant or your autonomous agent. It tells you those need governing, and leaves the framework to you.

That gap is what AI governance fills:

• MRM governs quantitative estimates. A credit scorecard, a pricing model, an AML detection model, a churn classifier. The questions are accuracy, stability, validation, and use.
• AI governance governs AI systems and their behavior. Generative outputs, tool use, autonomy, and the ways a system can be misused or manipulated. The questions add transparency, human oversight, guardrails, and societal impact. This is the territory of the EU AI Act, ISO 42001, and the NIST AI RMF.
• They overlap on the operating model. Inventory, ownership, tiering, approval gates, monitoring, and evidence are the same muscles. Running two disconnected programs duplicates the cost and produces two partial views of the same estate.

The regulators are converging on this too. The PRA held a model risk management roundtable on artificial intelligence and machine learning technologies in late 2025, examining how far SS1/23's principles stretch to cover AI and where they strain. The honest current answer is that classical MRM covers more AI than people assume and less than they need - which is exactly why AI lifecycle governance is emerging as the wrapper around both.

The Data Foundation

Read any MRM requirement closely and it resolves into a question about data. What inputs does this model consume? Are they the authoritative source? What does this field actually mean, and does it mean the same thing in the model as it does in the report the model is compared against? Where did the training data come from? Who owns it? What changed upstream last quarter, and did anyone tell the model owner?

SR 26-2 puts a critical assessment of data quality, relevance, and inputs squarely inside effective testing. SS1/23 covers data used in models as part of its principles. And validation cannot conclude anything about a model whose inputs it cannot trace. So the substrate of a credible MRM program is ordinary data governance:

• A data catalog that says which tables and features are authoritative, so model inputs are chosen deliberately rather than by whoever had access.
• A business glossary so that a term used in a model has one governed definition shared with finance, risk, and the regulator.
• Data lineage as the provenance record - the answer to "where did this input come from and what happened to it" that validation and audit both open with.
• Named data ownership and classification, so accountability for an input exists before a model depends on it and sensitive inputs are known.

Dawiso sits on this side of the boundary, and it is worth being precise about which side that is. Dawiso is not a model validation platform and does not replace a validation function or a model risk system of record. What it does is make the data-side evidence a by-product of normal work: the catalog of what exists and what is authoritative, the glossary of what each term means, interactive lineage for provenance and impact, and clear ownership across the estate. When a validator asks what fed a model and what it meant, that answer already exists instead of being reconstructed for the review. Paired with AI governance for the AI systems that MRM guidance leaves out, it covers the evidence half of both programs from one place.

Conclusion

Model risk management is what it looks like to treat models as infrastructure rather than deliverables: owned, inventoried, challenged by someone independent, validated in proportion to what rides on them, and monitored until they are retired. The 2026 revision of the US guidance sharpened two things worth carrying into any AI program - governance depth should follow materiality, not fairness of treatment, and generative and agentic AI are explicitly not covered by classical MRM, so they need an AI governance framework of their own. What both halves share is a dependency that no framework can supply for you: trustworthy, well-defined, traceable data underneath every model you are trying to defend.

Sources

• Board of Governors of the Federal Reserve System - SR 26-2: Revised Guidance on Model Risk Management (April 17, 2026)
• Board of Governors of the Federal Reserve System - SR 11-7: Guidance on Model Risk Management (April 4, 2011, superseded)
• Bank of England, Prudential Regulation Authority - SS1/23: Model risk management principles for banks
• Bank of England, Prudential Regulation Authority - Model risk management roundtable on AI and machine learning technologies (2025)