Why the SWIFT shared ledger concept is a BAD IDEA

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.

https://www.swift.com/news-events/news/need-rich-data-shared-ledger-paradigm?utm_campaign=Innovation&utm_content=Oktopost-linkedin&utm_medium=organic_social&utm_source=linkedin

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.

Not the perfect comparison, but a comparison that we must draw when we look at global spanning DLT infrastructure

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 16^th, 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.

Gas fees in Ethereum are used to cover the costs of running the network. Any shared ledger will have to implement something very similar to ensure nodes are operated and maintained

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…

Correspondent Banking 3.0: The importance of discovery

When we think of cross-border payments, wholesale PvP or any sort of activity cross-border, at the end of the day a Correspondent Bank is required, if only to facilitate an onward payment to the end beneficiary. What amazes me, however, is how many solutions overlook this fact, and worryingly how many do not take into consideration frankly, the hassle and time it takes, setting up a correspondent relationship.

Yes, there are easier ways of doing things, like using a global spanning bank that provides multi-currency, but all you are doing is hooking into that banks correspondent banking relationships and you pay a premium for that – meaning your transactions cross-border aren’t as attractive as the competition, they just can’t be.

If you really want to be able to compete, to offer customers great rates and a great experience (and who doesn’t want near real-time payments?) then embracing correspondent banking is the only way. Or is it?

RTGS.global, more than just PvP

RTGS.global is a financial market infrastructure that enables settlement, be that off of the back of a wholesale PvP trade or a need to execute a cross-border payment, RTGS.global provides that settlement certainty.

As a Settlement Fabric, it also provides the transparency of who else is available to interact with on the Settlement Fabric, now that means other participants (Banks, MTOs, FinTech or Corporates) but also other FMIs and Central Banks (currency). We call this our Discovery Service, which does exactly what you might expect, allows you to discover other participants on Settlement Fabric.

But, it does much more than just Discovery. Discovery is so important as it short-cuts the need to try and source a Correspondent bank in any given currency, it short-cuts that process because they are right there, listed. But Discovery isn’t just about finding a Correspondent, it’s also about forming relationshjips, and what does that look like.

Standardised enhanced due diligence

The Discovery Service provides an opportunity to introduce a standardised due diligence process. Within Settlement Fabric, participants can form bi-lateral relationships, which allow secure messaging tunnels to be created off of the Fabric between the two participants. In doing so, participants can now exchange identity proofs cryptographically, this forms the first stage of any due diligence, knowing your partner (or Knowing Your Customer).

Once you have some basic KYC carried out, you can request enhanced Due Diligence. This can be in the form of a detailed Risk Profile, which incorporates a Fabric wide standard for Sanctions Screening, PEP identification and AML. You may also request additional information, this comes in the form of expected documentation, such as AML policies etc. These are all bi-laterally shared, yes, truly point-to-point and 100% private to the relationship between the banks.

Securing Correspondent Banking

If all goes well in terms of enhanced DD, then a relationship can be agreed between the two parties. Typically, with Correspondent Banking, this triggers off a complex process with regards to identifying the connection you will make over SWIFT. That means RMA exchanges and various other processes, all of which are of concern to any CISO and require some heavy operational lifting.

With Settlement Fabric though and the Discovery Service, that’s all removed entirely. The use of Digital Identity here and the secure bi-lateral tunnel means your systems have already formed a highly secure connection with the entity, knowing that that entity is who they say they are. Additionally, all your security key exchanges are automated, so no human interaction is required, no lengthy security processes leading to a secure connection in seconds. You’re in real time, ready to trade, ready to make payments, ready to leverage that correspondent relationship.

Conclusion

The Discovery service within the RTGS.global Settlement Fabric short cuts all the pain and time when looking for a Correspondent – well Host is the terminology with Settlement Fabric. We say Host because there is also no need for Nostro/Vostro account opening processes, no credit risk and therefore a lot of the relationship is lighter touch than Correspondent Banking.

Settlement Fabric with the Discovery service, well that’s Correspondent Banking 3.0 right there.

RTGS.global Participation? It’s not just for banks.

I’ve often been asked if RTGS.global, as a Financial Market Infrastructure, is just for banks. I say ask, that’s not true, I have it replayed back to me that only banks can participate. Well, I can categorically say that it’s not just for the big banks. And let me explain how and why….

With the RTGS.global Settlement Fabric there is a concept of a Host. A host is capable of funding a segregated account at the central banks, so think Bank of England in the UK, Federal Reserve in the USA etc. The Host is also the participant that can have money sent to it from that segregated account. A host is therefore a special type of participant, and typically this means they are bigger banks, though they could be a large MTO which has access to Central Bank accounts.

Now the Host can play host for other participants, and in doing so they act as a sort of Correspondent. I say sort of because there is no need for a nostro/vostro, no credit lines being opened, no collateral needed for the relationship etc etc. But from a regulator’s perspective, they are the correspondent.

Various types of relationships and participants

So if a Host is a type of relationship on Settlement Fabric, what other types of relationships are there? Well a few, but the only other one of real concern is a payment partner. A Host may allow you to hold a given currency and therefore trade it, it can also act as your payment partner to make onward payments to end beneficiaries. But you aren’t limited just to your Host to do that.

Payment partnerships facilitate onward payments only. This can be payments within the Settlement Fabric itself, or payments that extend beyond the direct participation in Settlement Fabric over a domestic payment rail. Taking the UK as an example, that means a Payment Partner could be used to make payments over FPS as opposed to your Host bank.

With these two relationships now understood, you can see that there is no need for a participant to be a bank itself. A participant needs to discover and form relationships with at least Hosts, that’s true, but they don’t need to be a bank.

Participants can therefore be any organisation that has a need to purchase foreign currency, and to make payments with that currency. That’s it. So with that in mind, any FinTech can participate in Settlement Fabric, any MTO (Money Transfer Organisation) can participate, any organisation that has a need to make overseas payments can participate. Each participant saving in FX fees and enjoying near real time payment capability.

FinTech, MTO and Corporates

While Corporates are able to participate in Settlement Fabric directly, they won’t bring much to Settlement Fabric in terms of new innovation, rather they will simply benefit from the efficiencies and risk reduction that Fabric brings. However, FinTech firms and MTOs, they may well bring additional innovation to the marketplace that leverages the capabilities of Settlement Fabric. Such innovations maybe used by other direct participant banks, or corporates, but it will no doubt deliver better customer outcomes – all possible because Settlement Fabric enables a wide range of direct participation.

Time for Banking-as-a-Service to talk security

Banking-as-a-Service (BaaS) is an unbelievably powerful concept, one that leads to a plethora of new banking innovation, customer experiences, financial service offerings and even new industries, like embedded finance. But it also helps drive efficiency across the banking sector which in turn helps spread costs – which ultimately helps keep things like current accounts free, or very cheap to use.

Clearly, I am a big fan of BaaS, and no-one will be surprised by that, since I first started designing, I believe the world’s first ever BaaS solution, back in late 2014. This concept went on to form the core offering and proposition that was and is ClearBank, the UKs first new clearing bank in over 250 years and the first bank to bring what I call true Banking-as-a-Service capabilities to the market. I say true because, unlike other offerings, BaaS by ClearBank also means you can potentially leverage the “license”, which in turn means users of ClearBanks BaaS can provide FSCS protected bank accounts.

I digress….

BaaS always has had and still has today, a challenge regarding security. And this comes down to a few macro level issues, which include:

• Key creation and exchanges always run over the same infrastructure.
• Humans are involved in some aspects of the security process / key exchange
• A single form factor of authentication is used
• Limited capability to limit the lifespan of security keys
• Lack of immutability of messages

These aren’t small issues, and until recently were risks that had to be partially mitigated with complex, cumbersome processes, and the use of technology wherever possible. All this comes at a cost, and since BaaS is about driving costs down and lowering the barrier to entry, security constraints kind of go against the proposition a little. But things all changed when ID Crypt Global started to trail DPKIps, a Decentralised Public Key Infrastructure coupled with some smart tech based components and a set of protocols, aimed at solving the toughest of security challenges, that of systemically important payment systems….

So how does DPKIps help solve these challenges for BaaS. Well let’s look at them one at a time.

Key creation and key exchanges

No matter the BaaS solution, the challenge is always around security keys, their creation and potential reliance on a single point of failure, the Central Authority (CA), and how keys were exchanged between BaaS provider, and BaaS consumer.

With DPKIps, bi-lateral peer-to-peer secure communications channels are setup using the IDC Agent, think of this as an Identity Vault and Hardware Security Module (HSM) that is able to communicate securely with other agents. This peer-to-peer infrastructure is OUTSIDE of the control of the BaaS provider, and as such, removes the BaaS provider from the creation and key exchange infrastructure/processes. This alone significantly improves security and removes many risks.

When peer-to-peer communication channels are opened, they are cryptographically secured, which allows data and sensitive information, like security keys to flow safely between the two IDC Agents. Because of this, DPKIps creates “pairwise” keys which are unique to the peer-to-peer relationship connection itself. These pairwise keys are essentially two sets of private/public keys, where the public keys are exchanged between the two IDC Agents.

For a BaaS provider, this means security keys can be exchanged and the BaaS provider need not build any technology, any additional infrastructure, form a relationship with a CA, act as a CA or spend months building and designing operational processes to mitigate key exchange risk.

Human intervention

With the vast majority of BaaS implementation, security keys/tokens etc require some form of human intervention, be that operationally or even by interfacing with a BaaS providers web portal. At some point, humans are involved in the exchange of security keys, secrets, tokens etc. This adds risk, and when we are talking financial transactions, that potentially could be high value and volume, the risk is simply increased.

With DPKIps, key exchange is automated and humans never know where the keys are physically stored, even system administrators are unable to access the underlying infrastructure used by the IDC Agent.

By removing the need for humans to be involved, not only does DPKIps reduce the associated security risk, it also significantly reduces complexity and operational cost.

Single form factor

Almost all BaaS solutions use API keys and then some form of message signing. However, this doesn’t actually act like Multi-Factor Authentication (MFA) does for end users. There is only ever a single point of authentication – and that is through the BaaS provider.

DPKIps solves this because the creation of security keys and their exchange, takes place on infrastructure outside of the BaaS providers control. It also ensures keys that are exchanged and distributed over one infrastructure have been applied and used correctly for the purpose of message signing within the BaaS solution. This means there are now two independent forms of authentication. The first being the BaaS providers infrastructure and its inherent security, the second being the two cryptographic signatures that are attached with the message. These signatures prove several facts,

1. The message was signed correctly using expected keys.
2. The message content is immutable (tamper proof)
3. Who the message originated from
4. The intended recipient of the message (this could be the ultimate recipient, not limited to the BaaS provider)
5. The message can be stored tamper proof for the purpose of audit

Note that with DPKIps there are two signatures on the message. The first is based on the identity of the sender, the second on the unique pairwise keys exchanged between IDC Agents. I will talk to why there are two signatures when we look at the “lack of immutability of messages” in BaaS.

Key lifespan

BaaS security keys, tokens etc always have a lifespan that is longer than desired. This is purely because of the processes and therefore cost associated with key creation and exchange. Because these processes are fraught with risk, complexity and are expensive, rotating and replacing security keys becomes a risk based exercise. In addition, security keys aren’t cheap. If a CA is used, then keys typically can cost approximately £1,000 per key, so the expense of replacing keys also has to be taken into consideration. Many therefore leave security keys to be rotated/changed on an annual basis.

Longer living security keys carry risk. If a key is compromised and has a longer lifespan, then that key can be used for a longer period of time and therefore poses more risk. Even if the key isn’t used initially, the fact it has a longer window in which to be used, again increases risk.

Ideally, security keys would live for just a few hours, significantly limiting the risk associated with a compromised key. With DPKIps this is exactly what can be achieved…

DPKIps allows key exchanges to be automated, and as such, key creation and exchanges can be scheduled and automated. Since DPKIps delivers security keys without a CA and at a fraction of the cost, security keys can be rotated quickly, efficiently, easily and at a cost that is not prohibitive. One Financial Market Infrastructure (FMI) user of DPKIps rotates ALL keys across every single network member within a time period of less than 24 hours. Keeping in mind, that just two entities will have 4 keys to secure their relationship, a significant number of keys are being exchanged on a daily basis.

Lack of immutability of messages

Messages that flow across BaaS aren’t immutable, they aren’t tamper proof and therefore carry risk. How does a BaaS system cryptographically prove that the message originated from where it should have, and how does it store that message to prove immutability to an auditor years from when the message was sent?

Message signing within BaaS aids with the tamper control around messages, however, since keys will be changed, even if signatures are stored by the BaaS provider and auditor is unable to confirm that the message processed was the message received and more worryingly the message stored.

DPKIps solves this with its two signatures.

The identity signature, known as the public signature is based upon the senders digital identity. The IDC Agent writes the digital identity public key to a blockchain, which is an immutable ledger, therefore ensuring the public key is available to all forever. The public key relates to the identity of the sender, so an auditor is always able to decipher a message signature signed with DPKIps. That signature therefore proves the immutable nature of the message, from its origination to its processing to its storage, it can never be modified – if it is, then the signature no longer matches the message itself. Auditors can for the life of the message being stored, always prove it hasn’t been tampered with.

The second signature relates to the pairwise keys exchanged between the message parties. This signature proves that the sender meant for the recipient to receive the message, along with the immutable nature of the message, it also proves the immutable nature of sending it to the recipient.

Conclusion

Since I first started working on BaaS back in 2014, it’s safe to say it has come a long way. It is now estimated that by 2030, BaaS will be a $7 trillion industry, that’s right a $7 trillion industry. As the adoption of BaaS continues and the value of the industry continues to increase, so is the attention that BaaS providers receive from cyber-criminals. As such, BaaS needs to continue to be at the cutting edge of financial services, this time in terms of security implementation.

From a security footing, DPKIps significantly improves security associated with BaaS implementations, but it does more than just improve security. DPKIps mitigates security risks while at the same time, drives down all associated security and operational costs. Its these two factors, improving security and driving down costs, that sees BaaS and DPKIps strategically aligned.

For more information on DPKIps visit the ID Crypt Global website. You can also get a deeper understanding of what DPKIps is here.

Where RTGS.global uses the Blockchain

Ever since Nick Ogden first spoke of his idea for brand-new infrastructure for cross-border settlement, namely RTGS.global, there have been 3 main misconceptions that I have to answer.

1. RTGS.global uses a coin/token (could be even XRP)
2. RTGS.global uses DLT blockchain for settlement
3. RTGS.global doesn’t use any DLT blockchain technology

I can confirm, that ALL 3 of these statements are untrue. So, in this post I want to explain where RTGS.global uses blockchain technology to deliver its Global Settlement Fabric and equally important, where it doesn’t use blockchain technology.

Tokens, coins and XRP

I will start with the easy one. The “why” behind designing out RTGS.global was always to remove financial friction from cross-border activity. When we looked at a true end-to-end journey, it was very apparent that introducing a token, coin or utilising something like XRP was actually adding friction to a process we were trying to reduce friction from.

For quite a while now there has been this notion that to deliver more efficient cross-border settlement and transactions, you must use a blockchain. Now, where this notion has come from, I am not too sure about, but I would guess from blockchain companies themselves and or those invested in a specific coin (XRP gets a lot of support here for this very use case).

The reality is, RTGS.global Settlement Fabric deals in removing friction and the settlement of value. In its purest use case, that is good old FIAT currency held within a central bank. Please note, FIAT held within a central bank. We are not talking commercial bank money here; we are talking the highest quality liquid FIAT asset you can hold.

Now because the Settlement Fabric deals in value, it can be used to settle assets other than FIAT currency, but to settle cross-border and facilitate 24/7 immediate cross-border payments, you can use FIAT with RTGS.global. So why swap into a token, a coin or leverage someone else’s token like XRP? All you are doing at that point is adding friction (unless you believe we live in a world where all end beneficiaries want to receive a crypto asset and or can spend freely that asset).

So, in short, RTGS.global doesn’t use any form of token, coin and it doesn’t use XRP to facilitate cross-border settlement and transactions…

DLT Blockchain for settlement

I personally love DLT and blockchains, there are some very complicated and highly important problems that are solved with DLT and the blockchain. However, when it comes to cross-border settlement and transactions, this isn’t one of them. Even when we talk of domestic transactions, again, I doubt the blockchain is ever the right technology for that.

Let’s start with an issue that every single cross-border solution that uses the blockchain seems to miss. And I am including lots of CBDC discussions and proof of concepts. The fact that, every single transaction is recorded and replicated, and that every participant can therefore see all activity on the blockchain. This is a good thing, in some ways, but also a very bad thing. It’s good because, it is that which provides immutability of data, and that is mission critical for any payment system. It’s also a good thing because it allows others to simply act on transactions that appear on their nodes that they must act upon. There is no need to understand routing, rather the blockchain replicates to the relevant nodes/banks and hey presto they have the data.

But, now for the bad. Firstly, data replicating to all nodes is a bad idea for two primary reasons. The first is that data sovereignty becomes tricky, especially when you span multiple jurisdictions and geographies. We have seen within financial services time and time again; data needs to be sovereign in terms of storage location and even data paths must be known. So, this immediately makes the blockchain hard to adopt in the real world, especially for a cross-border situation or even if you have foreign entities able to interact with that blockchain. The second is, everyone with access to a blockchain node has access to the data. So, all the participants on your blockchain can read each transaction (as I said a moment ago that can be a good thing). However, it also means that I can see my competitors trades. I can see what other banks are doing on behalf of their customers. With some simple volumetric tool, I can quickly and easily take that data and essentially gain insider trading information.

The bad here outweighs the good, but the good points must not be lost.

Now, if point 3 is also untrue (RTGS.global doesn’t use any DLT blockchain technology) then where DOES RTGS.global use the blockchain?

Where the Blockchain is used

RTGS.global has three specific use cases where it leverages blockchain technology. Let’s start with ledgers and immutability of data. As I said, this is mission critical stuff for a payment system, so RTGS.global DOES use the blockchain to provide immutability of data. However, we use it in a way that isn’t the common approach…

RTGS.global runs currency ledgers all across the globe, e.g. a GBP ledger is run for all transactions that GBP is involved in. That ledger is sovereign within the UK. A EUR ledger is in the EU and yes, USD in the USA. Each one of these ledgers is based off Azure SQL DB Ledger. I have blogged about this previously, and you can read that post here.

Azure SQL DB Ledger gives RTGS.global all the typical flexibility that SQL Database gives you, however, it backs into a private Blockchain underneath. Private is the key here. The blockchain nodes are not accessible by participants, and they don’t need to be, rather data is pushed into the blockchain as it is written to the SQL DB. The blockchain therefore provides an immutable ledger, one that resides in that specific jurisdiction and one that doesn’t replicate data across the RTGS.global Settlement Fabric.

RTGS.global therefore uses a blockchain per currency that is within the Settlement Fabric. So yes, RTGS.global for sure uses Blockchain technology….

Now, in addition, Blockchain technology is also used to provide identity of participants within the Settlement Fabric. ID Crypt Global, an RTGS.global partner, provides sovereign digital identity capabilities utilising a public global spanning, you may call it traditional DLT Blockchain. This allows participants to discover and identify other participants on the network, and this feeds into the RTGS.global Correspondent Banking 3.0 implementation.

Finally, and yes, more Blockchain technology, RTGS.global utilises the Blockchain to secure Settlement Fabric itself. The Blockchain provides a decentralized approach to security. A centralised Public Key Infrastructure (PKI) is replaced with a Decentralized approach (DPKI) which enables true end-to-end encryption and immutable proof that messages have not been tampered with. It also removes many operational processes associated with security and replaces them with automation. Blockchain technology here also ensures that the lives of security keys are short lived, typically being rotated in hours as opposed to annually!

Final Blockchain thoughts…

In a nutshell, RTGS.global doesn’t use DLT or Blockchain technology to route messages around the world, nor to act as a shared ledger or for the actual settlement of transactions. Therefore, you will not see RTGS.global claiming to use the Blockchain to assert settlement, which is why most will say RTGS.global doesn’t use the Blockchain.

However, RTGS.global uses Blockchain technology where it works best, to provide immutable truth of identity, decentralized security, end-to-end encryption and yes, immutability of financial transactions within a specific currency.

The need for immutable data, but the challenge of residency

In every industry there is a real push to make sure you can be confident in the data that you hold. That means understanding how data is captured and stored, making sure its accurate and complete and then ensuring you have timely backups. An old mentor of mine always said, the challenge with data is, “shit in, shit out”. His comments were as true then as they are today. How many systems and platforms around the world and in every industry (especially financial services) is hampered by poor data integrity, out of date data or even worse, fields of data that just have garbage in them, or nothing at all.

Now how many systems struggle with data because it has been unexpectedly changed? The output therefore is inaccurate because data has been corrupted or worse still, tampered with? In the world of financial services, the ability to ensure your data is all present and correct is almost everything. Because of this challenge, there has, over the past years, been a real drive by certain technologies to push themselves as the de facto solution for immutability, I’m thinking blockchain here. Not only does blockchain make a strong case for it to be the “ledger” of truth for financial services, but it also makes a strong case for its ability to ensure operational resiliency.

On the surface here, blockchain may look like the perfect solution, but there are several challenges associated with that. Is there a better way than using a typical blockchain architecture? Does it really fit with financial service providers, more importantly, does it fit well with financial market infrastructure (FMI) providers? This one is of great interest, as many push a blockchain architecture to address current challenges with cross-border payments. But, is there something else?

Let’s look at the 3 big challenges for ledgers regarding ensuring the data they hold is all present and correct:

Data corruption

When we were setting up ClearBank, I had many a discussion with the Bank of England, the regulator and certain payment systems regarding data corruption – especially with regards to data corruption being replicated across nodes. The point is highly valid, that corruption can in some implementations replicate across your multiple nodes, and therefore into your backups. That makes the issue of understanding your RPO especially hard, simply because you need to understand at what point that corruption took place.

Cyber attack

A big challenge with a cyber-attack, especially when it targets your underlying datastores is, has the attack damaged your data – has it been altered. Again, this can be tough to address, especially with regards to your RPO. Sure, there are ways to capture these changes, looking through logs etc. but you ultimately rely on your data backups at this point, and again, identifying which data backup is accurate / pre-attack. This really can play havoc with your RTO and RPO as there is simply a lot of work that must be done to identify where data has been changed, and the impact that change has had going forward. In the world of financial transactions, you can’t just unwind every debit/credit that occurs after the point of tampering.

Insider threat

This is pretty much the same issue/risk as that which is presented by a cyber-attack. The difference here is, your logs may have easily been tampered with too, since the threat has come from an internal source. Granted this could also be true with a cyber-attack, but it is more commonly associated with an insider threat. So, in this case, how do you prove your data is correct?

The solution: An Immutable datastore, an immutable ledger

Most financial services ledgers are not immutable. There will be lots of operational and some technical workarounds to try and ensure data isn’t being tampered with, but at the end of the day, on the main, the data held in the worlds financial systems is not immutable.

Immutability of a ledger is common with hash chains and blockchains alike. So clearly the technology, which has been around a lot longer than most are aware of could be a great way to prove data is accurate, and that it hasn’t (or even better) or cannot be tampered with. For this section, I am going to split it into a typical blockchain approach and a not so typical blockchain approach…

A traditional blockchain solves the issue of immutability, but it sadly presents a few others, these include:

1. The integration overhead (cost and lines of code to maintain)
2. Underlying infrastructure requirements
3. IT support considerations, good old People Process and Technology (PPT)
4. System performance considerations (your choice of blockchain – will it be quick enough)
5. Data residency, where is the data being replicated

The five points above are major deal breakers, they render a blockchain based solution as pretty much a non-starter, if your system is a high volume transactional based system that spans different legal jurisdictions (geographies). This though hasn’t stopped many experts, central banks, banks etc investigating just what the technology could deliver in this space, and rightfully so. The quest for immutability and resiliency is always going to be core to any transactional type of system, especially a payment system.

A traditional blockchain solution would provide several nodes across the geographies in which you want the system to operate, so that would mean spanning different legal jurisdictions if you want something that could work for cross-border use cases. Several nodes provide great resiliency and the nature of a blockchain provides that immutable ledger. However, simple distance between nodes introduces latency, that’s before you look at the blockchain implementation. The location of the nodes also causes so many challenges regarding data replication and therefore residency. Can you imagine a regulator in one jurisdiction demanding to see data on all aspects of your solution because data is no longer located just in that specific jurisdiction? We’ve seen numerous examples of this inside and outside of the financial services sector. So right now, data replication and residency is a deal breaker for the technology.

So, while a traditional blockchain solves the immutable ledger challenge, it introduces many other challenges. All too often we see examples of technologies desperately seeking a problem to solve, in some ways this is blockchain in the traditional implementation sense, especially within the financial services sector. I personally believe in trying to solve the problem and identify the technology that best fits….With that in mind, how have we solved this at RTGS.global? What do I personally believe is the right approach/solution?

Database first, immutable ledger second…

A traditional database is suited to high transactional throughput and data storage. It’s proven to be the go-to tech for decades now, and with evolution of this technology, like Microsoft’s in-memory Azure SQL tables, the performance of a database is lightning. Couple this with micro-service-based architectures and really, it’s hard to see a better technology for high transactional based systems. Database technology now also includes concepts of nodes and high availability, couple this with a good old backup strategy, and almost all of the challenges are solved. Now, if you are smart with your implementation, then you can also ensure data residency and that’s true even for cross border solutions like RTGS.global.

The one challenge remaining is verifying that data is accurate, that it hasn’t been tampered with. This is where I need immutability. But the ask here is subtly different, which gives you room to use technology in a different fashion. Here I am asking to prove a traditional data store data is accurate, I am not asking for the primary data store to be immutable and I am not using that primary data store as a form of messaging across geographies…The solution is therefore a way of utilising an immutable ledger (like a blockchain) to confirm / verify the accuracy of my database. Now, if you can do this, then you have all the benefits of traditional database systems, including the ease for developers to use it, coupled with all the benefits of a blockchain. Enter Azure SQL Database Ledger.

Azure SQL Database Ledger

When we first started working with Microsoft on RTGS.global, our ask was a way in which to prove data was accurate. We had assessed many blockchain implementations and concluded that the technology added more obstacles to building out RTGS.global than challenges it solved. So, our ask of Microsoft was how do we prove immutability and verify our data is accurate. Luckily, we were able to work with them on Azure SQL Database Ledger.

Now for those of you who do not know what this is, at a macro level it is essentially an Azure SQL database. However, the data that you capture is also backed off into a blockchain implementation asynchronously. What this means is you don’t have the blockchain slowing you down, in terms of how long it takes you to leverage the technology, but also in terms of you transacting. In this case, the blockchain is in the background building out the immutable ledger.

The ledger can build “digests” which too are in themselves immutable, as they are stored and accessed within an Azure immutable storage. The digest can then be verified against the data held within a database by running a simple Stored Procedure (SP). The output confirms that the data within the DB is all accurate, that it hasn’t been tampered with and therefore, you have solved your immutability challenges.

At RTGS.global we run a distributed approach to our data storage, essentially each jurisdiction in which we operate has its own Azure SQL Database Ledger, that follows a high availability model in that jurisdiction.  Data residency is within the specific jurisdiction, with the blockchain that backs off of Azure SQL Database Ledger also being private and located in that jurisdiction only. We also showcase to central banks and regulators the immutability of the data within our ledgers by providing a portal view to the digest verifications that we run.

For us, the solution is simple, its elegant, highly powerful and solves all the challenges of performance, residency, people process and technology and obviously, delivers immutable data storage.

Many of the worlds financial systems ledgers are not immutable, and that’s a grave concern/big risk. However, a traditional blockchain ledger isn’t the solution. The solution is to use blockchain technology to prove data integrity, use the technology for what it is great at doing, delivering immutability.

For more information on how RTGS.global uses Azure SQL Database Ledger, check out the Microsoft case study here: Microsoft Customer Story-RTGS.global automates financial transfers, unlocks trillions in capital with Azure You may also want to look at the technology in more detail yourself, then this is a good place to start, Announcing Azure SQL Database ledger – Microsoft Tech Community

For my very technical readers, if you really want to get under the hood of the technology, then read these two blog posts from Jason Anderson

Azure SQL Database ledger PART 1 by Jason M. Anderson – SQLServerGeeks

Azure SQL Database ledger PART 2 by Jason M. Anderson – SQLServerGeeks