How do you build a model risk management framework?
By Nick Jang, founder of MINERVA Studio ·
The short answer
Build it in the order the decisions depend on each other: agree what counts as a model, write the policy and name who owns model risk, take an inventory, rate every model, then set development, validation, approval and monitoring standards whose depth follows the rating. Finish with reporting to senior management and the board, and a way to show it all works.
Start with the definition, not the policy
Most frameworks stall on a question that sounds trivial: is this thing a model? Answer it first, in writing, because every later step counts models. OSFI's E-23 uses a broad definition. If a method takes input data and turns it into an estimate using assumptions, statistics or a learned method, AI and machine learning included, it's a model. Spreadsheets qualify. So do vendor scores and AI agents.
Write down the edge cases you've decided, with the reasoning. "Deterministic calculators that apply a published formula are tools, not models" is a defensible line. Leaving it to each team isn't. Our four-question test is a reasonable starting point.
The build, in order
- Policy and ownership. One document, approved by senior management, that states the definition, the risk appetite for model risk, the roles (owner, developer, reviewer, approver) and the rules every model follows. Name the executive accountable for model risk.
- Inventory. List every model in use, in development and recently retired. E-23's Appendix 1 sets the fields: identifier, purpose, owner, developer, the rating, the dates of review and approval, limitations, and so on. Start with a template and fill what you know; a blank field is a finding you've found yourself, not a failure. See model inventory.
- Risk rating. Rate each model on what an error would cost and how likely one is: size of the exposure, the decisions it drives, complexity, autonomy, data quality. Pick three or four tiers. See model risk tiering, or try the free tier calculator.
- Development standards. What documentation a model needs before it goes anywhere: purpose, data, method, assumptions, testing, known limits. Scale it to the tier.
- Independent review (validation). Who reviews, how independent they must be from the developer, what they test, and how often. A high-tier model might get a full validation before use and every year; a low-tier one a lighter review on a longer cycle. See model validation.
- Approval. Who may approve use at each tier, and on what evidence. The approver shouldn't be the developer, and approval should wait for the review's findings.
- Deployment and monitoring. Controls on putting a model into production, then thresholds for performance and data drift with a named person who acts on a breach. See model monitoring.
- Exceptions and decommissioning. A dated, approved way to use a model past a missed review or outside its limits, and an orderly way to retire one that keeps its record.
- Reporting. What senior management and the board see, and how often: the inventory by tier, overdue reviews, open findings, exceptions, breaches.
Make the rating do the work
A framework that treats a staffing spreadsheet like a capital model will be ignored within a year. The fix is to let the tier decide the depth of every later step. Write it as a table and put it in the policy.
| Step | High tier | Medium tier | Low tier |
|---|---|---|---|
| Validation before first use | Full independent validation | Targeted review | Self-assessment checked by the second line |
| Periodic review | Every year | Every two years | Every three years |
| Monitoring | Monthly, with set thresholds | Quarterly | Annually |
| Approver | A senior committee | A named senior manager | The model owner's manager |
These cadences are an example, not OSFI's. E-23 expects proportionality and leaves the numbers to the institution's policy, which has to explain them.
Who does what
The usual split is three lines. The first line owns, builds and uses models. The second line, a model risk or validation function under the chief risk officer, sets the policy and challenges the first. Internal audit checks the whole system works. Small institutions often can't staff a separate validation team; E-23's proportionality allows using an independent person elsewhere in the organisation or an outside reviewer, as long as independence from the developer holds. See model risk governance.
How you'll know it works
A framework exists on paper long before it works. Three checks tell you which you have:
- Can you list every model and its tier in an hour? If producing the inventory is a project, it isn't being kept.
- For any model, can you show who built it, who reviewed it, who approved it, and that approval came after the review? This is where most frameworks break, because the evidence lives in email.
- When a monitoring threshold was breached last quarter, what happened, and who decided? No breaches at all usually means nobody is looking.
Where MINERVA fits
MINERVA holds the framework's record for Canadian banks and insurers: the inventory in E-23's fields, each model's tier and the cadence it sets, the owner, developer, reviewer and approver, findings and monitoring. It refuses an approval by the model's own developer or one missing the validation evidence its tier calls for. See the E-23 platform.
Related questions
What are the key components of a model risk management framework?
A definition of a model, a policy with named roles, an inventory, a risk rating, development standards, independent validation, approval, monitoring, exceptions and decommissioning, and reporting to senior management and the board.
How long does it take to build an MRM framework?
A first working version, with a policy, an inventory and ratings, often takes a few months. Getting every model through its first independent review takes longer and is usually phased by tier.
Do small banks need a full MRM framework?
They need one that fits their size. E-23 is proportional: fewer, simpler models can be governed with lighter processes, but every model still needs an owner, a rating and an independent look.
Who approves the model risk management policy?
Senior management approves it, and the board oversees model risk as part of the risk appetite. E-23 expects both to receive regular reporting.
Is an MRM framework the same as model governance?
Governance is the part that sets roles, policy and oversight. The framework also includes the operational steps: inventory, rating, validation, approval and monitoring.
Sources
- OSFI — Guideline E-23, Model Risk Management (2027)
- Federal Reserve — SR 26-2, Revised Guidance on Model Risk Management
- Bank of England PRA — SS1/23, Model risk management principles for banks
New answers are posted on MINERVA on LinkedIn. Follow along, or send the question you’d like answered next to minerva@minerva.studio.
A plain-language explanation, not legal advice. The regulator’s own text is the source; read it, and take advice on how it applies to your institution.