I use Chase with all notifications switched off. Still use monzo for app payments to other monzo users.
It seems completely crazy to me anyone would want to be notified when they use their card - and even worse when they use Apple/Google Pay! Might as well receive a system notification every time you unlock the screen. I really don’t get why it’s on by default, never mind not having the option to switch it off.
The only benefit I can think of is to alert me to fraud, but I’ve been paying for things by card for 20 years without ever having an unauthorised payment, while the notification is a daily nuisance.
I love the instant notifications. I think in the early days that was a big part of Monzo’s appeal, back when every other bank didn’t show your card payments for days (or at best hid them in an ‘upcoming payments’ section only on their browser).
You can turn all notifications for Monzo off too though, do it in your Android or iOS settings.
I like being able to see an accurate balance in the app. I don’t like having to clear the notifications telling me I just got on the bus, I just bought coffee everyday before I even get to the office.
And you can’t turn it off on iOS. You have to choose all transaction and payment notifications or none at all. If you use the system settings or the app settings you can only have all or nothing.
If I could customise I would have “you entered your overdraft” and “scheduled payment failed” on and all card payments off. And have monzo-to-monzo payment/bill split requests on.
Why do you want your phone to notify you that you just paid for the bus, when you literally paid for the bus by holding your phone to the card reader? I can’t be the only one who finds this incredibly irritating?
On the other hand, I don’t want my housemate asking me to pay the money they requested in monzo last week because I didn’t get a notification that they’d requested it.
For me, Monzo and Starling are the only apps I allow notifications for, so clearly I find them useful! Mainly for seeing when direct debits go out and stuff. I don’t use my card most days, so I guess the card notifications don’t bother me so much.
One thing Starling does have which I love is the option to turn off notifications for mobile wallet transactions which avoids the duplicate notifications
Thanks for the reply! I didn’t read that blog post when it came out, but I will now; looks interesting. I do have one question for you off the top of my head though - if you have thousands of services then do you have some kind of developer tooling to do jump-to-definition across the RPC boundaries?
Needless to say, I have all Wallet app notifications turned off anyway
The point is really just that you should have the option to have them on and me to turn them off. I would have thought this wasn’t so difficult for a digital-only bank. shrug
It probably isn’t so difficult, but also probably neither are the several thousand other QoL improvements people suggest on a daily basis and it just hasn’t come up as a priority in their user research I guess. Always feedback you can give of course.
The form to pay it from my HSBC account kept crashing in my browser, so I actually ended up using the separate form to pay it from , which did at least work
If this forum has taught me anything, it continues to be that everybody’s opinions and foibles about banking are spread across the widest set of possibilities, some I had not even envisaged
then do you have some kind of developer tooling to do jump-to-definition across the RPC boundaries?
Not sure what you mean by “jump to definition”, I assume “how do we know which services do what?”
There’s somethings that help:
All of our services use the same grammatical structure for RPCs
Once you learn this, you can pretty much guess roughly what an RPC will look like Services also follow obvious naming patterns (service.emoji deals with emoji, service.plushie deals with the Monzo Plushie etc etc – these are just fake example services)
We have shell completion for all RPC calls so if you can approximately guess what an RPC looks like, you can autocomplete it
As in “jump to the definition of this piece of code” these days probably powered by something speaking LSP). In a lot of languages jumping over an RPC boundary isn’t supported. That would be annoying with 2000 services.
So the editor sort of thinks that everything runs in the same process space, and so can infer the jump target? Or is that just an inbuilt feature of Go? (It’s mostly Go, isn’t it?)
Not sure! That’s a bit over my head. I can tell you when I click on a definition in a service it takes me there.
And yes, Monzo’s codebase is almost entirely Go. There’s a couple places we don’t ues it where it doesn’t make sense (for instance, Go isn’t very nice for machine learning stuff)
Ah, that’s cool. Yeah, probably either Go-native tooling (it’s for building services after all), or just kind of accidentally works. It does indeed sound like a pretty sweet environment, then. If I were to squint at it, it almost feels Erlang-like; the “runtime” (in your case k8s with a load of custom tooling) taking care of the distributed aspects seemlessly. I did like the idea, which I think I read on the blog a long time ago or else it might have been on one of the early employee’s Twitters, that having a “service for everything”, rather than sharing libraries, was preferable in a large system because you don’t have to deal with different versions of that library baked into different things - everything makes an RPC call so, as long as you verify that you’re not about to break any of your clients, then you can change the whole component out in one go - which sounds to me like a very favourable and clean way to make changes in such an environment! In that aspect you really want one or the other end of the spectrum - a monollith, so that it’s easy, or real (i.e. everything-is-a) microservices, so that it’s also easy. In each case you just have to kick one thing. The middle-ground there would be pain.
I have this running theory that microservices also work well for Monzo because there’s, for the most part, no “filtering joins” going on across the dataset. People look at their feed, and that data is augmented with other data (e.g. an emoji, whatever), but for the most part some random user doesn’t do a join across the whole dataset and then filter it down; people are quite well bucketed. The only things that do need to do that sort of joining are back-office apps (like “what is the average acount balance?” or “is anyone doing crime?”), so that can be scaled very differently (several orders less of users, can be ETL’d into some data lake, etc.)
I’ve personally seen several systems where the data layout and access patterns often cut across the whole dataset, and it had been implemented with “microservices”, and… well, there was a lot of ad-hoc join-filtering happening in memory!
That’s a fair point, imagine a toggle to have simple mode and advanced mode … old school vs new school …. Would be great to A/B test usage between the 2
, which did at least work
Services also follow obvious naming patterns (service.emoji deals with emoji, service.plushie deals with the Monzo Plushie etc etc – these are just fake example services)
.
