What model risk actually is

The intuitive definition is that model risk is the risk the model is inaccurate. That definition is wrong in a way that costs money, because it points every review at the one question the modellers have already spent months on. They know the accuracy. What nobody has examined is everything around it.

The supervisory definition is about consequences rather than correctness: model risk is the potential for adverse financial consequences arising from decisions made on the back of model output. Read that carefully and the surface area gets much larger than a performance metric. A model that is accurate on the population it was built for and is then pointed at a different population is a model risk event. A model whose number is correct but is read as a certainty when it was built as an estimate is a model risk event. The guidance is explicit that a fundamentally sound model producing accurate outputs consistent with its design objective can still exhibit high model risk, if it is misapplied or misused.

• Model. In the current guidance, a simplified representation of real-world relationships among observed characteristics, values and events. Deliberately broad: a spreadsheet with an assumption in it qualifies.
• Inherent risk. What the model is like before anyone uses it: its assumptions, its complexity, the quality of its inputs, the constraints in its data.
• Exposure. How much rides on the output. Bigger portfolio, bigger exposure.
• Purpose. What the output is for. A model used to meet a regulatory requirement or manage financial risk carries more weight than one that sizes a marketing list.
• Materiality. Purpose and exposure together. This is the dial that decides how much review a model earns.
• Effective challenge. Critical analysis by objective experts who can actually make the change happen. Session 2 is entirely about the last clause.
• Validation. The work of deciding whether the model performs as expected, what its limitations are, and whether the evidence offered actually supports the claim being made.
• Aggregate risk. What happens when twenty models lean on the same assumption, the same feed, or the same vendor. Each one looks fine alone.

Every institution that tries to validate everything to the same depth ends up validating nothing well, because the queue grows faster than the team. The guidance solves this by saying the rigour should be commensurate with the risk, and by giving materiality as the dial: a model may be judged immaterial on the basis of its exposure and purpose, in which case the sensible treatment is to record that it exists and watch for the conditions under which it would stop being immaterial.

That last clause is the part most registers get wrong. An immaterial model is not an unwatched one. The pricing sheet nobody validated because it only covered one product line becomes material the quarter that product line triples, and the trigger for a fresh look should have been written down when the model was first tiered, not improvised afterwards.

Model risk is assessed both for individual models and in aggregate, and the aggregate view asks a question no single validation can: what do these models share. Interactions and dependencies between them, reliance on common assumptions, a common data feed, a common methodology - any of these can move a whole portfolio of models in the same direction at the same time.

The practical version for a leader: ask what happens to the other models if the assumption in front of you turns out to be wrong. If the answer is "nothing, they are independent", ask who verified that. Shared inputs are the usual culprit, and they rarely appear in any individual model document.

The 2011 text said validation involves a degree of independence from development and use, and that it is generally done by staff who are not responsible for either and have no stake in the outcome. That sentence built a lot of org charts. The 2026 text says something different: that the quality of the validation process depends on the rigour and effectiveness of the review rather than on the organisational structure of the risk management function.

There is a real argument on both sides and it is worth having out loud rather than settling by preference. The case for the change is that separation was never sufficient: a separate team with no domain knowledge and no standing produces a document, not a challenge, and plenty of institutions have built exactly that. The case against is that structure is the only part of this that survives a change of personnel. Rigour depends on who is in the chair; a reporting line does not.

What the 2026 text does not do is remove independence from the definition of effective challenge, where it still sits alongside expertise and standing. The most defensible reading is that structure stopped being the test and did not stop being evidence. If your validators report to the head of modelling, you now have to demonstrate the rigour some other way, and the burden sits with you.

The 2026 guidance puts generative and agentic AI outside its scope explicitly, on the grounds that they are novel and rapidly evolving, while stating that its principles do apply to traditional statistical and quantitative models and to non-generative, non-agentic AI. It also says that a banking organisation's own risk management and governance practices should guide what controls apply to anything the document does not cover.

Read plainly, that is a gap with your name on it. The model risk regime will not tell you how to govern a large language model in a customer-facing process; the AI-specific regimes will, and learn-ai-governance-with-phoebe covers those - the EU AI Act tiers and obligations, the NIST AI Risk Management Framework, ISO/IEC 42001, and the MAS expectations for Singapore. The practical split is the one the guidance itself draws: model risk practice governs the statistical and non-generative models, and the AI-specific regimes pick up where it stops.