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