Although they do not carry the same cachet that they did a couple of years ago, distributed ledgers have established firm footholds in the financial services community. It is only a matter of time before buy-side and sell-side firms will need to integrate their workflows across multiple distributed ledgers that support different digital assets and front-, middle-, and back-office processes.
Markets Media caught up with Duncan Johnston-Watt, co-founder and CEO of DLT-management platform provider Blockchain Technology Partners, to discuss when and how these new challenges will wind up on the Wall Street CIO’s plate.
How close are asset managers and broker-dealers to needing to manage financial instruments and workflows across multiple distributed ledgers? Is it an actual thing yet?
Duncan Johnston-Watt,
Blockchain Technology Partners
The ability to manage financial instruments and workflows across multiple distributed ledgers is rapidly emerging as a challenge for asset managers and broker-dealers given the lack of standardization in the permissioned distributed ledger space.
Therefore this is definitely something that they need to be aware of and factor into their thinking in much the same way that they have had to learn to handle the plethora of market data platforms and liquidity pools in the past.
However, this is also an opportunity for fintech firms to develop tools to help asset managers and broker-dealers handle this complexity just as they have done so historically in, for example, the order management space.
Finally, while there is lack of standardization when it comes to distributed ledger technology, interoperability is possible with the right level of abstraction as exemplified by DAML, the smart contracts language, which Digital Asset open-sourced earlier this year. In the derivatives space, Digital Asset have teamed up with ISDA to create a reference implementation of the ISDA Common Domain Model (CDM). Written in DAML, this library will ensure that derivatives are traded and managed consistently across multiple distributed ledgers.
Would firms be more likely to roll their own management framework or rely on a hosted offering?
It is important to understand the difference between permissioned and public distributed ledgers. In the permissioned world, all the participants are known and there is a governance mechanism for admitting (or ejecting!) participants. Therefore permissioned distributed ledgers are the logical choice for most if not all consortia or multi-party use cases in a highly regulated industry such as financial services.
Against this backdrop, firms participating in a consortium underpinned by a distributed ledger actually have three alternatives when it comes to joining the network. They can rely on a service provider; roll their own nodes or use a blockchain management platform to facilitate this.
Although it may appear to be attractive for firms to use a service provider this only makes sense if its Blockchain-as-a-service (BaaS) offering supports the type of distributed ledger in question. Furthermore, it means putting their trust in a third party which arguably undermines one of the basic tenets of distributed ledgers, namely, that control is decentralized.
This leaves two alternatives for firms. Either they bite the bullet and each rolls their own management framework to contribute and maintain their nodes on the network or they adopt a blockchain management platform to facilitate this process. The first option imposes a huge overhead in terms of both deployment and ongoing management and maintenance whereas the second avoids this while ensuring that each firm still retains full control of its own nodes.
How would firms roll their own framework? Has the industry developed a set of best practices yet?
We would argue that the best way of participating in a distributed ledger is for a firm to use a blockchain management platform to facilitate this while retaining full control of its own nodes.
In terms of best practices such a blockchain management platform should be something that a firm can run itself; provide complete visibility into the stack being managed; automate standard operations and target Kubernetes as the runtime platform. Kubernetes is now the de facto standard for container management and can be deployed on-premises or in the cloud using a kubernetes-management platform such as Rancher.
In the interests of full disclosure, we have created such a blockchain management platform called Sextant and there is a case study commissioned by HyperledgerWhen Hyperledger Sawtooth met Kubernetes - Simplifying Enterprise Blockchain Adoption that your readers might find interesting.
What do you see as the next sea change in this space?
Financial services have a great track record of exploiting advances in middleware technologies by adopting the right level of abstraction.
In other words, to take full advantage of distributed ledger technology firms and fintechs need to focus on application development and avoid being tied to a specific implementation.
Once you get beyond the hype, distributed ledger technology is just another middleware play - this sea change in perception will unlock its true potential. We’ve been in this movie before with message-oriented middleware for example.
Where are the most advancements taking place in this space?
The two areas where we see the most innovation happening are in the smart contracts space and the underlying performance of distributed ledgers.
The first area - smart contracts - is exemplified by DAML which is built on a powerful functional programming language, Haskell, which, now it has been open-sourced, is being implemented on a wide variety of persistence layers ranging from distributed ledger technologies such as VMware Blockchain, Hyperledger Sawtooth and Corda to AWS Aurora and others.
The second area - performance - is crucial to the widespread adoption of permissioned distributed ledgers. This is closely related to research into both consensus algorithms and different privacy models that enable the immutable sharing of data while preserving Chinese walls where appropriate.
