Business Continuity | How Banks Keep Critical Services Running During Disruption

Continuity begins with the service, not the building

Traditional continuity plans can be imagined as backup offices: if one site fails, staff move somewhere else. That remains useful for some disruptions, but modern banking depends on far more than premises.

A critical payment service can depend on:

• customer authentication;
• core ledger availability;
• payment-routing software;
• telecommunications;
• fraud controls;
• settlement access;
• database integrity;
• third-party cloud or network providers;
• operations staff;
• incident command.

A second office does not help if the same failed identity service or network dependency sits underneath both offices.

The first question is: which operations are critical?

Not every bank process has the same urgency. A marketing report can wait. A payroll payment, customer cash access or settlement obligation may not.

The bank therefore identifies critical operations: services whose disruption could threaten the institution, customers, financial stability or the wider economy beyond tolerable limits.

The Basel Operational Resilience guidance centres this critical-operations view.

Disruption tolerance gives the plan a clock

A continuity plan needs more than “restore as soon as possible.” It needs an operating boundary.

How long can a critical operation be unavailable before customer harm, financial loss or system impact becomes unacceptable? How much data loss is tolerable? How much transaction backlog can accumulate?

critical operation → disruption tolerance → recovery strategy → tested evidence that the strategy can work inside the tolerance.

Recovery time and recovery point answer different questions

Concept	Question
Recovery time objective	How quickly should the service or system be restored?
Recovery point objective	How much data loss or rollback can be tolerated?

A database can come back quickly and still be unusable if the last several hours of transactions are missing. Speed and data integrity therefore need separate design.

Dependency mapping reveals the hidden bank

A customer sees one mobile-app button. Behind it may be dozens of systems, vendors and teams.

Dependency mapping asks what the critical operation needs to function:

• people and specialist skills;
• applications and databases;
• identity and access services;
• networks and telecommunications;
• facilities and utilities;
• data feeds;
• payment and settlement infrastructure;
• third-party vendors;
• intragroup entities;
• manual fallback processes.

Once the map is visible, the bank can find single points of failure that ordinary organisational charts hide.

Redundancy only works when the copies do not share the same failure

Two data centres connected to the same power grid, one network provider or one identity service can fail together.

Resilience therefore asks whether redundancy is genuinely independent enough to survive the scenario being tested.

Two copies are not two routes if one hidden dependency controls both.

Third-party continuity is bank continuity

Banks increasingly depend on external technology, cloud, payments, telecommunications, data and specialist service providers. A vendor outage can become a bank outage.

The bank therefore needs to understand the provider’s resilience, contractual obligations, concentration, substitution options and recovery dependencies.

Outsourcing execution does not outsource accountability to customers or supervisors.

Business continuity and disaster recovery overlap but are not identical

Discipline	Main focus
Business continuity	Keep critical business services operating through disruption.
Disaster recovery	Restore technology, infrastructure and data after a major failure.

A technology system can recover while the business process remains broken because staff, access, vendors or data reconciliation are not ready.

Incident response begins before continuity recovery

The bank first needs to detect and contain the event. A cyber incident may require isolating systems before restoring them. A duplicated-payment incident may require stopping new releases before clearing the backlog.

Response and recovery therefore form one sequence:

detect → contain → protect critical operations → recover → reconcile → communicate → learn.

A backup can restore yesterday’s mistake

Backups protect against data loss. They do not guarantee data correctness.

If corruption entered the database three days ago and every backup since then contains the same corruption, restoring the newest backup simply restores the problem.

Recovery plans therefore need clean restore points, validation and reconciliation—not just copies.

Manual fallback is useful only if people can still perform it

A continuity plan may say “process critical transactions manually.” That can work for low volumes. It can fail completely when a digital bank processes millions of transactions and staff have not practised the manual route.

A fallback must be sized, staffed and tested against realistic volumes.

People are a continuity dependency too

A pandemic, evacuation or transport disruption can make systems available while specialists are not. A critical operation that depends on three people in one location has a human concentration risk.

Cross-training, remote capability, alternate decision-makers and documented procedures reduce dependence on one individual or site.

Decision rights must survive the disruption

Normal governance can require several committees and approvals. During a crisis, the bank needs pre-agreed authority for incident command, emergency spending, system isolation, customer communication and recovery prioritisation.

The plan should know who acts when the ordinary chain is unavailable.

Communication is part of continuity

Customers need to know which services are affected, what remains available and what action they should take. Staff need one operating picture. Supervisors and counterparties may require timely information.

Silence creates uncertainty; inaccurate reassurance can create a second failure.

Continuity therefore includes approved communication routes and factual status updates.

A worked miniature

A bank’s primary data centre loses power. The mobile interface remains online but cannot reach the core ledger. The bank’s continuity design automatically shifts ledger processing to a secondary site. Customer authentication and payment routing use independent infrastructure, so critical payments continue.

Non-critical analytics and marketing systems remain offline to preserve recovery capacity. Operations reconcile transactions after failover and confirm that no duplicate settlement occurred.

The continuity objective was not “make everything look normal immediately.” It was “keep critical banking functions within tolerance and restore the rest in order.”

Testing is where a continuity plan becomes evidence

A plan can look excellent in a document and fail in the first real incident. Banks therefore use different tests:

• tabletop exercises;
• call-tree and decision-right tests;
• technology failover tests;
• backup restore tests;
• third-party exercises;
• simulation of unavailable staff or sites;
• volume and capacity tests;
• cyber recovery exercises.

The test should produce findings and repairs, not merely prove that the exercise occurred.

The scenario should attack the dependency, not merely the label

Testing “data-centre failure” is useful. Testing “loss of the one identity service used by both data centres” can reveal more.

Good resilience testing therefore rotates the failure across shared dependencies and assumes that several things can go wrong together.

Cyber recovery may require rebuilding rather than restarting

After a hardware failure, restarting from a known-good state may be enough. After a sophisticated cyberattack, the bank may not know which credentials, systems or data were compromised.

Recovery can therefore require clean-room rebuilding, credential rotation, forensic validation and staged reconnection.

Speed matters, but restoring compromised infrastructure too quickly can extend the incident.

Liquidity continuity is part of operational continuity

A bank may have enough liquid assets but be unable to mobilise them if collateral systems, settlement access or authorised staff are unavailable.

This is why The Contingency Funding Plan includes operational readiness as well as financial options.

Continuity must include reconciliation after recovery

A failover can keep transactions flowing while producing timing differences, duplicates or partial messages. The bank therefore needs to prove that ledgers, settlement systems and customer accounts agree after normal service resumes.

Recovery is incomplete until the bank knows what happened during the degraded state.

Lessons learned should change the system

After an incident or exercise, the bank should identify which assumptions failed, which dependencies were hidden and which decisions were too slow.

The continuity plan should then change. A lesson that never alters architecture is only a story about the past.

Operational resilience is the larger frame

Business continuity is one important component of operational resilience. The broader resilience discipline also includes governance, operational risk, incident management, third-party dependencies and resilient technology.

The Basel Committee’s current guidance states that banks should be able to withstand, adapt to and recover from operational disruption while continuing critical operations.

Read Basel Committee — Operational Resilience.

Four misconceptions to remove

Misconception	Better model
“Business continuity means having a backup office.”	Critical operations depend on technology, data, people, vendors, facilities and infrastructure together.
“Redundancy means two copies.”	Two copies can share one hidden dependency and fail together.
“A backup guarantees recovery.”	The backup must be clean, accessible, tested and reconciled after restoration.
“Recovery is complete when systems are back online.”	The bank must also reconcile transactions, restore customer service, close exceptions and learn from the event.

A mastery test

1. Why should continuity planning begin with critical operations rather than buildings?
2. What does disruption tolerance add to a recovery plan?
3. Why can two redundant systems still fail together?
4. How do third parties become part of the bank’s continuity risk?
5. Why is reconciliation necessary after failover and recovery?

If those answers connect, business continuity becomes visible as a prioritised promise to society: when the bank cannot keep everything normal, it must know what absolutely has to continue, how long it can be impaired and how to prove that the recovery is real.

---