E-23 Will Make Canadian Banks Build Fewer, Bigger Models

OSFI E-23 will not just add AI models to bank inventories. It will change which models banks build, and in doing so it will concentrate AI risk rather than distribute it.

What most people think

The consensus is that E-23 is a compliance exercise. The guideline, effective 2027-05-01, extends model risk management to AI and machine learning. The reading inside most banks is straightforward: extend the existing model inventory, run AI models through the existing independent validation cycle, document the results, and the industry adapts. Nothing about the shape of the model estate changes. The control framework catches up to the technology.

This is a fair reading of the text. It is also, I think, wrong about the effect.

What the data shows

We do not have bank model inventories. Nobody publishes them yet. What we do have is our live incident database, which tracks reported AI failures from public news, and the regulatory calendar.

In the last 45 days our database logged 440 stories, against 511 in the 45 days before that. Governance stories fell by 47, from 226 to 179. Compliance fell by 25. Fairness fell by 18. Meanwhile the regulatory calendar added E-23, the Colorado automated decision-making law effective 2027-01-01, and two California automated decision-making dates inside twelve months. Preparation load is rising while public coverage of governance is falling. That gap matters: the work is moving out of the press and into internal programmes, where the design choices get made quietly.

The severity mix barely moved. 52 critical stories in the last 45 days against 53 before. The reporting base is thin and concentrated: the top five outlets carry 7 percent of stories. So I would not read the governance decline as a decline in governance failures. I would read it as a decline in attention to them.

That is the backdrop. The mechanism below is the argument.

Why this happens

Independent validation is expensive and periodic. It is only affordable if the thing being validated stays still between validations. A validator has to be able to say: this is the model, this is what it does, this is the evidence, and it has not materially changed since the evidence was gathered.

AI models do not naturally stay still. They are retrained, fine-tuned, re-prompted, and re-grounded. A bank with two hundred small adaptive models faces two hundred validation events per cycle. A bank with eight large models faces eight. The validation cost per model per cycle is roughly fixed, so the arithmetic pushes hard toward consolidation.

The second effect is cadence. If validation is annual, the model freezes to an annual calendar. Updates that would have shipped monthly get batched into the validation window, because an out-of-cycle change triggers a new validation event. The model becomes slower to fix, not because anyone decided slowness was good, but because the control cycle set the clock.

Put those together and you get fewer, bigger, slower-to-fix models. That is the opposite of the diversification that model risk management exists to produce. Model risk management is supposed to stop you from betting the bank on one model. A validation regime priced per model per cycle gives you a reason to bet the bank on one model, because one model is cheaper to validate than fifty.

This is not a failure of E-23. It is E-23 working as written, applied to a technology it was not originally designed around. The guideline is doing what model risk management always does. The estate reshapes around the control.

The best argument against this

The strongest objection is that validation need not be periodic and per-model. Modern model risk practice already recognises monitoring-based attestation, ongoing performance testing, and tiered validation by materiality. A well-run programme can validate a small adaptive model once at approval, then attest continuously through monitoring, with deep review only on material change. Under that design, adaptive models are not penalised. They are cheaper to run than large ones, and the consolidation incentive disappears.

That is a real answer, and it is the right one. But it is not the default. The default in most banks is the periodic independent validation cycle inherited from credit and market risk, because that is the machinery that exists, the staff that exist, and the audit trail that regulators already know how to read. Building a continuous-validation route is a design choice that has to be made deliberately and defended internally. Left alone, the programme will drift to the periodic model because it is the path of least resistance.

So the objection is correct about what is possible and wrong about what will happen without intervention. The incentive is real; it can be counteracted, but only on purpose.

What I think happens next

In the two years after 2027-05-01, the number of distinct production AI and machine learning models disclosed in the model inventories of the largest Canadian banks, through annual reports, OSFI summaries or public model risk disclosures, will fall or stay flat while the total volume of AI-driven decisions rises. I commit to that by 2029-05.

What would prove it wrong: if disclosed production model counts at the largest Canadian banks rise materially after E-23 takes effect while decision volumes rise, the consolidation incentive is not operating and the claim is wrong.

What to do about it

• Add a model-concentration metric to your E-23 programme. Measure decisions per model, not models per business line. A rising decisions-per-model figure is the early signal that consolidation is happening.
• Design a continuous-validation route now. Monitoring-based attestation with periodic deep review, tiered by materiality, so adaptive models are not penalised into being frozen. Write it down before the first validation cycle sets the precedent.
• Raise the consolidation incentive explicitly in the board paper. Name it as a foreseeable consequence of the validation design. That turns concentration from a side effect into a documented choice, which is the difference between owning the risk and discovering it.
• Map the validation calendar against your release cadence. If the two are coupled, you have already frozen the estate. Decouple them deliberately.
• Track the regulatory stack as one programme. E-23, Colorado from 2027-01-01, California's automated decision-making rules from 2027-01-01, and the EU AI Act's high-risk obligations from 2027-12-02 all land inside the same window. A governance and risk programme can hold them together; four separate programmes will each optimise locally and miss the cross-cutting effect.

A risk team that builds its E-23 programme around per-model validation will discover it has funded a consolidation programme, and will own the concentration risk that results without having assessed it. That is the trap. It is avoidable, but only if someone names it before the inventory is set.

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:

• Why Your AI Projects Need Their Own Rulebook on ThreatClaw
• The Tiny AI File That Can Destroy Your Business on ThreatClaw