OSFI Guideline E-23 · Model Risk Management
Less than a year remains before OSFI Guideline E-23 takes effect for federally regulated financial institutions. Its definition of a model explicitly includes AI and machine learning: predictive systems, generative AI applications, and vendor APIs among them. Governance has to become a practiced operating habit before it can become reliable evidence.
OSFI E-23 readiness: an evidence trail that verifies offline
Why now
E-23 is principles-based and proportional. It still expects each institution to know its model population, assess inherent risk, and govern accordingly.
01
An accurate model inventory, calibrated risk ratings, and tested review records cannot be produced on the day a guideline takes effect. They have to be practiced first.
02
E-23’s definition of a model includes artificial intelligence and machine learning methods. That places predictive systems, generative AI applications, and AI-enabled decision processes inside the model risk conversation.
03
Using a third-party AI service does not transfer accountability to the provider. E-23 brings vendor models into identification, the inventory, rating, review, and monitoring.
The crosswalk
Three outcomes, twelve principles. For each one: what the guideline expects, how PulseAI supports the work, and what remains your institution’s, stated plainly.
Principle
What E-23 expects
How PulseAI supports it
What remains yours
1.1
Organizational enablement
What E-23 expects
Defined reporting structures, accountable roles, suitable expertise, and enough resources, with model risk communicated to senior management and the board.
How PulseAI supports it
Every model record names its accountable owner, developer, reviewer, and approver, so role accountability is explicit and reviewable rather than tribal knowledge.
What remains yours
Reporting structures, staffing and expertise, and the board communication cadence remain organizational decisions.
1.2
Model risk management framework
What E-23 expects
A framework connecting model use to strategy and risk appetite, covering identification, rating, governance, monitoring, and reporting, including externally sourced models and data.
How PulseAI supports it
OSFI E-23 activates as a framework alongside the ones you already run, embedding its expectations into the AI Impact Assessment workflow with completeness checks on the relevant evidence questions.
What remains yours
The framework itself (policy, risk appetite, and scope decisions) is authored and owned by the institution.
1.3
Use of models
What E-23 expects
Models fit for their business purpose, producing outcomes reliable enough for the intended use, with a process to modify, replace, or retire models that no longer qualify.
How PulseAI supports it
Each record carries the approved use cases a model serves and its lifecycle dates: production deployment, last review, and when the next review is due.
What remains yours
Fitness-for-purpose judgment and the decision to modify, replace, or retire a model stay with the business.
Principle
What E-23 expects
How PulseAI supports it
What remains yours
2.1
Model identification
What E-23 expects
Identify and track models in use and recently decommissioned, including vendor and third-party models, with an accurate, current, controlled enterprise inventory holding the Appendix 1 information.
How PulseAI supports it
The Model Registry holds an Appendix 1-aligned record per model, Google Workspace discovery surfaces vendor AI employees have connected, and the compliance export produces an E-23 Model Inventory Appendix that names what is captured and what is still missing.
What remains yours
Whether a model carries non-negligible risk, and therefore belongs in the enterprise inventory, remains your institution’s judgment.
2.2
Model risk rating
What E-23 expects
An inherent risk rating per model based on measurable criteria, with externally developed models rated standalone for their impact on the institution rather than inheriting a vendor’s assessment.
How PulseAI supports it
Every risk rating records who assessed it, when, and the rationale. A rating with no assessment on file is labeled exactly that, so an unexamined tier is never mistaken for a reviewed one.
What remains yours
The rating criteria and the assessment itself are the institution’s: PulseAI records provenance, it does not assign ratings.
2.3
Risk management intensity
What E-23 expects
The risk rating drives the depth and frequency of documentation, review, approval, monitoring, and reassessment, with robust handling of any exemptions.
How PulseAI supports it
Completeness checks and next-review dates make it visible where the evidence depth behind a model does not yet match its rating.
What remains yours
Calibrating intensity to rating, and approving and tracking exemptions, is your framework’s call.
Principle
What E-23 expects
How PulseAI supports it
What remains yours
3.1
Policies, procedures, and controls
What E-23 expects
Documented controls that work across model types and risk levels, explicit responsibilities, early stakeholder involvement, and review activities that preserve independence.
How PulseAI supports it
A single governance record per model makes responsibilities and evidence explicit, giving policies something concrete to attach to.
What remains yours
The policies and procedures themselves, and preserving independence between development and review, are organizational controls.
3.2
Model data
What E-23 expects
Data suitable for the intended use: accurate, relevant, representative, traceable, and timely, with bias understood and lineage documented.
How PulseAI supports it
Each model record captures its data sources and documented limitations, and the assessment workflow asks for the data evidence E-23 expects.
What remains yours
Data quality management, bias controls, and lineage tooling operate in your data estate, not in PulseAI.
3.3
Model development
What E-23 expects
Consistent development standards for methods, performance, documentation, assumptions, limitations, and explainability appropriate to the model’s purpose and autonomy.
How PulseAI supports it
Records state where each model originated (internal or vendor), and the inventory appendix names documentation that is still missing instead of quietly omitting it.
What remains yours
Development standards and their enforcement live in your engineering and validation practice.
3.4
Model review
What E-23 expects
Review independent from development, assessing conceptual soundness, performance, data quality, limitations, and fitness, including relevant third-party platforms, components, and libraries.
How PulseAI supports it
Every record names its reviewer and carries last-review and next-review dates, so review coverage and currency are visible at inventory level.
What remains yours
Conducting the independent review, and acting on its findings, is the institution’s process.
3.5
Model deployment
What E-23 expects
Deployment through quality and change controls: production testing, documented responsibilities and approval paths, and monitoring defined before the model enters a business process.
How PulseAI supports it
The approver is named on the record and the production deployment date is tracked, anchoring the approval trail E-23 expects.
What remains yours
Change management, production testing, and deployment gates run in your delivery pipeline.
3.6
Model monitoring and decommissioning
What E-23 expects
Monitoring standards proportional to risk (frequency, metrics, thresholds, drift, escalation) and controlled, documented decommissioning with downstream checks.
How PulseAI supports it
Monitoring status lives on every model record, and health findings raise governance gaps: an active vendor model without a confirmed data processing agreement is flagged automatically.
What remains yours
Monitoring execution, thresholds, escalation, and decommissioning runbooks remain operational responsibilities.
Appendix 1
Appendix 1 is the most testable part of E-23: six attributes for every identified model and eleven more for models in the inventory. Each one below has a place on a PulseAI model record, and the compliance export says so when a value is missing instead of leaving the line out.
Six attributes OSFI expects for every model you identify, whatever its risk.
Appendix 1 field
Where it lives in PulseAI
When the export says it is missing
Model ID
Where it lives in PulseAI
A unique identifier PulseAI assigns when the model is registered.
When the export says it is missing
Always present on a registered model.
Model name and description of key features and use
Where it lives in PulseAI
The model name, its description, and a usage context that says how the model is used.
When the export says it is missing
The description reads as not captured when it is blank. Name and key features are reported as separate lines.
Model risk rating
Where it lives in PulseAI
The risk tier, with who assessed it, when, and the rationale.
When the export says it is missing
Always shown, and labeled "not assessed" when no assessment is on file or the tier has changed since the one on file.
Model owner
Where it lives in PulseAI
A named person in your organization, chosen from your user directory.
When the export says it is missing
Not captured until an owner is assigned.
Model developer
Where it lives in PulseAI
The team or vendor that built the model.
When the export says it is missing
Not captured until it is entered.
Model origin
Where it lives in PulseAI
Internal or vendor. Recorded separately from how the model is hosted, because a self-hosted third-party model is still a vendor model.
When the export says it is missing
Not captured until it is set. The hosting method is never used as a stand-in.
Eleven more attributes for models your institution has determined carry non-negligible risk. PulseAI does not make that determination, so a blank here is an open question for your framework, not a confirmed gap.
Appendix 1 field
Where it lives in PulseAI
When the export says it is missing
Model version
Where it lives in PulseAI
The version of the model in use.
When the export says it is missing
Not captured when blank.
Date of deployment into production
Where it lives in PulseAI
A production deployment date on the record.
When the export says it is missing
Not captured when blank or dated in the future. The date the record was created is never used as a stand-in.
Model reviewer
Where it lives in PulseAI
A named person, chosen from your user directory.
When the export says it is missing
Not captured until a reviewer is assigned.
Model approver
Where it lives in PulseAI
A named person, chosen from your user directory.
When the export says it is missing
Not captured until an approver is assigned.
Model dependencies
Where it lives in PulseAI
A list of the models, platforms, and components this model depends on.
When the export says it is missing
Not captured when the list is empty.
Data sources
Where it lives in PulseAI
A list of the data sources the model uses.
When the export says it is missing
Not captured when the list is empty.
Approved uses
Where it lives in PulseAI
The use cases linked to the model in your use-case inventory.
When the export says it is missing
Reads "None linked" when no use case is linked to the model.
Model limitations, including exceptions
Where it lives in PulseAI
A limitations entry on the record, separate from the usage context.
When the export says it is missing
Not captured when blank. A description of how the model is used does not count as a limitation.
Date of most recent review
Where it lives in PulseAI
A last-review date on the record.
When the export says it is missing
Not captured when blank or dated in the future.
Monitoring status
Where it lives in PulseAI
A monitoring status on the record, separate from the lifecycle stage.
When the export says it is missing
Not captured until it is set. The lifecycle stage is never used as a stand-in.
Next review date
Where it lives in PulseAI
A planned next-review date on the record.
When the export says it is missing
Not captured when blank.
Operating in Québec as well? The AMF’s guideline on the use of artificial intelligence takes effect the same day. See the AMF crosswalk →
Third-party models
Buying an AI service does not outsource accountability, and there is no lower standard for vendors that will not disclose enough information. Your institution needs documentation adequate to its own model risk needs, and a third-party review should consider feeder models and dependencies, not only the branded application at the top of the stack. For a high-risk AI arrangement, that translates into practical questions:
PulseAI applies the same discipline to vendor models: Google Workspace discovery brings connected AI tools into review, and an active vendor model without a confirmed data processing agreement is raised as a health finding.
The checklist
Start with the operating cycle, not the final report. Six practice areas; the full item set ships in the readiness kit.
01
You cannot govern models you have not identified.
+2 more in the kit
02
Every model needs named humans behind it.
+2 more in the kit
03
A rating should change what happens next.
+2 more in the kit
04
A process that has never run is not a process.
+2 more in the kit
05
Using a third-party AI service does not transfer accountability to the provider.
+3 more in the kit
06
Enter May 2027 with evidence your process has already produced.
+2 more in the kit
The readiness kit
The full principle-by-principle crosswalk and the complete transition-period checklist, in one document you can circulate to your model risk, compliance, and vendor teams. No form, no cookies. Take it.
Prefer a guided pass? Ask us to walk you through it.
Available now
framework
Switch on OSFI E-23 alongside the frameworks you already run. Its expectations plug into the AI Impact Assessment workflow with completeness checks, so readiness becomes everyday governance rather than a separate project.
inventory
Each model carries one governance record: owner, developer, reviewer, and approver; origin; production, last-review, and next-review dates; monitoring status; dependencies, data sources, limitations, and approved use cases.
provenance
Every risk rating records who assessed it, when, and why. A rating with no assessment on file is labeled exactly that, so an unexamined tier is never mistaken for a reviewed one.
gap reporting
The compliance export includes an OSFI E-23 Model Inventory Appendix: the Appendix 1 information you hold for each model, with anything not yet captured named explicitly instead of quietly omitted.
vendor discipline
A vendor API model cannot be activated until a data processing agreement is confirmed on its record, and an active vendor model found without one is raised as a health finding. Google Workspace discovery brings shadow AI into the same review process as approved tools.
evidence trail
Certified attestations, approved impact assessments, shadow-AI decisions, and weekly governance health reports are sealed into write-once storage as they happen, encrypted under your institution’s own key. Signed auditor bundles verify offline with standard tools.
See the Evidence Vault →
Press release · October 7, 2026
Model inventory, assessed risk ratings and write-once evidence for AI models, including vendor AI, less than seven months before E-23 takes effect.
Read the press releaseEarlier: August release notes →
What PulseAI does not do. PulseAI organizes the evidence and makes the gaps visible. Whether a model carries non-negligible risk remains your institution’s judgment, and an E-23 mapping or report is not a regulator’s approval or proof of compliance on its own.
Available now to PulseAI customers with the Canada jurisdiction · E-23 is an explicit administrator opt-in · Guideline text: OSFI Guideline E-23 (final) ↗
Get started
PulseAI is inviting a small number of Canadian financial-services organizations to become design partners and shape how E-23 readiness works in real operating environments.
No commitment required · partnerships@pulseai.now