A wider definition of bank reliability
Banking resilience used to be discussed mainly in terms of keeping systems online, maintaining adequate capital and recovering from isolated outages. Today, a customer can experience a service failure even when a bank’s own core systems are functioning. An identity provider can become unavailable, a cloud service can fail, a payments intermediary can stop responding, or a telecommunications disruption can prevent an otherwise healthy institution from serving customers. That wider operational footprint has changed how boards should ask whether the bank can continue delivering essential services.
The Basel Committee’s Core Principles for effective banking supervision explicitly address operational risk and resilience, including the need to identify and protect critical operations, respond to disruptions and learn from incidents. The emphasis is not on promising that nothing will ever fail. It is on understanding which failures matter most and what the institution can still deliver when they occur. BCBS
Start with the customer service, not the technology inventory
A bank may maintain detailed inventories of servers, applications and outsourced contracts without understanding the sequence of activities required to complete a customer payment or release a business loan. Mapping a critical service in reverse—from the customer outcome to the people, data, systems and external counterparties that enable it—can reveal dependencies that remain invisible in departmental reporting. A mobile transfer, for example, may rely on authentication, fraud screening, account data, liquidity controls, clearing access and customer notifications.
This customer-outcome approach also helps institutions distinguish a critical service from an important internal system. The service may remain deliverable through an alternative process even if a component is unavailable. Conversely, one apparently modest component can become a single point of failure when several critical services depend on it. Basel’s operational-resilience guidance identifies the mapping of interconnections, business-continuity testing and third-party dependency management as related elements of a coherent framework. Basel Resilience
Third-party providers change the risk, not the accountability
Outsourcing can improve flexibility, specialist access and the pace of technology development. It also creates a second layer of questions: what happens if the provider fails, what information will the bank receive during an incident, and can the bank move operations without interrupting customers? Contractual service-level commitments are relevant, but they cannot by themselves restore a payment system or ensure data is portable at the moment of crisis.
The Financial Stability Board’s third-party risk toolkit encourages institutions and authorities to identify critical external services and manage exposure throughout a relationship’s lifecycle. Its approach is deliberately risk-based rather than a universal checklist. For banks, this means differentiating between a replaceable support vendor and a concentrated service provider whose outage could interrupt a substantial share of customer activity. FSB Toolkit
Concentration can hide behind multiple contracts
A board may take comfort from having several technology vendors while overlooking the fact that they use the same underlying infrastructure, subcontractor or geographic facility. Two services purchased from different firms may therefore fail together. Supplier diversification is not meaningful unless it extends to the dependencies that matter. Exit planning should test whether data, personnel, interfaces and licences can be transferred within a credible timeframe.
This does not mean every dependency must be replicated at unlimited cost. A risk-based approach asks which services justify additional redundancy, which interruptions are tolerable and where a controlled temporary workaround would protect customers more efficiently. Cost discipline and resilience are compatible when the bank can articulate what it is buying and why.
Regulation is becoming more operationally specific
The European Union’s Digital Operational Resilience Act, known as DORA, has applied since 17 January 2025 to financial entities within its scope. Its framework addresses information and communications technology risk, incident management, resilience testing and ICT third-party risk. Although requirements depend on the type and size of entity, DORA reflects a broader supervisory shift toward evidence that digital operations can withstand disruption. DORA
The European Banking Authority has also explained the importance of registers covering contractual arrangements with ICT third-party providers. Those registers support institutional monitoring and supervisory oversight; they are not simply administrative lists. Maintaining accurate information about subcontractors and critical functions becomes important precisely when a bank must understand the consequences of an incident quickly. EBA Registers
Measure disruption in terms customers recognise
Technical measures such as server availability and average recovery time remain useful. They are incomplete when they obscure customer effects. A bank can report that a platform recovered within an internal target even though thousands of customers could not access wages, settle bills or complete time-sensitive business transactions. Boards should therefore ask about failed or delayed transactions, affected customer groups, unresolved exceptions and the length of time required to restore trustworthy records.
An effective measurement framework may include operational indicators and outcome measures together: recovery time, backlog reduction, transaction integrity, reconciliation quality, complaints and the number of customers requiring manual intervention. These measures allow leadership to distinguish an incident that was technically short from one that created material customer harm.
Incident exercises need decisions, not theatre
A tabletop exercise can look impressive while avoiding the decisions that would be uncomfortable during a real event. A stronger scenario forces participants to choose between competing priorities: whether to pause payments, how to communicate uncertainty, when to escalate to a regulator, or whether to activate a provider exit plan before the full scale of an outage is known. It should also test how the organisation functions without a crucial data feed or senior decision-maker.
Exercises are useful only when they produce changes. Institutions should record the assumptions that failed, the manual workarounds that proved impractical, and the authorities required for emergency actions. A clear owner and deadline for correcting weaknesses is more valuable than a report declaring that the exercise was successfully completed.
Data integrity deserves as much attention as availability
Financial services cannot always resume safely by bringing an application back online. If balances, transaction statuses or audit logs may have been corrupted, restoration can create additional risk. A cautious recovery sequence may involve validating data, reconciling records with counterparties and restricting certain transactions until the bank has confidence in the information displayed to customers.
This distinction matters for cyber incidents as well as ordinary technology faults. A service that returns quickly with unreliable records can undermine trust more severely than one that communicates a controlled delay. Recovery planning should therefore establish who can certify data integrity and how exceptions are managed after systems restart.
Governance should connect business and technical teams
Operational resilience becomes a governance problem when responsibility is split into isolated dashboards. Technology teams monitor applications, procurement monitors contracts, finance monitors costs and customer-service teams manage complaints. None of these perspectives is sufficient alone. For each critical service, a named business owner should understand dependencies and have access to the people who can make recovery decisions.
Boards need not approve every technical architecture choice. They do need to challenge the institution’s tolerance for disruption, the evidence used to support that tolerance and the funding assigned to known vulnerabilities. The strongest questions are practical: which service would hurt customers most if it failed tomorrow, which outside party could stop it, and what has a recent exercise taught us?
Making resilience a design decision
Resilience is easiest to improve before a new product or supplier arrangement becomes embedded. Product approval should include an explicit view of fallback procedures, customer communications, data portability and the point at which a disruption becomes unacceptable. A fast launch that creates an unmanageable dependency may prove expensive later, even when the initial contract looks efficient.
Banks also need to avoid the opposite mistake: treating every possible failure as a reason to delay change indefinitely. The objective is proportionate preparation. A clearly documented critical-service map, tested recovery options and trustworthy incident information help institutions innovate with a more realistic understanding of risk.
A practical test for leadership teams
One useful exercise is to choose a critical customer journey and ask every responsible team to describe the same failure scenario independently. Technology staff might identify the application outage, while the payments team highlights delayed clearing, compliance raises reporting issues and customer service anticipates complaints. Differences in those accounts show where governance is fragmented. A single timeline can then identify what must be restored first, who can authorise an emergency workaround and which customers need timely information.
Banks should also challenge optimistic recovery assumptions. A vendor contract may specify a recovery objective, but the institution needs to know whether that objective has been achieved under realistic conditions, whether the necessary staff would be available and how exceptions are cleared after the primary service returns. Testing can distinguish a process that exists on paper from one that will work during a regional disruption.
Finally, lessons should influence investment choices. If the same weakness appears in successive exercises, it should be visible in the institution’s risk appetite discussion and capital planning for technology. Resilience spending then becomes a prioritised response to identifiable customer consequences rather than a general appeal for more systems and larger budgets.
The question boards should ask next
The central issue is no longer whether a bank has a business-continuity document or a sophisticated cybersecurity programme. It is whether the institution can sustain the services on which households and companies depend when part of its operating network fails. That requires visibility across internal functions, contractual boundaries and payment chains.
For banks investing in digital channels and external partnerships, resilience will increasingly depend on how well these connections are governed. The institutions that make dependencies visible, test difficult decisions and measure customer outcomes will be better placed to recover from disruption without confusing technical recovery with a genuine return to service.
References
Basel Resilience — https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/orr/20
EBA Registers — https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act/preparation-dora-application