Resilience in Payments and E-Money

Resilience in payments and e-money is about a payment completing, or a balance being reachable, at the moment someone needs it. The service might be a card payment in a shop, an online transfer between accounts, a wallet balance used to pay, or a merchant receiving the proceeds of sales. When it stops, the harm is visible within minutes. A shop cannot trade. A customer at a till cannot pay. A worker waiting on a transfer cannot access earnings. A merchant waiting on settlement cannot pay suppliers. Payments are unusual among financial services because the service is the transaction itself: there is no later appointment to reschedule, and a failed payment at the point of sale is a sale lost, not a sale delayed.

A payment service is a chain, and the chain is the service. A card payment passes from a terminal or checkout through an acquirer and a scheme to an issuer, and then back again for authorisation. An account transfer passes through sending and receiving institutions and the rails between them. An e-money payment draws on a balance held with one firm and may settle through a sponsor bank. Each link has its own systems, its own failure modes, and its own recovery time. Mapping the service means naming those links in order, so that a disruption can be located: is the failure at the terminal, at the acquirer, at the scheme, or at the issuer, and which payments are affected by each?

Merchants are harmed as traders. A shop, a restaurant, or an online seller that cannot take payment loses revenue for the duration of the outage, and for a small merchant that loss may be a large share of takings for that period. The harm is not only the lost sale. Staff time is spent explaining the failure, queues build, and customers who leave may not return. A merchant that depends on a single acquirer or a single terminal provider has no alternative route, and the outage therefore falls entirely on that merchant, even if the root cause sits several links away in the chain.

Payments depend on parties the payment firm does not control: schemes that set the rules and run the network, acquirers that connect merchants, issuers that authorise card use, sponsor banks that give e-money firms access to payment systems, and the technology providers that run terminals, gateways, and fraud screening. A disruption at any of those parties presents as a failure of the payment firm's service, and the firm may have limited ability to fix it directly. Its resilience therefore depends on what it can do while the dependency is down: route around it, queue safely, communicate clearly, and reconcile accurately when it returns.

A useful payments test follows a payment from initiation to settlement under disruption. One example is an acquirer outage during a busy trading period: can merchants switch to a backup route, are customers told that payments have not been taken, and does settlement catch up without duplication when the acquirer returns? Another is a scheme outage: which payment types are affected, which still work, and how quickly can merchants and customers be steered to the working route? A third is a sponsor bank disruption affecting an e-money firm: can customers still reach balances, and can the firm explain the position of those balances without overstating its own control?

Check whether the service description follows the payment all the way to settlement, and whether each link in the chain has a named owner and a fallback or a workaround. Check whether e-money balances are treated as a separate service question from payment movement, with their own recovery and communication plan. Check whether the plan covers queuing and reconciliation after an outage, not only restart. And check which regime is being applied: 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.