On Wednesday 19 August, Monzo had an outage. DownDetector logged more than 3,000 reports by midday. Monzo’s own statement was direct about what it did next: it activated Monzo Stand-in, its fully independent backup bank, while it investigated an issue affecting customers. By the end of the day, Monzo said the issue was resolved and all services were back.

Stand-in did roughly what it was built to do, keeping essential banking functions running while the primary platform had a problem. At the same time, some customers reported transfers and balances not behaving as expected while it was active. Neither fact cancels the other out, and the interesting part of Wednesday is what sits in the space between them.

What Stand-in actually is

Monzo has written publicly about the architecture behind Stand-in before, and it’s more substantial than “backup” usually implies. The primary platform runs on AWS. Stand-in runs separately on Google Cloud Platform, deliberately on different infrastructure, so a problem hitting the primary system is less likely to take the fallback down with it.

It’s also intentionally small. Monzo has previously described Stand-in as running around 18 microservices against roughly 3,000 in the primary platform, a fraction of the functionality, built deliberately to keep a fraction of the complexity and cost. When it’s active, customers can still make card payments, withdraw cash, send and receive transfers, and freeze a card. Most of the rest of the normal banking app goes quiet for a while.

The switch itself is deliberate too. Stand-in doesn’t take over automatically the moment the primary platform has trouble. Engineers turn it on through internal tooling, and returning traffic to the primary system afterwards is its own conscious decision rather than an instant cutover, which avoids the platform flapping between two environments mid-incident.

Monzo first activated Stand-in for its entire customer base during an outage in August 2024, lasting around an hour. On the evidence Monzo published afterwards, it worked cleanly. Wednesday was messier.

What happened on Wednesday

Monzo’s account of the incident is the standard resilience story: an issue affected customers, Stand-in came on, core functions kept working, the underlying problem got fixed later that day.

Some customers described something else. Reports on social media, picked up by several outlets, included people saying expected transfers weren’t showing up in their balances while Stand-in was running. One customer waiting on an early payment said they couldn’t even get to the screen to check it.

Monzo hasn’t published a technical explanation for those reports, and at this distance it would be guessing to say whether the gap sat inside Stand-in itself, in the handover between platforms, in an upstream dependency, or somewhere in account synchronisation. What can be said with more confidence is narrower, and probably more useful: a system built to degrade gracefully still left some customers feeling like the bank was broken. That’s not proof the architecture failed. It’s a reminder that “designed to provide resilience” and “proven to deliver the expected experience under every real failure” are two different claims, and Wednesday is what the distance between them looks like from the outside.

The harder half of the work

Building a fallback system is mostly an engineering problem: decide what matters most, separate the infrastructure, cut dependencies, design how traffic moves across. Proving it holds during a real incident is a different kind of problem, because a live failure brings a combination of traffic, timing and customer behaviour that’s genuinely hard to reproduce in a test environment. Good testing catches most of what can be found in advance. Some of it only shows up once, under conditions nobody scheduled.

That’s roughly the logic behind operational resilience regulation like the EU’s DORA too. It doesn’t stop at requiring a documented fallback plan, it expects firms to test, monitor and evidence how their systems and the third parties they depend on actually behave, not just what the architecture diagram says should happen. The regulatory appetite for that distinction isn’t abstract: in December 2022, the FCA and PRA jointly fined TSB £48.65m over operational resilience failings tied to its 2018 IT migration, a case built on the gap between what the bank believed its systems could handle and what happened when they were tested for real. TSB’s situation and Monzo’s Wednesday aren’t comparable in scale or severity, but they sit on the same underlying principle: regulators care what a system does under stress, not what it was designed to do.

Wednesday isn’t a regulatory failure, and it isn’t evidence that Stand-in doesn’t work. Building a fully independent fallback environment at all puts Monzo ahead of most financial infrastructure, most of which would just be waiting for the primary platform to come back. What Wednesday shows is narrower and more durable than either a win or a failure: proving resilience isn’t a one-time engineering milestone. It’s something that has to keep being checked against what customers actually experience, and the gap between the two is where the real work lives.

For financial teams thinking about their own third-party arrangements under DORA, independent external monitoring is one way to keep evidencing that gap rather than assuming it away.

See how StatusCake supports DORA programmes →