TL;DR
- What this is: a layer-by-layer read of RBI’s draft guidance on model risk management, mapped to its actual chapters and paragraphs, not a generic best-practices list.
- The five layers: governance, risk assessment and tiering, inventory and documentation, lifecycle management, and a layer built specifically for AI and machine learning models.
- What’s new: a 10-year retention rule for decommissioned models, explicit risk-based tiering, and a dedicated chapter on AI/ML explainability, bias assessment, and human oversight.
- Status check: this is draft guidance, issued June 24, 2026, with a comment period that closed July 24, 2026. It is not yet in force.
- Honest caveat: a framework built to this structure now is a framework you won’t have to rebuild once the draft is finalized. That’s a reason to start, not a reason to wait for the final text.
Most write-ups on model risk management frameworks describe governance, validation, and monitoring in general terms, the way any consulting deck might. RBI’s draft guidance on regulatory principles for model risk management, released June 24, 2026, is more specific than that. It sets out an actual chapter structure: governance, model risk management as a distinct discipline, model lifecycle management, and a dedicated chapter for AI and machine learning models. This piece walks through that structure layer by layer, with the paragraph references, so you can check your own framework against the document rather than against a paraphrase of it.

Model risk management tools and what each layer does covers the software side of this same problem, the technical stack that produces the evidence a framework like this one requires. This piece stays on the framework itself: what RBI’s draft guidance structures, chapter by chapter, and what each layer has to be able to show.
The draft guidance opens with its own vocabulary, and it’s worth fixing before going further. Chapter I defines a Model as any quantitative method or system used to process data into an estimate or decision, a Model Owner as the individual accountable for a specific model’s performance and compliance, and a Model Validator as the party responsible for independently assessing it. That last distinction, owner versus validator, is the one framework designers get wrong most often: the same person cannot hold both roles for the same model without collapsing the independence the rest of the framework depends on.
What a model risk management framework has to cover, under RBI’s draft guidance
A model risk management framework, under RBI’s draft guidance, has to cover five distinct layers: governance, risk assessment and tiering, inventory and documentation, full lifecycle management, and a dedicated layer of controls for AI and machine learning models. Each layer maps to its own chapter in the draft text, not an implied best practice.
That’s a more specific structure than “have a policy and a validation process.” Chapter II of the draft guidance sets out governance requirements at the board, committee, and senior management level. Chapter III treats model risk management as its own discipline, with risk-based tiering and a documentation standard that includes a 10-year retention requirement for models taken out of service. Chapter IV covers the full lifecycle, from selection through change management. Chapter V adds a set of requirements that apply specifically to AI and machine learning models, on top of everything the earlier chapters already require. A framework missing any one of these five is missing something the draft guidance names directly, not something a reviewer inferred.
The governance layer: board, committee, and senior management roles
The governance layer of a model risk management framework assigns specific responsibilities to three levels: the board approves the institution’s risk appetite and endorses the policy, the risk management committee reviews validation outcomes, and senior management implements the framework and maintains the model inventory day to day.
This is not a generic “leadership buy-in” requirement. RBI’s draft guidance names board-level oversight and risk appetite approval directly, alongside a risk management committee whose duties include reviewing validation outcomes, and senior management functions covering implementation, resource allocation, and inventory maintenance. A framework that has a validation process but no committee reviewing what validation finds has built the technical half of governance without the accountability half, which is exactly the gap a board-level review is meant to close.
The risk assessment and tiering layer: not every model needs the same scrutiny
The risk assessment and tiering layer of a model risk management framework classifies models by risk level so that the highest-risk models get the most scrutiny, rather than applying one uniform review standard to every model regardless of what it decides.
A model that scores a marketing email is not the same risk as a model that decides a credit line, and a framework that reviews both on the same cycle is spending scrutiny in the wrong place. RBI’s draft guidance builds risk-based tiering directly into the framework, alongside an enterprise risk assessment structured around three lines of defense and a documentation standard requiring a 10-year retention period for any model taken out of service. That retention requirement alone changes what “documentation” means in practice: a decommissioned model’s records have to survive a decade past the model’s own working life, well beyond how long most institutions currently keep that file open.
The tiering sits inside a broader enterprise risk assessment structured around three lines of defense: the business or model-owning unit that manages risk day to day, a risk management function that provides independent oversight, and an internal audit function that tests whether the first two are actually working. A tiering scheme with no independent second line reviewing it is a business unit grading its own homework, which is precisely the setup a three-lines structure exists to prevent.
The lifecycle management layer: from selection to change management

The lifecycle management layer of a model risk management framework covers a model’s full path from selection and development through independent validation, formal approval, deployment, ongoing monitoring, and a defined process for material changes, with each stage feeding evidence into the next rather than standing alone as a one-time check.
This is the layer where most of the actual work happens, and RBI’s draft guidance treats it as a sequence rather than a single checkpoint. Independent, pre- and post-deployment validation comes before a formal approval structure, which comes before deployment and monitoring, which feeds into a defined change management process once a material change crosses a set threshold. A framework that validates a model once at launch and calls the lifecycle complete has covered one stage out of five, and the draft guidance’s change management requirement exists specifically to catch what happens after that first validation, when a model gets retrained, retuned, or fed new data sources nobody re-validated against.
The layer built specifically for AI and machine learning models
Model risk management frameworks need a dedicated layer of controls for AI and machine learning models that goes beyond what a traditional statistical model requires: explainability thresholds, bias assessment, and human oversight mechanisms including override capability, with third-party AI models carrying an additional, enhanced oversight requirement of their own.
RBI’s draft guidance treats AI and machine learning models as a distinct category rather than folding them into the general model risk chapter, and adds requirements a traditional regression model was never built to satisfy: an explainability standard a reviewer can act on, a formal bias assessment step, red-teaming before deployment, and human-in-the-loop mechanisms with the ability to override a model’s output.
Deployment-specific controls sit alongside those requirements too, covering cyber safeguards and the disclosures a customer is owed when a decision was AI-driven. Third-party models get their own enhanced oversight requirement in the same section, since a model an institution didn’t build carries the same risk with less visibility into how it was validated in the first place. A framework that treats every model type identically is the one this chapter exists to correct.
If you’re not sure which of these five layers your current framework is missing, that’s usually the layer a regulator finds first. Book a working session with our data science team to map your framework against the draft guidance directly.

