I mentioned this on another thread but this might lead into a calendar feed where you can scroll forward and see predicted income and expenditure. Would really help with that forward look and predicted balance etc. A bit like money dashboard do.
3 Likes
Enhanced budgeting has been hinted as part of the upcoming Plus/Premium accounts.
Iād also like to see some predicted income and expenditure improvements, to āsee into the futureā more to help avoid financial mistakes. Hereās one previous idea;
2 Likes
This would be amazing.
Iāve long been keen to be able to go forward in time as well as backwards. Two things that I think would be really useful:
- Future feed items (including predicated income, direct debits etc potentially months in advance that can be easily hidden or shown etc)
- Some easy modelling/what-if scenarios to show your predicted future balance
3 Likes
Did B (part of Yorkshire) do something like this. It was years ago I had an account with them and I think they may have done predicted balances etc.
This is something, that if done right, could make Monzo appealing enough to become my primary account again.
That, along with
Would hit the nail on the head for me. Itās an aspect of Monzo Iāve critiqued them for numerous times here. Iām glad theyāre listening to feedback.
2 Likes
They did!
The implementation was terribly confusing and obtuse though. Much like when legacy banks launch something innovative it usually feels like something designed by bankers for bankers, rather than human interface designers for humans.
I think simplicity is the key to getting these things right.
1 Like
if you work you should know technically know what day you usually get paid so by a lot of people making post about not getting their money on friday is just strange, monzo should have some information when you click to get the paid early and this would be displayed āyour money is due on tuesday you can get paid early from 4pm mondayā at least that could cut down on the repetitive new threads, i like the earlier notice of upcoming payments at least i get more time to add money if necessary
Just some minor/light corrections to what Dan has said here. But before I get into that, some background and terminology:
Firstly, when we talk about a payment scheme, we need to talk about both participation and technical connectivity. When we talk about participation, this normally refers to āfinancial connectivityā:
- A direct participant, or a directly settling participant, is one who settles directly with the scheme. For the UKās major payment schemes - FPS, Bacs, CHAPS, LINK, Cheque image clearing; plus GBP participants of Visa Europe, this is done at the Bank of England via the bankās RTGS (Real Time Gross Settlement) system.
- An indirect participant settles āindirectlyā with the scheme through an indirect member (their āsponsorā or āagencyā bank)
The BoE RTGS is the primary means by which banks exchange GBP - pretty much the only other way is via hauling physical cash around. When you make a CHAPS payment between two banks, youāre making an immediate movement of funds between the two banks at the Bank of England, while with FPS, Bacs or cheque clearing movements are netted together and the net amounts are settled (3x a day for FPS, daily for Bacs). There are various reasons for the continued existence of CHAPS as a distinct system from FPS, but one of those is that CHAPS payments mean a direct funds movement on the RTGS, and donāt need a separate collateral account (If you send Ā£50m to buy a mansion through CHAPS, thatās a direct movement at the BoE; if you were to send it via FPS, the bank actually needs Ā£100m to hand - Ā£50m to fund the payment through its āliveā working account, and Ā£50m in its FPS collateral account which provides insurance to every other participant in the FPS scheme in case come settlement time you didnāt have that Ā£50m in your working account)
Payment schemes and other systems which donāt settle directly at the BoE - such as Mastercard - are settled by CHAPS transfer. Thereās still a notion of ādirectā vs āindirectā participation here - a member can settle through another member, and their settlement amounts will be netted together into one amount
Technical connectivity is somewhat more obvious:
- A participant with direct connectivity is one which directly exchanges messages with a scheme
- A participant with indirect connectivity is one who connects via a third party company
This one gets a little squishy - as an example, CHAPS messages are always exchanged over SWIFT, and of course even direct connectivity via leased lines involves a telecommunications company in the middle. But I think the spirit of it is āAre there any third party companies or systems I could remove from this connectionā?
Even within the indirect technical connectivity, thereās a sliding scale and sources of confusion. At one extreme there are companies like Form3 who provide what is almost a payments abstraction layer and handle all of the details for you; and at the other there are cases like our old FPS gateway where they did little beyond directly passing messages through during normal operations.
Finally, thereās a bunch of confusion which arrives from people talking about SWIFT as a payment system; but SWIFT isnāt a payment system, and SWIFT-the-company is not involved in the movement of money. Instead, āSWIFT paymentsā work by each bank publishing a list of their ācorrespondentsā (banks with whom they have a legal/settlement agreement with), and payments are made by chaining together these correspondents until you have a full path to the recipient. These transfers are then settled either by internal book transfers at the banks in the chain, or other national RTGS or clearing systems.
But back to Bacs.
We connect to the Bacs scheme as indirect participants (though an āagency bankā). As you might expect, this broadly has no impact on things day to day - other than causing some minor changes to how money movements happen āinsideā the bank.
Back when Monzo was setting itself up as a bank back in 2017, for each scheme we connected to, we had to make a decision as to how to do it - both technically and in terms of participation.
Thereās trade-offs to all of these decisions, in terms of upfront costs of joining the schemes, setting up infrastructure and building things. To directly connect to Bacs technically, you need to either
- Connect directly over leased lines, and implement a specific file transfer protocol (this is called the āEnhanced Transmission Serviceā), or
- Connect and exchange these files over SWIFT (the āSWFTNet Transmission Serviceā)
The first of these required additional data-center hardware with an associated lead time, and the latter required the complicated process of connecting to SWIFT. By contrast, our connection to our agency partner is just a case of a service in our platform connecting to an SFTP server they host and uploading or downloading files; and the Bacs clearing files are in almost exactly the same format as the ones produced by Bacs itself (they add a few fields at the end of every record which are always blank - I believe theyāre for clearing Bank Giro Credits, those tear off slips you see at the bottom of utility bills)
And other than the fact that we received our clearing files later than we would have done so had we been directly technically connected, I doubt anybody ever noticed the difference - especially given few other banks give advance notice of direct debits.
But the disadvantage was that our agency partner only supports the transfer of inward clearing files - they donāt support things like
- Direct debit instruction setup or cancellation
- Outbound clearing files for returns of failed payments
Instead, these had to be exchanged via the Bacs web portal.
By itself this wouldnāt be a major problem - manually uploading or downloading a few files a day is workable, and there are some places that we do it (for example, the directory of sort codes for UK banks can only be fetched this way, and the same applies for the description on how to validate account numbers for each sort code).
But some of these files have size limits, which means the number of them were growing with our customer base and they each need to be uploaded to the website individually. We had systems in place (e.g. downloading a report listing every file weāve uploaded today) to verify that we hadnāt missed a file, since thatās an easy mistake to make, but fundamentally uploading files manually is a waste of time for everyone involved and does not scale in the long term.
So a couple of weeks ago, after a lot of hard work, we became directly connected to Bacs (though still indirect participants). All of our files are now exchanged directly with them over our automated systems, which frees up a bunch of ops time to work on other, meaningful things.
That the files now show up earlier was expected. The bug that caused the GPE UI to show up early last week was very unfortunate; the GPE system assumed that Bacs payments always showed up on the day that they could be paid because, to be fair, they always had - and we made a change elsewhere in our systems which violated this assumption.
There are always risks when making changes - we test things as best we can, but there are limitations to that; and the test environments offered by payment systems are unfortunately limited in how well they can reflect the real world (both because of the vast complexity of the real world and the ways in which merchants/other banks can behave in ways which are outside of the specifications, and because they do not have traffic patterns which are in any way reflective of reality)
So when building payment systems, we tend to be quite defensive - if a field has an unknown or unexpected value, weāll reject a payment or flag it for human inspection and things along those lines. For each step of the Bacs payment process, we check that weāve passed the appropriate time rather than just assuming that the scheduler is doing the right thing. The button wouldnāt have shown up until 4pm on Monday, but even if it had, if youād clicked it you would have just gotten an error screen. And when making changes, we try to factor in any downstream services we think these might impact.
Unfortunately, the code which generates transaction widgets was missed.
As for whether weāll add something to these upcoming payments: given it is causing confusion and quite easy to do, I suspect we might. Disabling the incorrect widget was quick fix; working out the right wording for a replacement is a slightly longer task
37 Likes
Wow, that was a read and a half. Thank you for your explanation, @erincandescent, itās very much appreciated.
2 Likes
Does this mean international payments are a bit closer?
1 Like
Great write up, thank you Erin!
Great explanation thanks a lot!
That is very interesting indeed!
Never going to say no to having even greater visibility of upcoming payments. That extra bit of foresight will im sure save people alot of headaches.
It is always interesting to know how things work inside a bank. Thank you for the explanation!
Thanks so much for the time youāve taken to put this explanation together @erincandescent - absolutely fascinating and really informative.
To make this topic have a happy endingā¦
The 3 days from today notification now has the pay early box showing asking you to check back at 4pm to claim it 
2 Likes
Mine in 2 days has no mention of pay early
Just so Iām not misunderstanding. Is that get paid even earlier than early?
I have a Tuesday payment (my salary).
On Saturday, this appeared in my feed labelled 3 Days from Now
I can claim it early today (Monday, as expected)
Assuming this is what @Ordog is also seeing, everything seems to be working as expected.
3 Likes