Perspectives

Blockchain for treasurers

Published: Jan 2017

Several conferences in 2016 have persuaded me that most treasurers (and most bankers) do not really understand distributed ledgers such as blockchain and their implications for the profession. Here I take a closer look at the key attributes of distributed ledgers and put these into perspective.

Blockchain has been associated with bitcoin, which in turn has been associated with many scandals. Fintech has, therefore, moved to the more neutral term ‘distributed ledger’. But this term doesn’t mean much – treasury management systems and general ledgers are normally distributed for resilience purposes. I prefer the term ‘mutual distributed ledger (MDL)’, which conveys the multi-owner aspect of the technology.

How it works

MDLs are composed of chains of data blocks containing records of some kind. Whenever a new block is added to the chain, a hash (an encrypted checksum that is unique to the underlying data) is added to the top of the chain, effectively “locking” the chain (any change in the records in any block would result in a different hash, making any tampering evident).

The records within each block can be encrypted so that only their owners can see the details. This means the network of nodes does not have to see the data within each record – it merely certifies through consensus on the hash what is stored in each block. This is why MDLs are used for medical records, KYC, and other sensitive information.

Every node (or server) in the MDL network has a full copy of the entire chain, and all the nodes must agree on the hash before a new block becomes part of the chain.

In summary, MDLs have four key attributes:

  • Ledger:

    MDL is composed of blocks of records.

  • Distributed:

    MDL is distributed across many nodes or servers.

  • Mutual:

    MDL is spread across multiple entities and relies on consensus to validate the hashes.

  • Immutable:

    MDL blocks are secured by the hashes that are cumulative including the latest block and all previous blocks.

Let’s then take a look at these attributes in more detail and put them into perspective.

Ledger

Ledgers have existed for millennia. First sticks then clay tablets, then paper in its various forms, then punched cards, and now bits and bytes in different forms.

Ledgers are generally composed of records – such as journal entries in an accounting general ledger. They are commonly used to record transactions such as money flows or purchases and sales, and to record assets such as real estate, trade, and financial asset ownership. They can also be used to record data such as legal and individual documents (for KYC), medical records, institution membership, and so on.

In MDLs, the ledger is composed of blocks of records, which are analogous to pages of a paper ledger, arranged in a chain, which is analogous to the binding that holds the individual pages together in a paper ledger book.

Current generation ledgers are typically held on SQL databases, though other forms of database are used in different circumstances.

Distributed

MDLs are normally highly distributed. The bitcoin blockchain, for instance, runs on thousands of otherwise unrelated servers operated by “miners” who are paid for their efforts in bitcoins. Commercial MDLs tend to be run across a smaller group of interested parties – banks for payments, brokers for securities, etc.

Being distributed increases the resilience of the MDL. Since all nodes have a full copy of the MDL, when any node goes down the MDL continues to function.

This insight is not new to MDLs. Most SQL databases offer clustering, whereby the database is replicated across multiple servers in different locations. Apache – the open source organisation that drives most web servers – offers at least three distributed database solutions: Cassandra for NoSQL, CouchDB for JSON and Hadoop for big data.

Distributed databases are not just for cloud and the web. Most corporate ERPs and TMSs will have distributed databases in at least two locations to ensure sustainability.

Mutual

MDLs are typically shared across a number of participants. The industry talks about permissioned and permissionless MDLs. The bitcoin blockchain is permissionless – anyone can participate and no-one controls onboarding.

In fact, the bitcoin blockchain also provides an example of an ownerless MDL. Satoshi Nakamoto – whoever they are – wrote the original paper describing the bitcoin blockchain and has since left it to live its own life. Governance is purely baked into the algorithms themselves.

Permissioned MDLs have some kind of mutual or individual gatekeeper, so it’s more like a private club. This is the kind of MDL envisioned by most banks and regulators. MDLs can also be private.

MDLs enable a kind of technical mutuality that is different from what can be achieved with traditional databases. But there are plenty of examples of shared data systems. Wikipedia is a huge example. SWIFT is a major example in finance. Most clearing systems are mutually owned by banks and/or government. But it is true that they all required human old school governance.

Immutable

Absent tricks like disappearing ink, the old paper ledgers were immutable. Think of shivering Bob Cratchit transcribing entries into Scrooge’s ledger. Any mistakes have to be corrected with a reversal and new entry.

We have carried the same principal into our digital ledgers. For example, auditors routinely perform tests to ensure that general ledger entries cannot be tampered with after posting. This is routine with current accounting systems using old school SQL databases.

So ‘immutable’ is also not unique to MDLs.

What MDLs do change is the governance model. To trust an SQL database, you need to trust the governance of that database. Intrinsically, an SQL database is mutable using SQL’s “UPDATE” and “DELETE” statements. We need to have digital and human controls in place to ensure that general ledger entries are not changed after posting. For our own general ledger, we trust our internal controls. For external ledgers like a bank account, we trust the service provider’s control and verify with reconciliation.

The MDL governance model is different. In an MDL we trust the hashing of the blocks, cryptography, and the consensus mechanism. This tech governance is probably as good or better than traditional controls. What is significant is that we trust the technology rather than the institution. This can be a very powerful shift.

Some considerations

When considering financial technology, it is important to remember that there are many issues beyond technology per se at play. Capital and liquidity will always be critical – for example, instant payments reduce or eliminate counterparty and also bring possible liquidity issues (period net settlement in central bank money has the benefit of reducing liquidity tied up in payments).

Regulations will affect fintech feasibility. This is why progressive central banks like BoE and MAS have created regulatory sandboxes for fintech experimentation. While MDLs have the potential to greatly smooth KYC, regulators will still want money flows to be controlled for fraud, AML and KYC.

In the end, humans have to trust the new systems if they are going to use them. Treasurers are for good reason very conservative. Current low tech, for all its frustrations, basically works (albeit slowly and expensively) and the problems are well known and generally mitigated. New tech may bring new risks – is it really secure, will it be sustainable, will there be liquidity in tight times?

These issues are not insurmountable, but we need to remember that non-tech issues may be critical to success. A good example is Ripple which has 45 banks doing sub-second cross-border payments; Ripple has addressed many of these problems by working with and through banks (and hiring experienced bankers).

Looking to the future

MDLs clearly offer many potential benefits. They will likely become very important in finance, and maybe even a key part of the internet itself. However, MDLs are not the only technology that provides those four key features:

  • Ledger:

    There are many database technologies that work fine as ledgers.

  • Distributed:

    Most current databases are distributed.

  • Mutual:

    Mutual systems are prevalent throughout finance and work reasonably well and are well understood.

  • Immutable:

    We have long experience with reliably locking down ledgers in current database technology.

MDLs per se and from a strictly technological perspective will not necessarily upend the treasurer’s world. However, the threat of MDLs (and even the fashion for MDLs) will likely prompt banks et al to push forward with things they should have done years ago, like trade and KYC registries and fast, cheap, transparent cross-border payments. But for treasurers, it does not really matter whether they do it with MDLs or SQL or NoSQL.

David Blair, Managing Director

David Blair, Managing Director, Acarate Acarate logo

Twenty-five years of management and treasury experience in global companies. David Blair has extensive experience managing global and diverse treasury teams, as well as playing a leading role in eCommerce standard development and in professional associations. He has counselled corporations and banks as well as governments. He trains treasury teams around the world and serves as a preferred tutor to the EuroFinance treasury and risk management training curriculum.

Clients located all over the world rely on the advice and expertise of Acarate to help improve corporate treasury performance. Acarate offers consultancy on all aspects of treasury from policy and practice to cash, risk and liquidity, and technology management. The company also provides leadership and team coaching as well as treasury training to make your organisation stronger and better performance oriented.

david.blair@acarate.com | www.acarate.com

The views and opinions expressed in this article are those of the authors

All our content is free,
just register below

Already have an account? Sign in

Please only use letters.
Please only use letters.
Please only use letters.
Please complete this field.
Please select an answer.