ORBIT

The problem

Operational resilience regimes share a common architecture: identify your important business services, set impact tolerances, map the dependencies that deliver each service, test against severe but plausible scenarios, and report to the board with evidence. The PRA wrote it first (SS1/21, with the UK transition complete since March 2025). DORA hard-codes a version of it for the EU. OSFI’s E-21 brings it to Canada with full adherence expected by September 2026 and scenario testing of critical operations by 2027. The U.S. agencies sketched the same shape in their 2020 sound-practices paper.

Now ask a mid-tier bank where that architecture actually lives. The honest answer, almost everywhere: a service inventory in one spreadsheet, dependency maps in another (accurate as of whenever someone last chased the owners), impact tolerances in a policy PDF, test results in slide decks, and a board report assembled by hand each quarter from all four. The regime assumes an integrated, living system. The tooling is a filing cabinet.

Large banks are building integrated platforms in-house. Vendors sell modules that solve fragments. The banks in between, carrying nearly the full regulatory weight with a fraction of the build capacity, are the gap.

What it does

ORBIT is an enterprise-grade operational resilience workbench built for that gap, as a working prototype and reference blueprint:

Important business services. A structured inventory with ownership, criticality rationale, and the regulatory mapping behind each designation: why this service, on what evidence.

Impact tolerances. Tolerances expressed in the metrics boards actually approve (duration, customers affected, financial and market impact), with the calibration reasoning attached, not just the number.

Dependency mapping. The delivery chain under each service: people, processes, technology, facilities, third parties, and the nth-party links behind them. Concentration and single points of failure surface instead of hiding in tabs.

Scenario testing. Severe-but-plausible disruption scenarios run against the map: where tolerance is breached, how long recovery actually takes, which dependencies drive the breach. Results persist as evidence, connected to the services and tolerances they tested.

Board-ready reporting. Reporting assembled from the underlying data on demand: current posture, breaches, remediation, trend. The quarterly copy-paste exercise disappears, and the answer to “show me” is the system itself.

Why it matters

Every regime named above converges on one demand: demonstrate, with evidence, that critical services survive disruption within tolerance. That demand cannot be met from disconnected spreadsheets: not credibly, not repeatably, and not by September 2026 for institutions under E-21. The point of ORBIT is to show what meeting it properly looks like when the system is designed by someone who has had to defend one.

Honest framing

ORBIT is a blueprint, not a product. It is the working answer to a design question (what should resilience tooling for a mid-tier bank actually be), published so it can be examined and challenged.