Nothing is as permanent as a temporary fix

Two numbers decide how September 2026 goes for a Canadian institution that put a replacement platform on the critical path of its E-21 work, and neither of them appears in the guideline.

The first is how long a federally regulated institution takes to put a new risk platform into production. From approved budget through procurement, security review, configuration, integration, data migration and change governance, the honest planning number is two to three years. That is not a vendor's figure or a survey's. It is the number I would expect any experienced programme office to write down unprompted, and anyone who has lived such a delivery can test it against their own scars.

The second is twenty-four months and ten days: the distance from 22 August 2024, when E-21, the guideline Canadian operational risk runs on, was finalised, to 1 September 2026, the date by which the letter that accompanied it expects critical operations identified and mapped, tolerances for disruption set, a scenario-testing methodology developed, and testing begun.

Set the numbers side by side and the conclusion is reached before anyone opens a slide. An institution that waited for the final guideline before committing budget to tooling, and that sequenced the content and adoption work behind the build rather than alongside it, does not reach that date with the tooling live, populated and trusted. That is not a story about complacency. It is arithmetic, and it was settled the day the budget cycle met the effective date.

One scope note, and I mean it. Institutions that kept tooling off the critical path are on a different route and outside everything that follows. I am not describing a market, and I am not describing any institution. I am following one sequencing choice to its end.

Go-live is a schema date

Suppose the number is beaten anyway. The purchase order signs the week the final text lands, procurement compresses, configuration runs hot, and the platform reaches production in the summer of 2026. What arrives on go-live day is an empty system.

The work E-21 actually cares about lives in the content, and the content has its own logic. Basel's fourth resilience principle opens with the words once a bank has identified its critical operations. E-21 says that once identified, critical operations should be mapped, and the mapping runs across people, technology, processes, information, facilities, third parties and the dependencies among them. Setting a tolerance for disruption means knowing which other critical operations lean on the same resources. An end-to-end test consumes that chain, and early tests repay it by exposing where it is wrong, but the chain has to be recorded somewhere before a test can traverse it. All of that content either already exists in older tools, and must be migrated, reconciled and revalidated into the new platform, or it gets built inside the platform after go-live. Either way, go-live is a schema date, not a readiness date. The distance between the two is measured in quarters, and on this route it starts being paid after the implementation programme has taken its bow.

The slower clock

Under the tooling clock runs a slower one. OSFI expects scenario testing to run end to end, across multiple business lines, through internal and external dependencies. That is a different discipline from business continuity testing, and the difference is precisely the part that cannot be procured. The first line has to learn to test an operation, not recover an application. Roles have to exist, people have to fill them, and the first cycles will be rough in the way first cycles always are. On this route the clock starts only after the tooling question is settled, because the operating model gets designed around whatever the tooling turned out to be. Systems reach production on a date. Judgment arrives on its own schedule.

What September looks like

Put both clocks against that calendar and the shape of September on this route is already visible. An institution on this route does not arrive at the effective date with nothing; it arrives with what is at hand. Registers kept in spreadsheets. Maps drawn in slides. A facilitated workshop, conscientiously minuted, standing in as the first scenario test. A modest first cycle is not by itself a failure against a guideline that says scenario testing is iterative and should become more sophisticated over time.

Two hazards sit underneath, and what follows is implementation synthesis, not anything E-21 prescribes, since the guideline names no required artefact, format or retention period. The first hazard is one anyone who has run a regulatory programme will recognise: when a build has consumed most of the runway, the work that remains can reorient from building the capability to evidencing the milestone, and everyone in the room feels the difference even when the minutes cannot show it. The second is what the interim step becomes. A test result means nothing without the version of the map and the tolerance it was built on, so the spreadsheet holding your tolerances on the day of your first recorded test is, from that day, a baseline, and the eventual platform inherits the job of migrating it, reconciling against it and preserving its lineage. Not because the guideline says so. Because otherwise the test result stops meaning anything. The window after September makes the load heavier, because the same letter expects testing to be completed for all critical operations by 1 September 2027, and a platform that is not authoritative until late in that window means a year of tests, findings and baselines accruing somewhere else first. The workaround becomes the system of record. Nothing is as permanent as a temporary fix.

The argument nobody can win

So whose failure is that.

The case against institutions says nobody was ambushed. A draft of E-21 circulated from October 2023, OSFI had signalled resilience for years before that, Basel's principles date from 2021, and Canadian groups with in-scope UK subsidiaries have watched those subsidiaries operate under binding resilience rules since March 2022. On this reading the direction of travel was published, and waiting was a choice.

The case against the calendar reads the same dates the other way, through the comparator this essay reaches for. The UK gave firms twelve months from final rules to an equivalent first milestone, important business services identified, impact tolerances set, testing commenced, and then three further years, to March 2025, to reach its terminal milestone, the ability to remain within those tolerances, with consultation stretching back to a 2018 discussion paper. Canada's first leg is twenty-four months, double the UK's. Its second leg is one year, to a different terminal milestone: testing completed for all critical operations by September 2027. The endpoints are not the same obligation, a capability line there, a coverage line here, so the regimes do not map onto each other exactly. The runways are still the planning fact. Roughly three years from final text to terminal milestone, against roughly four, which themselves followed nearly three years of public consultation.

Both cases will be argued between now and September. Notice, priorities and the capability work that never needed a platform are beyond this essay's route. The tooling part is not, and on the tooling part I do not think either side can win, because both are arguing about the same block of time.

The number doing all the work

Read on tooling alone, the case against institutions points to the 314 days spent between draft and final text, days a build could have used. The case against the calendar points to the 740 days that remained. Both are arguments about where a two-to-three-year block, 730 days at its most optimistic, fits on a timeline. Neither asks whether the block has to be two to three years long.

It deserves asking, because the two-to-three years is not physics, and because nothing in E-21 requires a platform programme in the first place; the requirement is the capability. Consider where the time goes on the generic-suite route. A large GRC or resilience suite serves many institutions, so any one institution's world has to be represented through the suite's object model and its configured fields: the taxonomy mapped to the vendor's structures, operations and dependency maps expressed in the fields available, legacy registers migrated and reconciled into the result. Configuration, integration, change windows measured in quarters. Bespoke was always possible in principle. On the economics I have seen, it was rarely the rational choice, so the generic suite became the practical route to enterprise-grade capability, and part of that route's time is the translation just described. The question is whether the economics still hold.

The obvious rejoinder is the one this essay has already made: a system built faster arrives just as empty. It would, if it were built the same way. The difference worth testing is not typing speed. It is the direction of fit. Here is the proposition in full, because all of it is under test: that AI-assisted development makes it feasible to build the specific system instead of configuring the generic one, the institution's own taxonomy as the data model, its existing mappings and legacy registers as the starting content, its operations and its language in the workflows, end to end; that the alignment work above moves from the middle of the programme to the start; and that the result, a governed resilience record built to fit, content migrated or created, reconciled and versioned, workflows in daily use and at least one full test cycle run through it, stands up in closer to six months than three years, at a fraction of platform cost.

If the proposition's timing claim holds, the timeline argument inverts. September 2026 was never too close for tooling. It was too close for one kind of tooling.

The question

I publish non-commercial resilience prototypes at oprisk.ai in a personal capacity; that is where I test the proposition above, in public and at small scale. This analysis uses public regulatory sources and does not describe any institution, vendor or implementation.

The question I would carry into September is not the one the argument keeps circling, which is whether your institution can be ready in time. It is the quieter one underneath. When your plan says ready, which decade's delivery assumptions is that word standing on?