Grey payments

Just to add my voice here, I love the fact that I can see incoming payments early in Monzo. I see how some people have conflated that with the get paid early function, but I’d be very much against removing early visibility.

If there’s a problem, I’d rather work on the flow and try and decouple pay early from feed visibility, rather than do the easy (and wrong, in my view) thing of just taking away the early sight.


This :point_up_2::point_up_2::point_up_2:

1 Like

I think it’s similar to the loan value fluctuations etc.

More transparency/info is best, but it needs to be explained.

1 Like

I like the fact that it displays upcoming payments early.

1 Like

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.


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;


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

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.


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


Wow, that was a read and a half. Thank you for your explanation, @erincandescent, it’s very much appreciated.


Does this mean international payments are a bit closer?

1 Like

Great write up, thank you Erin!

Thanks @erincandescent! Now I can pretend I know even more :joy::pray:t3:


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.