OSFI E-23 Will Push Canadian Banks Toward Black-Box APIs, Not Safer Models

OSFI Guideline E-23, effective 1 May 2027, will push Canadian financial institutions to retire internally fine-tuned open-weight models and replace them with closed vendor APIs. Not because the closed models are safer, but because the guideline's independent validation requirements are easier to satisfy with a vendor's paperwork than with your own engineering.

What most people think

The consensus in the field is that model risk management frameworks raise the floor for everyone. Put a guideline like E-23 in place, the thinking goes, and every model in the inventory, whether a fine-tuned open-weight model on your own infrastructure or a proprietary API from a large vendor, has to clear the same bar. Independent validation, ongoing monitoring, documented assumptions, clear ownership. The architecture should not matter. The framework is architecture-neutral, and neutrality is the point.

That is a fair reading of the text. E-23 is written to cover all models used by a federally regulated financial institution, including AI and machine learning. It does not single out open-weight models. It does not privilege vendors. On paper, the standard is uniform.

What the data shows

Our live incident database, which tracks reported AI failures from public news, has logged 1,500 stories in the last 180 days. The last 45 days carried 430 of them, down from 508 in the 45 days before. Governance stories fell from 224 to 170. Compliance fell from 66 to 34. Security was flat at 33 versus 32. Genai stories rose from 30 to 55. The severity mix barely moved: 57 critical in the last 45 days against 53 before.

What that tells us is that the public failure record is still dominated by privacy (216 stories in 180 days), multi-agent risks (125), security vulnerabilities (101) and fraud (97). Governance failures drew 37. The failure modes that matter most for model validation, the ones that come from training data and weights, barely appear. Model poisoning and data poisoning show up as recurring tags in our sister security platform's output but almost never in the mainstream governance coverage.

That gap matters for E-23. The risks that independent validation is supposed to catch are exactly the ones the news does not report, because they do not produce a headline until they produce a loss. A poisoned fine-tune does not make the IAPP feed. It makes an internal audit finding six months later.

Why this happens

Independent validation under a model risk framework asks three hard questions. What was this model trained on? How confident is it, and can you reproduce that confidence? Can you show that the model you validated is the model you deployed?

For a fine-tuned open-weight model, answering those questions is real engineering. You need weight-level provenance: a record of which base checkpoint, which training data, which fine-tuning run, which merge or quantisation step produced the artifact now in production. You need reproducible uncertainty quantification: calibration that holds across the fine-tune, not just on the base model. You need to show that a red-team finding on the fine-tune was actually remediated in the weights you shipped. None of that is impossible. All of it requires an internal capability most governance teams do not have and cannot buy off the shelf.

For a closed vendor API, the same three questions get answered by attestation. The vendor says what its training data policy is. The vendor publishes an evaluation report. The vendor signs a contract that puts certain obligations on them. The institution's validation team reviews the paperwork, asks follow-up questions, and files the result. The model is still uninspectable. But the file is complete.

E-23 does not require the institution to inspect the weights. It requires the institution to demonstrate that the model has been independently validated. Those are different obligations, and the second one is much easier to meet with a vendor relationship than with an internal fine-tune. A governance team under deadline pressure will notice this. Some will act on it.

The result is a quiet migration. Not a dramatic rip-and-replace, but a slow drift: the fine-tuned model that was going to be refreshed this year gets retired instead, and the use case moves to a vendor API. The inventory looks cleaner. The validation file looks thicker. The institution has traded a model it could inspect for a model it cannot.

The best argument against this

The strongest objection is that this gets the incentives backwards. E-23 is a risk framework, not a procurement rule. It explicitly expects institutions to manage third-party risk, and a vendor API is a third-party dependency with its own validation burden. The guideline does not let you outsource accountability to a vendor's attestation. If anything, the third-party risk sections make vendor APIs harder to justify, because you now have to validate a model you cannot see and a supplier you do not control. On that reading, E-23 should push institutions toward open-weight models, where they can at least inspect what they are running.

That objection is correct about the text and wrong about the practice. The framework does impose third-party risk obligations. But those obligations are process obligations: due diligence, contractual terms, ongoing monitoring, exit planning. They are satisfiable with documents. The obligations on an internally fine-tuned model are technical obligations: provenance, calibration, reproducibility. They are satisfiable only with engineering. A governance team facing a deadline will find the document path faster than the engineering path every time, even when the document path covers a model it cannot inspect. That is the mechanism, and it does not depend on anyone acting in bad faith. It depends on the two paths having different costs.

What I think happens next

By May 2028, regulated Canadian financial institutions will have reduced their deployment of internally fine-tuned open-weight models by more than 40 percent, with the displaced use cases moving to closed vendor APIs. The reduction will show up first in refresh decisions and new deployments, then in retirements.

What would prove this wrong: public regulatory filings or model inventory disclosures from Canadian banks showing an increase in internally fine-tuned open-source model deployments over the same period. If the inventories get more open, not less, the thesis fails.

What to do about it

• Build a weight-level provenance pipeline before you adopt any open-weight model into the E-23 governed inventory. Record base checkpoint, training data, fine-tuning run, and every merge or quantisation step. If you cannot produce that record on demand, you do not have a validatable model.
• Write an explicit validation standard for third-party API training data provenance. Ask vendors the same questions you would ask your own fine-tune team, and put the answers in the validation file. This is how you avoid defaulting to vendor lock-in while still satisfying E-23.
• Treat vendor attestation as evidence, not as validation. A signed report is an input to your independent validation, not a substitute for it. Document what you could not verify and why.
• Keep a small internal capability for inspecting open-weight models even if you deploy few of them. The capability is what lets you tell the difference between a vendor claim and a vendor fact.
• Put the architecture decision in front of the model risk committee explicitly. If you are retiring a fine-tune for an API, say so, and say what you are giving up. The decision is legitimate. Making it silently is not.

A governance or risk programme can help here by making the provenance and validation evidence auditable rather than ad hoc. It cannot make anyone compliant, and it should not be sold that way. What it can do is make the trade-off visible before it gets made for you.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.

Related reading:

• AI Can Now Forge Your Boss's Writing Style on ThreatClaw
• The AI Dashboards Built for Trust Can Be Turned Against You on ThreatClaw