How Money Moves in the Banking System: A Record Bitcoin Transaction Explained

Nearly 125,000 bitcoins worth $1.1 billion were transferred from one wallet to another in a single transaction, Mashable reports.

The transfer fee came to just over $80. The deal became the largest one-off transaction ever, measured in dollars at the exchange rate at the time the bitcoins were transferred.

124,946 bitcoins were transferred in a single transaction. That's $1,100,000,000, and the fee for transferring it was $80. No government, bank or third party had to review this deal, and none could have stopped it even if they had wanted to. That's the real power of bitcoin

The number of bitcoins transferred amounts to almost 0.7% of the total number of units of the cryptocurrency in circulation.

The previous record belonged to a transaction carried out in October 2019: 94,000 bitcoins worth almost a billion dollars.

The largest transaction by number of cryptocurrency units so far remains a 2011 deal: 550,000 bitcoins for one and a half million dollars — one bitcoin was worth about three dollars at the time.

There have been many comments about how expensive and difficult it would be to accomplish this within the ordinary banking system, and that may well be true. But what struck me is this: in my experience, almost no one understands how payment systems actually work. That is: when you "transfer" funds to a supplier or "make a payment" into someone else's account, how does the money move from your account to someone else's account?

With this article I'll try to change that, and I'll give a simple, but hopefully not too simplified, analysis of this area.

Let's start by finding some common ground

I think, first of all, you need to understand that bank deposits are liabilities [of the bank to you]. When you put money into a bank, you don't actually have a deposit. It isn't a bag of cash with your name written on it. Instead, you have lent that money to the bank. The bank owes it to you. That money becomes one of the bank's liabilities. That's exactly why we say our money sits in a "credit" account: we've extended credit to the bank. Likewise, if you go into overdraft and end up owing the bank, that becomes your liability and the bank's asset. To understand how money moves, it's important to grasp that every entry in a set of accounts can be viewed from these two perspectives.

Transferring funds to an account of a customer at the same bank

Let's start with a simple example. Imagine your name is Alice, and you're a customer of, say, Barclays bank. You owe 10 pounds to a friend named Bob, who also banks with Barclays. Paying Bob is easy: you tell the bank what you want to do, it withdraws the money from your account, and credits 10 pounds to your friend's account. The whole thing happens electronically through Barclays' automated banking system, and it's about as simple as it gets: no money ever comes into the bank or leaves it; the system of accounts is simply updated. The bank now owes you 10 pounds less and owes Bob 10 pounds more. Everything balances out, and it all happens inside the bank: the transaction is said to have been "booked" in the bank's ledgers. This is shown in the diagram below: only three parties are involved — you, Bob, and Barclays. (Naturally, the same analysis applies if you carry out a transaction in euros through Deutsche Bank, or in dollars through Citi, and so on.)

But what happens when you need to transfer money to an account held at a different bank?

This is where it gets more interesting. Imagine you need to pay someone named Charlie, a customer of HSBC. A problem arises: it's easy enough for Barclays to take 10 pounds out of your account, but how can they persuade HSBC to increase Charlie's account by 10 pounds? Why would HSBC agree to owe Charlie more than before? They're not a charity! Clearly, the answer is that if we want HSBC to owe Charlie a little more, they need to owe someone else a little less.

So who is this "someone else"? It certainly isn't Alice: as you'll recall, she has no relationship with HSBC at all. By process of elimination, the only possible candidate is Barclays. And the first thing that comes to mind is: what if HSBC opened an account at Barclays, and Barclays opened an account at HSBC? Each bank could open an account at the other and use these accounts to settle problems of this kind…

Here's how it could work:

• Barclays can take 10 pounds out of Alice's account
• Barclays can then add 10 pounds to HSBC's account held at Barclays
• Barclays can then send HSBC a message saying they've increased HSBC's account by 10 pounds and would like HSBC, in turn, to increase Charlie's account by 10 pounds
• HSBC would receive this message and, knowing they now have an extra 10 pounds on deposit at Barclays, could increase Charlie's account.

Everything balances out for Barclays and HSBC. Before, Barclays owed Alice 10 pounds; now they owe HSBC 10 pounds instead. HSBC was previously at zero; now they owe Charlie 10 pounds, and Barclays owes them 10 pounds.

This model of processing payments (and its more elaborate variants) is known as correspondent banking. It can be shown graphically much like the diagram below. It builds on the previous diagram by adding a second commercial bank; it's worth noting that a correspondent relationship makes it easier for banks to deliver payments to their respective customers.



The scheme works reasonably well, but a few complications arise:

• Most obviously, this only works when the two banks maintain a direct relationship with each other. Otherwise, either the payment simply can't be made, or you'll need to route it through a third (or fourth!) bank until you complete the path from point A to point B. This naturally adds cost and complexity. (Some specialists restrict the term "correspondent banking" to situations involving different currencies, but I find it useful to apply the term even in simpler situations)
• More worryingly, it's also risky. Look at the situation from HSBC's point of view. The payment they made left them with increased exposure to Barclays. In our example, that's only 10 pounds. But imagine the amount was 150 million pounds, and the correspondent bank wasn't Barclays but a smaller, and perhaps less reliable, institution: HSBC would be in serious trouble if that bank went under. One way to address this is a small tweak to the model itself: instead of crediting funds to HSBC's account, Barclays could ask HSBC to debit the account that Barclays holds with them. That would remove the need for large interbank settlements. However, this approach brings its own complications, and either way, the interdependency inherent in this model is a fairly serious problem.

We'll come back to some of these complications later.
[Note: this isn't actually *what happens* today, since the systems described further on are used instead, but I think it made sense to start the story this way so you can clearly picture what's going on]

Hold on… why complicate things? Can't we just use the SWIFT system [Society for Worldwide Interbank Financial Telecommunications, the international interbank messaging and payment system] and be done with it?

As a rule, whenever payment systems come up for discussion, there's always someone who will wave their hands, shout "SWIFT," and consider the matter settled. In my view, this only confirms that such people probably don't understand what they're talking about.

The SWIFT network lets banks exchange electronic messages with each other seamlessly. One of the message types SWIFT supports is the MT103. An MT103 lets one bank instruct another bank to credit an amount to one of its customers' accounts, while the same amount is debited from the sending institution's account at the receiving bank, so that everything balances out. You can imagine how an MT103 message would apply to the case described in the previous section.

So, sending an MT103 message over the SWIFT network "moves" money between two banks, but it's especially important to understand what's actually happening: a SWIFT message is nothing more than an instruction; the actual movement of funds happens through crediting and debiting specific accounts, and depends on banks holding accounts with other banks (directly or through intermediary banks). Simply waving your hands and shouting "SWIFT!" hides these complexities and, as a result, gets in the way of understanding the system.

Okay… fine. But what about ACH, EURO1, Faster Payments, BACS, CHAPS, FedWire, Target2, and so on, and so on????

Hold on… let's briefly recap first.

We've shown that transferring money between two account holders at the same bank presents no difficulty.
We've also shown how money can be transferred between two account holders at different banks using a fairly clever trick: having each bank open an account at the other bank.

We've also discussed how electronic messaging systems like SWIFT can manage the flow of information between two banks and make sure transfers happen quickly, reliably, and cheaply.

But there's still more to discuss… since serious issues arise, such as counterparty risk, liquidity, and cost.
Let's first look at liquidity and cost.

We need to solve the liquidity and cost problem

First, you need to bear in mind that the SWIFT network costs money. If Barclays had to send HSBC a SWIFT message every time you wanted to transfer 10 pounds to Charlie's account, you'd soon find hefty charges on your statement. But worse than that, a more serious problem arises – liquidity.

Think about how much money Barclays would need in order to stay connected with every correspondent bank every single day, if the system described earlier were actually used in practice. They would need to hold large sums in accounts at every other bank, in case one of their customers wanted to transfer money to a customer of HSBC, Lloyds, the Co-op, or anywhere else. That cash could otherwise have been invested, lent out, or spent in some other way.

But here a rather interesting idea might occur to you: after all, a Barclays customer is presumably just as likely to transfer money to an HSBC customer as an HSBC customer is to transfer money to a Barclays customer at any given moment.

In other words, what if we kept track of all the many payments made over the course of a day and only settled the difference? With this approach, each bank could keep far less cash in each correspondent account, and each could put its money to more efficient use, cutting costs while (hopefully) passing some of those savings on to you. This line of thinking led to the emergence of deferred net settlement systems (DNS). In the UK, BACS is such a system, and equivalents can be found in any country. These systems don't exchange messages over the SWIFT network. Instead, messages (or files) go into a central "clearing" system (such as BACS), which tracks all the payments and then, at set intervals, calculates the net amount that each bank owes every other bank. After that, they carry out certain operations between themselves (possibly transferring funds to/from the accounts each bank holds with the other) or use the RTGS system described further on.

This method significantly reduces the cost and liquidity requirements and adds one more block to our diagram:



It's worth noting that credit card mechanisms, and even the PayPal system, can be described in much the same way (as deferred net settlement): all of them are characterized by a process of netting out internal transaction costs, the result of which is only a net amount that gets settled between the major banks.

But even with this approach a potentially more serious problem arises – the loss of settlement finality . You can send the instruction for your payment in the morning, but the receiving bank will not be able to receive (clean) funds until a certain point in time.

That is why the receiving bank has to wait for (clean) settlement on the account, in case the sender goes bankrupt during the transfer: it would be reckless to credit the funds to the receiving party in advance. The result is a delay.

On the other hand, you could take on the risk and reverse the transaction if a problem arises. But then settlement would never be considered "final," and in that case the recipient would have no way to count on receiving those funds by a given deadline.

Is it possible to achieve both settlement finality and zero counterparty risk?

This is exactly where all the pieces of the puzzle come together. None of the approaches discussed earlier can be applied in situations where you need to be absolutely certain that the payment will go through quickly, and that it cannot be reversed, even if the sending bank later goes bankrupt. You badly need this kind of guarantee, for example, if you intend to build a settlement system for securities transactions: no one will hand you $150 million worth of bonds or shares if there is a risk that those $150 million will not be paid, or cannot be returned!

What is needed is a system like the first one we looked at (Alice transfers money to Bob's account at the same bank) - because everything happens truly instantly in it - but one that works with more than one bank involved. The multilateral interbank system discussed earlier seems to work, but it becomes quite messy when transferring fairly large sums, given the possibility that any given bank might go bankrupt.

Now, what if banks could hold accounts at a bank that could never go bankrupt... a kind of bank sitting right at the center of the system. We could come up with a name for it. Let's call it a central bank!

Following this logic, we arrive at the idea of a Real-Time Gross Settlement system (RTGS).
If every major bank in a country holds an account at the central bank, they can transfer money from one bank to another simply by instructing the central bank to debit one account and credit the other. That is exactly what the CHAPS, Fedwire, and TARGET2 systems are for, handling transfers in pounds, dollars, and euros respectively. These systems move funds in real time between the accounts that banks hold at the relevant central bank. So, this is a system that is:

• Gross - there is no netting of obligations (otherwise the system could not be instantaneous)
• Settlement - it has finality; no reversal of funds
• Real-time - settlement happens instantly.

This system completes our diagram:

I thought this article was supposed to be about Bitcoin

Good thing you reminded me. Now the question arises: can Bitcoin be fitted into this model?

It seems to me that Bitcoin very much resembles an RTGS system. There is no netting of obligations in it, (obviously) no correspondent relationships between banks, and all settlement is gross and final.

However, what is interesting about the "traditional" financial landscape is that most retail transactions today are not carried out through an RTGS system. For example, direct electronic payments between UK residents go through the Faster Payments System (FPS), which nets offsetting claims several times a day, not instantly. Why is that? I would say it is chiefly because FPS is (almost) free, whereas payments through CHAPS cost 25 pounds. Many customers would surely use an RTGS system if it were just as convenient and cheap.

So my question, which remains unanswered, is this: will the Bitcoin payment system remain just an analog of a traditional RTGS, handling only the most significant transfers? Or will changes to the underlying network (block size limits, micropayment channels, and so on) happen, and keep happening quickly enough as transaction volumes grow, to let the system stay accessible for both larger and smaller payments alike?

It seems to me the question is still open: I am confident that Bitcoin will change the world, but at the same time I am not so sure that we will live in a world where every transaction carried out via the Bitcoin network "passes through" the blockchain database.

It should also not be forgotten that, besides the exchange of messages between banks, there is almost always an exchange of messages with the national bank - the only bank that has the right to issue its own currency. There is also mandatory financial monitoring of banks, and, when a suspicious transaction is detected, the transfer of information to the state financial monitoring authority.