Almost seems like they can do anything at monzo.com
Monzo Stand-In
31–40 of 59 posts
Re: Monzo Stand-In
#32Minor thing but I do like they use the word "Stand In" here in the payments / financial sense of Stand-in processing (STIP), which is usually used when a bank is offline to keep essential services such as public transport working.
Re: Monzo Stand-In
#33Earlier quoted context omitted.
Well I haven't moved my number for a couple of decades at least, but the last time I did you had to phone them and go through the whole "are you sure? Let me see if I can get you a better deal" nonsense.
Cancellation is different to porting a number. You'll still need to cancel your previous plan, but legislation fixed carriers holding numbers hostage a while ago.
No, when you port the number it automatically cancels the service.
Re: Monzo Stand-In
#34I 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…
No, it's a great idea. Any systems engineer knows redundancy is good, even better if it's across providers. I see no issues with this from a system architecture point of view. As to how the implementation is done that's up to them to do right.
Agree, I know nothing about their system but in terms of clear auditability and accountability of systems I agree it's great. Every subsystem failure or inconsistency can be clearly attributed to one or the other site/stack, and the stand-in could for example apply other rules (e.g. approve only smaller transaction amounts that are accepted by an incident-only set of risk rules).
Re: Monzo Stand-In
#35Re: Monzo Stand-In
#36There are 3 things I have in mind when reading this: - 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. - if you build a totally different implementation to handle high traffic transaction from third parties that don't operate for days or months, i would expect it to be fragile. Like for example suddenly you receive unicode special…
"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.
Re: Monzo Stand-In
#37Monzo 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.
Compared to Lebara or other cheap MVNOs their offering is not great. While they eventually give you 30% off (after 6 years) their starting price is 30% higher.
Re: Monzo Stand-In
#38Monzo 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.
This is either a bot comment, or you have a very poor understanding of the UK financial market. They are quite far down the leaderboard for ISA rates and SIPPs.
While Monzo are expensive their approach of rewarding loyalty (5% off per year for Monzo Mobile) is a good idea compared to the endless switching you have to do to get the best rates.
Re: Monzo Stand-In
#39Almost seems like they can do anything at monzo.com
The only limit is themselves.
Re: Monzo Stand-In
#40Earlier quoted context omitted.
Redundancy is great, absolutely, but there are multiple ways to do it and this is not necessarily the right one. Which is better: 3 DCs for 2 DCs worth of traffic, running the same stack but isolated failure domains... or 4 DCs for 2 DCs worth of traffic, that work in completely different ways, where 2 are left cold until needed. I can see some advantages of the latter, but not a lot. This also isn't about fault tole…
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 concerned about stockouts).
My guess is a little of both. I would bet that the 1% is the unused cost, but that for periods that they are running the stand-in system it's much closer to normal. But from what I've heard of their infrastructure I'd also bet that stand-in is significantly cheaper in part because it had the benefit of hindsight and could resolve issues in the first system.
None of this really changes my original feeling though. A cell based architecture spreads the risk, failover is essentially built-in without being a special mode you have to put the system into and then recover from again, on cloud you can scale those up and down with traffic and they also take peaks from each other, and so on. There's a reason why there are very few cloud outages that cross all regions for a provider, and if you're paranoid you can run multi-cloud (as they already do).