I must start this post of first saying, I do love DLT (Distributed Ledge Technology) and the Blockchain. It is a fantastic technology that has so many capabilities that I believe is currently underutilised. However, it constantly amazes me how many times within financial services I read about use cases that promote DLT, when quite frankly DLT is NOT the appropriate technology.
In this post I call out the concept of a universal shared ledger, recently promoted by SWIFT.
What is the shared ledger?
The concept here is to move away from the traditional method of books and record keeping where financial market infrastructure (FMIs) and participants (typically banks) keep records of transactions in isolated systems. Typically, transactions are stored in a structured database. Traditionally, messaging layers enable the data of transactions to flow over the FMI and onto the banks that participate. However, here, a shared ledger provides a common view to all participants – providing information on transactions and real-time balances.
There are numerous studies as to the potential benefits of such a ledger carried out by SWIFT and also various other institutions, including the BIS. Most benefits come from the concept of operating in real-time and on a 24/7 basis. The shared ledger would also reduce the need for numerous reconciliation processes and could improve speed, efficiency and ultimately reduce costs for banks and customers. All sounds good so far right?
The problems
Sadly, while the benefits are easy to measure and discuss, the drawbacks require a little more deeper thinking, and an understanding of how the technology works in depth.
Firstly, almost every study talks about the immediate nature of settlement on a DLT based infrastructure. However, the reality is this isn’t possible, and it slows once we add significant volume. In a global unified shared ledger, the volume would quickly dwarf anything that we have seen on a DLT infrastructure to date in a matter of weeks, months at worse. So, let’s look at Bitcoin, the world’s longest running DLT solution for a financial asset.
How long does it take Bitcoin to truly settle a transaction? Well it’s not instant. Currently the average time has risen to approximately 10 minutes. But at times of congestion, and let’s face it, financial services is highly prone to spikes in activity, settlement time can be significantly impacted. Network activity, hashrate and transactions fees all have a role to play on actual settlement times. If the network is congested, then transactions with higher fees are prioritised, which leads to longer wait times for smaller fee-based transactions.
As of March 16th, 2024, the average confirmation time was reported to be 258.67 minutes, that’s over 4 hours. Even on Ethereum settlement time can be up to 5 minutes.
Secondly what is the real cost of a shared ledger, who is hosting the nodes, and what are the cost implications. Well for a resilient DLT based solution, a shared ledger would have to operate nodes all over the world, and these would be strategically located to minimise the risk of outage. Let’s look at Bitcoin and Ethereum again.
Bitcoin has over 18,000 nodes globally, each one requiring over 1Tb in data storage and unlimited bandwidth for broadband connections. Ethereum has over 7 modes globally, again each one with demanding bandwidth requirements and data storage. In order to compensate for such hosting, Ethereum for example charges “gas fees”. These fees effectively go back into the network. But ask anyone who trades cryptocurrencies, gas fees are far from uber cheap. At the lowest level, a transaction fee of $0.69 could be applied to a simple transaction on the ledger.
Gas fees are payments that compensate the network for the computational energy required to process and validate transactions on the ledger. These fees are denoted on a unit basis, So the $0.69 fee is based on typically 19 units. But units will increase as the blockchain becomes larger. But this is the lowest level, in reality Gas fees are much higher based on who transactions are carried out by, and again this is to do with efficiency of computation. Gas fees are also dependent on other factors, such as Network congestion (our peak times of transactions), the complexity of a transaction (relating to programmable smart contracts), supply and demand and good old block space limits.
Now maybe gas fees would be applied differently for a shared ledger, but the comparison and illustration is still a valid one, hosts of nodes will not be expected to provide an underlying global infrastructure free of charge. If gas fees were representative of a transaction over Faster Payments in the UK, then a shared ledger would be costing the banks more to settle transactions over than the current implementation of Faster Payments, which can be accessed via agency banks for as little as 6p. That’s quite a difference, compared to $0.69 in gas fees.
Thirdly, data location. It seems that everyone forgets a number of regulations globally around where data can be stored. The simple nature of data storage location has meant cloud providers such as Microsoft have had to evolve their cloud services to allow banks to ensure the exact nature of where data is located. When I was building ClearBank, understanding exactly where your data is located was a key factor in our decisioning around cloud and cloud-based services. This hasn’t changed. When we look at global regulators the majority insist on data residency in their jurisdiction only. That means data cannot be replicated outside of that jurisdiction, nor can it be stored there in back-up form. When we look at the challenges of rights of access, and there have been several legal cases around this, regulators do not like the idea of foreign regulators or investigators being legally able to access their data. The federal government in the USA and many other governments can access all data, even if stored outside of their jurisdiction if it holds US based data. Now let’s think on a global scale, how does a shared ledger work between the USA and Europe? Or more challenging, USA and Cuba? How about China and anyone?
Finally, privacy of data should be critical, but in a shared ledger, anyone can see what is happening on that ledger. When we think of that, it means competing banks can now see balances held by others. If they can see balances and transactions, then this can lead to insider trading activities and or other activities which regulators around the world clamp down on. A shared ledger opens up an entire heap of challenges around access to the ledger and acting on what you can see from it. The obvious solution here is to then ensure participants cannot directly access the ledger, but if that’s the case, that means we have FMIs between the participant and the ledger, and that means most of the so-called benefits of a shared ledger are negated immediately….
Conclusion
DLT and the Blockchain is a fabulous technology for many many use cases. However, financial services persist in using it in areas where it isn’t a great fit. All too often we look at the benefits of a technology, but fail to look at potential issues with it, or as a result what other problems can arise.
When I look at many use cases of DLT and blockchain in financial services, the technology seems to be selected not because of its immutable nature primarily, but because it solves routing and reconciliation challenges. But while solving these issues, we aren’t looking at the problems that arise from the technology, performance, scale, infrastructure fees, data location and access to that data. And, I have only touched on a number of issues…
FinTechAndrew - The blog 