51–60 of 61 posts
Earlier quoted context omitted.
Surely by being a bank, you are already exposed to that.
Exposed yes, but not fatally if you're working with alternative de-dollarised banking systems in the eurozone, for example.
Earlier quoted context omitted.
Exposed yes, but not fatally if you're working with alternative de-dollarised banking systems in the eurozone, for example.
Won't help if they sanction you and cut you off from SWIFT (or the card networks) so it just depends on the degree of the governance issues here.
Earlier quoted context omitted.
I've never run a bank either, but their current setup is very cost effective. A true multi cloud architecture would be "much" (a couple of 9s) more available, but I believe it would introduce other issues. The goal was to ensure the use of a subset of features for short periods of time, which is probably already above the market standard.
The cost effectiveness doesn't really add up for me either though (and again, I lack a lot of context). 1% of cost to run everything essential doesn't pass the sniff test, I assume it's much more during an actual failover. But I'm also not suggesting running any more hardware than the number of failure domains you want to be resilient to losing, and on cloud you could choose to run less and scale (assuming you aren't…
Earlier quoted context omitted.
I'm a bit curious about Spanner. At $EMPLOYER we were going to do multi cloud with multi-region CockroachDB clusters but gave up on it because write latencies and costs were too high. Do you not get the same thing with Spanner, where technically you can have multi region but it's very unattractive to actually do?
I'm afraid I'd have to defer to the public docs on this. I've only used it internally and a bunch of that is not public. What I would say is that it's considered to be much better than CockroachDB, but that there's no getting around physics. Spanner is subject to the same speed of light... but in every other way it does what it can do to improve things at every level. Google's use of GPS hardware for better timing is…
Earlier quoted context omitted.
Won't help if they sanction you and cut you off from SWIFT (or the card networks) so it just depends on the degree of the governance issues here.
Most european banking entities already have and use SEPA.
Earlier quoted context omitted.
Surely by being a bank, you are already exposed to that.
Monzo are a UK bank that briefly but afaik no longer operate in the US
Earlier quoted context omitted.
"it should be so frustrating for a dev to work on a full core banking that is mostly useless and userless except maybe 1h every 3 years." When other banks go down and Monzo stays up, even for 1 hour, that is a massive PR win and will bring in new customers. It's also been used multiple times as of the article (2025), and they are always exposing some users to it for testing.
I don't say that it is not useful, and that it is not a good thing for the company. More than I would be very frustrated to spend my life on that if it was my job.
I think some people found that job really peaceful when others might've found it more frustrating.
To me, I think though the issue isn't the scale or even the internal part of it but rather in this case, there's a difference because its being used infrequently (1 hour) as compared to that other HN comment was still being used quite frequently (it was used every day)
Though, I must admit, I don't find it too frustrating. I can be wrong I usually am but, Sysadmin/DevOps/Security engineer does the work as well where sometimes 1 hour can matter much more than months and they do work for months so that they don't get to face that 1 hour issue just because of how devastating it can get, Though Sysadmins do a lot of regular work as well.
There are many jobs where they exist for reasons where the employee exists to handle the bad things. You would wish for the bad thing to not happen and the employee might feel like they might not be doing much if the bad thing doesn't happen, BUT when that bad thing happens, You would be happy that they would then be there for you.
Maybe not a direct 1:1 comparison but hopefully I can express my point. I feel like there are many jobs in tech, or maybe in the world in general which fall into a similar fashion?
I can't help but think this isn't the best idea, it raises so many questions. How does fail over work (it failed for me!), can you safely fail over, how does product think about the stack, is it funded well enough, how do you scale a system from zero to all traffic instantly, how do you effectively keep this environment warm, how do you determine which services are critical enough to be in it, how do you manage findi…
The EU activated the Digital Online Resiliency Act (DORA) last year (passed in 2023) which, amongst other things, mandates that financial services providers who run their core business functions in the cloud (i.e. Monzo) must be able to demonstrate that they are not entirely reliant on a single cloud provider. Otherwise, big, big fines.
Like GDPR, there are auditors that are responsible for signing off on EU DORA compliance. Also like GDPR, there are ways to check those boxes without _really_ checking them. This is probably why Stand-In only has 18 services in its GCP failover "region" instead of the 1K+ production services in AWS; it's just enough to keep critical services (payments/card networks, balances, ledger, etc.) operational and, more importantly, keep DORA auditors at bay.
This article IMO is more for other FSIs who _want_ to run _entirely_ in the cloud (there are very, very few that do). Financial services is a very risk-averse industry. Most providers have biz-critical systems running on mainframes still. (Mainframes are practically indestructible and are much more technically-interesting than people give them credit for, but that's another post.) Being able to tell AWS "yeahhhhh we can run this business on GCP and/or Azure in literally 10 minutes" is a money line for procurement to use during price negotiations. Or at least it was until RAM prices mooned hard enough to make their existing datacenter inventory suddenly very attractive.
Cloud-aside, pretty much every bank in the US has some architecture like this for their critical banking systems, except they are usually an old-school hot-cold (sometimes hot-hot) datacenter failover strategy. Historically failover has been done manually with a runbook (with some automation) and tested during DR/BCP days (sometimes more frequently). They, of course, have zonal/regional replication in place.
Due to the recent outage where it didn’t work properly, this should be renamed Monzo Limp-In.
"We're going to be so reliable after this; big banks don't stand a chance" was what I took away from it.
The migration went horribly. Tier 0 clusterfuck. Debit cards were completely unusable and they lost ledger data. That and the occasional duplicate transaction (like the duplicated student loan payment that put me in a really bad spot at the time, which I was only given $50 for the inconvenience) was enough for me to _run_ bank to Chase.
So, yeah, I get why the big banks are totally fine with keeping their mostly-rock-solid core banking functions on the mainframe and stick with datacenters everywhere.
Monzo is great. Rare example of a consumer banking company that makes things easy. I just signed up for their phone service in literally 3 minutes. Didn't even need to talk to anyone to port my old number. I'm going to move all my ISAs and SIPP to them next I think.
Same service with HSBC and Giffgaff here. Meh.