PulseAI
OSFI E-23 Readiness Kit
Model Risk Management crosswalk and transition-period checklist for federally regulated financial institutions.
Section 1
The E-23 crosswalk
OSFI Guideline E-23 is organized around three outcomes and twelve principles, and its definition of a model explicitly includes AI and machine learning methods. For each principle: what the guideline expects, how PulseAI supports the work, and what remains your institution’s, stated plainly.
Outcome 1Model risk is understood and managed across the enterprise
| Principle | What E-23 expects | How PulseAI supports it | What remains yours |
|---|---|---|---|
| 1.1Organizational enablement | Defined reporting structures, accountable roles, suitable expertise, and enough resources, with model risk communicated to senior management and the board. | Every model record names its accountable owner, developer, reviewer, and approver, so role accountability is explicit and reviewable rather than tribal knowledge. | Reporting structures, staffing and expertise, and the board communication cadence remain organizational decisions. |
| 1.2Model risk management framework | A framework connecting model use to strategy and risk appetite, covering identification, rating, governance, monitoring, and reporting, including externally sourced models and data. | 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. | The framework itself (policy, risk appetite, and scope decisions) is authored and owned by the institution. |
| 1.3Use of models | 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. | 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. | Fitness-for-purpose judgment and the decision to modify, replace, or retire a model stay with the business. |
Outcome 2Model risk is managed using a risk-based approach
| Principle | What E-23 expects | How PulseAI supports it | What remains yours |
|---|---|---|---|
| 2.1Model identification | 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. | 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. | Whether a model carries non-negligible risk, and therefore belongs in the enterprise inventory, remains your institution’s judgment. |
| 2.2Model risk rating | 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. | 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. | The rating criteria and the assessment itself are the institution’s: PulseAI records provenance, it does not assign ratings. |
| 2.3Risk management intensity | The risk rating drives the depth and frequency of documentation, review, approval, monitoring, and reassessment, with robust handling of any exemptions. | Completeness checks and next-review dates make it visible where the evidence depth behind a model does not yet match its rating. | Calibrating intensity to rating, and approving and tracking exemptions, is your framework’s call. |
Outcome 3Governance covers the full model lifecycle
| Principle | What E-23 expects | How PulseAI supports it | What remains yours |
|---|---|---|---|
| 3.1Policies, procedures, and controls | Documented controls that work across model types and risk levels, explicit responsibilities, early stakeholder involvement, and review activities that preserve independence. | A single governance record per model makes responsibilities and evidence explicit, giving policies something concrete to attach to. | The policies and procedures themselves, and preserving independence between development and review, are organizational controls. |
| 3.2Model data | Data suitable for the intended use: accurate, relevant, representative, traceable, and timely, with bias understood and lineage documented. | Each model record captures its data sources and documented limitations, and the assessment workflow asks for the data evidence E-23 expects. | Data quality management, bias controls, and lineage tooling operate in your data estate, not in PulseAI. |
| 3.3Model development | Consistent development standards for methods, performance, documentation, assumptions, limitations, and explainability appropriate to the model’s purpose and autonomy. | Records state where each model originated (internal or vendor), and the inventory appendix names documentation that is still missing instead of quietly omitting it. | Development standards and their enforcement live in your engineering and validation practice. |
| 3.4Model review | Review independent from development, assessing conceptual soundness, performance, data quality, limitations, and fitness, including relevant third-party platforms, components, and libraries. | Every record names its reviewer and carries last-review and next-review dates, so review coverage and currency are visible at inventory level. | Conducting the independent review, and acting on its findings, is the institution’s process. |
| 3.5Model deployment | Deployment through quality and change controls: production testing, documented responsibilities and approval paths, and monitoring defined before the model enters a business process. | The approver is named on the record and the production deployment date is tracked, anchoring the approval trail E-23 expects. | Change management, production testing, and deployment gates run in your delivery pipeline. |
| 3.6Model monitoring and decommissioning | Monitoring standards proportional to risk (frequency, metrics, thresholds, drift, escalation) and controlled, documented decommissioning with downstream checks. | 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. | Monitoring execution, thresholds, escalation, and decommissioning runbooks remain operational responsibilities. |
Section 2
The transition-period checklist
What to practice before May 2027: the goal is to enter the in-force date with a process that has already produced evidence, exposed gaps, and improved through use.
1. Build the inventory
You cannot govern models you have not identified.
- Identify internally developed, vendor, embedded, and recently decommissioned models, including AI and ML systems.
- Record the Appendix 1 information you hold for each model, and mark missing information honestly.
- Bring discovered and shadow AI tools into the same review process as approved ones.
- Confirm the inventory has an owner and a process that keeps it current, not an annual snapshot.
2. Assign accountability
Every model needs named humans behind it.
- Name the accountable owner, developer, reviewer, and approver for each model.
- Confirm each role understands the decisions it makes and the evidence it must produce.
- Close out models with no current owner: orphaned models are unmanaged risk.
- Establish how model risk reaches senior management and the board.
3. Calibrate risk ratings
A rating should change what happens next.
- Define measurable rating criteria: purpose, complexity, autonomy, data reliability, customer impact, exposure.
- Rate each model and record who assessed it, when, and why.
- Rate vendor and third-party models standalone for their impact on your institution; do not inherit the vendor’s view.
- Test that the rating actually changes the depth of governance a model receives.
4. Exercise review and monitoring
A process that has never run is not a process.
- Run independent review on a representative set of models, including third-party components.
- Test change triggers, escalation paths, and reassessment on a real change.
- Define monitoring frequency, metrics, and thresholds proportional to each model’s risk.
- Walk one decommissioning through end to end, including downstream-effect checks.
5. Challenge vendor readiness
Using a third-party AI service does not transfer accountability to the provider.
- Review vendor documentation, dependencies, update practices, and performance evidence.
- Confirm information and audit rights, and timely reporting of material model, data, or security events.
- Check that model and dependency changes are visible before they alter your exposure.
- Record accepted limitations and the compensating controls that cover them.
- Confirm you can continue critical operations if the service deteriorates or becomes unavailable.
6. Repeat the cycle
Enter May 2027 with evidence your process has already produced.
- Update the inventory when use, data, infrastructure, performance, or dependencies change.
- Re-run gap and completeness reviews after each cycle instead of waiting for the annual review.
- Keep review and monitoring evidence current between formal snapshots.
- Treat gaps as a work list: assign, close, and re-check them.
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.