Operational resilience is the successor discipline. Most banks haven't noticed.

There is a question I have heard asked in risk committees for eighteen years: what are our top operational risks? It is a reasonable question. Whole frameworks, taxonomies, and careers, mine included, are built on answering it well.

But it is no longer the question our supervisors are asking. The question they now ask is different in kind, not degree: which of your services would fail under severe but plausible disruption, how fast, and would the failure stay within a tolerance your board has approved?

Most banks are treating the second question as an extension of the first: a new workstream bolted onto the operational risk framework, staffed from the business continuity team, reported one agenda item down from the loss dashboard. I think that is a category error, and I think the institutions making it will discover the difference in an examination room. Operational resilience is not a workstream of operational risk. It is the successor discipline.

The rename that isn't cosmetic

Start with what the regulators actually did. OSFI did not publish a resilience annex to its operational risk guideline; it rewrote Guideline E-21 and renamed it Operational Risk Management and Resilience, with full adherence expected by September 2026 and scenario testing of critical operations by 2027. The Bank of England did not amend its operational risk rules; it built a standalone regime (PRA SS1/21 and the FCA’s parallel rules) around a new object, the important business service, with impact tolerances the board itself must approve. The EU did not extend its operational risk directives; it passed DORA, Regulation (EU) 2022/2554, a freestanding regulation with its own architecture, applying since January 2025. The U.S. agencies, characteristically, signalled rather than legislated, but their 2020 interagency paper on sound practices reads as the same blueprint in advisory voice.

Four jurisdictions, one convergent design: identify the services that matter, set tolerances for their disruption, map the dependencies that deliver them, test against severe but plausible scenarios, and hold evidence the board and the supervisor can inspect. None of that is a refinement of the loss-event taxonomy. It is a different discipline wearing the same department’s badge.

What actually changed

The deep change is the unit of analysis. Operational risk decomposes the bank into risk categories: internal fraud, external fraud, process failure, system disruption. Resilience decomposes the bank into services: payments clearing, client onboarding, trade settlement. These are not two views of the same object. A risk category cuts across every service; a service depends on a chain of people, processes, systems, facilities, and third parties that no risk register was ever built to represent.

With the unit of analysis, everything downstream changes too.

The success metric changes. Operational risk asks whether losses are within appetite, an actuarial question answered in distributions. Resilience asks whether the payments service comes back inside its tolerance on a bad day, an engineering question answered in hours and dependencies. A bank can be comfortably inside its operational risk appetite and catastrophically outside its impact tolerances, and most banks cannot currently tell you which of the two they are.

The artifacts change. The register, the central artifact of operational risk for two decades, records assessments. Resilience requires a map and a test log: a living representation of what delivers each service, and accumulating evidence of what happened when you stressed it. A register is a noun. A map under test is a verb.

The audience changes. Operational risk reporting was written for the risk committee. Impact tolerances belong to the board; SS1/21 is explicit about this, and E-21 follows. When the board owns the tolerance, the board owns the uncomfortable conversation about the legacy settlement system three vendors deep in the dependency chain. That conversation does not fit in a heat map.

The bolt-on trap

Here is what “not noticing” looks like in practice, because I have watched it from the inside.

The resilience mandate lands. It gets staffed from business continuity: capable people, but trained on recovery plans, not dependency architecture. The important business services list gets drafted to mirror the org chart, because the org chart is the data that exists. Impact tolerances get set at whatever the current recovery time objectives already achieve, because nobody wants to create a breach on day one. The dependency mapping goes into a spreadsheet, current as of the week it was built. Scenario testing becomes an annual tabletop, minuted and filed. And the whole apparatus reports into the operational risk framework as one more row, where its outputs are dutifully converted back into the register format, the format of the predecessor discipline, losing in translation exactly the information that made them valuable.

Every step is locally sensible. The sum is a resilience program that produces compliance artifacts instead of resilience: a rename, not a succession. Regulators are getting better at telling the difference, and the tell is always the same: ask to see the evidence that a specific service was tested against a specific scenario and recovered within tolerance, and watch how long the answer takes to assemble.

What noticing would look like

A bank that took the succession seriously would do a few visible things differently.

It would treat the service map as core infrastructure, not documentation: owned, versioned, and current, the way the general ledger is current, because every other resilience activity is only as good as the map it runs against. It would set impact tolerances from customer and market harm, then confront the gap to current capability honestly, rather than reverse-engineering tolerances from capability to avoid the gap. It would test continuously and cumulatively, each scenario adding to an evidence base, rather than annually and performatively. It would report to the board in the board’s own unit: services, tolerances, breaches, trend. And it would resource the discipline the way successors are resourced, with its own tooling, its own data model, its own talent profile, not with the predecessor’s hand-me-downs.

Almost none of that runs on the tooling banks currently own. The GRC platform holds registers; it has no first-class concept of a service, a tolerance, or a test. Which is why so much resilience work today lives in spreadsheets: the universal symptom of a discipline whose instruments haven’t been built yet. That gap is buildable, and closing it is precisely the research agenda this site exists to prototype. But the tooling follows the recognition. A bank that still thinks resilience is a workstream will buy a module. A bank that recognizes a successor discipline will demand an instrument.

The clock

None of this is speculative on the timeline. The UK transition closed in March 2025; UK-regulated firms are now in the demonstrate-or-explain phase. DORA has applied for eighteen months. E-21 reaches full adherence in September 2026, with tested critical operations expected a year later. The supervisory conversation is moving from “show me your framework” to “show me the test evidence,” jurisdiction by jurisdiction, on published dates.

Operational risk is not going away: losses still need measuring, capital still needs holding, the register still has its uses. Predecessors rarely disappear; they get absorbed into the thing that succeeds them. But the center of gravity has moved, the regulators moved it deliberately, and they wrote the dates down. The discipline has a successor. The only open question is how many banks will notice before their examiners point it out.

The prototype: ORBIT implements this argument as a working operational resilience workbench, from important business services through impact tolerances to board-ready reporting.