Resilience in Retail Banking

Resilience in retail banking is about a household being able to use its money when it needs to. The central service is usually a current account: receiving income into it, paying bills and rent from it, and drawing on it through a card, an app, or a branch. When that service stops, the harm is immediate and personal. A customer cannot pay for food, cannot settle a bill that falls due, and cannot tell, from a silent app, whether the money is safe or simply unreachable. The technical cause matters less to that customer than the practical question of when the account works again and what to do in the meantime.

The service is best described as a bundle that customers experience as one thing: seeing a balance they can trust, moving money out of the account, and receiving money into it. Behind that bundle sit separate systems: a core ledger, a payments engine, a card processor, and the digital channels that present them. A failure in any one of those can break the bundle for some customers and not others. Card payments might fail while transfers still work, or the app might fail while cards still work. Mapping the service means tracing those splits, so that a disruption can be described in customer terms: who can still pay, who cannot, and through which route.

Households are harmed first and most directly. A failed salary credit leaves a household short for the whole period until it lands. A failed direct debit can trigger a missed payment elsewhere, with consequences the bank cannot see from its own systems. A customer who cannot check a balance may spend cautiously or not at all, which is a harm even if no payment actually fails. Small businesses face a parallel harm: a shop that cannot take card payments loses sales it cannot recover later, and a business that cannot pay suppliers or staff on the expected date damages relationships that took years to build.

Retail banking depends heavily on its core platform, which holds the ledger and the account record, and on payment rails that move money between banks. It also depends on card schemes and processors, on telecom and data networks, and on the providers that run parts of its digital channels. A disruption at any of those points can present as a bank outage to the customer, even when the bank's own systems are running. That distinction matters for communication: customers need to know whether their money is affected or only their route to it, and a bank that cannot explain the difference will be assumed to have lost control of both.

A useful retail banking test picks a customer task and follows it to completion under disruption. One example is a salary credit arriving while the app is down: can the money still land, can the customer confirm it through another channel, and can direct debits still go out? Another is a card processor outage during a busy shopping period: can customers still pay by another route, and does the bank tell merchants and customers promptly enough for them to switch? A third is a core platform failure that forces a switch to a backup: do balances remain accurate through the switch, and does reconciliation catch any payment that was in flight when the failure happened?

Check which retail service the plan actually covers, and whether the fallback channel has been tested at the volume a real outage would produce. Check whether the plan names the customers with the fewest alternatives, and whether their route still works when the main channel does not. Check whether recovery is defined as customers being able to complete tasks, rather than systems being back online. And check which regime is being applied at each point: DORA, which applies from 17 January 2025, and the UK regime under FCA PS21/3 and PRA PS6/21 are labelled separately in this guide, and their expectations should not be blended into a single checklist.