this i agree with.
That’s not what I was suggesting at all. Personal accounts should be, essentially, joint accounts with one account holder. If abstract account functionality is built around the idea that there’s one or more account holders, mostly everything should work for both types.
It’s also a design that’s compatible with business accounts with many account holders. If references are handled correctly, layering on granular permissions shouldn’t be too difficult either.
In the end, you want PersonalAccount, JointAccount, and BusinessAccount all implementing the AbstractAccount interface and layering on their own subtle differences. Most of the account features should support AbstractAccounts not PersonalAccounts or JointAccounts specifically.
Any assumption that this isn’t the way it’s done is purely an assumption so I’m not sure we’re doing anything else but building a house of cards here. “What ifs” can be fun but in a forum they tend to build momentum and people start believing them.
2 Likes
Agreed. 
We shouldn’t make assumptions about how things actually are as there’s no way we can know for sure without a Monzo dev explaining it.
But my point still stands that parity between account types shouldn’t be very hard as is often said. Yes, to some extent, all software is very hard, but good software design should make this kind of functionality sharing possible. The best programmers are hired for their ability to make very hard things very simple.
1 Like
I have a Personal account. The sort code and account number are linked to my Personal Monzo Profile.
MrsW also has a Personal Account. The sort code and account number are linked to her Monzo Profile.
We also have a Joint Account. The sort code and account number are linked to both my Monzo profile AND MrsW’s Monzo profile.
So, 2 individual accounts (personal) and a third account linked to 2 user profiles.
This proves that Joint Accounts, while having the same core features as Personal Accounts, are processed - and therefore developed as an entirely different account type. This is because - as previously mentioned - Monzo bolted on Joint Accounts due to demand and and competitive offerings. This bolt-on approach could well be the Achilles heel of the Joint Account structure and a considerable re-structure may be necessary to achieve PA/JA parity.
Agree with @Feathers at this stage - without further knowledge it is mostly assumption.
How does having different account numbers and sort codes have anything to do with the not sharing abstract features between different accounts types? My personal account number is different from your personal account number, but they’re running from the same software.
But you have only 1 profile linked to the account number.
Monzo appears to be driven at the very top level using user profiles - not account numbers/types.
It’s a “has and belongs to many” relationship between Profiles and Accounts. A Profile can have many Accounts and an Account can have many Profiles. There’s probably an roles table with an index on account_id and profile_id, joining them together. This is also a good place to track the permissions a given Profile has for an Account.
1 Like
Exactly. And if you add that a PA and a JA are in fact 2 different account types with different feature sets - then there is a product management issue involved in retaining parity.
Not if they share core functionality through a common abstract interface, and then layer on their own subtle implementation differences.
Also agreed. But the parity is simply not there. Yet 
Plus subscription applies to JA’s (Interest)
IFTTT integration with JA
Ideally the ability to have ONLY a JA so summary and budgeting work properly for overall financial management
1 Like