A simple explanation of the movement of money in the banking system

Original author: Richard Gendal Brown
  • Transfer
From a translator: In recent months, the news of the financial sphere has firmly entered the life of many people. One of the recent topics is the possible disconnection of Russia from the SWIFT system . The threat looks very serious, but what really threatens the country if events develop in this scenario? Our material today is designed to help you figure out how everything works in the global world of finance.

Last week [article published in November 2013] Twitter went crazy due to someone transferring almost $ 150 million per transaction in cryptocurrency. The appearance of such a tweet was in the order of things: Transaction of 194,993 bitcoins worth $ 147 million generates many secrets and speculations

There were many comments about how expensive and difficult it would be to implement in a conventional banking system, and it is quite possible that it is so. But at the same time, I drew attention to this: from my own experience I know that almost no one understands how payment systems actually work. That is: when you "transfer" money to a supplier or "make a payment" to someone else’s account, how do the money transfer from your account to the accounts of others ?

With the help of this article I will try to change the situation and conduct a simple, but, I hope, not too simplified, analysis in this area.

First, find common ground

I think, first of all, you need to understand that bank deposits are the obligations of [the bank to you] . When you deposit money in a bank, in fact you have no deposit. This is not a bag of money on which your name is written. Instead, you loaned that money to a bank. He owes them to you. This money becomes one of the obligations of the bank. That is why we say that our money is in the credit account: we provided a loan to the bank. Similarly, if you exceed the loan and you owe it to the bank, this becomes your obligation and theiran asset. To understand how money is moving, it is important to understand that each entry in the financial statement can be viewed from these two points of view.

Transfer of funds to the client's account of the same bank

Let's start with a simple example. Imagine your name is Alice , and you are a client of, say, Barclays Bank. You owe 10 pounds to your friend named bobwho also uses the services of Barclays. It’s easy to pay off Bob: you tell the bank your intentions, he withdraws money from your account and deposits 10 pounds into your friend’s account. The procedure is carried out in electronic form through the automated banking system Barclays, everything is extremely simple: the money neither comes to the bank nor is withdrawn from it; only the system of accounts is updated. The bank owes you 10 pounds less, and Bob - 10 pounds more. Everything is balanced, and everything happens inside the bank: they say that the transaction is “fixed” in the books of the bank. This is shown in the diagram below: only three parties are participating - you, Bob and Barclays. (Naturally, the same analysis can be performed if you make a transaction in euros through Deutsche Bank or in dollars through Citi, etc.)

But what happens when you need to transfer money to the account of a client of another bank?

Here the situation is more interesting. Imagine that you need to pay a certain Charlie , a client of HSBC Bank. There is a problem: Barclays can easily withdraw 10 pounds from your account, but how can they convince HSBC to increase 10 pounds for Charlie? Why would HSBC agree to be indebted to Charlie more than before? They are not a charitable organization! Clearly, the answer is that if we want HSBC to owe Charlie a little more, they need to owe someone else a little less .

Who should this "other" be? This is definitely not Alice: if you remember, she has nothing to do with HSBC. By means of an exception, it turns out that the only possible option is Barclays. And the first thing that comes to mind: what ifWill HSBC open an account with Barclays and Barclays open an account with HSBC ? Each of the banks could open an account with another bank and regulate these accounts to solve these kinds of problems ...

Here's what you can do:

  • Barclays can withdraw 10 pounds from Alice's account
  • Then Barclays can add 10 pounds to the HSBC account opened with Barclays
  • After that, Barclays can send an HSBC message that they increased their account by 10 pounds and would like those, in turn, to increase their account by 10 pounds Charlie
  • HSBC would receive this message and, knowing that they have an extra 10 pounds on deposit at Barclays, could increase Charlie's account.

Everything is balanced for Barclays and HSBC. Prior to that, Barclays owed 10 pounds to Alice, now they owe 10 pounds to the HSBC bank. HSBC had been at zero before, now they owe 10 pounds to Charlie, and Barclays owed 10 pounds to them.

This model of payment processing (and its more complex varieties) is known as the activity of banks on the basis of correspondent relations. Graphically, it can be represented like the diagram below. As a basis, the previous scheme is taken and a second commercial bank is added; it is important to note that the presence of correspondent relations allows banks to facilitate the payment of payments to relevant customers.

The scheme works pretty well, but there are some difficulties:

  • Most obviously, this is possible only when two banks maintain direct communication with each other. Otherwise, either you will not be able to make the payment, or you will need to get the route through the third (or fourth!) Bank until you complete the journey from point A to point B. Of course, this increases expenses and the degree of difficulty. (Some experts limit the use of the concept of “correspondent relations” to situations involving various currencies, but it seems to me that this term is useful to apply even in simpler situations)
  • More worrying is the fact that it is also risky. Take a look at the situation from the position of HSBC Bank. The payment they made resulted in increased vulnerabilityfrom the side of Barclays. In our example, just 10 pounds. But imagine that the amount was £ 150 million, and the correspondent bank was not Barclays, but a smaller and perhaps less reliable organization: HSBC would have had big trouble if this bank went bankrupt. One solution is to make a small change to the model itself: instead of crediting funds to an HSBC account, Barclays might ask HSBC to debit the account used by Barclays. Then there would be no need for large interbank settlements. However, with this approach, other difficulties arise and, one way or another, the interdependence inherent in this model is a rather big problem.

In the future, we will talk about some of these difficulties.
[Note: this is not what is happening today * in fact *, because instead the systems described below are used, but I think it was logical to start the story just so that you could clearly imagine what was happening]

Wait ... why complicate things? Is it possible to simply use the SWIFT system [eng. Society for Worldwide Interbank Financial Telecommunications - International Interbank Information Transfer and Payment System] and end it?

As a rule, during the discussion of payment systems, there will certainly be a person who will wave his hands, shout “SWIFT” and assume that the issue is resolved. In my opinion, this only confirms that such people, for sure, do not understand what they are talking about.

The SWIFT network allows banks to seamlessly exchange electronic messages with each other. One of the message types supported by the SWIFT network is MT103. MT103 enables one bank to give instructions to another bank so that the latter transfers the amount to the account of one of its customers, while the same amount is debited from the account of the organization sending the message to the bank that receives it, so that everything is balanced. You can imagine how MT103 would apply in the case described in the previous part.

Thus, as a result of sending MT103 message on the SWIFT network, money is “sent” between the two banks, but it is especially important to understand what is really happening: a message on the SWIFT network is just an indication; cash flow is carried out when they are transferred to some accounts and depends on banks that have accounts with other banks (directly or through intermediary banks). Just waving and shouting: “SWIFT!”, Means hiding these difficulties, and therefore hinder understanding of the system.

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

Stop ... Let's first briefly repeat.

We have shown that transferring money between two account holders in the same bank does not cause difficulties.
We also showed how you can transfer money between two account holders in different banks in a rather ingenious way: to make each bank open an account in another bank.

In addition, we discussed how electronic messaging systems like SWIFT can control the flow of information between two banks and ensure that transfers are made quickly, reliably and cheaply.

But we have something else to discuss ... since serious issues arise such as counterparty risk, liquidity and expenses.
First considerliquidity and expenses .

We need to solve the problem of liquidity and expenses.

First, keep in mind that a SWIFT network costs money. If Barclays needed to send a message over the SWIFT network to HSBC every time you want to transfer 10 pounds to Charlie's account, you would soon find significant costs in your statement. But worse, a more serious problem arises - liquidity .

Think about how much money Barclays would need to keep in touch with all correspondent banks every day if the system described earlier were put into practice. They would need to have large amounts in their accounts at all other banks in case one of their clients wanted to transfer money to their client’s account at HSBC, Lloyds, Co-op or elsewhere. This cash could be invested, loaned or otherwise spent.

But here a very interesting thought may arise: in the end, the Barclays client will probably start transferring money to the HSBC client's account with the same degree of probability that the HSBC client will start transferring money to the Barclays client's account at a certain point in time.

That is, what if we continued to track all the numerous payments during the day and recorded only the difference ? With this approach, each of the banks could have much less cash on each of the correspondent accounts, and everyone could invest their money more efficiently, while reducing costs and (hopefully) sending part of this money to your bank. Such reasoning led to the appearance of deferred net settlement systems.(SONR). In the UK, such a system is BACS, and in any country its analogues can be found. In such systems, they do not exchange messages through the SWIFT network. Instead, messages (or files) are sent to a central “clearing” system (such as BACS), which tracks all payments and then, at a certain time, calculates the net amount that each bank owes to any other bank. After that, they carry out certain operations among themselves (possibly sending money to / from accounts that each bank has in another bank) or use the RTGS system described below.

This method significantly reduces the cost and liquidity requirements and complements our scheme with one more block:

It is worth paying attention to the fact that in the same way (as SONR) you can describe the mechanisms of using credit cards and even the PayPal system: all of them are characterized by the process of calculating internal transaction costs, the result of which is only the net amount determined for large banks.

But even with this approach, a potentially more serious problem arises - the loss of completeness of calculation . You can send an indication of your payment in the morning, but the receiving bank will not be able to receive (net) cash until a certain point.

Therefore, the receiving bank has to wait for the receipt of a (net) settlement of the account in the event of the sender's potential bankruptcy during the transfer: it would be rash to transfer funds to the receiving party in advance. The result is a delay.

On the other hand, one could take the risk and, in case of a problem, cancel the transaction. But then the calculation would never have been considered “completed”, and in this case, the recipient could not have expected to receive this money before a certain date.

Is it possible to achieve completeness of settlement and zero counterparty risk?

This is where all the pieces of the mosaic are stacked. None of the approaches discussed earlier can be applied in situations where you need to be absolutely sure that the payment will be made quickly and cannot be canceled, even if the sending bank subsequently goes bankrupt . You really need this kind of guarantee, for example, if you intend to create a system of settlements for operations with securities: no one will give you $ 150 million in bonds or shares, if there is a risk that these 150 million will not be paid, or they cannot be returned!

A system is needed, like the first of those that we considered (Alice transfers money to Bob's account in the same bank) - as everything happens really fast in it - but which will work with the participation of more than one bank. The multilateral interbank system discussed earlier seems to work, but it becomes quite confusing when transferring large enough amounts and if there is a possibility that a particular bank may go broke.

Now, if banks could have accounts in a bank that could not go bankrupt ... a kind of bank that would be located in the very center of the system. You can come up with a name for it. Let's call it the central bank !

Following this logic, the idea of a real-time gross settlement system comes up[eng. Real-Time Gross Settlement system, RTGS].
If all the country's largest banks have accounts with a central bank, they will be able to transfer money from one bank to another simply by instructing the central bank to write off funds from one account and transfer them to another. For this, the CHAPS, FedWire and Target 2 systems are designed, which are engaged in the transfer of pounds, dollars and euros, respectively. These systems carry out cash flow in real time between the accounts that banks have with the respective central bank. So this is the system:

  • Gross - no accounting for debts (otherwise the system could not be instantaneous)
  • Settlements - availability of completeness; no refund
  • In real time - calculations are carried out instantly.

This system completes our scheme:

I thought this article was somehow related to Bitcoin.

Well, that reminded. Now the question is: can you put Bitcoin in this model?

It seems to me that Bitcoin is very much like RTGS. There is no accounting for debt, (obviously) there are no correspondent relations between banks, and all settlements are gross, completed.

However, the “traditional” financial landscape is interesting in that most retail transactions today are not carried out through the RTGS system. For example, direct electronic payments between UK residents are made through the FPS expedited payment system. Faster Payments system], which sets off counterclaims several times a day, not instantly. Why is that? I would say because, first of all, FPS is (almost) free, while the cost of payments in the CHAPS system is 25 pounds. Many customers would probably use RTGS if it were just as convenient and cheap.

Therefore, my unanswered question is: will the Bitcoin payment system remain just like the traditional RTGS, which carries out only the most significant transfers? Or will changes in the core network (block size restrictions, channels for micropayments, etc.) occur and will occur rather quickly with increasing transaction volumes, allowing the system to remain available for both more significant and less significant payments?

It seems to me that the question still remains open: I’m sure that Bitcoin will change the world, but at the same time I’m not so sure that we will live in a world where every transaction made using the Bitcoin network will “pass” through the Blockchain base.

Other financial and stock market related materials from ITI Capital :

Also popular now: