In December 2017, I wrote about the SWIFT Blockchain Proof of concept (PoC), and why I felt that the result was most likely going to be “DLT for international payments processing is still work in progress”.
SWIFT finally released the results of the PoC this month and have confirmed that there is a lot more work needed within Banks’ back office technology and operational processes for DLT to be relevant.
The PoC was aimed at international payments and how intraday/real time liquidity management could be performed using DLT. Correspondent banks provide services on behalf of another overseas financial institution through a correspondent account (Nostro/ Vostro account). However, about 34% of the cost of an international payment is related to Nostro trapped liquidity. This is due to the lack of real-time data to optimize intraday liquidity management.
Managing Nostro accounts and ensuring there is no over funding or overusage of credit lines depend on availability of real time data. A real-time feed of transaction data would allow banks to release payments to customers quicker, whilst reducing liquidity risks.
With that as the driver behind the initiative, a consortium of 34 banks worked on this use case with SWIFT. In Q1 2017 SWIFT had launched their Global Payments Initiative (GPI) with these banks and it went live without DLT. SWIFT wanted to get their product out using legacy systems, and not wait for the results of the DLT prototype.
The results of the DLT prototype are as follows:
Nostro DLT application, combined with the ISO 20022 data model, delivered the business functionalities and data richness required for automated real-time liquidity monitoring and reconciliation. Real-time confirmation of each account entry and use of the unique end-to-end transaction reference (UETR) – SWIFT’s central payments tracker, made it possible.
Further progress is needed on DLT technology before it is ready to support applications in large scale critical global infrastructures. 528 channels were required in the PoC to ensure Nostro accounts would only be stored on the nodes of their account servicers and owners. But when the solution is in production, more than 100,000 such channels would need to be defined. DLT solution hasn’t matured yet to handle that load.
All Nostro Account service providers will need to migrate their back-office liquidity reporting process from Batch to real time processing. ISO 20022, will need to be applied across banks to ensure data shared across different banks has consistent data elements. Such a common data model is essential to reduce integration costs (between SWIFT and the banks).
We will continue our R&D efforts to ensure that SWIFT customers will be able to leverage their existing SWIFT infrastructure and connectivity to benefit from blockchain services, whether offered by SWIFT or by third parties, on a secure and trusted platform.
Stephen Gilderdale, Chief Platform Officer, SWIFT
While the existing GPI has been successful for SWIFT, for the GPI to use DLT, it requires all banks to have a real time infrastructure. SWIFT is currently focused on helping that transformation happen.
Adoption of ISO 20022 is a pre-requisite to save costs before DLT can be beta tested for wider adoption. As this progresses, SWIFT will continue to explore advancements within the DLT space to ensure there are no non-functional performance/scaling challenges.
I see this as a major setback for banks’ adoption of Blockchain. If banks’ back office processes and technologies need to be transformed before DLT can be used, we may have to wait for a good part of another decade.
The official press release mentions that it is a question of “when rather than an if” for DLT to be used in this context. However, I believe that is a gross underestimation of banks’ inability to transform their back office technology and operational processes.
Arunkumar Krishnakumar is a Fintech thought leader and an investor.
Get fresh daily insights from an amazing team of Fintech thought leaders around the world. Ride the Fintech wave by reading us daily in your email.