A plain-language guide Updated 25 October 2026

OSFI Guideline E‑23, explained.

What Canada’s banking regulator asks every federally regulated bank and insurer to show about its models, AI included, from 1 May 2027.

01 At a glance

What it is: OSFI’s principles-based guideline on enterprise-wide model risk management.
Published: 11 September 2025, as the final guideline.
In effect: 1 May 2027.
Applies to: Every federally regulated financial institution: banks, foreign bank branches, life, fraternal, property and casualty insurers, trust and loan companies, and foreign insurance branches.
How hard: In proportion to each institution’s size, strategy, risk profile and complexity, and to each model’s risk.
The source: Guideline E‑23: Model Risk Management (2027), on osfi-bsif.gc.ca

02 What counts as a model

Any application of theoretical, empirical or judgemental assumptions or statistical techniques, AI and machine learning included, that turns input data into results.

OSFI breaks a model into three parts: the data that goes in (with its assumptions), the processing that finds relationships in it, and the results presented for use. A spreadsheet that does this is a model; so is a vendor’s credit score and a large language model answering customers. Model risk is the chance of financial, operational or reputational harm from how a model is designed, built, deployed or used.

The guideline names six roles around every model: the owner, the developer, the reviewer, the approver, the user and other stakeholders.

03 The three outcomes OSFI expects

Model risk is well understood and managed across the enterprise.
Model risk is managed with a risk-based approach.
Model governance covers the entire model lifecycle.

04 The twelve principles

OSFI Guideline E-23 principles, in OSFI’s numbering
Principle	Area	What it asks, in plain words
1.1	Governance	Reporting structures and enough of the right people make model governance work.
1.2	Governance	The model risk framework ties risk-taking to the institution's strategy and risk appetite.
1.3	Governance	Every model is fit for the business purpose it serves.
2.1	Inventory	Every model in use, or recently decommissioned, is identified and tracked.
2.2	Rating	A risk rating approach assesses the key dimensions of each model's risk.
2.3	Proportionality	The scope, scale and intensity of model risk management match the risk a model brings.
3.1	Lifecycle	Policies, procedures and controls are robust, flexible and applied across the whole lifecycle.
3.2	Data	The data a model uses is suitable for its intended use.
3.3	Development	Development follows clear standards for performance and documentation.
3.4	Review	An independent process assesses each model's conceptual soundness and performance.
3.5	Deployment	Models run in an environment with quality and change controls.
3.6	Monitoring	Defined standards govern monitoring and decommissioning.

05 The model inventory

An enterprise-wide record of every model, vendor models included, kept accurate and current, with decommissioned models kept for a reasonable time.

Institutions identify models periodically, through surveys and triage across the business. Triage separates models with non-negligible risk, which get full lifecycle governance, from the rest. Appendix 1 of the guideline sets the fields:

For every model identified

Model ID
Name, and a description of its key features and use
Risk rating
Owner
Developer
Origin: built in-house or from a vendor

Also, for every model in the inventory

Version
Date deployed to production
Reviewer
Approver
Dependencies
Data sources
Approved uses
Limitations, including exceptions
Date of the most recent review
Monitoring status
Date of the next review

06 Risk rating, and why it drives everything

Every model gets a risk rating for its inherent risk, from clear, measurable criteria. The rating then sets how hard every other control works.

What goes into it: quantitative factors such as the importance of the portfolio and the possible operational, security or financial impact; qualitative factors such as business use, complexity or autonomy, data reliability, customer impact and regulatory risk. Vendor models are rated on their own.

What it decides: how often and how deeply a model is reviewed, how much documentation it needs, who may approve it, how closely it is monitored and when the rating itself is looked at again. Ratings are reviewed regularly and after trigger events such as a drop in performance or a material change in use, data or infrastructure. Where risk falls outside appetite, remediation is required.

07 The lifecycle, step by step

Rationale: The owner states the model's purpose, scope, coverage and outputs, the business use and its risk. For AI and machine learning, that includes transparency, explainability, bias, ethics and privacy, and other controls where a model is a black box or acts on its own.
Data: Data is accurate, relevant, representative, traceable and timely, with quality checks, controls over synthetic and proxy data, and bias managed.
Development: Standards cover documentation (set-up, limitations, data, assumptions, method), expert judgement, the developer's testing, how the method and the model were chosen, explainability, how outputs are used, and what will be monitored.
Independent review: Someone independent of development reviews the model, in-house or an objective third party, at an intensity set by its rating. The review can confirm or challenge the rating and ends with findings and a recommendation to the approver.
Approval: The approver decides whether the model is suitable for production or continued use and affirms its risk rating and residual risk. A model with known weaknesses can be approved with mitigants or a stated justification.
Deployment: Configuration, testing and readiness checks before production; documented change control, monitoring and exception handling, overlays included; cyber and operational risks assessed first.
Monitoring: Frequency, scope and criteria are set by rating and model type: performance, usage, inputs and dependencies are tracked against breach thresholds, with escalation and contingency plans, and AI-specific risks such as drift.
Decommissioning: Stakeholders are told, the model and its documentation are kept as a fallback, third-party issues are handled, and effects downstream are watched.

08 Governance, vendors and the board

Senior management defines roles and accountabilities across the enterprise, makes sure people have the skills (particularly for AI) and that model risk is reported to the board. The framework sits inside the institution’s wider risk framework, reflects its appetite for model risk and is reviewed periodically as technology changes. Reporting should show both inherent and residual risk.

Third-party and vendor models are in scope: identified, inventoried, rated and reviewed, down to their platforms, data and libraries, in line with OSFI’s Guideline B‑10 on third-party risk.

09 What to have on file before an examiner asks

A model risk framework and policy, tied to your risk appetite and approved by senior management.
The inventory in Appendix 1’s fields, vendor and AI models included, with recently decommissioned ones.
A rating for every model, the criteria behind it and when it was last reviewed.
For each model: who built it, who independently reviewed it, who approved it, and the evidence each relied on.
Monitoring results against stated thresholds, and what happened when one was breached.
Exceptions and limitations, with who granted them and until when.
Reports to senior management and the board on model risk.

10 Where MINERVA fits

MINERVA keeps the record E‑23 asks about: every model in the inventory’s own fields, its rating, owner, developer, independent reviewer and approver, its validation results, findings and monitoring. It refuses an approval by the model’s own developer, or one made without the validation evidence the rating calls for. And it prints the gap report, the board pack and an evidence packet an examiner can verify offline. MINERVA keeps the record; your institution and its examiners judge it. It issues no certification.

Talk to us about E‑23 See the plans

11 Questions people ask

When does OSFI Guideline E-23 take effect?

On 1 May 2027. OSFI published the final guideline on 11 September 2025.

Who does E-23 apply to?

Every federally regulated financial institution in Canada: banks, foreign bank branches, life insurance and fraternal companies, property and casualty insurers, and trust and loan companies, including foreign insurance company branches. It applies in proportion to each institution's size, risk profile and complexity.

Does E-23 cover AI and machine learning models?

Yes. OSFI's definition of a model expressly includes AI and machine learning methods, and the guideline asks for explainability, bias management, controls for black-box or autonomous models, and monitoring for drift.

What must a model inventory contain under E-23?

For every identified model: an ID, its name and description, risk rating, owner, developer and origin. For every inventoried model, also its version, deployment date, reviewer, approver, dependencies, data sources, approved uses, limitations and exceptions, last review date, monitoring status and next review date.

Are vendor and third-party models in scope?

Yes. Vendor and third-party models must be identified, inventoried and risk-rated on a standalone basis, and reviews cover third-party models, platforms and components such as data and libraries, in line with OSFI Guideline B-10.

Does model review have to be independent?

Yes. Review must be independent of development. It can be done by internal reviewers or an objective third party, at an intensity set by the model's risk rating.

This page summarises OSFI’s published guideline in plain words. It is not legal advice; for any decision, read the guideline itself.