OSFI E-23 takes effect 1 May 2027
Get your AI use cases ready for model-risk review before E-23 takes effect
The three questions I hear most: could it leak our data, can we prove we are in control, and do we know what is running?
One record per use case, readable before the first review meeting, inside the review you already run.
See a filled-in intake record before you talk to anyone: a synthetic AI use case showing its data boundaries, missing evidence, proposed review route and the decisions left to your model-risk team. Then book a scoping call, or email one stuck case as a hypothetical.
Have one case stuck right now? Email a hypothetical version of it: no customer data, no internal case detail. A written reply within two business days with the questions that decide its route.
Everyone wants to be in control of AI, and nobody wants another form. Meanwhile a use case has been waiting for approval for months, and the date on the calendar does not move.
The short version. OSFI, Canada's banking regulator, published Guideline E-23 on 11 September 2025. It takes effect on 1 May 2027 and covers all models at federally regulated financial institutions, including AI and machine learning models and models bought from third parties, and it names the fields a model inventory keeps. OSFI's July 2026 bulletin on generative and agentic AI adds 33 measures (my count) that institutions can consider now.
For a queue of AI use cases, that changes one thing: from 1 May 2027, every model behind a use case is in E-23's scope, and a use case with no record is where your inventory is most likely to miss one. The fix is unglamorous, and it is easier before the date than after: one record per use case, linked to the model records E-23 asks for, kept where your reviewers already look. The next section shows one such record, filled in.
One intake, filled in: a synthetic example
UC-0417 is invented for illustration; no institution and no client is behind it. It is an intake record, never a readiness assessment, and its security conditions are not model-risk clearance. It shows what a business team writes, what the record turns that into, and what is left for your reviewers.
What the business team wrote
"An assistant that drafts first versions of our campaign briefs from the brand guidelines and past briefs in the document system. First drafts only; a person edits every one. We would like to pilot next month." Owner: the head of marketing operations. Technical owner: the marketing technology lead.
The record it becomes
Stage: idea, pilot proposed. Role: assists a person; no decision about any person; employees only. Model: one foundation model in the company's approved cloud account, version pinned, no fine-tuning, model record to be linked. Data: internal, confidential if unreleased campaign plans are included; personal information believed none. Direction: documents and the prompt go out to the model; output lands in a drafts folder, not in a system of record. Placement: approved cloud account, private connectivity, no-training and no-retention terms in the contract. Access: a service account that reads two document libraries and writes one drafts folder, one-hour tokens, single sign-on for users. Autonomy: bounded folder writes, no irreversible action, a spend cap and a per-run ceiling. Logging: prompts, retrieved document IDs and outputs to the platform's log store. Evaluation: a set of 30 briefs rated by the owner before the pilot, rerun on any model version change.
The evidence still missing
Three facts the record cannot settle on its own, each with the person who can: a sample check for personal information in the source libraries (the data steward); whether retrieval honours each user's library permissions (the platform owner); the country of processing (the cloud owner). Two more gaps: the risk owner is unassigned, and the threat model is planned, not done.
The recommended review route
Proposed disposition CAVEAT (proceed, with conditions): the proceed path for a confidential, data-out use case on an approved cloud account applies once the three facts are settled. If customer data is ever added to the libraries, or the assistant is given write access to the content system, the record returns to review. Reviewer: security. Approver: the head of marketing operations with the CISO's delegate. The question to put to the reviewer: which of the three would change your decision?
What remains for the institution
Resolving these gaps does not authorize deployment. Your institution determines model classification, risk rating, validation requirements and approval. Whether this assistant is a model under E-23, and which tier it sits in, are your model-risk function's determinations; the record carries the facts those determinations read, and links to the model inventory entry once one exists.
The full record behind this example (26 fields, 0 to 25, with its decision log) is the intake method the Review runs. The example's conditions are synthetic; a real record carries your reviewers' names and your own rules.
What the record is, and what it is not
We document candidate models and their uses for your institution to classify and risk-rate. These records support model identification and link to your model inventory; they do not establish E-23 compliance. E-23 itself separates identifying a model from including it in the inventory, which it ties to non-negligible risk; that line is drawn by your model-risk function, not by the record.
The questions a head of model risk asks about a record like this, each answered as far as the Review can answer it:
How does the record feed our own tiering and materiality? It carries the fields your tiering reads: purpose, who the output affects, data classification, direction, placement, autonomy and the dependencies on shared models. The tier and the materiality judgment are yours; the record does not propose a tier.
Does it help us decide whether a generative AI use case is a model under E-23? It gives that decision its facts: what the system computes, from which inputs, and what its output changes. The determination is your model-risk function's. Not yet answered: a worked example of that determination on a real queue, because no institution has run one with us yet.
Intended-use limits, validation evidence gaps, remediation owners, and the changes that trigger reassessment? Recorded, per use case: the intended use and what the system may do alone, the evidence still missing with the person who can supply it, and the model version pin. A model or version change reopens the record. The Review documents validation gaps; it does not produce validation evidence.
Many use cases on one shared model, one use case on several models? Each record links to every model record it depends on, and one model record can be linked from many use cases. The Review writes the links it finds; it does not reconcile your inventory.
We have 150 use cases. Which dozen, and what does the dozen leave out? A dozen is a sample, chosen with you by exposure (customer-facing, decisions about people, data leaving the institution, autonomy) and by what is stuck. It leaves the rest undocumented; your team runs them through the same template and decision log afterwards. Not yet answered: a tested selection rule. The first Review writes one, and this page will say so when it exists.
How much of our staff's time? Estimated during scoping, from your number of use-case owners and your review calendar. We do not quote an average, because we do not have one.
What can we estimate or prioritize afterwards? Which use cases can go to review first; which are blocked on the same missing evidence, so one fix unblocks several; and which need a model record that does not yet exist. Not an estimate of compliance or readiness.
What you get
One offer, the three-week Review, and the two things every use case leaves with. It adds no new process: it fills the one your model-risk team already runs with records a reviewer can use.
The E-23 Readiness Review
Up to a dozen use cases, worked through with the people who own them. Each one leaves with its record, its triage and a recommended route for your reviewers to confirm.
The inventory E-23 asks for is started, as a by-product of work your teams needed done anyway.
USD 15,000, fixed fee: three weeks, up to a dozen named use cases, starting once your owners and reviewers are booked. An AI Use Case Triage fee credits in full. Later delivery is separately scoped. Any fee credit is agreed in writing; required discovery is not waived. See what a triage looks like →
What each use case gets: one record
Each use case gets one record with its data classification, its direction (data going out to a model, output coming back into a system of record, or both), where the model runs, and the limits on what it may do alone.
The record is tagged on the open FINOS AI Governance Framework and mapped to OSFI's expectations, so an examiner, an auditor or a peer can read it without a glossary.
What each use case gets: a written triage
For every use case, a short written note on which questions decide its route: which reviews it is likely to need, and which facts are still missing before it can.
Your team walks into the review knowing what will be asked, and so do the reviewers.
A fixed fee for a fixed scope, confirmed in writing before the start. Emailing one stuck case first costs nothing.
How the Review runs
Three weeks, with the business owners and the specialists who already review AI. Approval stays with your reviewers throughout.
Inventory and classification
We list the use cases in scope and open a record for each. Business owners fill in what they know, in plain words: the purpose, the owner, the data and its classification, the direction, the vendor product it lives in, and how much it may do without a person.
Routes and gaps
For each case, the questions that decide its route, the reviews it is likely to need, which of E-23's inventory fields the record still lacks, and which of the measures OSFI's July 2026 bulletin says institutions can consider it does not yet address. The specialists add the evidence: placement, identity and permissions, logging, and the privacy assessment where personal information is involved.
The record set and the handover
Each use case leaves with its record, its triage and a dated decision log, handed to the team that runs your model-risk review. The records are yours, in your systems, and every new use case can start from the same template.
The Review prepares records and routes. It does not approve, validate or certify any model; those decisions stay with your institution.
Proof you can check
The mapping behind the record is public. I opened a pull request to the FINOS AI Governance Framework that adds OSFI's July 2026 bulletin to the framework's Canadian references and links its six areas from 16 of the framework's risk pages, with a measure-by-measure table of the 33 sound practices in the pull request's first comment: 17 files, signed off under the Developer Certificate of Origin. It is open and not merged, so read it as a proposal you can inspect line by line.
It also shows where the catalogue runs out. In my reading, eight of the 33 measures have no implementing mitigation in the framework yet. I would rather you see that gap in public than find it in your own review.
I run an AI use-case intake with data classification, direction, model placement and autonomy limits inside a Fortune 500 financial-services company.
If you want to read before you write, the field guide covers what Canada's regulators expect, on one dated calendar, free.
Who this is for, and who it is not
Each row maps the Review to the guidance that applies to that kind of institution. It is a reading of public guidance, not a statement that OSFI's expectations bind everyone, and not legal advice.
Federally regulated banks and insurers
Applicable guidance: OSFI Guideline E-23, effective 1 May 2027, covering AI, machine learning and third-party models. The July 2026 bulletin's 33 measures are sound practices institutions can consider.
What the Review does: One record per use case, mapped to E-23's inventory fields, so the inventory is under way well before the date.
Institutions the AMF supervises in Quebec
Applicable guidance: The AMF's Guideline for the Use of Artificial Intelligence, published in April 2026, effective 1 May 2027.
What the Review does: The same record per use case, mapped to the AMF guideline. OSFI's expectations are added where the institution is also federally regulated; otherwise they are a voluntary reference, not applicable guidance.
Ontario credit unions
Applicable guidance: FSRA, not OSFI, so no OSFI date applies. FSRA expects AI governance "commensurate with the scope and impact of the AI use cases".
What the Review does: A record sized to the use case, mapped to FSRA's expectation. Reading OSFI's guidance as sound practice for a credit union is Magma's inference, not FSRA's statement.
Pension plans
Applicable guidance: E-23 excludes pension plans from its scope.
What the Review does: Not the Review's focus. If you still want one record per use case, the field guide shows how to start one yourself.
Vendors selling AI to any of these
Applicable guidance: Your buyer's, so it depends on who the buyer is. For a federally regulated buyer, E-23 brings third-party models into scope and the July 2026 bulletin lists third-party notification of AI use among its sound practices; a credit union's or a pension plan's vendor follows that buyer's own guidance.
What the Review does: A record for your product, written in the terms your buyer's reviewer uses, ready before the questionnaire arrives.
Each row summarizes only what the sources below say on these points. It is a reading of public guidance, not legal advice.
Questions a model-risk lead asks
Do we need a new tool?+
No. The record lives where your team keeps records today: a spreadsheet, a ticketing system, or the governance platform you already own. If you buy a platform later, the records can move into it.
Does this replace our model-risk process?+
No, it feeds it. Validation, approval and monitoring stay with your model-risk team. The Review hands them records they can read, so their time goes to judgment rather than chasing facts.
What do you need from us?+
The list of use cases in scope, a short conversation with each business owner, and a named contact in model risk, security and privacy who can answer questions in week 2. Your current intake form or review checklist helps, if one exists.
What if we have no inventory yet?+
Then week 1 is where it starts. The records for the use cases you name become the first entries, and every later use case joins through the same record.
Is any of our data sent anywhere?+
The Review needs no customer or personal data: the records describe each use case, not the data it processes. Where the work happens and where drafts are kept is agreed with your security team before week 1, and the finished records are delivered into your systems. The free stuck-case reply needs even less: a hypothetical or public example, with no names and no data.
What happens after the Review?+
Your team keeps the records, the triages and the template, and runs every new use case through them. If you want help with the next batch, we scope it then. Nothing renews by default. Your reviewers decide the route. Later delivery is separately scoped. For what is forming in AI beyond E-23, the AI uncertainties watch is a free sample written for AI governance leads at banks and insurers.
How do the credits work?+
Credits come only from fees you have paid, only from the step just before, and they never stack. An AI Use Case Triage fee credits in full to the Review. Nothing else is credited unless it is agreed in writing, and required discovery is never waived.
Email one stuck case
Describe one use case that is waiting for approval, the way you would to a peer at another bank: a hypothetical, or a public example you are allowed to share. Do not send customer data, internal case detail, names or documents. Within two business days you get a written reply with the questions that decide its route, never the route itself: limited context supports a discussion of the decision, not a judgment on your case.
Email [email protected]One case per team, answered in writing within two business days. For more than one, the AI Use Case Triage takes up to eight for USD 1,500, three in depth, and credits in full to the Review. LinkedIn works too.
Book a scoping call for the Review
Thirty minutes to confirm which use cases are in scope and who needs to be in the room. If it fits, the three weeks start once your owners and reviewers are booked.
A straight answer, not a sales pitch.
Sources
OSFI, Guideline E-23, Model Risk Management, its publication letter and its backgrounder: the publication and effective dates, the scope including AI and third-party models, the inventory fields, the distinction between model identification and inventory inclusion, and the pension plan exclusion.
OSFI, "Generative and Agentic Artificial Intelligence: Implications for Technology, Cyber Security, and Operational Resilience" (Technology Risk Bulletin, July 2026): the 33 measures and the "can consider" wording.
Autorité des marchés financiers, Guideline for the Use of Artificial Intelligence (April 2026): the effective date and the scope.
FINOS, the AI Governance Framework repository (version 2, 2025-10-20, CC BY 4.0) and pull request #418, the OSFI bulletin mapping (open, not merged).
NIST, AI Risk Management Framework 1.0 (NIST AI 100-1): the shared vocabulary, with GOVERN 1.6 as the AI system inventory.
FSRA, credit union town hall (June 2026): the "commensurate with the scope and impact of the AI use cases" expectation and that no AI-specific guidance is planned. Sources are listed in the field guide.
The synthetic intake (UC-0417) is Appendix B of Magma's AI use-case intake method: an invented campaign-brief assistant, filled in to a conditional decision, with no institution behind it.
By Daniel Zivkovic, founder of Magma Inc.