A banking application can be available while an essential service remains unusable. A customer may log in successfully but fail to complete a payment. A business may submit payroll instructions without knowing whether employees will receive the money. Reliability therefore needs to be assessed through the outcome the customer depends on, including what happens when part of the operation fails.
For banks, that creates a challenge extending beyond technical maintenance. Customer services rely on records, employees, suppliers and payment connections. Restoring one system may not restore the complete activity. The bank must understand those dependencies before disruption, then establish how it will continue or recover the service within an acceptable period.
Operational resilience brings these questions into management decisions. It concerns the ability to withstand disruption and deliver critical operations, rather than assuming every incident can be prevented. The investment case includes the costs of recovery, customer harm and the practical limits of alternative arrangements.
Start with the service customers need
A technical inventory lists applications and infrastructure. A service assessment asks what a customer needs to accomplish and which resources make that possible. These views overlap, but they answer different questions. A bank can maintain an accurate technology register without knowing how a failure affects the completion of customer transactions.
The Basel Committee's Principles for operational resilience provide an international reference for banks' ability to withstand operational disruptions. They are supervisory principles, with implementation depending on the relevant jurisdiction. They should not be presented as identical legal requirements for every bank worldwide.
In practice, a service perspective can change priorities. A modest internal component may support several customer activities, while a larger application may be less critical during a short outage. Allocating investment by system size or visibility alone can overlook that distinction. Management needs an explanation of the service consequences.
Availability and completion are different measures
Uptime records whether a system is available under its defined measurement. It may not capture rejected transactions, delayed processing or errors that customers discover later. A favourable percentage can therefore coexist with a significant service problem if the measurement excludes an important stage of the process.
Banks can supplement technical measures with evidence about completed activity. For a payment service, that could include whether instructions were accepted, processed and reconciled correctly. The exact measures depend on the bank's role and the payment arrangement. The objective is to identify failure between stages rather than equate a responsive interface with a successful outcome.
No single indicator will explain every disruption. A dashboard should make its coverage and exclusions understandable so that decision-makers can interpret the result. A service that appears healthy because rejected requests disappear from reporting offers little reassurance. Measurement design influences what management sees and which problems receive attention.
Disruption has different consequences for different users
The impact of an interruption depends on timing and the customer's circumstances. A brief delay may be manageable for one payment but serious for a transaction with a deadline. A business waiting to pay employees or suppliers may need information quickly even when the bank expects a relatively short technical recovery.
The UK's Financial Conduct Authority explains its operational resilience requirements through important business services and impact tolerances. Firms within scope had until 31 March 2025 to ensure they could operate those services within their tolerances. This is a specific UK framework, not a universal deadline for banks in other jurisdictions.
The broader analytical lesson is that recovery planning should reflect consequences. Banks need to understand which customers may struggle to use alternative channels and when a delay becomes materially harmful. That assessment should inform communication, contingency resources and the scenarios used in testing.
Dependency mapping must reach beyond the first supplier
A customer service can rely on several organisations. A software supplier may depend on a hosting company, a telecommunications provider or an identity service. The bank may contract with only one of them while still being exposed to a failure further along the chain.
The Financial Stability Board's third-party risk toolkit addresses critical service relationships and dependencies. It is designed to complement existing standards and guidance, recognising differences between jurisdictions. Its usefulness lies in helping institutions frame questions about the full relationship rather than assuming a signed contract resolves operational exposure.
For a bank, the practical assessment includes what it can observe and what it cannot readily replace. A provider may offer reliable normal service while leaving customers with limited alternatives during a wider failure. Understanding that limitation supports a more realistic recovery plan and a better-informed decision about concentration.
Separate providers can share a point of failure
Using two suppliers does not necessarily create two independent routes. Both may rely on the same underlying infrastructure or a shared connection. During normal operations, the arrangements can appear separate. Under stress, the common dependency may become the factor that determines whether either route remains available.
An illustrative bank might maintain two customer contact systems that both require the same authentication service. If authentication fails, neither system provides the intended alternative. This example does not describe a particular institution. It shows why resilience analysis needs to examine dependencies rather than count vendors.
Removing every shared dependency would be expensive and may be impractical. The decision concerns which dependencies are significant enough to justify an alternative, additional testing or a different recovery approach. A clear account of remaining exposure is more useful than an unqualified claim that a bank has redundant systems.
Recovery needs trustworthy information
Restoring service after interruption may require identifying which transactions completed and which remain outstanding. If records are incomplete or inconsistent, restarting processing can create duplicates or omissions. Recovery speed and data integrity therefore need to be assessed together.
BCBS 239 addresses risk data aggregation and reporting, particularly in the context of systemically important banks. It is not a customer payment standard. Its emphasis on reliable information nevertheless illustrates why management decisions during stress depend on the quality of the underlying data.
For operational recovery, banks need records that allow teams to establish the state of work. A restored database is only part of the answer if it cannot be reconciled with external confirmations. The commercial value of data quality includes the ability to investigate an interruption and resume activity without introducing another set of errors.
Alternative arrangements need capacity
A manual process can provide a useful fallback, but it has limits. Employees may be able to handle exceptional transactions for a small number of customers while lacking the capacity to replace a high-volume automated service. Describing a manual option without assessing demand can overstate readiness.
Testing should consider how many requests staff could process, what information they would need and which controls remain necessary. Additional capacity may take time to organise. Some employees may also be affected by the same disruption, reducing the available resources precisely when demand for help increases.
The bank must decide how the fallback fits the service objective. It may preserve a narrow set of urgent activities while the main process recovers. That can be a reasonable arrangement if its purpose and limits are explicit. A contingency plan becomes more credible when it identifies what it can deliver under realistic conditions.
Scenario testing should examine incomplete recovery
An exercise that ends when a system restarts can miss a difficult stage of an incident. Queued work, unresolved customer requests and uncertain transaction status may continue after availability returns. The service may remain impaired while teams reconcile the backlog.
The FCA's 2026 observations on operational resilience discuss the relationship between disrupted services and harm. They provide a current UK supervisory perspective. Banks elsewhere should interpret the observations alongside their own requirements rather than assume every point applies in precisely the same way.
An operational exercise can examine recovery in stages, including partial restoration and a surge in enquiries. The result should inform improvements to processes and resources. Passing a rehearsed scenario is evidence about that exercise; it does not establish that the bank can withstand every form or combination of disruption.
Customer communication is part of the service
Customers need to know what has happened to their transactions and what they can do next. A generic statement that engineers are investigating may be insufficient for someone facing a payment deadline. The bank should distinguish confirmed information from estimates and explain the available alternatives clearly.
Communication can also reduce avoidable demand. If users cannot tell whether a payment completed, they may submit it again or contact several channels. That response can increase the backlog and complicate reconciliation. Giving reliable status information supports both the customer and the recovery operation.
The communication route needs resilience too. A status page dependent on the affected infrastructure may be unavailable when it is most needed. Banks can consider how to maintain an accessible source of updates, while avoiding messages that promise a recovery time unsupported by the evidence available to incident teams.
Changes can alter the resilience of a service
Banks regularly replace applications, launch products and connect additional suppliers. Each change can alter how a service works. A recovery plan based on last year's dependencies may become inaccurate even when the bank has not experienced a significant outage in the meantime.
Resilience assessment should therefore accompany material operational change. A project may improve normal processing while making a fallback more difficult. A new integration may create a dependency shared by several services. These consequences belong in the review of the project rather than waiting for a later continuity exercise.
The review need not make every routine update a major governance event. Its depth should reflect the potential consequences and applicable requirements. Keeping service ownership and documentation current helps banks identify which changes need more attention and which remain within an already tested operating arrangement.
Boards need evidence that explains the tradeoff
Operational resilience consumes resources that could otherwise support product development or expansion. The return may be difficult to express as a single annual figure because disruption is uncertain. That does not make the investment unimportant, but it requires a transparent account of the exposure being reduced.
Useful reporting links vulnerabilities to services, explains the likely consequences and identifies what remediation will change. Management should also understand the cost and time required. A general statement that systems are resilient provides less decision value than evidence about a specific dependency or recovery limitation.
Some residual risk will remain. The board's assessment should recognise uncertainty, sector obligations and the effects on customers. A provider's assurance report or a successful test can inform that decision, but neither substitutes for understanding how the bank's own service depends on the arrangement.
Learning continues after an incident
An incident review should consider more than the immediate technical cause. It can examine why detection took time, whether staff had accurate records and how customer information changed during recovery. These findings may identify weaknesses that were not visible in the original scenario tests.
Near misses can also provide useful evidence. A failure that was contained by an alternative arrangement offers an opportunity to assess how much capacity remained. If the same event had occurred at a busier time, the outcome might have differed. That possibility should be examined without treating it as a prediction.
The value of review depends on follow-through. Assigning responsibility, verifying remediation and incorporating lessons into future changes helps the bank improve. Repeating the same finding in several reports without resolving its cause can leave the service exposed despite extensive documentation.
Questions banking leaders are asking
Does high uptime establish operational resilience
It provides useful technical evidence but does not establish that every important service can continue through disruption. Completion, recovery and the consequences for users need separate assessment. The definitions behind the uptime measure also determine what it reveals and what it excludes.
Can outsourcing transfer responsibility for reliability
A provider can perform tasks and supply controls, but a bank still needs to understand the dependencies affecting its services and the obligations that apply to it. Contracts, oversight and tested alternatives should support that understanding. Outsourcing alone does not establish service resilience.
What makes a recovery plan credible
A credible plan uses accurate service information, specifies responsibilities and tests its assumptions against plausible disruption. It also recognises capacity limits and the work required after systems restart. Evidence of remediation matters alongside the existence of a written plan.
Banking reliability depends on the complete path from customer instruction to confirmed outcome. Banks that examine that path can make more informed choices about infrastructure, suppliers and recovery resources. The purpose is to understand where disruption could cause harm and to establish arrangements capable of supporting essential services when normal operations are interrupted.
References
1. Basel Committee on Banking Supervision. Principles for operational resilience. March 2021.
https://www.bis.org/publications/202103-guidelines-principles-operational-resilience
2. Financial Conduct Authority. Operational resilience.
https://www.fca.org.uk/firms/operational-resilience
3. Financial Stability Board. Enhancing Third-party Risk Management and Oversight A toolkit for financial institutions and financial authorities. December 2023.
4. Basel Committee on Banking Supervision. Principles for effective risk data aggregation and risk reporting. January 2013.
5. Financial Conduct Authority. Operational resilience insights and observations one year on. 2026.