Operational resilience management where every recovery time is timed from test evidence, every breach gets an owner and a date, and a person signs each result
Every recovery time proven by test evidence, every breach fixed with an owner and a date.
See one case, screen by screen ↓Operational Resilience Management is operational resilience management software for banks: risk teams map important business services, test impact tolerances and track fixes. A Mapping agent keeps each service's chain of people, processes, technology, sites and suppliers current; a Scenario agent times recovery from failover tests and incidents; an Impact agent counts the customers and payments affected; and a Remediation agent re-tests each fix on the same clock. The Head of Operational Resilience checks every result, and the SMF24 accepts fixes and approves the self-assessment.
AI use cases in banking: a buyer's guide to agentic AI for bank and credit union operations →
Updated
Operational resilience management is the work of proving that each important business service stays within its impact tolerance, the most disruption the bank can tolerate, under severe but plausible scenarios. Since March 31, 2025, every UK bank must have mapped and tested to that level (FCA SYSC 15A, PRA SS1/21), and its board approves a written self-assessment. The mapping lives in spreadsheets and records that the CMDB, the third-party register and the continuity plans each contradict, and it is wrong after the next reorganization or hosting move.
Recovery times are what the tabletop room estimates, not what the last failover test measured. Customer harm is approximated from annual volumes. Two "independent" suppliers turn out to run in the same cloud, and breaches sit in an issue log as "in progress" with no owner, no funding and no date. Then the self-assessment is written by hand over six to eight weeks, and the evidence behind each statement is hard to find when the PRA asks. Operational Resilience Management puts agents on the evidence and keeps people on the decisions.
Estimated split of about six weeks (30 working days) to assemble and write the annual self-assessment by hand, against about 3 days to review the agents' cited draft; our arithmetic for the demo bank's 11 services, kept modest.
Seven agents map, time, count and draft; people confirm, check and accept every result.
A worked operational resilience example at Corvane Bank UK. Make a Faster Payment, for personal customers, has an impact tolerance of 4 hours. Yesterday a scenario test showed it would not hold if the payments gateway supplier were hit by ransomware. Here is Thursday, October 22, 2026, screen by screen, in the working solution.
Imogen's morning opens on a few numbers: 8 of 11 important business services within tolerance, 2 outside and 1 not yet tested; 17 of 22 scenario tests done; 6 open fixes, 1 overdue. Each service shows its slowest tested recovery against a tick for its tolerance. The agents' overnight brief cites every line, including that both Faster Payments gateways now host in one cloud region.
Make a Faster Payment opens as a chain of six links: start the payment, check and approve, route through the payments hub, send to the scheme, post to the account, tell the customer. The Mapping agent built it from four systems of record, Service Owner Tom Ashworth confirmed map v14 on Oct 9, and Imogen checked it: 135 resources, from 34 people and teams to 8 third parties. Above the chain, a clock runs from 0 to 7 hours with the 4-hour tolerance marked.
Recovers in 6 h 10 m; outside tolerance by 2 h 10 m.
Callum ran SCN-2026-18 from the 2026 test plan with the Scenario agent: Brackmoor Payments, which runs the primary Faster Payments gateway, has its platform encrypted at 10:00 a.m. on a Tuesday. Run on screen, the clock's needle steps through the chain, and the link that breaks, send to the scheme, lights up with its suppliers, its gateway keys and its runbook.
Payments stop routing at 18 m (the February gateway incident). The major incident is declared at 52 m (the same incident and the Brackmoor contract). The decision to fail over comes at 1 h 35 m (runbook RB-PAY-07 v6). Keys and certificates are exchanged at 3 h 25 m, and routing and screening re-pointed at 4 h 20 m, past the tolerance at 4 h. 41,000 in-flight payments are replayed at 6 h 10 m. Each step shows its evidence kind and a confidence from 0.89 to 0.95.
Why does the failover take so long? Three steps the May 14 test timed: keys and certificates exchanged by hand (1 h 50 m), routing and screening re-pointed (55 m), and 41,000 in-flight payments reconciled (1 h 50 m).
Imogen opens the evidence. All six steps are matched to sources between 5 and 8 months old, under the 12-month limit, so none is an estimate. Beside them sits failover test FT-2026-05-14, run by Payments Platforms on May 14, 2026, with its timings and its lesson: a standby with pre-exchanged keys would remove the longest step. Tabs open the incident, the runbook and the contract.
Total from the decision to fail over to all traffic on the alternate gateway: 4 h 35 m.
The Impact agent replayed the payments hub's volumes for Tuesday, October 13 through the 6 h 10 m disruption: 312,000 payments worth £48.6m delayed, for 268,400 customers, 4,870 of them with a support need. 38,200 were rent, bill or loan payments due that day. Its conclusion is that intolerable harm is likely, and a switch replays payday, Friday October 30, instead.
Counts only: no customer is named.
The Third-party agent read a supplier notice and found that the alternate gateway, Tolland Clearing, moved its hosting to Corrabeg Cloud, UK South, where Brackmoor already runs. Kwame Asante, the Third-Party Risk Manager, confirmed it the same afternoon. Corrabeg Cloud supports 6 important business services directly and 9 through the suppliers that host on it, and a test of that outage is proposed for Dec 2.
Callum was the maker, so Imogen signs the result as the checker, and REM-2026-031 goes on the remediation plan. The Remediation agent had already proposed three options and re-run each on the same clock: A, a warm standby gateway off Corrabeg Cloud, 3 h 5 m, inside tolerance by 55 m, £1.9m one-off and £420k a year; B, a two-hour recovery commitment from Brackmoor, still outside by 45 m; C, a priority queue for time-critical payments as an interim. Imogen recommends option A to the SMF24.
The person who runs a test can never sign it.
Only the SMF24 accepts a remediation item. Diane accepts option A by March 31, 2027, owned by Owen Pryce, Head of Payments Platforms, and funded from the 2027 resilience budget. Option C runs as the interim from Dec 15, 2026, and a live failover re-test is booked for March 2027.
Section 6 of the 2026 self-assessment, vulnerabilities and remediation, now lists REM-2026-031 with its owner, its date and Diane's acceptance, and all 10 sections are ready. The approval chain runs from Imogen to Diane, then the Board Risk Committee on Nov 19 and the board on Nov 26.
The same breach, seen by the five people who carry it: what their day looked like, and what it looks like now.
Seven agents map, time, count and draft; people confirm, check and accept every result.
Builds and keeps each service's chain of people, processes, technology, facilities and third parties, comparing the CMDB, the third-party register, continuity plans and runbooks with every confirmed map each night.
Runs severe but plausible scenarios on the chain and times each recovery step from failover tests, incident timelines, runbooks and contract clauses, citing each one.
Replays real volumes from the payments hub and the core banking system for the disruption window and counts payments, value, customers, customers with a support need and payments due that day.
Tracks supplier evidence and exit plans, traces where each supplier hosts, finds concentration and prepares the material third-party register.
Proposes fixes with owners, costs and dates, re-runs the scenario with each fix in place, tracks the plan and escalates overdue items.
Drafts the annual self-assessment by the sections of SYSC 15A.6.1R, cites every statement and flags a section when its evidence changes.
Links live incidents to the services they hit, starts the disruption clock and proposes lessons learned.
Checks every result; the SMF24 accepts fixes. The agents propose; a named person decides.
The Head of Operational Resilience can ask in plain words. Each answer cites its evidence and can open the screen it is about.
Which services are outside tolerance, and why?
Two of 11. Make a Faster Payment recovers in 6 h 10 m against 4 hours when the gateway supplier is hit by ransomware: the failover to the alternate gateway took 4 h 35 m in the May test. CHAPS for a home purchase recovered in 4 h 25 m against 4 hours in June; the runbook fix is due Dec 18. IBS-11 has no test yet this year; it is booked for Nov 18.
What if the gateway fails on payday Friday instead?
Replaying Friday Oct 30 volumes through the same 6 h 10 m: 401,000 payments worth £71.2m delayed for 331,000 customers, 61,400 of them rent, bill or loan payments due that day.
Which suppliers sit under more than three important services?
Five. Heskaby Hosting (9), Corrabeg Cloud (6 directly, 9 through fourth parties), Kestwick Software (5), Orrin Network Services (5) and Brackmoor Payments (4). Corrabeg Cloud also hosts both of your Faster Payments gateways.
What would bring it inside tolerance?
A warm standby gateway, keys pre-exchanged and routing automatic: the Remediation agent re-tested it at 3 h 05 m, inside by 55 m. It must not host on Corrabeg Cloud, where both current gateways run.
13 screens from the working solution, on its sample data. Pick one to see it large.
Tolerances, scenarios, evidence rules, roles, agents, SLAs and retention are settings. Every change needs a second administrator and goes on the record; a tolerance change also needs the SMF24.
| Setting | Default | Choose from |
|---|---|---|
| Impact tolerance, Make a Faster Payment | 4 hours; no more than 50,000 time-critical payments missing their due day | One time tolerance and a customer metric per service, approved by the board; reviewed by the Head, approved by the SMF24 |
| Scenario library | 8 scenario types: the FCA's five, plus ransomware, a shared supplier failing, and payday and month-end peaks | Severity steps up each year: On or Off |
| Evidence age | Older than 12 months is flagged | A step below 0.80 confidence is labeled an estimate |
| Agent confidence thresholds | Mapping 0.85 · Scenario 0.80 · Third-party 0.85 · Incident watch 0.90 | Per agent, with its version, prompt version and golden-set score |
| Reason codes | RT-01 to RT-06 to return a result, MR-01 and MR-02 for map changes, OV-01 and OV-02 for overrides | For example RT-01, evidence is older than 12 months; RT-04, the scenario is not severe enough |
| Review SLAs | Map changes 10 business days · scenario results 5 · a breach on the plan 10 | Reminders, then escalation to the Head of Operational Resilience |
| Overdue remediation | Escalates to the SMF24 after 10 business days | Evidence expiry warns the Third-Party Risk Manager 60 days before |
| Retention and access | Self-assessment records and every version kept 6 years | Customer impact aggregate only; names in maps shown as roles on shared screens; data kept in the United Kingdom |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
Sources: FCA PS21/3, Building operational resilience, and the FCA Handbook, SYSC 15A (fca.org.uk) · FCA, Operational resilience: insights and observations for firms, May 2024 · PRA SS1/21 · Federal Reserve SR 20-24, sound practices to strengthen operational resilience (federalreserve.gov) · Treasury Committee findings on bank IT outages, reported March 2025 (158 incidents and 803 hours across nine UK banks and building societies, January 2023 to February 2025) · "demo" = seen in the working solution, on its sample data · "target" = design goal, measured in the live solution · "typical" = the published figure named here · "estimated" = our arithmetic for the demo bank, kept modest. Corvane Bank UK, its suppliers and services, and the people named on this page are fictional: characters and sample data in the working solution.
Operational Resilience Management is operational resilience management software for banks: risk teams map important business services, test impact tolerances and track fixes. A Mapping agent keeps each service's chain of people, processes, technology, sites and suppliers current; a Scenario agent times recovery from failover tests and incidents; an Impact agent counts the customers and payments affected; and a Remediation agent re-tests each fix on the same clock. The Head of Operational Resilience checks every result, and the SMF24 accepts fixes and approves the self-assessment.
It is a bank's ability to keep its important business services running, or recover them in time, when something severe goes wrong: a cyber attack, a lost site, a failed supplier, corrupted data. In the UK, the FCA (SYSC 15A) and the PRA (SS1/21) require banks to set impact tolerances, map and test their services, and fix what fails. Large US banks follow the interagency sound practices (Federal Reserve SR 20-24), and the EU's DORA has applied since January 17, 2025.
An impact tolerance is the most disruption an important business service can suffer before it causes intolerable harm to customers, set as a time plus customer metrics and approved by the board. In the demo, Make a Faster Payment has a tolerance of 4 hours and no more than 50,000 time-critical payments missing their due day. The tolerance clock shows each scenario against it, and a change needs the SMF24's approval.
An analyst runs a scenario from the year's test plan with the Scenario agent, which steps through the service's chain and times each recovery step from failover tests, incident timelines, runbooks and contract clauses, citing each one. A step without evidence under 12 months old is labeled an estimate. The result, such as "Recovers in 6 h 10 m; outside tolerance by 2 h 10 m", goes to a different person to sign or return with a reason code.
Yes. The Third-party agent traces where each material supplier hosts and flags when a backup shares a failure with the primary. In the demo it found that both Faster Payments gateways host in the same cloud region, before the fix was chosen. The Third-Party Risk Manager confirms each finding, and the agent never contacts a supplier on its own.
The Self-assessment agent drafts the document by the sections of SYSC 15A.6.1R from the record: services and tolerances, mapping, testing, lessons learned, remediation, third parties, communications and methodology. Every statement cites its evidence, and a section is flagged when its evidence changes. The Head of Operational Resilience prepares it and the SMF24 approves it before the Board Risk Committee and the board.
Yes. The agents propose, time, count and draft; they never sign a result, accept a fix, approve a tolerance or change a confirmed map. Every map change, scenario result, tolerance change and remediation item has a maker and a different checker, and every override needs a reason code. Every action by a person or an agent is on the audit trail.
The Agentic Solution Engine builds and deploys it from your requirements and documents: your important business services, tolerances, test plan, maps and systems of record. It goes live once every quality gate has passed, and the agents start from your own evidence rather than the demo's.
An approved ALCO pack in 3 days, with every change explained and cited.
1-min demoInterest Rate Risk (IRRBB) ManagementEvery key assumption checked against what members actually did, with proof for examiners.
1-min demoLiquidity Risk MonitoringEvery morning, each liquidity move explained by the accounts behind it, before 7:30 a.m.
1-min demoWe'll run Operational Resilience Management on one of your important business services, with your own maps, test reports and incident timelines.