Hardening the Chain: DLT and Operational Risk Management

The following article is from The RMA Journal, April 2018 issue

Core principles of safety and soundness dictate that bank executives fully assess, and ensure the sound management of, the operational risks in new business initiatives founded upon distributed ledger technology.   

The rise of distributed ledger technology (DLT) comes just as the financial services industry is under pressure to increase revenue while holding flat, if not reducing, operational costs. With the power to transform and drive needed efficiencies, DLT has emerged as both an opportunity and a threat.

Fintechs are harnessing DLT to launch products and deliver services more swiftly, at lower cost, and with a better user experience. Left unchecked, fintechs are poised to disintermediate established players and disconnect them from their customers1. In response, banks are investing in DLT, and their projects are transitioning from proof-of-concept to commercial implementation. As they go forward, project managers and business sponsors will need to satisfy senior bank executives and regulators that they have a framework for understanding and controlling the operational risks of DLT.

Sound management of operational risk requires that banks implementing new business initiatives undertake a self-assessment to ensure that major risks are recognized and key controls are in place. For DLT-based products and services, a viable framework for analysis begins at the platform layer, proceeds to the applications that sit upon it, and then progresses to issues and challenges at the user interface.

@ The Platform Layer


Governance structures, which set out the rules by which a system is operated and managed, can both control and expose a system to risk. DLT technology first emerged as a public (permission-less) blockchain construct, supporting Bitcoin. Its function was centered on facilitating trust and transactions in the context of anonymous users, by implementing governance in software code: immutable rules that result in similarly immutable transaction records. Anonymity has proven a substantial challenge, given that it has been leveraged to enable a range of illicit activities.

The promise of immutability has also been challenged by business need—for example, to annul theft by reversing and erasing transactions, or to increase processing speed. As a result, advanced DLT constructs have emerged to meet alternate-use cases, such as private (permissioned) blockchains suitable for business networks, where access is limited only to known and trusted parties, privacy and confidentiality are paramount, and industrial-strength transaction processing performance is required. For risk managers, a clear understanding of DLT governance policies and procedures is critically important.

For DLT platforms, major governance risks are associated with system usage, software development, decision making, and information sharing. For example:

  • What are the rules for platform membership? The answer for a public and permission-less blockchain will differ from that of a private, permissioned blockchain. In financial services, suitability is an important regulatory consideration.
  • What is the process for writing, testing, and releasing software? Updates can introduce bugs and security vulnerabilities. Proposed changes in, for example, public blockchains to improve performance, such as processing speed, can challenge ecosystem cultural and political biases.
  • What is the specification for code running on the network and the (trusted) environments in which it can run?
  • Who can create and instantiate a smart contract or chain code?
  • How is oversight maintained? Are robust decision making and sound risk management supported?
  • What are the procedures for incident and emergency response?
  • What are the protocols for information sharing and maintenance of a ledger across entities? These can impact privacy and confidentiality risk, as well as resiliency.
  • What are the mechanisms for dispute resolution?

Information Security

In DLT, information security is achieved through implementation of encrypted messaging and authentication via digital signatures. Maintaining security requires effective generation of public/private key pairs and certificates, along with associated management practices and procedures. Failure to effectively protect the public key infrastructure and user keys can result in spoofed user identities, decrypted communications, and a compromised blockchain record.

For industrial-strength systems, a question to consider is whether software can provide the needed cryptographic service levels, or are hardware accelerators required for pervasive encryption? Further, are hardware security modules required to store cryptographic keys at the highest security levels? Is tamperproof code execution enabled? Nodes hosting private blockchain applications can also be assessed for vulnerabilities subject to malicious exploits.

Consensus Model

In a distributed system where multiple parties hold copies of the underlying database and are able to write to it, a mechanism is needed to fix a single version of the truth and provide for transaction finality. In DLT, this function is defined by consensus requirements that are coded into an agreed algorithm. When the requirements are met, transactions are accepted, ordered, and written to the shared ledger—where they are stored as linked blocks and create an audit trail— and then propagated to the network. As the distributed consensus mechanism defines the core function of a blockchain, it deserves particular attention in a risk assessment.

In public (permission-less) blockchains, the two major consensus variants are proof-of-work and proof-of-stake. Proof-of-work, the most common consensus protocol for public blockchain technologies, is commonly associated with Bitcoin. It is designed for a system like Bitcoin, where participants are anonymous (and not to be trusted) and the design objective is to prevent a participant from taking over the system and double spending, or rewriting the ledger. It does this by incenting participants (called “miners”) to compete to add the next set of transactions (block) to the chain by solving a complex cryptographic puzzle, which is very expensive in terms of time and energy.

In proof-of-stake systems, a “validator” is selected in part by the fraction of coins (stake) it holds in the system and its block is committed by a process that may require a vote of a majority, or designated group, of signers. Those with the highest stakes in the system are seen as having the strongest incentives to be good stewards.

In private (permissioned) blockchains, the parties are known and partially trusted, which unlocks a range of (“pluggable”) consensus algorithms that can be engineered to enable industrial-strength processing speeds and scalability. For example, a transaction can be endorsed by its counterparties without any other participant involved. The transaction may then be validated against an endorsement policy and mechanism that authenticates digital signatures and performs a versioning check to ensure data integrity—paving the way for the transaction to be committed to the ledger.


Privacy risks arise in DLT because ledgers share information across network participants. If all transactions and their details are visible, they may disadvantage parties to a transaction and violate banking laws. Further, the guarantee of immutability may conflict with emerging privacy laws. For example, the European General Data Protection Regulation (GDPR) provides consumer rights to correct stored personal information, to be forgotten, and to data portability. These rights may be stymied by immutability.

While there are available potential exceptions to GDPR (for example, consent, performance of a contract, or legitimate interests), privacy risks may be reduced or eliminated by separating personal information from the shared ledger—by using “off chain” distributed databases that are linked by pointers to ledgers— with access controls protecting the stored personal information.


Confidentiality can prove a major risk in DLT-powered business processes because weakness or failure can expose valuable competitive information. On public blockchains (such as Bitcoin), transactions are pseudonymized, which makes linking to an identifiable person very difficult if there are many users, but traffic analysis and other tools could be used to identify users. Sidechains may also be used to maintain operational security and confidentiality by registering transactions off-chain and later moving them onto the original chain.

On private blockchains, confidentiality and information security can be maintained by data separation and isolation using private channels, so that all data—including who is transacting and the transaction detail—is invisible and inaccessible to third parties if they are not given the right to view it.

Operational Capacity and Scalability

Operational capacity and scalability depend on factors such as transaction processing speed, the consensus mechanism used, and the type and quantity of data maintained. For example, while the Bitcoin network may process three to four transactions per second, to be secure against double spending users may wait until a transaction is six blocks deep for confirmation, which can take 60 minutes. By comparison, private “permissioned” blockchains are capable of millisecond transaction performance.

Performance can also be impacted by network size and distance between nodes, since it may be faster to achieve consensus when the nodes that need to communicate are in close proximity to each other. Further, the amount of data written to a blockchain can also impact performance and scalability.


Aspects of resiliency and reliability particular to DLT include the ability to withstand unavailability of key components, such as validating and ordering services. Procedures are needed to alert transacting parties when requisite services are not available and then to enable the system to catch up when they come back online. The system should also be able to handle cases where incorrect data formats are used in messaging. Testing can assess the potential impact of failure and also show how well ledgers are synchronized.

@ The Application Layer

Secure Software Development

Languages used to program smart contracts (“chain code”) may be complex and hard to audit, so errors may not always be identified. There are several highly publicized instances of programming errors resulting in very large losses of cryptocurrency, whether due to end-user mistakes or hacker exploits. Penetrationtesting services are coming online to provide application analysis and secure code reviews that can identify potential vulnerabilities.

Legal Risk

“Smart contracts” are generally discussed as self-enforcing computer code, but they are legally binding and enforceable only if their underpinnings are supported by applicable law. This depends on the law of the particular jurisdiction(s) involved and potential hurdles such as the legal acceptability of electronic contracts and signatures. That said, smart contracts’ output may be used as evidence that the terms of a legal agreement were followed— or not.

Initially, smart contracts were based on the concept that many kinds of contractual clauses can be embedded in computer hardware and software in a way that makes breach of contract expensive. With the advent of blockchain, the concept evolved to describe self-executing software code written deterministically to specify all possible outcomes, including penalties. Performing transactions that can be verified through cryptographic protocols, code execution can be triggered by the parties involved, or by external events (such as via an “oracle”), and the blockchain can render the resulting transactions traceable and immutable.

@ The User Interface

Key Management and Fraud Risk

Failures in cryptographic key management have caused the largest blockchainrelated losses. For example, because bitcoins are tied to the private keys for the addresses they are stored against, loss of those keys results in irrevocable loss of the coins. Without the keys, the bitcoins cannot be spent.

By stealing private keys, hackers have drained Bitcoin wallets, spoofed user identities, intercepted and decrypted messages, and launched man-in-themiddle attacks. Security problems can be mitigated by the use of effective key management practices. Secure computing environments can also help, but they are not generally available on desktops.

Virtual Currency Issues

Authorized Use

Generally, central banks are the only authority that may issue exchangeable legal tender. Many regulators have issued consumer warnings about the risks involved in the use of virtual currency, including volatility and fraud, and have confirmed that it is not legal tender.

As an emerging technology, virtual currency has been met with a range of responses that vary by country and geographic region. For example, Asian central banks and regulators seem to be encouraging adoption more actively than others around the world—perhaps spurred by the opportunity to promote financial inclusion.

Some central banks have expressed interest in adopting central bank digital currency, and as of early 2018, at least one central bank, Uruguay, has begun to issue this fiat currency in a pilot. In several other countries, virtual currency transactions appear to be authorized. A few regulators have established regulatory sandboxes that allow pioneers to experiment and test their products and business models in a live environment with minimal legal requirements. For example, in the United Kingdom, the Financial Conduct Authority offers potential waivers and modifications to its rules. In some jurisdictions, such benefits are available only to start-ups.

At the other end of the spectrum, however, there are countries that

  • Prohibit banks and other financial services companies, including third-party payment providers, from working with virtual currency.
  • Bar the exchange of virtual currency for foreign currency, or require a license.
  • Explicitly ban or criminalize the use of virtual currency.

Anti-Money-Laundering and Counterterrorist Financing

In places where virtual currency is used, regulators commonly confirm that virtual currency transactions are subject to anti-money-laundering and anti-terrorist- financing rules. This means that traditional controls, such as know-yourcustomer procedures and watch-list reviews, need to be implemented. In the U.S., regulators have confirmed that the Bank Secrecy Act applies to Bitcoin and ruled that an administrator or exchanger of a virtual currency, such as Bitcoin, is required to register as a money services business with the Department of Treasury’s Financial Crimes Enforcement Network.

Tax Liability

Because virtual currency is not legal tender, a number of countries have deemed it taxable as an intangible good or service. This means that taxes may be due upon sale—for example, when used to pay for goods or services—and that tax reporting requirements apply. In the U.S., for example, the Internal Revenue Service’s guidance is that, for federal tax purposes, virtual currency is treated as intangible property. Accordingly, transactions using virtual currency are subject to the same general tax principles that apply to property transactions. As a capital asset, Bitcoin, for example, receives capital gain and loss treatment.

Securities Regulation

Virtual currency may be subject to securities laws when offered for sale to raise capital, such as through an initial coin offering (ICO). The U.S. Securities and Exchange Commission, for example, found that the 2016 crowdfunding of the DAO was subject to federal securities laws, including the requirement to either register with the SEC and make “full and fair disclosure,” or qualify for an exemption. China, for its part, has ordered that all ICOs be halted, that funds already raised be returned to investors, and that crypto exchanges stop trading with local customers.


When classified as an asset, what is the accounting treatment for virtual currency? For example, does virtual currency fall under mark-to-market rules so that unrealized gains and losses are reported? In the U.S., the Financial Accounting Standards Board is exploring accounting rules for reporting digital assets and currencies. However, there are currently no specific accounting standards that address virtual currencies under either GAAP or IFRS.


The substantial media attention and flows of investment into distributed ledger technology should not obscure the fact that it is a young and emerging technology. As such, there is much to learn. Core principles of safety and soundness dictate that bank executives fully assess, and ensure the sound management of, the operational risks in new business initiatives founded upon DLT. Importantly, the overall risk management framework needs to be evergreen and updated through an emerging riskmonitoring process.

Any views or opinions expressed in this article are solely those of the author.

Jonathan Rosenoer is an IBM Master Inventor and the global governance and compliance leader for IBM Blockchain & Digital Currency. Prior to joining IBM, he served as a senior operational risk management executive for JPMorgan Chase and BNP Paribas. He is also a member of the State Bar of California and the District of Columbia Bar. He can be reached at jrosenoer@us.ibm.com.

1. See Bank of England, “The Macroeconomics of Central Bank Issued Digital Currencies,” Staff Working Paper No. 605, July 2016.

Single vs. Dual Risk Rating: Key Differences Explained

Read More

Washington - The Week Ahead, June 29-July 3, 2020

Read More

Leaving LIBOR – What Your Institution Should Be Doing Now

Read More

comments powered by Disqus