Your Vendor's Model Is Now in Your Inventory
Guideline E-23 takes effect on 1 May 2027. It applies to every federally regulated financial institution in Canada, including foreign bank and insurance branches, and it applies to all models regardless of source or purpose. Internal models, models from a foreign office, models bought from a vendor. If it carries non-negligible model risk, it belongs in your inventory with a risk rating attached.
7 months. From today to 1 May 2027, when Guideline E-23 takes effect.
Most of the readiness work under way right now is about scope and inventory: finding the models, triaging them, rating them, writing the policies. That work is tractable. The part that is not tractable, and that very few institutions have solved, is what happens when a model in your inventory belongs to somebody else.
OSFI saw this coming and said so
The guideline does not pretend that third-party models can be governed the same way as internal ones. It expects institutions to identify vendor and third-party models, to store them in the inventory where they carry material risk, and it notes that this matters particularly for AI and machine learning models that depend on multiple components, dynamic data sources and third-party elements.
The sharper point appears in how counsel and consultancies have read the guideline since publication: many AI vendors do not yet have validation and reporting capabilities consistent with these requirements, and institutions are therefore expected to assess and manage the residual risk from vendors who fall short, keeping that risk inside their stated appetite.
Read that again from the institution's side. You are accountable for a model you did not build, cannot inspect, cannot re-run, and whose behaviour may change without your knowing. The regulator has told you to manage that risk anyway.
What managing it looks like today
In practice, the toolkit for third-party model risk is roughly this:
- A vendor questionnaire, answered by the vendor
- Model documentation and a model card, written by the vendor
- Validation reports, produced by the vendor or by someone the vendor engaged
- Contractual representations, drafted to limit the vendor's liability
- Performance monitoring on outputs, which detects drift but not substitution
Every item on that list has the same author. It is a coherent programme and it is genuinely better than nothing. It is also, in the end, the vendor's account of itself, assembled by the party whose model is under scrutiny.
The gap is narrower than it sounds, and worse
The concern is not that vendors are dishonest. It is that nothing in the current arrangement would reveal it if something went wrong. A vendor under margin pressure substitutes a smaller model. A version ships without a corresponding notice. A routing layer quietly directs a fraction of traffic to a different provider. In each case the outputs keep arriving, monitoring sees nothing unusual, and the model named in your inventory is no longer the model producing your decisions.
Then a claim is denied, a credit decision is challenged, an examiner asks about one specific case from eighteen months ago. At that point the institution reconstructs: pull the logs, ask the vendor, assemble a timeline, produce a narrative. Reconstruction is expensive, slow, and only as credible as the records it draws on, all of which were written by the party being asked.
Evidence captured, not evidence assembled
There is a different way to hold this, and it is not more paperwork. Every inference produces a cryptographic receipt that binds the exact model, the exact input and the exact output, issued by a verifier that did not run the job. The institution holds the receipt. Anyone can check it offline, years later, without access to the vendor's systems and without the vendor's cooperation.
The architectural rule underneath it matters more than the cryptography: the party that executes is never the party that attests. That is why a vendor, however diligent, cannot produce this about its own work, and why an institution that holds these receipts is no longer relying on the vendor's word for the one fact that matters most.
For an MRM function, the practical difference is that the evidence for vendor models stops being something you reconstruct under pressure and becomes something you already have.
What a receipt does not do
Being precise about the boundary is part of the point. A receipt does not tell you the model was appropriate for the use case. It does not tell you the output was correct, fair or well calibrated. It does not validate the model, replace independent review, or discharge any obligation under the guideline. Validation, monitoring, governance and challenge all remain exactly where E-23 puts them.
What it removes is one specific and increasingly expensive doubt: whether the model named in your inventory is the model that produced the decision in front of the examiner.
Seven months
Institutions treating E-23 as a readiness journey rather than a filing exercise are using this window to find the gaps that will be hardest to close. Third-party model evidence is one of them, because the fix does not live inside the institution. It lives in what you require of vendors, and in what those vendors can actually produce.
The requirement worth writing into the next vendor contract is not another attestation. It is evidence you can verify without them.
Cyberian Systems is the verification layer for AI inference, issuing independent cryptographic receipts that are live in production today. If you are working through E-23 readiness for vendor models, write to philippe@cyberiansystems.ai.