Domestic Payment Schemes in the UK – By Pradyumna Acharya
Every day in the UK, millions of pounds are moved between bank accounts. This complex ecosystem is dominated by three main domestic payment systems – BACS, CHAPS, and Faster Payments – which are used by individuals and businesses alike to electronically transfer money ranging from a few pence to millions of pounds.
Let’s try to understand the Evolution of these 3 Domestic payment schemes using simple use cases.
Paying somebody with an account at the same bank
Imagine Alice wants to transfer £100 to Bob. Both Alice and Bob hold accounts with BARCLAYS.
Alice requests BARCLAYS to transfer £100 to Bob.
BARCLAYS debits (subtracts) £100 from Alice’s account and credits (adds) £100 to Bob’s account.
It’s all done electronically on BARCLAYS’s core banking system. No money either enters or leaves the bank; it’s just an update to their accounting system. They owe Alice £100 less and owe Bob £100 more and the transaction is “settled” on the books of BARCLAYS.
Imagine Alice, who banks with BARCLAYS, wants to transfer £100 to Carl, who banks with HSBC.
Alice requests BARCLAYS to transfer £100 to Carl’s account with HSBC Bank.
BARCLAYS debits (subtracts) £100 from Alice’s account but how does BARCLAYS persuade HSBC to increase Carl’s balance by £100 and why would HSBC be interested in agreeing to owe Carl more money than they did before? The answer, of course, is that HSBC agrees to owe Carl £100 by owing £100 less to BARCLAYS.
What if HSBC held a bank account with BARCLAYS and BARCLAYS held a bank account with HSBC? They could hold balances with each other and adjust them to make everything work out…
Here’s how it would work:
BARCLAYS debits (subtracts) £100 from Alice’s account with it.
BARCLAYS credits (adds) £100 to HSBC’s account with BARCLAYS and sends a message to HSBC that they had increased their balance by £100 and would like them, in turn, to increase Carl’s balance by £100.
HSBC would receive the message and, safe in the knowledge they had an extra £100 on deposit with BARCLAYS, could increase Carl’s balance by £100 and the transaction is complete.
It all balances out for Alice and Carl… Alice has £100 less and Charlie has £100 more.
And it all balances out for BARCLAYS and HSBC. Previously, BARCLAYS owed £100 to Alice, now it owes £100 to HSBC. Previously, HSBC was flat, now it owes £100 to Carl and is owed £100 by Barclays.
This works well, but it has some problems:
Most obviously, it only works if the two banks BARCLAYS and HSBC have a direct relationship with each other. If they don’t, BARCLAYS either can’t make the payment or need to route it through a third (or fourth!) bank until you can complete a path from BARCLAYS to HSBC. This clearly drives up cost and complexity.
More worryingly, it is also risky. Look at the situation from HSBC’s perspective. As a result of this payment, their exposure to BARCLAYS has just increased as BARCLAYS owes them £100 more. In our example, it is only by £100. But imagine if it was £100 million aggregate and the correspondent wasn’t BARCLAYS but was a smaller, perhaps riskier outfit: HSBC would have a big problem on its hands if that bank went bust.
One way round this is to alter the model slightly:
Rather than BARCLAYS crediting HSBC’s account, BARCLAYS could ask HSBC to debit the account it maintains for BARCLAYS. That way, large inter-bank balances might not build up. However, there are other issues with that approach and, either way, the interconnectedness inherent in this model is a very real problem.
Note: This isn’t what happens today, but this flow helps to build the story for what’s going on currently.
Why can’t we just rely on “SWIFT” and be done with it?
The SWIFT network exists to allow banks securely to exchange electronic messages with each other. It’s critically important to realise that the SWIFT message is merely the instruction: the movement of funds is done by debiting and crediting several accounts at each institution and relies on banks maintaining accounts with each other (either directly or through intermediary banks).
But we still have further to go… because there are some big problems: counterparty risk, liquidity, and cost.
First, we need to acknowledge that SWIFT is not cheap. If BARCLAYS had to send a SWIFT message to HSBC every time Alice wanted to pay £100 to Carl, the customers would soon notice some hefty charges on their statements. But, worse, there’s a much bigger problem: liquidity.
Think about how much money BARCLAYS would need to have tied up at all its correspondent banks every day if this system stated above were used in practice. They would need to maintain sizeable balances at all the other banks just in case one of their customers wanted to send money to a recipient at HSBC or LBG or RBS or wherever. This is cash that could be invested or lent or otherwise put to work.
But there’s a nice insight we can make: On balance, it’s probably just as likely that a BARCLAYS customer will be sending money to a HSBC customer as it is that an HSBC customer will be sending money to a BARCLAYS customer on any given day.
So, what if we kept track of all the various payments during the day and only settled the balance?
If we adopted this approach, each bank could get away with holding a whole lot less cash on deposit at all its correspondents and they could put their money to work more effectively, driving down their costs and (hopefully) passing on some of it to customers. This thought process motivated the creation of Deferred Net Settlement systems. In the UK, BACS is such a system and equivalents exist all over the world. In these systems, messages are not exchanged over SWIFT. Instead, messages (or files) are sent to a central “clearing” system (such as BACS), which keeps track of all the payments, and then, on some schedule, calculates the net amount owed by each bank to each other. They then settle amongst themselves (perhaps by transferring money to/from the accounts they hold with each other) or with the Central Bank.
This dramatically cuts down on cost and liquidity demands
But this approach also introduces a potentially worse problem: we have lost settlement finality. You might issue your payment instruction in the morning, but the receiving bank doesn’t receive the (net) funds until later. The receiving bank therefore must wait until they receive the (net) settlement just in case the sending bank goes bust in the interim: it would be imprudent to release funds to the receiving customer before then. This introduces a delay.
The alternative would be to take the risk but reverse the transaction in the event of a problem – but then the settlement couldn’t in any way be considered “final” and so the recipient couldn’t rely on the funds until later in any case.
Can we achieve both Settlement Finality and Zero Counterparty Risk?
To be continued