OSFI Guideline E-23 (2027) — Model Risk Management
OSFI Guideline E-23 (2027) — Model Risk Management — is Canada’s federal regulatory expectations document for enterprise-wide model risk management at federally-regulated financial institutions (FRFIs). Issued by the Office of the Superintendent of Financial Institutions on September 11, 2025, with effective date May 1, 2027. The guideline is the Canadian regulatory anchor for AI/ML model governance and is the wiki’s federal-anchor citation for any Canadian-bank claim about model inventory, validation independence, and model lifecycle management.
E-23 (2027) replaces the earlier 2017 E-23 guideline (which covered model risk for deposit-taking institutions only) and substantially expands scope to all FRFI types AND to AI/ML models explicitly — including black-box approaches and autonomous decision-making systems.
What the “(2027)” Suffix Means
The guideline document is titled “Guideline E-23 — Model Risk Management (2027).” The “(2027)” refers to the effective date (May 1, 2027), not to a version year. Published 2025-09-11, the guideline gives FRFIs ~20 months of preparation runway before compliance becomes formal.
Effective-date posture
Findings tied to E-23 in any 2026 assessment are positioned as pre-emptive readiness, not current non-compliance. The runway is finite — banks operating well below E-23 expectations today have ~1 year (as of mid-2026) to close gaps. After May 1, 2027, gaps become formal supervisory concerns.
Why AI/ML Specifically
Section A of the guideline opens with a direct acknowledgment of the AI/ML drivers behind the 2025 revision:
“The financial services industry is experiencing a rapid rise in digitalization and model applications amplified by the surge in artificial intelligence / machine learning (AI/ML) models.”
OSFI’s identified AI-specific risk categories:
- Dynamic self-learning and autonomous decision-making models may become prevalent.
- “Rapidly progressing technologies, like AI, can exacerbate these risks and others.”
- “Black box” approaches and autonomous models require alternative controls.
- Potential for biased outcomes, negative social/ethical implications, and privacy risks.
- Autonomous re-parametrization and elevated drift potential in AI/ML systems.
This is the federal-anchor citation surface for the wiki’s claims about human-parity-line expectations, AI model drift, and rollback requirements for AI models in Canadian banks.
Structure
E-23 organizes around three primary outcomes (Sections B, C, D) plus a context preamble (Section A) and a model inventory schema (Appendix A).
Section B — Enterprise-Wide Model Risk Management
Three principles operationalize MRM as an enterprise function:
- B.1 / Principle 1.1 — Organizational Enablement. Senior management defines roles, accountabilities, and expectations for MRM across the enterprise; institution recruits MRM personnel with requisite skills, “particularly for novel technologies, like AI”; multi-disciplinary teams include legal/ethics professionals as appropriate; resources allocated optimally toward identified risks.
- B.2 / Principle 1.2 — MRM Framework. Framework reflects institution’s risk appetite for model risk; defines processes to identify, assess, manage, monitor, and report on model risk; includes guidelines for model identification, inventory, risk ratings, and lifecycle governance; covers external models (third-party vendors, foreign offices) per Guideline B-10; subject to periodic review as new technologies emerge.
- B.3 / Principle 1.3 — Use of Models. Models deployed only when they “meaningfully contribute to decision-making, risk assessment or business purposes” and deliver reliable outcomes; models no longer fit for purpose modified, replaced, or decommissioned.
Section C — Risk-Based Approach
Three principles operationalize risk-proportionate management intensity:
- C.1 / Principle 2.1 — Model Identification. Periodic enterprise-wide surveys identify new models and update status of existing ones; triaging process identifies non-negligible inherent model risk; provisional risk ratings assigned for new models, updated when materially changed; enterprise-level model inventory maintained with comprehensive key information (see Appendix A); inventory must be “accurate, evergreen, robust, timely, and inclusive of decommissioned models.”
- C.2 / Principle 2.2 — Model Risk Rating. Ratings assess inherent model risk reflecting vulnerabilities and materiality of impacts. Quantitative factors: portfolio size/growth, operational/security/financial impacts. Qualitative factors: business use, model complexity, autonomy, data reliability, customer impacts, regulatory risk. Each model assigned a rating; processes defined for temporary and confirmed ratings; ratings regularly reviewed when trigger events occur (performance decrease, material changes in use/data); negligible-risk category may exempt models from full lifecycle governance with robust approval tracking; external models assessed standalone.
- C.3 / Principle 2.3 — Risk Management Intensity. Risk rating drives frequency, intensity, and scope of model review; determines documentation requirements and approval authority level; establishes monitoring frequency, scope, and reassessment intervals; informs usage limits, safeguards, monitoring intensity, and mitigants; governance capabilities must match complexity levels (“e.g., extensive AI/ML requires mature oversight”).
Section D — Model Lifecycle Management
Six lifecycle stages with named expectations per stage:
| Stage | Key expectations |
|---|---|
| Design | Clear organizational rationale with well-defined purpose, scope, coverage, use case. For AI/ML: assess transparency/explainability, “black box” controls, bias/social/ethical/privacy risks. Data “accurate and fit-for-use … relevant and representative … compliant … traceable … timely.” Implement data quality checks, synthetic/proxy data controls, and data cleansing procedures. |
| Development | Clear, consistent, repeatable development processes with standardized documentation; document setup, running instructions, limitations, data provenance, assumptions, methodology; define expert judgment role and involvement; performance tests by developers; guidelines for methodology/data/algorithm selection and explainability requirements. |
| Review (Principle 3.4) | Independent from development; validates proper specification and fit-for-purpose status; triggered by new models, modifications, performance breaches, data changes, scheduled reviews; assess risk rating, purpose, soundness, limitations, data quality, novel methodologies; evaluate explainability per intended use; review third-party components; document assessments and report recommendation to model approver. |
| Approval | Two components: suitability for production based on intended use; affirmation of risk rating and residual risk. May approve despite weaknesses if compensating mitigants exist or justification provided. |
| Deployment (Principle 3.5) | Coordinate among developers, owners, reviewers, users, technology teams; ensure consistency between development and production datasets; conduct tests demonstrating expected operation in production; document deployment procedures, responsibilities, change control, monitoring, exception handling. Perform cybersecurity and infrastructure risk assessments (per Guidelines B-13 and E-21) — the explicit integration point between E-23 and B-13. Review explainability requirements and communicate to stakeholders. |
| Monitoring (Principle 3.6) | Define standards covering frequency, scope, evaluation criteria by risk rating and model type; quantitative measures (performance metrics) and qualitative assessments (scope compliance); track operational factors: performance, usage, input data, external dependencies, modeled characteristics; define breach thresholds and material modification criteria; for AI/ML: implement processes for autonomous decision-making, re-parametrization, drift detection; escalate issues promptly with contingency plans for unavailability or failure. |
| Decommission | Formal retirement process triggered by performance issues, business/regulatory changes, obsolescence; alert stakeholders; retain model/documentation as benchmark for set period; determine actions for third-party model decommissions; monitor downstream effects. |
Appendix A — Model Inventory Schema
OSFI prescribes a minimum inventory schema. The fields are split between universal (all models) and extended (non-negligible-risk models only):
Minimum fields (all models):
- Model ID
- Name and key feature description
- Risk rating
- Owner, developer, origin (internal/vendor)
Extended fields (non-negligible-risk models):
- Version, production deployment date, reviewer, approver
- Dependencies, data sources/description, approved uses, limitations/exceptions
- Most recent review date, monitoring status (with exceptions), next review date
This schema is the direct anchor for the wiki’s AI-BOM concept for Canadian FRFIs — an AI-BOM for a non-negligible-risk model must, at minimum, satisfy this schema.
Three Lines of Defense
E-23 establishes accountability layers without using the explicit “three-lines-of-defense” label:
| Line | Roles |
|---|---|
| First line | Model developers and owners (Design, Development stages) |
| Second line | Independent reviewers and approvers (Review, Approval stages) |
| Third line | Monitoring functions (Monitoring stage, internal audit) |
Senior management holds “an enterprise-wide view” supported by multi-disciplinary teams including legal, compliance, and ethics professionals.
Integration with OSFI B-13
The integration point is explicit and unidirectional. E-23 Section D Deployment (Principle 3.5) states:
“performance of risk assessments for related risks prior to deployment such as cybersecurity risk, infrastructure vulnerabilities, and other potential operational risks (see OSFI Guidelines B-13 and E-21).”
In practice: when an AI/ML model goes into production at a Canadian FRFI, the E-23 deployment expectation triggers a B-13-aligned technology and cyber risk assessment. The two guidelines are operationally a single governance chain.
Cross-References to Other Frameworks
E-23 is the Canadian peer to the US Federal Reserve’s SR 11-7 (Supervisory Guidance on Model Risk Management, 2011) and its OCC counterpart (OCC Bulletin 2011-12). The 2025 E-23 update materially expands beyond the SR 11-7 baseline by:
- Adding explicit AI/ML scope (SR 11-7 predates the AI era and has no AI-specific language)
- Adding monitoring requirements for autonomous re-parametrization and drift (AI/ML-specific)
- Expanding sector coverage beyond deposit-taking institutions to all FRFIs
- Tightening the inventory schema requirements (Appendix A)
Convergence with peer frameworks:
| Framework | Class | Relationship to E-23 |
|---|---|---|
| NIST AI RMF 1.0 | US voluntary framework | Convergent governance and lifecycle outcomes; E-23 is the Canadian regulatory expression. |
| NIST SP 800-218A | US federal AI-SSDF profile | Convergent AI development scope, especially training-data integrity and model-weight protection. |
| ISO/IEC 42001 | International AI management system standard | Convergent enterprise-wide AI management requirements; E-23 is regulator-issued and Canada-specific. |
| US SR 11-7 / OCC 2011-12 | US regulatory expectation | Pre-AI peer; E-23 (2027) is the AI-era Canadian successor. |
| EU AI Act | EU regulation | Risk-tiered approach broadly convergent; E-23 is sector-specific (FRFIs), EU AI Act is horizontal. |
In the CMM
E-23 maps onto the wiki’s CMM across multiple domains:
| CMM domain | E-23 anchor |
|---|---|
| D1 — Governance & Accountability | Section B (B.1, B.2, B.3) |
| D2 — Risk Management | Section C (C.1, C.2, C.3) |
| D4 — Threat Modeling & Adversarial Defense | Design stage (bias/social/ethical assessment); Monitoring (drift detection) |
| D5 — Data & Memory Governance | Design stage (data quality, provenance, synthetic/proxy data controls) |
| D6 — Supply Chain & Component Governance | Section B.2 (external models per B-10); Review stage (third-party components) |
| D7 — Observability & Anomaly Detection | Monitoring stage (Principle 3.6) |
| D9 — Incident Response & Recovery | Decommission stage (retirement triggers, downstream effects) |
How this fits the wiki
- Second dedicated Canadian-financial-regulatory framework page after B-13.
- Federal-anchor citation surface for the wiki’s AI/ML model-governance claims in Canadian banking. Replaces wiki-internal assertions with documented regulatory expectations.
- Direct anchor for the Canadian-bank assessor scorecard — every Section B question maps to an E-23 section or sub-principle identifier.
- Cross-walk to the wiki’s AI-BOM concept — Appendix A’s inventory schema is the regulatory backbone for the wiki’s AI-BOM treatment in a Canadian banking context.
See also
- Office of the Superintendent of Financial Institutions (Canada) — issuing organization
- OSFI Guideline B-13 — Technology and Cyber Risk Management — sibling OSFI guideline; integration point at E-23 Deployment
- Assessor’s Quick Scorecard — Secure-SDLC and AI Practices for a Large Canadian Bank — operational instrument anchored on E-23 (Section B questions)
- NIST AI RMF 1.0 — US peer voluntary framework
- NIST SP 800-218A — US federal AI-SSDF profile with convergent training-data and model-weight expectations
- AI Bill of Materials — wiki concept; Appendix A is the Canadian regulatory backbone
- Agentic AI Security CMM 2026 — wiki CMM citing E-23 in multiple domains