On 25 Jan 2016 the DTCC released a white paper entitled “Embracing Disruption – Tapping the potential of distributed ledgers to improve the post-trade landscape”. It is a very good read: high quality, succinct, and cuts through the hype.
I attempt to summarise for those with less time to read the full paper.
What is DTCC?
According to Wikipedia, The DTCC is a user-owned post-trade financial services company providing clearing and settlement services to the financial markets, and a central custody of securities. Ie it lists ownership and changes of ownership for US equities, corporate and municipal bonds, unit investment trusts, government and mortgage-backed securities, money market instruments, and over-the-counter derivatives.
In a nutshell
My summary and selected sentences from the paper are in normal text. My own comments are in purple italics. I’ve changed the ordering to make a more logical summary.
KEY TAKEAWAYS
- The current U.S. equity market convention of T+3 is based on laws and market structures, not technology.
- Modernizing current practices and laws to enable real-time settlement are not dependent on the use of blockchain technologies.
- The financial services industry has a once-in-a-generation opportunity to reimagine and modernize its infrastructure to address long-standing operational challenges.
- DTCC is skeptical that moving assets from a centrally, risk-managed, regulated, governed repository to multiple vendors creating bifurcated markets with proprietary settlement and asset management mechanisms is a good thing.
- Currently the state of Distributed Ledger Technology is not enterprise-ready.
- Siloed attempts to create standards will result in mess; DTCC best positioned to coordinate the dialogue.
- There is a list of use cases presented in the paper which are worth diving into. Master/Reference Data management, Netting/Clearing, and Collateral Management seem to be the most appropriate and accessible use cases for Distributed Ledger Technologies.
SUMMARY
Limitations of the current Financial Market infrastructures
- Multiple versions of the truth maintained in silos eg banks leading to inefficiencies
- Vulnerability to cyberattacks and other tech threats
- Complexity due to historical reasons
- Not 24/7/365 ready
Why use Distributed Ledger Technology (DLT) in post-trade services? Because:
- Standard rules exist for securities transaction validation and replication
- Distributed ledgers work well with standardised in rules in place so that each validator can validate transactions according to those rules.
- DLT creates immutable linkage to transaction history and auditability.
- Distributed ledgers can ensure some degree of immutability, unless changes are made by consensus.
- Auditability can possibly be made easier if there is a fairly immutable, and trusted data source.
How can DLTs support solutions to current challenges?
- DLTs are a shared common version of the truth where every trusted member has a copy.
- All data is encrypted in a common manner and can only be inspected by the rightful owner of the data
- This can also be implemented without DLTs
- DLTs Provide a common network and platform that can be built upon (tools, workflows etc) in a consistent manner
- DLTs are pretty good for 24/7/365 trading, and more resilient than existing hardware replication models
Concept of “trust boundary” which is the boundary between on-chain and off-chain. On-chain stuff doesn’t rely on trust but trust is still necessary when external entities interact with the chain, for example when the custodian of an asset gives you the actual asset that the chain proves you are the rightful owner of. I like this concept.
Key challenges for adoption:
- Is implementing DLT more cost effective than improving existing systems?
- Can DLT overcome scaling and performance challenges?
- Are third parties best positioned to develop DLTs?
- I would add, can DLT overcome privacy challenges?
BACKGROUND
Simplified trade flow in a T+2 world (currently T+3 is the norm)
T+2 means a trade done today will settle, ie the ownership will change, two days later.
Key features of Blockchains and DLT using Bitcoin as an example
- The asset is built in (eg you own a bitcoin because the bitcoin ledger says so. The bitcoin exists in and only in the ledger)
- Party identity abstraction (the ledger uses account numbers, not people identifiers)
- Transaction linkage (Bitcoin payments “out” of an account refer to previous payments “in” to the account, creating a lineage for every single payment, right back to the mining of the bitcoin. This is both much much better for tracing money flow, and also has privacy and fungability implications)
- Transaction scripts (every validating node in bitcoin validates transactions and blocks by the same rules, the “bitcoin protocol rules”)
- Transaction Distribution (transactions are relayed via a peer-to-peer gossip-network)
- Blockchains (Transactions are added to each individual ledger in blocks, which reference the previous blocks, forming a chain). Here they say “This is the official point of immutable recording of a transaction.” but technically this is not accurate, as consensus rules say that if a longer chain is found, then discard the shorter chain; hence a bitcoin transaction is never immutable, it is just probably immutable with increasing immutability as time passes and more blocks get added. This is arcane.
- Decentralised consensus (the technical and business rules for what constitutes a valid transaction and block, and other rules of the game)
- Permissioned vs Permissionless (you can have blockchains that are open to all to write to and read from; or you can have a limited known list of participants)
Limitations of DLTs
- Current DLTs are not ready to ‘plug and play’ into existing technology stacks.
- Reversability / cancels / amends are common in real life and aren’t supported using DLTs.
- I’m not sure I agree here. For audit purposes, trades in normal bank databases should never be reversed / amended / cancelled, once written. Instead new rows are added to the ledger, referencing the previous entries, and creating the desired change. One does not simply amend a trade, one creates a new trade referencing the old one as invalid. However, if DLTs imply immediate settlement, this may cause a problem, as usually there is a window of opportunity for people (eg sales staff) to adjust a mistyped trade before it goes for settlement.
- Various other nonfunctional requirements basically saying “it’s just a database and doesn’t add much from a data processing or analysis perspective”
Tradeoffs between centralised and decentralised processing
- More participants in a decentralised system mean increased latency and more resource overhead (bandwidth, storage etc) than a centralised system with zero latency
- Sure but in a centralised system, you don’t just have the central system, you have other participants with their own version of events, who are reconciling against this golden source. So in a centralised environment, you still have duplication of data and reconciliations.
- How to manage regulatory challenges like keeping Personally Identifying Information (PII) “onshore” if this data is shared among participants in a different jurisdiction?
- I think this has already been solved by the existing industry: Store PII onshore with an ID, use the ID for the trade.
- Does the industry want trusted responsible authorities or does it want maths to guarantee integrity? Or maybe both?
USE CASES
How to think about Distributed Ledgers, and use cases
| Use Case | Verdict | Face |
|---|---|---|
| Identity Management (“KYC information”) | The data associated with identity would not be appropriate to have stored on a decentralized ledger until the technology has matured and proven its ability to survive an attack.
I also wrote about this here: On KYC and blockchains. |
🙁 |
| Master Data Management (“Reference data”) | Ideal candidate for improvement using decentralized consensus, rule standardization and auditable change history. | 🙂 |
| Asset/Securities Issuance and Servicing | Obvious benefits but integration with off-ledger “underlying” assets is challenging. | :s |
| Trade/contract validation, recording and matching | Smart contracts could be useful. DLTs may not be appropriate for matching but better for recording confirmed trades. Complex trades could benefit from standardisation using smart contracts, however tension between standardisation and regional regulatory differences. | :s |
| Netting, Clearing | DLT rules could automate netting and clearing. This could be the use case that makes full use of DLTs as value transfer mechanisms or ownership transfer mechanisms, rather than just as a place to record what happened. | 🙂 |
| DLTs replacing Central Counterparties | (This is DTCC’s pitch explaining why they’re not going to be killed by blockchains yet. Most of the arguments are pretty good) Not likely yet. High bar due to efficiencies of central counterparties including:
|
🙁 |
| Settlement | Shares settling T+3 is not due to technology, it’s due to market practices, financial industry laws and regulatory requirements, primarily to accommodate the needs of retail investors. Case in point: You can force through a same day settlement by submitting a trade “as-of” 3 days ago and it will settle today. Settlement could be a longer term opportunity for DLTs, but issues that need consideration include revising laws, changing market practices and structures, incorporating the complex realities of asset servicing and working with regulators on issues such as investor protection.
DLTs could simplify asset servicing, but would require that either all of that asset is on that specific ledger or a full integration with all of the off-chain assets, including all legacy custodians of those assets, as well as those assets that have been implemented on other chains/ ledgers. Syndicated loans that currently take weeks to settle could be a candidate for DLT settlement (a nod to one of DTCC’s investments, Digital Asset Holdings who are running a project with JP Morgan around Syndicated loans). |
:s -> 🙂 |
| Collateral Management | Due to visibility of ownership movements of assets, DLTs are well suited to collateral management processing. | 🙂 |
CONCLUSION
DTCC notes the potential of DLTs, the current immaturity of the technology, and suggests they are the best organisation to work with regarding DLTs in Financial Services.