Last year SWIFT released a paper – SWIFT on Distributed Ledger Technologies – highlighting the opportunities and challenges of distributed ledger technology in financial services. I know I’m a year too late (!!), but better late than never, eh? Anyway, following is a quick summary of the key points that i noted from the SWIFT paper on distributed ledger technologies (DLTs).
Firstly, What is the difference between Blockchain and Distributed Ledger Technology?
That was the first question i asked, and came across a cool summary by Bits on Blocks. And if you’re not sure what blockchain is, check out these awesome infographics!
Distributed Ledger Technologies STRENGTHS:
SWIFT outline how DLTs enable:
1. Trust in a disseminated system
- Removing the need for a central body
- Enabling trust in the authenticity and validity of the data on the ledger
- Digitally signed transactions that are maintained and validated by the network of nodes and specific software that replicates the ledger among the community
2. Efficiency in publishing information across a distributed system
- Data is added and replicated across the network in pretty much real time, thereby ensuring that all nodes in the network are accessing and referencing the same dataset
3. Traceability of transactions
- Data can be added to the distributed ledger, but cannot be deleted from it – making it immutable
- This gives participants full traceability right the way through the chain
4. Simplified reconciliation
- All participants have access, in real time (more or less), to the complete and validated ledger – guaranteeing that everyone is referencing and working off the same data set
5. System robustness
- Distributed processing and distributed ledgers remove the need for a centralised infrastructure and service model
- In the event of a failure in one area, distributed processing allows the connected nodes to continue processing
- Similarly with data, a local failure can be recovered from the distributed ledger
Distributed Ledger Technologies “OPPORTUNITIES”:
SWIFT outline how, from a financial services adoption perspective, DLTs are still relatively immature and need further exploration. Keep in mind this was written a year ago, and a lot of those explorations / proof of concepts are happening now. Still the following areas need to be addressed:
1. Strong governance
- The need to define roles and responsibilities and operating rules
2. Data controls
- Outlining the need for clarity and consensus around the meaning of shared data
- Access to data needs to be controlled and confidentiality must be respected
- Encryption of the data is often cited as a potential solution, but managing encryption/decryption keys across multiple parties quickly becomes a headache
3. Regulatory compliance
- In a decentralised, cross border distributed ledger who is the Regulator and who are they regulating?!?!?!
- Given the above, how will the industry ensure compliance with KYC, sanctions lists….fill in any other regulatory requirement…?
4. Standardisation
- Highlighting the opportunity to use ISO 20022 to enable interoperability across DLTs
- The ability to enable Straight-Through-Processing (STP) and ensure “backward compatibility”
- SWIFT question what would happen if a smart contract – embedded business logic on the distributed ledger that executes itself – was to go wrong?
- Who handles the errors and exceptions…hmmm?
5. Identity structure
- After the 2008 financial crisis, the financial services sector has implemented various controls so that you can identify all key parties in a transaction – how do you handle the question of identity in DLTs where the participants are “pseudo-anonymous”? If you can’t identify participants, how do you ensure traceability?
- Need to ensure participants can be identified so they are accountable and thereby allowing non-repudiation of financial transactions
6. Cyber Security
- The need to identify and prevent complex cyber attacks
- SWIFT highlight that in a distributed ledger the protection of any non-encrypted data is down to each participant, and you cannot always guarantee the security credentials of the whole network
- SWIFT ask some good questions:
- Does a distributed network potentially create multiple points of attack
- Could an attacker bombard the ledger with bad transactions and create a DoS (denial of service) attack?
7. Reliability
- The technology must be able to support important and complex financial services
- Availability of the service is transferred to the ledger participants, and appropriate controls ensuring their availability need to be agreed
- Software updates need to be carefully managed and implemented by each participant – if this is not coordinated, ledger inconsistencies may be encountered (“forks”)
- Apparently “a maximum number of fraudulent participants can be handled without compromising the integrity of a distributed system” – i will need to look into that!
8. Scalability
- The ability to complete hundreds/thousands/millions of transactions – how do you manage that given all of the above questions ..?
SWIFT & Distributed Ledger Technologies:
SWIFT is delving into DLTs on several fronts:
- Research and Development (R&D) with DLTs and its community to understand use cases
- Working on proofs of concept (PoC) in the SWIFT Innovation Lab
- Through the Linux Foundation’s Hyperledger Project, of which SWIFT is a Board Member
- Collaborating with industry partners to develop open source Blockchain technology
- Partnering with its community and FinTech companies through its innovation arm, Innotribe
What do you think about the indicated strengths and weaknesses, share your comments below. One thing is for sure, this is a fascinating topic and i am learning all the time – More to come….!