OSFI E-23 Decoded: What Financial Services Actually Need to Do

OSFI's E-23 guideline dropped in November 2023, and if you work in risk, compliance, or technology at a Canadian bank, trust company, or insurer, you've been living with it since. The problem isn't that E-23 exists. The problem is that most institutions are still translating regulatory prose into operational reality.

I spent 20 years watching this pattern repeat itself. A new guideline arrives. Leadership asks what it means. Teams scramble to interpret "expectations" that read like philosophical statements rather than checklists. Six months later, you're in an audit room explaining why your AI governance framework is still "in development."

E-23 is different in one critical way: it's the first OSFI guideline that explicitly addresses artificial intelligence and machine learning. That means you can't borrow last year's template and swap the title. This one requires original thinking.

What E-23 Actually Says

The guideline is titled "Model Risk Management" but the scope is broader than traditional credit models or capital adequacy calculations. OSFI's definition of a model includes "any quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates."

Translation: if it uses data to make a decision, it's a model. Your fraud detection system. Your underwriting algorithm. Your customer segmentation tool. Your chatbot that routes service requests. All of them fall under E-23.

The guideline establishes three lines of defense and seven core principles. Let's skip the regulatory language and talk about what you're actually being asked to build.

The Seven Principles (In Plain Language)

1. Board and Senior Management Oversight

Your board needs to understand the risks AI introduces to the business. Not at a theoretical level. At a "what could go wrong and what would it cost us" level. That means board reporting that goes beyond "we use AI for efficiency." You need to show them where AI touches customer data, how decisions get made, and what failure modes exist.

Senior management isn't off the hook either. Accountability has to be assigned. Who owns AI risk? If the answer is "the Chief Data Officer and the Chief Risk Officer collaborate," you're already in trouble. One executive needs to be accountable. One person who gets fired if it goes wrong.

2. Model Development and Implementation

This is where most institutions trip up. E-23 expects documentation of your development process. Not just the final model card. The entire lifecycle. How did you choose this approach? What alternatives did you consider? What data sources are you using and how did you validate them? What are the model's limitations and where might it fail?

I've reviewed dozens of AI implementation plans that treat documentation as an afterthought. The model gets built, tested, deployed, and then someone scrambles to write up a justification document for the audit file. That doesn't satisfy E-23. The documentation should exist before deployment, not after.

3. Model Validation

Independent validation isn't optional. Your data science team cannot validate their own work. You need a second set of eyes—preferably someone with both technical skill and governance expertise—to review the model, test its assumptions, and challenge its outputs.

Validation has to answer three questions: Does the model work as intended? Are the results accurate across different scenarios? Could the model produce unintended outcomes?

That third question is what separates compliance from checkbox exercises. A credit model might accurately predict default rates but inadvertently discriminate against certain demographics. A fraud detection system might work beautifully in testing but flag legitimate transactions at scale. Validation should surface these risks before they become regulatory findings.

4. Model Use and Monitoring

Once a model is in production, ongoing monitoring is mandatory. E-23 expects institutions to track model performance, detect drift, and identify when a model's predictions start diverging from reality.

This is where operational rigor matters. You need thresholds. You need alerts. You need someone who reviews those alerts and escalates when performance degrades. "We monitor our models" is not the same as "we have documented thresholds, automated alerts, and a quarterly review process."

5. Model Risk Management Governance

Governance means policies, standards, and procedures that define how models are approved, deployed, and retired. E-23 expects a formal model inventory. Not a spreadsheet someone updates occasionally. A living system that tracks every model in production, its risk rating, its owner, its validation status, and its next review date.

Most institutions have this for credit risk models. Fewer have it for operational models. Almost none have it for AI systems deployed outside the risk function—marketing algorithms, customer service chatbots, procurement tools. E-23 expects you to govern all of them.

6. Third-Party Model Risk Management

Vendor-provided models and AI systems aren't exempt. If you're using a third-party fraud detection tool, a credit scoring platform, or an AI-powered underwriting system, you own the risk. E-23 makes that explicit.

That means due diligence before onboarding. It means ongoing monitoring after deployment. It means contract clauses that give you access to model documentation, validation reports, and change logs. If your vendor can't provide those, you have a problem.

7. Data Quality and Management

AI is only as good as the data it learns from. E-23 expects institutions to maintain data quality standards, validate data sources, and understand data lineage. If your AI model makes decisions based on incomplete, biased, or outdated data, the model itself doesn't matter.

This principle intersects with every other guideline OSFI has issued on data governance. You can't treat AI as a standalone problem. It's woven into data strategy, cybersecurity, operational resilience, and privacy compliance.

What This Means in Practice

Let's translate principles into projects. If you're building an E-23-compliant AI governance program from scratch, here's what you're actually building:

1. A model inventory system that tracks every AI model, its owner, its risk rating, and its review schedule.
2. A validation framework with independent reviewers, documented testing procedures, and approval workflows.
3. A monitoring infrastructure with automated performance tracking, drift detection, and escalation protocols.
4. Board reporting templates that communicate AI risks in business language, not technical jargon.
5. Vendor due diligence checklists that assess third-party AI systems before procurement and during renewals.
6. A policy suite covering model development, deployment, monitoring, and retirement.
7. Training programs for model developers, validators, and business owners who deploy AI systems.

Common Pitfalls (Based on Real Audit Findings)

Having sat through more AI-related audit discussions than I care to count, here's where institutions consistently stumble:

Treating AI as an IT problem. If your AI governance program lives entirely within the technology organization, you're missing the point. Model risk is a business risk. Risk management needs to own the framework. Technology builds the systems. Business units deploy them. But risk sets the standards.

Validation theater. I've seen validation reports that are glorified user acceptance testing. "We tested 100 transactions and the model was 98% accurate." That's not validation. That's spot-checking. Real validation digs into edge cases, stress scenarios, and failure modes. It challenges assumptions. It asks what happens when conditions change.

Documentation debt. Building the model first and documenting it later creates risk. When auditors ask why you chose this algorithm over that one, "it performed better in testing" isn't good enough. You need to show that you evaluated alternatives, understood the trade-offs, and made a documented decision.

Shadow AI. Business units deploying AI tools without involving risk or compliance is the fastest path to a regulatory finding. E-23 expects governance over all models, not just the ones the CRO knows about. That means awareness campaigns, procurement controls, and consequences for unsanctioned deployments.

Where to Start

If you're looking at E-23 and wondering where to begin, start with visibility. You can't govern what you don't know exists.

Run a model census. Inventory every AI system, every predictive algorithm, every decision-support tool in production. Ask three questions for each one: Who owns it? How critical is it? How much do we know about how it works?

The answers will tell you where the risk is concentrated. Some models will be well-documented, independently validated, and closely monitored. Others will be black boxes that someone deployed two years ago and nobody has touched since. Focus your early efforts on the high-risk, low-maturity quadrant.

Second, define what "good" looks like. E-23 gives you principles, not checklists. You need to translate those principles into standards. What does an acceptable validation report contain? How often do models get reviewed? What performance thresholds trigger escalation? Document your standards. Get them approved by senior management. Then hold everyone to them.

Third, build incrementally. You don't need to solve everything at once. Pick one high-impact model and take it through the full governance lifecycle. Document the process. Learn what works. Then scale that process across the organization. Progress beats perfection.

The Bottom Line

E-23 isn't a suggestion. It's not a best practice guide. It's a regulatory expectation that OSFI will test during examinations. The institutions that treat it seriously today will avoid painful findings tomorrow.

More importantly, E-23 compliance isn't just about avoiding regulatory risk. It's about building AI systems that actually work. The discipline of documentation, validation, and monitoring catches problems before they reach customers. It forces you to think through failure modes. It creates accountability.

The worst AI disasters I've witnessed in financial services weren't caused by bad technology. They were caused by governance failures. Models deployed without validation. Risks assumed without documentation. Decisions made without accountability. E-23 is designed to prevent exactly that.

If you're building an AI governance program from scratch or retrofitting one to meet E-23 standards, you're not alone. This is complex work that sits at the intersection of technology, risk, and regulatory compliance. But it's also work that protects your institution, your customers, and your career.

Start now. Document your progress. Show forward momentum. And when the examiners arrive, you'll be ready.