Latest Products

Blockchain a Dead End

Wednesday 4 April 2018

by Patrick McConnell

*This article was originally published by Patrick McConnell on LinkedIn, and has been republished on the GRC News Page with the permission of the author. 

Normally, any media report that combines SWIFT and Blockchain in the same sentence has the chain-sphere in a frenzy. But not, apparently, the Final report produced by SWIFT on its much-ballyhooed Nostro Proof of Concept (POC).

The SWIFT announcement, much delayed from its scheduled date in December, fizzled out quickly, because it didn’t support the massive hype around blockchain and its upmarket twin, distributed ledger technology (DLT).

Although putting a very brave face on the project's findings
[i], SWIFT announced it had, in fact, pulled the plug on the project, which was probably the largest such POC to date—certainly in terms of the number of key participants involved (34 major banks).
SWIFT concluded that blockchain/DLT was (in my, not their, words) a dead end. Nowhere else to go but turn around.

Why was this POC important?
The SWIFT Nostro POC was THE uber use-case for DLT in the financial world. If blockchain/DLT does not work for this tailor-made situation, there is very little (approaching zero) chance of the technology ever being useful in more complex situations, in modern finance.

A very quick tutorial on Nostro accounts
Say an American manufacturer wishes to set up an import/export presence in an emerging market, such as Kyrgyzstan, they will normally go to the bank with which they have the bulk of their credit and transactional business and ask them to help with the practical finances. But what if their home bank does not have a branch in Bishkek, the capital? There are two problems: first the manufacturer does not want to start up a relationship with a local bank (mainly because the rules may be very different to home) and the home bank does not want to lose the business of one of their key customers.

This is where the concept of correspondent banking’ comes in.

In such a situation, the home bank will, after extensive due diligence, approach a bank in the foreign country, such as the ‘Commercial bank KYRGYZSTAN’ (CBK), and suggest an ongoing, mutually-beneficial relationship. When/if agreed, the manufacturer can then begin to treat his local bank as having a branch in the foreign country and can do business (almost) as usual, although obviously additional fees will be charged. Everyone wins, and the home bank can then approach other corporations offering to handle their growing business in Kyrgyzstan, always leaving open the option, if regulations allow and business grows, to eventually set up a full branch in Bishkek.

The account that the home bank has with the foreign bank is called a ‘Nostro’ (or ‘our’) account and the home bank will use such an account for the bulk of its transactions for all of its customers. In practice for a large bank, there may be transactions totalling billions of dollars into and out of a Nostro account every day. Because it is handing very large transactions for some of its largest customers, a bank must monitor the balance in each Nostro account very carefully, otherwise vital payments for key customers may not be made, because, for example, the account may inadvertently become overdrawn. It is a tough job, but one for which correspondent banks get paid very well.

As one can imagine in today’s global marketplace, there is a huge network of Nostro accounts operated and used by the largest banks in the world, all trying to maintain the balances in these hundreds of accounts in the black. This is a non-trivial problem, but there are well-established processes to handle this situation in most correspondent banks

Nostro - a use-case made for blockchain?
One can see that managing a Nostro account has some similarities with Bitcoin, the one example of blockchain in serious operational use today. First, everything is done using discrete transactions, either to make or to receive a payment across a Nostro account. Second, ideally everything is (or should be) done in real-time, with an immediate confirmation that a transaction has been accepted and acted upon. Third, there is no central authority, as all transactions are, naturally, peer-to peer. And in general (but not always[ii]), transactions are irrevocable.

Should be a stroll in the park for DLT? No wonder SWIFT and the banks were tempted by the prospect and, given the hype, it should be a sure thing?

Afraid not. Reality kicked, in as SWIFT and the participating banks discovered.

What the POC found
The SWIFT POC project was a very serious and expensive[iii] attempt to prove the blockchain hypothesis. Although technical detail is sparse, the project used “leading distributed ledger technology”, Hyperledger Fabric 1.0, and importantly used existing SWIFT technical assets and standards to create permissioned distributed ledgers for each of the 28 banks that ‘actively tested’ the application. Traffic across the individual peer-to-peer ledgers was generated via a ‘simulated back office tool’ using ISO 20022 (i.e. SWIFT) data standards. Governance was imposed by SWIFT—in particular, the SWIFT ‘intraday liquidity standard rulebook’ and importantly, the concept of the unique end-to-end transaction reference (UETR) that has been developed for SWIFT’s new global payments innovation(gpi) infrastructure and product set. Identification of parties was based on the standard SWIFT business identifier code (BIC) and certification of parties used a SWIFT-controlled Certification Authority (CA), through the issuance of certificates.

In effect, the POC was built upon the infrastructure and processes already in place for SWIFT gpi. But that is not a bad thing for a POC, as re-inventing the wheel is not very sensible in such test cases.

First, the good news. The POC worked in achieving its internal functional objectives. However, remembering that the POC consisted of merely a piece of computer code, that should not come as a surprise. The POC showed that transactions, in an agreed format, could be transmitted in real time across a secure, closed SWIFT network and be received and used to update[iv] one or more balance figures.

This should not come as a total surprise because it already happens millions of times per day in other situations, such as the Australian 
New Payments Platform (NPP) which is also based on SWIFT formats [but does not use blockchain/DLT].
So, what is the bad news?

The bad news is that for a scheme, such as that developed in the POC, to have any chance of working in the real world of finance, an enormous amount of work has to happen for benefits to be achieved. The key finding of the report was that

“While the results are encouraging, testing also highlighted the need for a set of pre-requisites for such a solution to deliver the expected benefits and be adopted by the industry”.

In other words, it wasn’t the POC, but everyone else that was holding up progression on applying DLT to the Nostro problem.

The report then listed four killer pre-requisites:

  • There is a need for all Nostro Account Servicers to migrate from batch to realtime liquidity reporting and processing”.However, this is not going to happen anytime soon, since as the report noted “Today, 44% of cross border payments exchanged over SWIFT generate a real-time confirmation of debit or credit”. Not a large figure and one which does not include other sources of Nostro changes, such as undated expected receipts.
  •  “While the DLT application could provide a platform to share the information, there is significant work and investment required by all banks to upgrade their back office applications to feed the platform with real-time updates”.Again, this is not going to happen anytime soon, even if it was a real business requirement, which it is not!
  • A value proposition for each market segment catering for different levels of sophistication, automation of operations and past investments is key to ensure industry-wide adoption and coexistence, hereby delivering maximum value.”
This is stated elsewhere in the report as ‘a “one size fits all” DLT solution will not work’! This is because the main players, such as the universal correspondent banks, have already invested in technology that is superior to that trialled, and small firms cannot afford and often do not need to adopt such a solution, not requiring real-time updates.

  • Unique identification of each entry is the cornerstone of any liquidity and reconciliation solution”.
Because the implications of this may not be immediately obvious, the report spelled it out: “To cover all Nostro account movements, its usage must be extended to identify key message types such as FX and securities transactions that potentially do not settle through a payment message”. In other words, in order for this model to work, not only must payments systems be re-engineered but many others too.

In summary, the report concluded that, even if the POC was extended so that it could actually go live: 1) large firms don’t need it, because they have the functionality already; 2)small firms don’t need it because they don’t require real-time functionality; and 3), every system in every firm that generates monetary movements would have to be re-engineered for the benefits to be achieved.

In plain English, the report shows that the wild claims made for benefits of blockchain/distributed ledger technology (DLT), are illusory.

No wonder that the SWIFT project shied away from any detailed analysis of costs/benefits and implementation risks!

Aside from functionality, the final report also noted some key technical problems, concluding that while the POC showed that DLT “now provides the necessary foundation for building financial applications”[v]:
“However, it also showed that further progress is needed on the DLT technology itself before it is ready to support applications in largescale mission-critical global infrastructures”.

In other words, DLT is just not ready for prime time.

The final report expanded on a problem that had been identified in the Initial report – the exploding channel problem.

Since, for privacy and consensus reasons, in the permissioned DLT, every party has to have a dedicated channel open to every other party, then the number of distinct channels that must be created rises with the number of parties, if not exponentially but very quickly[vi]. For example, with the 34 representative banks, some 528 distinct channels were needed and SWIFT calculated that if the ‘system’ was to go live more than 100,000 channels would need to be defined.

In a classic understatement, the report noted that this would present “significant operational challenges”.
In short, this particular distributed peer-to-peer model falls apart at scale.

To summarise, the SWIFT Nostro POC shows that, for the Nostro application, blockchain/DLT will not work: functionally (without major unrelated changes elsewhere); cost effectively; technically; nor operationally.
It is a business dead end!

And since Nostro would appear on the face of it to be an ideal use-case for blockchain/DLT, the conclusion must be that this approach is a non-starter for other much more complex applications in finance, such as equity trading and settlement.
The author would argue that the problems encountered in this project would/should have been foreseen before any work started. It just requires good systems analysis. 

It is an indictment of modern finance (and technology) that something must, at great cost, be demonstrated not to work before people will believe it!

[i] The SWIFT media release is unfailing upbeat declaring a victory – for SWIFT – but nonetheless closing the project down.
[ii] For example, whenever a mistake has been made.
[iii] No costs were given in the report but with 34 banks and SWIFT and Hyperledger involved it would have run to tens of millions of dollars.
[iv] It is, however, not obvious from the report, whether balance updates are an integral part of the distributed ledger or as part of a separate Hyperledger database.
[v] This is an extremely contestable assertion given the other reservations made in the report.
[vi] If there are n participants in such a DLT, the theoretical maximum of channels will be n*(n-1)/2 channels, if all participants have a relationship with each other.