Monzo for Android - Teardowns & Deep Dives šŸ‘Øā€šŸ’»

I agree that it’s been bad on the signups front, but it’s a little annoying that ā€œthe joint account issueā€ is a bit obfuscated at this point. A staff member was recently making positive waves about the whole ā€œjoint accout situationā€, but upon reading that teardown I get the solid impression that we might just end up with people able to sign up for them en mass again, but no custom categories, and no virtual cards. Sure, it is bad that some people have not been able to sign up for a little while, but Joint Account Parity has been an issue for much, much longer. We can see from the teardown that the signup flow is getting fixed (did it need fixed? didn’t feel like that was really the issue), but is anything being done on custom categories or virtual cards? I see no indications whatsoever. It would be very frustrating if internally the conversation at Monzo went something like ā€œoh we fixed the JA issue now, on to other thingsā€. That’s not the JA issue! Damn parity is!

:angry:

I hear you and I’m not disagreeing.

The point I’m trying to land is that you might (unfortunately) need to be a bit patient. Extra features will only make sense if a) they can increase customer numbers and b) they can monetise it.

So I expect phase one to be fix the problem, phase two open up sign ups, phase three introduce overdrafts (and profit), phase four introduce paid accounts (and profit).

That said, I have a feeling that there’s gonna be a shake up in paid accounts. I’m thinking features like custom categories will become free, which means that aligning it to the new joint account offer would make a lot of sense.

But I’m probably wrong. Sadness.

2 Likes

Because of that poll the other week, I guess?

I just want Joint Account Parity so much. It feels like I am using Monzo through oven mitts at the moment. Virtual cards enable using a spending pot for ad-hoc spending, bringing much sharper edges to things (my old discretionary/mandatory line). And custom categories, I mean, it actually boggles my mind that we still don’t have them. Do you remember how much people screamed for them on the personal account? It was just about the most requested feature ever.

3 Likes

I still suspect the fundamental underlying structure of users/accounts is to blame. Not just for Monzo, but for Starling too.

The user at the top of the tree. Whereas traditional bank accounts have the account at the top of the tree. Allow me to demonstrate using the medium of words:

Old-school bank:

  • Personal account → user
  • Joint account → user#1 and user#2

Monzo/Starling bank:

  • User → Personal account
  • User → Joint account
  • User#2 → Personal account #2
  • User#2 → Joint account

The traditional way has 2 account types to consider and one of the account types has access by 2 parties
The Fintech way has 2 users to consider. One of them with access to 2 account types (Personal & Joint) and one of them also with access to 2 account types (Personal & the same Joint)

Totally different architectures.

3 Likes

I think it’s worse than that.

I think it’s

Personal account == user
> Joint account
> Flex
> Pots
> Connected accounts. 

That’s why Monzo uses the avatar associated with your ā€œpersonal detailsā€ as the logo for your personal account. It just can’t separate them.

Don’t think there’s anything necessarily bad with having the individual at the top level of the hierarchy, but it needs to work differently, something like:

> User (Tom Bloom)
>> Monzo personal account
>>> Pot 1
>>> Pot 2
>> Monzo joint account
>> Tesco connected account

Etc

It’s not worse, but not any better.

The Joint account structure issue was evident before Flex or Connected accounts. So I don’t believe Flex/Connected accounts have worsened the situation. Pots may have introduced a sub-issue, but if the top-issue is sorted, so should pots be.

The problem is exaclty as you demonstrate in your ā€˜something like:’ statement - the User cannot be at the top level. An account has to be at the top level:

'> Monzo personal account
'>> User
'>>> Pot 1
'>>> Pot 2
'>>> Connected accounts

'> Monzo joint account
'>> User
'>> User#2
'>>> Pot 1
'>>> Pot 2
'>>> Connected accounts

1 Like

Ok, my turn:

I recon that their microservices architecture is oriented completely towards single-ownership of all entities. You log in as you, and you can go to the TransactionsMicroservice and get your transactions which can then be decorated by the CustomCategoriesMicroservice, and so on. The datastore in each microservice can have a user id against every record, such that the only thing that it’s possible to return from that microservice is your own data. I wouldn’t be surprised, because this is banking and highly regulated, if there weren’t some underlying infrastructure that locks each service to just the subset of data for that user - that you couldn’t accidentally return the data of another user even if you tried.

And then along comes Joint Accounts and spoils the sauce. This one user can see all their own stuff but also the stuff this other user owns. So you add a hack for the TransactionsMicroservice and AccountsMicroservice that lets two users own one account, but it’s kind of ugly and those guys on the forum have shut up now so you consider joint accounts done and get on with building the Monzo Marketplace or whatever. And then later some other team writes the CustomCategoriesMicroservice which seems awfully easy to do for a single user and, umm, oh dear it’s really not so easy when two users can view each one, potentially. Especially when it’s only the subset of categories that are assigned to transactions in the joint account; we can’t have that HokeAndCookers tag being leaked to your partner by mistake! But then the CustomCategoriesMicroservice is going to have to depend on the TransactionsMicroservice from an authentication perspective. And also probably the AccountsMicroservice, again from an authentication perspective. But… the TransactionsMicroservice was depending on the CustomCategoriesMicroservice from a datapath perspective - it wanted to decorate the transactions with the custom category names.

So, yeah, I recon it’s the cardinality change in the ownership layer that’s making it a pain in the ass.

3 Likes

Do you reckon it’s for abroad types, or just anywhere the system believes you’ve been out of your normal area ie your trip to Manchester cost you Ā£470 on Canal Street? :face_with_peeking_eye::joy:

3 Likes

Same here i was wondering where it had disappeared to. Had to manually classify all transactions, hopefully they bring it back

App version 5.38.0 - Combined Accounts & Pots on Statements, Investments & Pensions - oh my!

21 Likes

Nice to see Flex transactions showing up in activity feed too.

2 Likes

Paid early, automatically?

3 Likes

I read that one as ā€œOpted in users can get paid early into an instant access savings potā€ - Maybe an auto-get-paid-early-into-an-IASP setting?

Both showing for me. In ā€˜Activity’ and ā€˜See all’

I don’t have the Live Call Status thing yet though

:android: :cry:

2 Likes

What’s Live Calls?

Yes, first time I opened up ā€˜all activity’, the flex transactions started to populate throughout my scrolling through.

Maybe its paid users (plus and premium) are allowed more than one Instant Access Savings Pot, and there is an early access roll out happening now?

So you get one pot for free, and more if you pay?

1 Like

I like your thinking on the feature - more IASP’s for paid tiers - Yes!

The paid_instant_access_early_access_launched flag still has a ā€˜=false’ attribute against it, so no roll out until that is changed to ā€˜=true’

:running_man: Runs off to double-check the feature flags…

EDIT: I can confirm that the attribute (for my account) is still set to =false as at 16:54 today

5 Likes

Guess we know what this means now!

2 Likes

Yeah - totally unexpected link to interest rate changes!

2 Likes