Resilience in Fintech and Challengers

Resilience in fintech and challenger firms is about a customer who has one main route to money: the app. Challenger banks and fintech firms often serve customers entirely through a phone app and a card, without branches to fall back on. When the app fails, the customer may have no other way to check a balance, make a payment, or freeze a card. When the card system fails, the same customer may have no second account to use. The harm is therefore concentrated in a way it is not for a traditional bank with several channels. A fintech resilience plan has to reckon with that concentration honestly, rather than assuming customers will find another route.

The core service is usually an account accessed through an app, with a card for spending, transfers for moving money, and notifications that tell customers what has happened. Onboarding is part of the service too: a customer who cannot open an account, verify identity, or receive a card cannot become a customer at all. Each of those functions can fail independently. The app might fail while cards still work. Card authorisation might fail while the app works. Identity verification might fail while everything else works, blocking new customers and some existing transactions. The service map has to separate those functions, so that a disruption can be described as customers experience it, not as engineers describe the platform.

App-first customers are harmed by loss of their only channel. A customer who banks only through an app, and holds a single card, cannot pay, cannot check a balance, and cannot freeze a card if the app and card systems fail together. A customer travelling, or relying on the account for daily spending, faces immediate practical difficulty. A customer who receives income into the fintech account and has no second account faces a sharper harm: the money may be present but unreachable, and the customer has no alternative source of funds while the outage lasts.

Many fintech firms depend on a banking partner for access to payment systems, for safeguarding of customer funds, or for issuing cards. That partner is a critical dependency, and a disruption at the partner presents as a failure of the fintech service, even when the fintech firm's own systems are running. Cloud providers are another critical dependency, running the app backend, data storage, and often the card and payment processing. A cloud outage can therefore take down several functions at once, which is why the plan has to consider correlated failure: functions that look independent on a diagram may share a single underlying provider.

A useful fintech test follows a customer task through an app outage. One example is an app backend failure: can customers still use cards, can they freeze a card through another route, and can they be told, through a channel outside the app, what has happened and when to expect recovery? Another is a banking partner disruption: can customers still access balances, can payments still be made, and can the firm explain the position of customer funds without overstating its own control? A third is a card processor outage: can customers be steered to another payment method, and does support cope with the volume of contacts that follows?

Check whether the plan names a fallback route for each core task that does not depend on the app, and whether that fallback has been tested. Check whether banking partners and cloud providers are named as critical dependencies, with their own recovery and communication roles. Check whether the service map is updated when the product changes, and whether major changes trigger a resilience review. 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.