Operational resilience automation is the use of software, and now AI agents, to do the evidence work that the FCA's SYSC 15A and the PRA's SS1/21 demand of a bank: comparing service maps with the systems of record, finding the measured duration of each recovery step, counting the customers and payments a disruption would hit, tracking every fix and drafting the written self-assessment. That work is most of the effort in an operational resilience programme, and it is mechanical enough to automate. What cannot be automated is the judgement the rules assign to people: which services are important, what harm is intolerable, whether a breach is acceptable, which fix to fund. Botminds' Operational Resilience Management is an agentic solution built on that split, with seven agents that map, time, count and draft, and people who confirm, check and accept every result.
The examples come from the solution's fictional sample bank, Corvane Bank UK, on one October morning in 2026. Rules and regulators' findings are quoted and linked where they appear.
Seven agents in operational resilience automation, and the person who decides after each
Agent
Mapping agentCompares the CMDB, supplier register, continuity plans and runbooks with every confirmed service map each night, and proposes the differences with sources.
Never: changes a confirmed map
A person decides
Service Owner, then HeadConfirms or rejects each change; the head of operational resilience checks it before a new map version is published.
Agent
Scenario agentTimes each recovery step of a severe but plausible scenario from failover tests, incident timelines, runbooks and contract clauses, citing each.
Never: signs a result
Agent
Impact agentReplays a real day's payment volumes through the disruption and counts payments, value, customers and customers with a support need.
Never: reads or shows an individual customer's data
Agent
Third-party agentTraces where each supplier hosts and flags shared failure points, exit plan gaps and expiring evidence.
Never: contacts a supplier, or rates one, on its own
A person decides
Head of Operational ResilienceSigns the scenario result as checker, or returns it with a reason code; the analyst who ran it cannot sign it.
Agent
Remediation agentProposes fixes with owners, costs and dates, and re-runs the scenario with each in place.
Never: accepts an item
A person decides
SMF24Accepts one fix into the plan with an owner, a date and funding.
Agent
Self-assessment agentDrafts the self-assessment from what was signed and accepted, cites every statement, and flags a section when its evidence changes.
Never: approves, or calls a service resilient without a signed result
Agent
Incident watch agentLinks live incidents to the services they hit and starts the disruption clock.
Never: declares a major incident
A person decides
BoardApproves the services, tolerances and self-assessment, and judges which tested failures it accepts.
Can operational resilience be automated?
The evidence work can be automated; the decisions cannot. The FCA's rules ask a bank to keep five things true at once: a list of important business services, a tolerance for each, maps detailed enough to find vulnerabilities and fix them, a testing plan with tests, and a written self-assessment its board approves (SYSC 15A.2 to 15A.7). Each one rests on evidence that lives in other systems and goes stale: the configuration database, the supplier register, test reports, incident timelines, payment volumes. Keeping the evidence current and assembled is exactly the kind of work agents do well.
The rules are equally clear about what is left. Boards must approve the important business services and the tolerance set for each (PRA SS1/21, 7.1). When a scenario shows a breach, the board and senior management decide whether that breach is acceptable (SS1/21, 6.12; who maps, tests, checks and signs quotes both passages). And remediation plans must be "approved, fully funded, and appropriately governed" (FCA, May 2024). None of those can be delegated to software, and no honest product claims otherwise.
What can AI do in operational resilience, task by task?
AI can do the chasing, finding, counting and first drafting, which is where the working days go. The solution's own estimate for the sample bank's annual self-assessment, 11 services and modest assumptions, puts about 30 working days into those tasks by hand and about 3 into reviewing the agents' cited draft. The more interesting finding is how the remaining time is spent.
Where an operational resilience team's days go, by hand and with automation
By hand, about 30 working days
- Chasing service owners for maps · 26.7%
- Finding recovery evidence · 23.3%
- Writing the sections · 20%
- Counting customers and payments · 13.3%
- Updating the remediation log · 10%
- Answering reviewers · 6.7%
Reviewing a cited draft, about 3 days
- Confirming map changes · 16.7%
- Checking recovery evidence · 16.7%
- Reviewing the sections · 33.3%
- Checking impact counts · 8.3%
- Checking the remediation plan · 8.3%
- Answering reviewers · 16.7%
By hand, the writing is a fifth of the work and the rest is gathering. With the gathering automated, reviewing the document the board will read becomes the largest single share, and answering reviewers grows relative to everything else, because every answer is now one click from its source. The head of operational resilience's time moves from assembling evidence to judging it, which is the part of the job the rules care about.
Can AI map important business services?
AI can keep a service map current, but it should not decide which services are important. Identifying important business services is a judgement about harm to clients and markets: SYSC 15A.2.4G lists thirteen factors, from the kind of clients served and how vulnerable they are to substitutability and time criticality, and the FCA has warned that a service "should be determined without reference to response or recovery capabilities" (FCA, May 2024). That list belongs to people and, finally, the board.
Keeping the map of an agreed service current is different work. The FCA's 2026 review praised firms whose mapping uses "multiple data sources used to ensure accuracy and comprehensive coverage" and criticised maps that look mostly at technology (FCA, March 2026). In the sample bank, the Mapping agent compares four systems of record with all 11 confirmed maps each night. At the moment of the sample it had nine proposed differences waiting, among them a change in where the alternate payments gateway hosts and two of three certified night-shift staff moving teams, each with its source and a confidence score. A low-confidence change, one at 0.79 in the sample, is marked for judgement rather than proposed as fact. None reaches the map until the service owner confirms it and the head checks it. Why maps need checking every night sets out what drifts and how fast.
Can an agent sign a scenario test result?
No, and a well-designed system makes it impossible rather than discouraged. The FCA's rule leaves the firm answerable for the quality and accuracy of every test, whoever runs it (SYSC 15A.5.5G), and a signature means a named person has looked at the evidence. In the solution, the Scenario agent prepares the result with the analyst who runs the test; a different person, usually the head, signs it or returns it with a reason code. The agent is neither maker nor checker.
A scenario result the agent prepared and a person must sign
What the agent can do is make the signature informed. Each of the six recovery steps above shows its evidence kind and a confidence between 0.89 and 0.95; a step with no evidence under 12 months old would be labelled an estimate and sit below 0.80. The checker sees which minutes are proven and which are guesses before deciding, which is the point of timing each step from evidence.
What do the FSB's 2026 practices say about AI agents and human oversight?
The Financial Stability Board's final report on AI adoption, published on October 15, 2026, treats agents as a distinct risk and names human oversight as one of its twelve sound practices. Its list of agentic risks includes "Additional risks from inadequate human oversight", and it explains why oversight gets harder once an agent is acting rather than advising.
This challenge is further compounded in live environments, where opportunities for human intervention may be limited once actions are being taken.
Financial Stability Board, Sound Practices for Responsible Adoption of AI, final report, 15 October 2026
Resilience work has a convenient property here: almost nothing an agent does in it is a live action. Proposing a map change, timing a step, counting payments or drafting a section changes no system and moves no money; a person acts on it later. The design question is therefore not how to watch agents in real time but how to keep every agent output a proposal until a named person turns it into a decision. Sound Practice 12 of the same report, on third-party AI risk management, applies as well: an agent product is itself a third party, and belongs in the bank's own map.
In the United States, the April 2026 interagency model risk guidance, SR 26-2, deliberately leaves generative and agentic AI outside its scope (Federal Reserve SR 26-2; the passage is quoted in customer risk rating model). A bank with a US parent cannot point to model validation as its control for resilience agents; it needs controls of its own, like those below.
Seven agents, seven limits: the matrix to ask any vendor for
A useful test of any operational resilience automation is whether its vendor can write down, for each agent, what it may do, what it may never do, and which person decides. The table is that matrix for the solution; a product that cannot produce one has not decided where its limits are.
What each operational resilience agent may do, may never do, and who decides
| Agent | May do | May never do | Who decides |
|---|---|---|---|
| Mapping | Propose map differences from the CMDB, supplier register, plans and runbooks, with source and confidence | Change a confirmed map | Service owner confirms; head checks |
| Scenario | Time each recovery step from tests, incidents, runbooks and contracts; label steps without recent evidence as estimates | Sign a result | A checker who did not run the test |
| Impact | Count payments, value, customers and customers with a support need from aggregate volumes | Read or show one customer's data | Head uses the counts; board sets tolerances |
| Third-party | Trace hosting and fourth parties, flag concentration, prepare the supplier register | Contact or rate a supplier on its own | Third-party risk manager |
| Remediation | Propose fixes with owners, costs and dates; re-test each on the same scenario; escalate overdue items | Accept an item into the plan | SMF24 |
| Self-assessment | Draft each section with citations; flag a section when its evidence changes | Approve, or call a service resilient without a signed result | Head prepares; board approves |
| Incident watch | Link live incidents to services, start the disruption clock, propose lessons learned | Declare a major incident | The bank's incident process |
How do you keep humans in control of resilience testing?
Humans stay in control when every agent output is a proposal, every proposal carries its evidence and confidence, and every decision is made by someone other than the person who prepared it. Those three rules are cheap to state and easy to erode, so the controls that enforce them should be settings, versioned and changed only with a second approver.
In the sample bank's settings, each agent has a version, a prompt version, a model and a confidence threshold: 0.85 for mapping, 0.80 for scenario timing, 0.85 for third parties and 0.90 for incident watch. A new agent version runs on a golden set of 60 past results before release, and a second administrator approves it. Evidence older than 12 months is flagged, and a step below 0.80 confidence is labelled an estimate. A person can override any agent value, but only with a reason code, so a run of overrides on one agent is visible as a pattern rather than lost in email.
The FCA's 2026 review gives one more reason to keep confidence visible: it listed as good practice self-assessments that "include confidence ratings in testing output, to help understand how mature resilience approaches and options are" (FCA, March 2026). An agent that reports confidence on every step gives the board that rating for free.
A maker and a checker on every tolerance, map and result
Who accepts a remediation item?
A senior manager accepts it, in a UK bank usually the SMF24, because accepting a fix means committing money and a date. The FCA expects remediation plans "approved, fully funded, and appropriately governed to ensure delivery, with evidence at closure through repeated scenario tests" (FCA, May 2024), and its 2026 review criticised firms with no recorded actions, owners or target dates for their fixes (FCA, March 2026; the self-assessment guide quotes the review).
Automation helps most with the comparison that precedes the decision. For the sample bank's payments gateway breach, the Remediation agent proposed three options and re-ran the same scenario with each in place: a warm standby gateway hosted away from the shared cloud, recovering in 3 h 5 m against the 4-hour tolerance, for £1.9 million one-off and £420,000 a year; a two-hour recovery commitment from the supplier, still 45 minutes outside; and a priority queue for time-critical payments, which cuts harm but not recovery time. The SMF24 accepted the first, owned and funded for March 31, 2027, with the queue as an interim from December 15. The same re-test is what will prove the fix at closure.
What operational resilience automation does not fix
Automation cannot create evidence that does not exist, and that is its main limit. If a recovery step has never been tested, rehearsed or contracted, the honest output is an estimate, and the fix is a test, not software. Four other limits are worth stating before any purchase:
- Records of poor quality stay poor. An agent comparing a stale CMDB with a stale supplier register finds the disagreements, not the truth. The first months surface a backlog of differences that people have to resolve.
- Suppliers that share nothing stay opaque. Tracing where a supplier hosts relies on its notices, contracts and assurance reports. Where a supplier gives none, the agent can only flag the gap.
- Judgement stays judgement. Choosing services, setting tolerances and accepting breaches are board decisions under SS1/21; an agent can supply the counts and the options, nothing more.
- The rulebook is UK-first. The solution drafts by the sections of SYSC 15A.6.1R; a US bank working to the interagency sound practices in SR 20-24, aimed at the largest firms, would configure its own framework.
Six questions to ask of any operational resilience automation before you buy
- Can it show, for every agent, what it may never do?
Good: a written limits matrix enforced by the system. Red flag: "it's configurable".
- Does every recovery time open the evidence it came from?
Good: one click to the test report, incident timeline, runbook or contract passage. Red flag: a number with a label.
- How does it show a step it has no recent evidence for?
Good: labelled an estimate, with an evidence-age rule you set. Red flag: every minute looks equally certain.
- Can the person who ran a test sign it?
Good: no, enforced. Red flag: a role permission an administrator can change alone.
- What happens to a map change it is unsure of?
Good: flagged for judgement below a stated threshold. Red flag: applied automatically.
- Can internal audit export the evidence without asking you?
Good: a pack with every version, hashed, customer data reduced to counts. Red flag: a services request.
To see the seven agents on one important business service, with your own maps and test reports, start from Operational Resilience Management; what you bring to start lists the records the agents need.
Questions people ask
What is operational resilience automation?
It is software, increasingly AI agents, that does the evidence work of an operational resilience programme: keeping service maps current, timing recovery from tests and incidents, counting customer harm, tracking remediation and drafting the self-assessment. Under SYSC 15A and SS1/21 the decisions on services, tolerances, breaches and fixes stay with named people and the board.
Can AI replace operational resilience scenario testing?
No. An agent can replay a scenario on a service map and time each step from existing evidence, but the evidence has to come from somewhere: failover tests, simulations, real incidents. The FCA has pushed firms from desk-based tests toward a wider range of tests that produce measured data, and automation depends on that data rather than replacing it.
Do AI agents in operational resilience count as models?
For UK rules the question does not arise in those terms; the bank is responsible for the quality of its testing and records either way. In the US, the April 2026 model risk guidance excludes generative and agentic AI from its scope, so a bank needs its own controls: versions, thresholds, golden-set testing and a second approver for changes.
How long does it take to automate an operational resilience programme?
The software is the shorter part; the bank's own records set the pace. A first important business service can run on its existing maps, test reports and incident timelines, and the agents' first job is usually to show where those records disagree.
Does automation help with the FCA's 2027 incident reporting rules?
It can prepare the inputs: which services an incident hit, when the disruption clock started and how many customers were affected. The decision that an incident meets a reporting threshold, and the report itself, remain the firm's; the rules apply from 18 March 2027.
Should the agents be in the bank's own resilience map?
Yes. An agent product used to run the programme is a third-party technology dependency like any other. The FSB's 2026 report names third-party AI risk management as its twelfth sound practice, and the same mapping, testing and exit planning apply.