Blockchain implementation: Connecting the missing DLT links

For centuries, the integrity of commerce has been built on the principle that all of the parties created and maintained...

duplicate records of the information that documented their transactions. But multiple copies created multiple risks for conflicts and disputes, as well as multiple surfaces against which adverse actors could gain access to confidential business records with high, competitive value. As a result, many of the most intensive information security investments have prioritized protecting the integrity of corporate records.

Now, blockchain technologies -- the same platform on which Bitcoin and other digital currencies are evolving -- are accelerating transformative disruption by replacing redundant, duplicative books and records with a single, distributed ledger to which all parties in a supply chain or trading system can connect. Collectively called distributed ledger technologies (DLTs), these new blockchain implementations offer enormous potential for improved efficiencies and reducing costs associated with identity management, information governance and regulatory compliance.

Quite simply, DLTs enable the creation of a single record to be maintained, with all of the best information security attributes mathematically proven using existing cryptographic capabilities. That single record can be relied upon across the full transaction lifecycle, enabling the components and business processes to sequentially proceed without the inherent time delays, redundancies of validation, and layers of cost associated with maintaining and auditing information controls across multiple networks.

As is often the case, new technologies stir up tremendous enthusiasm: Harvard Business Review described blockchain as a foundational technology upon which economic and social structures will proceed. New technologies, however, are also often marked by flaws, failures and missteps as enthusiasm fuels investments that prove not ready for prime time.

Once parties move to distributed ledgers, it is critical to define and express in the related agreements the rights of the parties to the records themselves.

While DLT offerings are still young, we have already learned a great deal from the missing links that have been overlooked during early stage implementations. Below are two key questions to ask in order to better assure the success of your first steps forward with DLT. As you will quickly realize, answering these questions require full collaboration across teams from throughout the organization: IT, security, communications, legal and compliance.

Who owns the records? DLT distributes transaction records, rather than requiring parties to maintain redundant duplicate copies inside their respective firewalls. But prior to blockchain, many commercial agreements have failed to address who owns and controls the actual records themselves. Once parties move to distributed ledgers, it is critical to define and express in the related agreements the rights of the parties to the records themselves. Whatever encryption is employed may not be sufficient to fully protect the records, so additional controls expressed in the contracts can be invaluable.

What are the rules? Early cryptocurrencies touted that their platforms did not require contracts or governance, but those claims simply do not apply to any DLTs. To the contrary, their success relies heavily on the consistent, precise and automated execution of complex rules and requirements. But as for any new implementation, identifying, finding and mapping of all of the rules can be a challenge. A big part of the challenge is that the rules for any DLT product must be extracted from different, disconnected sources.

At the University of Oxford, the Unified Rules Model (URM) is a tool presented in a graduate course on designing information governance that can be useful to planning DLT and blockchain implementation.

The URM delivers a multilayered framework and classification structure with which all of the rule sources can be organized and, in turn, connected so the operating software code is fully conforming to all of the related rules.

The Public Layer is populated by all of the public laws, regulations and interpretations (such as agency releases or judicial decisions) that govern the structure of the records to be stored on the DLT or the business operations to which the records relate. Many DLT advocates overlook the fact that transforming how the records are created and stored does not change the applicability of these laws and regulations. There are two questions: What rules exist for the records involved? What do the rules require, if anything, for digital versions of those records? Of course, answering those questions becomes more complex as additional jurisdictions are connected to the related business processes.

The Implementation Layer is populated by all of the corporate policies, procedures, contracts and agreements by which a company manages its operations. As illustrated, there are two large classifications: Business Rules, largely expressed by written policies and agreements, and Technology Rules, largely expressed by standards or technology-specific control requirements (such as the level of authentication required for varying types of digital records).

With DLTs, as well as nearly any cloud-based product, a company populates the Implementation Layer with their proprietary documents as well as the contracts, policies and procedures of the DLT. Those are, in effect, the governing rules of the DLT systems. They can be remarkably complex in number and in their operation. Identifying them, understanding them and aligning the rules of a DLT with the Business Rules and Technology Rules for a company can be surprisingly time-intensive, but failing to do so can endanger the full investment.

The Execution Layer is populated by the software application code itself. Here the rules are explicit, precise and automatically executed. DLTs, utilizing and extending blockchain technologies, achieve their power by automating business processes that have often been redundant, labor-intensive and vulnerable to security risks. First, the code has to function correctly, produce correct results and be mapped to the requirements of the higher URM layers. Second, a company needs assurances the code will produce records of those results that support compliance obligations the company must satisfy.

This second element is vital: Whenever shifting to a system outside a company's direct control, strong assurances must be expressed in the agreements for how compliance will be documented. Metadata, operating logs, access control logs -- all of these become vital products of the Execution Layer code assets.

The URM is visually simple to absorb. But using it as a tool to conduct due diligence can help teams organize the full portfolio of rules to which a DLT must align in order to be successful. Parent-child relationships between rules can be more clearly mapped. Ambiguities in what the rules may require (such as "appropriate security" or "reasonable safeguards") can be aligned to specific rules in the Implementation and Execution Layers. In doing so, CIOs can better assure all of the rules are in place to best complete a successful DLT and blockchain implementation.