Blockchain for Enterprise? Not so Fast!

Nitin Gaur | Director at IBM Blockchain Labs

This is a long overdue post, because I have been immersed in many workshops and client conversations around use case identification and identifying hurdles (both technical and political) for the adoption of blockchain in an enterprise. In this post I intend to outline the challenges around enterprise adoption of blockchain technologies.Even though we differentiate between permissioned and permission-less blockchain, the initial adoption issue relates to the enhancement of workflow and business procedures, which is primarily a technology question. While it is unlikely that in the near term blockchain will replace the entire capital market infrastructure, I believe it will flourish in markets that are less automated and less regulated but which have a high clearing and settlement risk, and these do not necessarily have to be financial markets. The promise of disruption lies in cutting the costs involved in technologies and reducing the inefficiencies that add to post-trade processes and securities servicing fees. Some of the costs in existing financial systems are incurred as a result of current delays and inefficient operations surrounding the update of redundant and duplicative systems. All intermediaries and counterparties need to ensure correct accounting in order to complete the business transaction, and the intermediaries need to update their respective ledgers based on the messages exchanged between them. These delays in simply maintaining the order result in capital and liquidity costs (and risks).

The idea of a shared distributed ledger with an appropriate crypto system for transaction verification and consensus to ensure transaction integrity sounds like an appealing and feasible solution; after all, if the inefficiencies are due to redundant and duplicative systems, then collapsing that to a single shareable ledger seems like a plausible fix. This also leads to the fact that the need for duplicative regulatory requirements such as Anti-Money-Laundering (AML) and Know Your Customer (KYC) can also be eliminated by using the shared ledger, with the advantages of shared cost and removing the market inefficiencies, and the problem is solved! …Not so fast!

A shared ledger also implies shared data, which then means visibility of not only the transactions, but even of the customer’s relationship data. I am not sure any financial institution would be amenable to freely giving away client and relationship information in exchange for the advantage of saving on costs. This also raises the question of accountability in the event of a breach due to bad actors that may be permissioned : is the accountability for the breach shared across the network because the ledger is shared? And how does one ensure PCI-DSS (data security standards) in a business network? Not to mention the costs incurred due to availability to data across many nodes that form the network.

While there are technical solutions like Homomorphic encryption (processing to be carried out on cipher text), Butterfly Cipher (for fractal visibility), enhanced encryption of data in block placed by a participant entity, and so on, these add massive computation costs and complexity to the permissioned network (which are bound to grow exponentially as the transactions are processed). If the promise of the blockchain technology and system is truly to create a self-governed trustless system, the consensus algorithms and trust systems devised have to mimic today’s intermediaries in providing similar services with guarantees. This guarantee equates to transaction integrity in the network, implying that there will be computation costs due to high network and systemic IO with faster transaction processing capability to counter fraud and reduce transaction re-processing. When these costs add up, not to mention the skills and expertise needed to maintain the system, are we trading one cost structure for another and the only advantage is the processing speed and efficiency? While enterprise permission models (such as consortium networks, business networks, private networks etc.) are evolving, the cost structure is yet to be developed; one thing is for sure, the initial costs of adopting or establishing a business network are not going to be minimal. Perhaps the system may reach economies of scale, but that will only be determined by the test of time. Let’s look at other enterprise challenges (there is a long list of these, so I will discuss just a few to be succinct):

Starting with Litmus Test for Enterprise Use Cases.

            To avoid blockchain being used as a hammer, we ought to devise litmus tests, which can be developed during the application design process as we intend to apply blockchain technology to a certain application in an enterprise. I have provided a few examples that help in a structured approach for an application or a system benefitting from Blockchain tenets.

  1. Adhere to Trade, Trust and Ownership. – While trade and ownership implies the churn and the transfer of ledger entries, trust implies the trustless nature of a transaction system. These three tenets – Trade, Trust and Ownership, are fundamental to any blockchain system.
  2. Application is Fundamentally Transactional in Nature – We often debate why we cannot achieve the perceived benefits of blockchain from a distributed database – either a no-sql or a relational database. It is a multi-party transaction that makes an application suitable for blockchain. Essentially, suitability requires long-running processes with many micro-transactions that are verified and validated by the blockchain-powered transaction system, although databases can still be employed for persistence or replication to fit the enterprise models/systems. Considerations include small data set size, which may increase overtime, and logging overhead, etc.
  3. Business Networks Comprised of Non-Monopolistic Participants – This fundamentally addresses the distributed vs. decentralized computation models. While Blockchain trust systems may work in any model, the trust nature of a trustless system that will power a business network will come from multi-party participants with non-monopolistic participation (the consortium permissioned network model); although oligopolistic participation may be acceptable (the private permissioned network model), it is the avoidance of a single party control and devising a trust model that assures us that even with rational behavior of the participants a single or centralized control over a distributed system will be prevented. Many internal use cases do not adhere to this principle and are more of a distributed application model.

What about the Regulation – AML, KYC?

Shared ledger has an obvious advantage in that a single source of data and chained transactions/blocks make the analysis and linkage easier for fraudulent and AML -type analysis. The idea with blockchain is an integrated system to perform KYC and AML between shared financial institutions, which enables the regulators to have access in order to audit the system. All participants have access to audit data/logs, which leads to a model where financial institutions, in order to share data in a trusted ledger, are providing more linkable data for effective analysis. AML is all about analysis, and transactions linked across multiple institutions will make the analysis easier. The KYC process would have to be reengineered so that a tagged transaction would not be subjected to duplicative KYC process. This can only be achieved where the legal system allows it. The idea is to reduce the costs of AML and KYC due to limiting the number of transactions that need investigation, thanks to improved analytics of linked transactions in a Blockchain transaction pool. While this may be ideal, the challenges with shared ledger (discussed above) would have to be addressed prior to dealing with AML/KYC on blockchain. Although various AML/KYC services in Blockchain need to evolve, there are two models that will fit in the near term:

  1. Keep Blockchain as a system of transaction and provide enterprise integration to KYC/AML systems. – Here AML/KYC do not benefit from Blockchain, and instead add to the integration challenges.
  2. Develop KYC/AML models that will be integrated into enterprise blockchain – with concepts such as an inter-ledger, side chains etc. but systemic in nature to take advantage of blockchain’s ways of processing transactions. – This model enhances AML/KYC processes but requires reengineering and shared data/ledger challenges (discussed above).

Regardless of these models and their respective advantages, without a thoughtful consideration of AML/KYC and other related regulatory applications, no blockchain application will see the light of production deployment.

Adjacent Business Activity – Things Like Reporting, Analytics and Other Business Functions.

 Building upon the thesis of enterprise integration for AML, KYC etc. for applications prescribed by the regulatory requirements, enterprises have been creating their own business systems to better measure and manage the business. These systems include reporting, analytics, business application management, dashboard, counter-fraud management, etc. Many of these systems feed off of the enterprise’s System(s) of Record (SoR). These SoR systems can be a relational database, an enterprise information system (EIS), a messaging system like ESB, etc. Blockchain in an enterprise suggests a system design around integrated systems of transaction (trust systems) and systems of record (shared ledger); any application that is either transitioning or originating using Blockchain technology would need to consider the enterprise systems for adjacent business activity. This also brings up other interesting considerations, such as:

  1. Duplicative transaction processing
  2. Enterprise integration into SoR – this challenges the notion of ledger immutability and creates the very problem blockchain intends to solve : updating multiple data sources/ledgers.
  3. Transaction velocity – the mismatch between transaction processing in Blockchain and traditional multi-tier or n-tier enterprise systems. Impact of the transaction velocity on business activity is unknown, as enterprises aspire for real time data analysis of various business systems.
  4. And more…

Enterprise Integration considerations:

  • Integration with incumbent SoR
  • Compliance and regulatory requirements
  • Data formats – ISO20022, EDI 820 etc.
  • Blockchain to enable transaction processing, and preserve the enterprise SoR systems.
  • Design Intent
    • Path of least disruption
    • Accelerate Enterprise adoption

Conclusion

While Blockchain technologies are viewed as a disruptive force for the existing financial systems and market infrastructure and fundamentally change the way the financial services operate day-to-day business, the challenges of enterprise adoption still needs to be addressed as well. Blockchain currently lacks generally accepted definitions and standards. Even though the financial services industry is experimenting with the Blockchain technology in an effort to understand the disruptive forces, for these experiments to be adopted into full-blown production systems, where enterprise can exploit the benefits and realize the promise of Blockchain, the industry has to address the enterprise challenges around transaction audibility, visibility and integration into existing business functions. Without this, the blockchain revolution may never see the light of day in the enterprise world.

One comment on “Blockchain for Enterprise? Not so Fast!

Comments are closed.