OSFI E-23 takes effect May 1, 2027. It covers your AI models too.
OSFI Guideline E-23 comes into effect on May 1, 2027, following an eighteen-month transition period. It applies to all federally regulated financial institutions, including foreign bank and insurance company branches. And it applies to all models regardless of source or purpose. Internal or third party, both in scope.
What E-23 requires.
An enterprise-wide, risk-based model risk management governance framework, with policies and procedures governing each stage of the model lifecycle. Four components are named: data governance, sufficient resourcing and expertise, comprehensive documentation, and proportionality.
An enterprise-wide framework
E-23 requires a model risk management governance framework that runs enterprise-wide and is risk-based. Scope follows the risk a model carries, not the team that happens to own it.
Policies at every lifecycle stage
Policies and procedures have to govern each stage of the model lifecycle. Design, development, review, approval, deployment, ongoing use and retirement all sit inside the framework, not beside it.
Data governance
Named as a component of the framework. The data a model is built on and the data it runs on are inside model risk management, not adjacent to it.
Resourcing and expertise
Named as a component. Sufficient resourcing and expertise means the people reviewing and challenging models are equipped to do it, and that the framework is staffed rather than merely written.
Documentation
Comprehensive documentation is a named component. A control that is not written down cannot be shown to a reviewer, and an undocumented framework cannot be evidenced at all.
Proportionality
Named as a component. Controls scale with the risk a model carries. A low-risk model does not draw the same treatment as a high-risk one, and the framework has to be able to tell them apart.
What changed for AI and machine learning.
E-23 covers traditional and actuarial models alongside AI and machine learning models. The 2025 update added context and clarity specifically for AI and machine learning model risk management.
One framework, every model type
Traditional models, actuarial models, AI and machine learning models are all governed by the same framework. There is no separate AI regime to stand up, and no exemption for a model because it happens to be statistical rather than learned.
Principles-based and technology-agnostic
E-23 does not prohibit any modelling approach. Institutions may innovate provided risk management holds. The guideline sets expectations about how risk is governed, not about which techniques are permitted.
Harder than a ban, not easier
A prohibition is simple to answer. You either used the technique or you did not. A requirement to manage the risk puts the burden of proof on the institution instead. You have to show what the model was allowed to do, what controls were in place while it did it, and why the residual risk was acceptable. That is a heavier obligation, and it recurs for as long as the model is in use.
The third-party clause.
E-23 applies to all models regardless of source or purpose. Internal or third party, both in scope.
This is the most operationally consequential sentence in the guideline, and the one most often read past. An institution running a hosted model, a vendor-supplied scoring engine, or a third-party agent framework still owes E-23 evidence for that model. The obligation sits with the institution. It does not move to the vendor because the model was bought rather than built.
Which means a vendor's own assurances do not discharge it. An attestation, a security questionnaire, or a supplier's description of its own controls tells you something about the vendor. It does not tell your reviewers what that model did inside your institution, under your limits, on your data, on a given day.
So the third-party clause is a runtime problem before it is a paperwork problem. The record of what a bought-in model was authorized to do, what it actually did, and who signed off on each exception has to be produced from the environment the institution controls. That is the only place the institution can produce it from.
Where Reign fits.
Reign produces the operating record across the model lifecycle. Which limits applied at the moment of each action, what was authorized, what the outcome was, and who decided each exception.
The compliance and assurance assessment rests with the institution's risk officers, compliance professionals, auditors and advisers. Reign gives those experts the operating evidence their judgment draws on.
Reign is aligned to OSFI E-23. It is not certified against it, no product can be, and no product makes an institution compliant with it. OSFI does not endorse, approve or recommend Reign or iTmethods.
OSFI E-23 FAQ
Direct answers on the effective date, the population in scope, AI and machine learning coverage, third-party models, and what the framework has to contain.
When does OSFI E-23 take effect?
OSFI Guideline E-23 takes effect May 1, 2027, after an eighteen-month transition period.
Who does OSFI E-23 apply to?
OSFI E-23 applies to all federally regulated financial institutions, including foreign bank and insurance company branches.
Does E-23 cover AI and machine learning models?
Yes. The guideline covers all models regardless of the technology used, and was updated to add explicit context for AI and machine learning.
Does E-23 apply to third-party or vendor models?
Yes. It applies to all models regardless of source, internal or third party.
Does OSFI E-23 prohibit any modelling approach?
No. It is principles-based and technology-agnostic. It requires that risk be managed, not that particular methods be avoided.
What does E-23 require institutions to have in place?
An enterprise-wide, risk-based model risk management governance framework with policies covering each stage of the model lifecycle, including data governance, resourcing and expertise, documentation, and proportionality.
The date is fixed. The evidence is the work.
E-23 comes into effect May 1, 2027. The framework, the lifecycle policies and the documentation that supports them are built before that date, not after it. Start with a briefing on what the operating record has to contain, or with an assessment of the models already running in your environment.