THE BLOCKCHAIN SPHERES - PART 2 - WORKING WITH DISTRIBUTED LEDGERS

Big thank you to 4500+ Finextra members who opened Part 1. I hope Part 2 keeps you equally interested.

PART 2: WORKING WITH DISTRIBUTED LEDGERS

If trade finance, securities settlements and loans get increasingly processed on DLT, then at what point, will we witness that a substantial part of the corporate and investment banking business has transformed?

How Transformational Change rolls out

New technology in itself does not directly disrupt an industry. Changes induced by it must first break the market balances and move the goal posts by passing on new value to the end customers. 

In the January 2017 volume of the Harvard Business Review (1), Lansiti and Lakhani observe that the use of the internet was long limited to private emails, before becoming a World Wide Web of commercial opportunities (.com). Recalling early uses of the Web, such as on-line purchases of books and travels, success came from the opportunity provided to the respective industries to improve their business models. Airline tickets, for example, did not come cheaper because they were purchased on Expedia; however, lining up all offers on a single page made the market a lot more transparent and competitive, driving airline companies to adapt their business models. Likewise, people started ordering books on Amazon for the convenience of it, before publishers considered it an essential distribution channel. Disintermediation and cost cutting resulted from those changes but were never the initial aim. New value was. 

For Blockchain to generalise, a similar process must take place. The fact that HSBC and ING ship soybeans over DLT does not confront the industry. If Cargill, however, turn it into a consistent competitive edge, then others will have to follow. Likewise, loan syndication will certainly be made a lot cheaper, faster and efficient on DLT, but it is only when borrowers and lenders will derive new value propositions for their own customers that the practice will generalise.  

Second, the transition from old to new technology must be progressive and voluntary. It must involve steps to combine with legacy and gradually build dependence on the new benefits.  The first iPods did not oblige users to buy music on-line, for example. On the contrary, tools were provided to easily transfer CD content into MP3 format. Later on, as consumers were on-line with their smart phones, they found it very natural to download content as opposed to buying it on other supports and transfer it. In the Blockchain world, ASX will not force the migration to the DLT. Users may choose to connect and transact by sending and receiving messages “in a similar way as today” or they may choose to take a DLT node and interact directly (2). Forced change does not accelerate transformation. It might just stall it.

Finally, change in foundational technology comes with its own technical challenges. The Web could only progress as households equipped their homes and firms allowed accessing the internet. 

The take up in Blockchain could seemingly be very fast as it sits on the internet and does not need new enabling technology, once the security issues are addressed. Not quite. Extracting the full power of Blockchain in finance may actually require very different types of IT infrastructures, as most legacy systems were created for businesses which would never operate in sync past a bilateral agreement between traders –be it a trade ticket, a loan or a letter of credit. 

Working with Distributed Ledgers

In their haste to get a first move advantage and stake their claim, many firms have prioritised the development of a Minimum Viable Product (MVP). It is probably a mistake. Could we imagine Steve Jobs presenting the iPhone as an MVP? Say, it only makes phone calls and the rest is roadmap?  Transformational change requires big value upfront. 

Since the purpose of a distributed ledger (DL) is for all participants to work in sync on a shared set of data, the deeper it gets into the process, the more value. For example, a bilateral agreement created by 2 traders on a DL instead of a centralised server creates little value, if the smart contract is merely used for confirming the deal while the respective back-offices are not engaged. Using the golden copy for additional services such as matching and settlement gradually increases the added value; still it merely replaces a messaging system with Blockchain.  Transformational change requires more than this. Even a large cut in processing costs would not move the goal posts. In our example, big value could come from a final stage of integration, where transactions, settlement, delivery and payment using crypto-currency are carried out on the DL within a same day -thus cutting the duration of the outstanding market and credit exposure accordingly. This mathematically reduces all volatility based calculations, including margin, collateral, liquidity and capital. Now that is a game changer. Gains in operational efficiency also add value, but it comes on top of it.

This leads us to the main technical challenge. The graphic attached illustrates how systems for the financial industry have been organised around Relational Databases Management Systems (RDMS), where data is captured, stored, then re-extracted by procedures or scripts to be used for tasks such as generating messages to counterparties. In a distributed ledger, the transaction data is shared and directly used within the smart contract. Upon completion of the process, each node can eventually archive the transaction data and the history of state changes, but this takes place post-processing, no longer before.

The DLT approach therefore requires a critical review of workflows and associated data management, which could turn many legacy systems into, well legacy. Smart contracts need to contain the static data required for all processing they are instructed to do, such as credit limits, underwriting fees or settlement instructions for example. However, shuttling between RDMS and smart contracts and launching one process at a time equates to using Blockchain as a mere messaging network. 

Re-Architecturing for Blockchain

We have seen that building game-changing value with Blockchain required a lot more than cherry picking areas of friction and easing them individually. All data necessary to the programmed changes of state of the ledger should therefore be present within the network, accessible by smart contract, ahead of the transactions. The notion of front- versus back-office system disappears. In parallel, a new distinction appears between on-line shareable and non-shareable data. 

Sophisticated DLT languages allow the various nodes to permission data disclosure on a counterparty basis. As the depth of services available on DLT will gradually increase, the data required shared and present on the network will also inflate. 

When systems evolved some 20 years ago from flat files and batch processes to become event-based, object oriented and extendible, the set of functions provided have revolved around the RDMS. To this aim, custom workflows were developed to query the right set of tables and produce output on demand. As the last 10 years have seen efforts to rationalise and consolidate a maximum of functions onto a minimum number of systems, applications have become extremely versatile and efficient, but also quite complex and monolithic. To adapt this type of systems to a DLT approach will take a very substantial effort to rethink each workflow, use tables that were never designed to be used outside stored procedures, review security to share data that were never intended to be distributed.

We can therefore expect a new breed of systems and applications to come to light, alongside the existing ones, allowing for progressive migrations. They will no longer be built around proprietary databases, but around smart contracts and data shared across distributed ledgers. These applications will be designed to accommodate variable numbers of participants to networks. At this point, the KYC and authentication capabilities of Blockchain will become essential, as the networks will be governed by rules embedded in the processes, for on-boarding and participation levels for example. The new applications shall be light and naturally designed for cloud services since there will be little interest to maintain proprietary infrastructure. So far, new applicatins have been greatly associated with the development of bespoke User Interfaces (UI), while most attention was brought to development of smart contracts. This should evolve in priority within domains where Blockchain reaches production stage (the spheres). 

This paper has discussed the conditions of transformational change applied to Blockchain. Within the current spheres of DLT activity, the tilting point will occur when the total value build-up creates a clear competitive advantage, or sufficiently impacts a firm’s return on equity (ROE). At that point, DLT will become part of corporate strategies. Embedding settlement and payment services to distributed ledgers is likely to become key to reaching such value threshold. Finally, the migration onto DL must be progressive and derive from the legacy infrastructure. 

A new breed of IT systems and cloud-based deployment will be necessary to build such value and allow gradual change. They should be designed for cloud-based services, distributed data and network based governance from day one. The latter may require embedded KYC and authentication services.

References

(1): The Truth about Blockchain, Harvard Business Review, Jan-Feb 2017, Marco Lansiti, Karim Lakhani

(2): CHESS replacement New Scope and Implementation Plan, ASX, April 2018