Why Monzo built a second bank on GCP

Recently, Monzo’s engineering team published a wonderfully dense technical post detailing how they built a system to tolerate catastrophic cloud outages. They call it Monzo Stand-In, a redundant fleet of infrastructure hosted on Google Cloud Platform designed to seamlessly take over if their primary AWS environment fails. Naturally, the tech community over at Hacker News immediately tore it to shreds. The consensus formed with predictable speed: running active-active multi-cloud infrastructure is a phenomenal waste of engineering cycles, an open invitation to split-brain database corruption, and a terminal case of resume-driven development.

This reaction makes perfect sense if you view Monzo as just another software-as-a-service application. To understand why a notoriously competent engineering organization willingly signed up for this operational headache, we have to apply a translation layer. We must convert standard software engineering complaints into the visceral realities of prudential regulation. (To the software professionals reading this, I am deeply sorry; we are going to discuss compliance.)

Let us examine the architecture itself, starting with the first technical objection from the forum thread: surely maintaining eighteen separate microservices on a completely different cloud provider is an indefensible waste of money.

We translate this by looking at what those eighteen microservices actually do. The Stand-In platform deliberately abandons any attempt to replicate the entire bank. Rather than attempting to originate mortgages, process mailing address updates, or catch inbound SWIFT transfers, this heavily optimized piece of Go infrastructure operates with one singular mandate: deciding whether to approve or decline a debit card authorization message when the primary AWS ledger is unreachable.

(In payments industry parlance, this is a souped-up version of Stand-In Processing, or STIP. Usually, your card network—Visa or Mastercard—provides a rudimentary version of this, but it relies on highly static rules, such as automatically approving any purchase under fifty pounds while the bank is offline. Monzo wanted a smarter, real-time shadow ledger.) By moving this in-house to GCP, Monzo maintains a constantly updated mirror of customer balances, processes the cryptographic validations of the card network, and queues up the resulting state changes to be carefully merged back into AWS once the fires are put out.

Why isolate just the cards? Let us physically trace a dropped AWS packet down to the real world. If a B2B SaaS application fails, you get a spinning loading wheel or an HTTP 503 error; you tab over to Twitter, complain about the downtime, and go get coffee. The system degradation is entirely contained within the browser.

If a core banking ledger fails, the blast radius is immediately physical. A retail consumer is standing at a grocery store checkout in Tesco, staring at a declined point-of-sale terminal, completely unable to pay for their family's food. The card network has essentially fired an HTTP request (more accurately, a legacy ISO 8583 message over a dedicated pipe) at the bank asking whether this specific person has funds to cover a forty-two pound grocery bill, and the bank has failed to respond in the required milliseconds. (This is a uniquely humiliating experience that software engineers working in abstractions frequently underestimate. The consumer assumes they are broke; the cashier assumes the consumer is broke; the line behind them sighs loudly; everyone involved is having a miserable time.)

To a retail consumer, a localized cloud outage translates viscerally to the sensation that their money has simply vanished. Fiat currency is largely an exercise in collective hallucination, and the user interface for that hallucination is the card terminal. Tap the plastic. Read the chip. Green checkmark on the terminal. Bam. You have successfully interacted with the global financial system. If that transaction fails, the consumer does not ponder the complexities of BGP routing; they assume systemic insolvency.

This brings us to the second, more sophisticated technical complaint: why go multi-cloud at all when you could just rely on Amazon's highly robust multi-region availability zones?

Translating this requires zooming out from the codebase to the terrifying macroeconomics of modern digital bank runs. Historically, bank runs were rate-limited by the physical speed of people standing in line outside a branch in the rain. Your risk management was constrained by the capacity of your front doors and the operating hours of the teller windows. Having a slow database served as a highly functional feature back when the physical world provided the ultimate rate-limiting mechanism.

Today, a bank run is a multiplayer internet event, entirely divorced from physical geography. We have visceral, hard data on the velocity of modern panic. During the collapse of Silicon Valley Bank, rumors cascaded through Twitter and private venture capital WhatsApp groups, resulting in depositors initiating $42 billion in withdrawals in a single day. The money moves at the speed of an API call.

A localized technology outage that appears to be insolvency possesses the exact same power to trigger contagion as actual insolvency. If AWS pushes a bad configuration file to their global network routing layer—which they have historically done—multi-region architecture provides precisely zero protection. Your us-east-1 and eu-west-2 clusters go down together. Suddenly, tens of thousands of customers are loudly complaining on social media that their cards are being declined, triggering immediate rumors of a liquidity crisis. A vendor-level networking error escalates into a systemic macroeconomic nightmare in a matter of hours.

The translation layer finally hits bedrock at the Bank of England’s Prudential Regulation Authority (PRA). The UK administrative state, alongside global central bankers, watched the digitalization of retail finance and realized, with growing horror, that the entire nation's money supply was becoming critically dependent on the operational uptime of roughly three American technology conglomerates. Regulators look at AWS and see a systemically important financial market utility masquerading as a vendor.

(Engineers reliably point out that Amazon operates some of the most robust infrastructure in human history. The regulators agree, but they are paid specifically to model the Tuesday morning when the global routing tables violently fail and the blast radius threatens 40% of the UK's GDP.)

They responded by publishing aggressive, sprawling mandates on operational resilience, most notably Supervisory Statement SS2/21 on outsourcing and third-party risk management. Regulators are fundamentally terrified of vendor concentration risk—the nightmare scenario where a single cloud provider taking down multiple banks simultaneously triggers nationwide chaos. They mandate that financial institutions must identify their most critical business services—like processing retail payments—and mathematically prove they can remain within strict impact tolerances even during severe but plausible disruptions.

This is where the engineering complaints about resume-driven development miss the mark entirely. Monzo engineers wrote this GCP fallback code because the administrative state required a verifiable answer to a structural risk question, which renders standard complaints about architectural redundancy entirely moot. When the central bank demands proof that you can mitigate vendor concentration risk, you do not attempt to lecture them about Amazon's historical SLA. You build a second, heavily constrained ghost bank on Google's servers. The administrative state structurally demands this exact flavor of paranoia. They greatly prefer that your engineering managers complain about distributed state synchronization than that the Bank of England be forced to manually halt a Twitter-induced liquidity crisis.

This structural reality bridges the gap between the internet forum and the boardroom. The architecture that commenters view as an absurd vanity project represents the literal, codified cost of doing business as a regulated financial institution in a post-SVB world. The Administrative State Called And Demands You Mitigate This Risk Immediately. The GCP platform is just a compliance checklist implemented in Kubernetes.

Do you, as a typical retail consumer of financial services, need to obsess over your bank's cloud concentration risk? Probably not, although keeping a secondary account at a different institution funded with a payroll cycle of liquidity is smart insurance against someone pushing a bad config file to production. But you can rest assured that very serious people are spending millions of dollars of engineering time simply to ensure your grocery run remains entirely, beautifully boring.