R3's Richard Brown emphasises privacy of Corda project

A wise man once said that what blockchain solves for banks is not a technology problem but a game-theory problem − that is, how can we collaborate with one another without one of us ending up owning the others.

The underlying problem of privacy appears to loom large in Richard G Brown's thoughtful blog post introducing the features and rationale behind the R3 consortium shared ledger design, Corda.

Indeed, the first bullet point of Corda's key features is: "Corda has no unnecessary global sharing of data: only those parties with a legitimate need to know can see the data within an agreement".

This point is reiterated: "Unlike other designs in this space, our starting point is individual agreements between firms ('state objects', governed by 'contract code' and associated 'legal prose'). We reject the notion that all data should be copied to all participants, even if it is encrypted."

There is also an emphasis here on automated agreements, often called smart contracts, between relevant parties. Some headway has been made in this regard in the OTC space, for instance; a use case whereby the negotiation of bilateral contracts would benefit from increased automation combined with regulatory scrutiny.

It's interesting that the likes of ICAP have reached a conclusion similar to R3's, whereby each organisation will hold only the information they are entitled to receive. Jenny Knott, CEO of ICAP's post-trade risk and information, made this point: "We believe that for some use cases the industry is not ready yet to adopt the pure model. Instead, we believe in a more practical approach where each organisation will hold only the information they are entitled to receive."

Providing privacy within a block-chain arena, both public and private, has been a buzzing space, with solutions like homomorphic encryption and zero-knowledge proofs being touted by eminent scientists in the space. One problem with heavy encryption is that it tends to slow down shared systems that change state, and speed at scale is another thing financial services can't compromise on.

But at a more primal level, information leakage is one of the things that capital markets veterans fear most about a blockchain upgrade. And even encryption can't get around some aspects of this problem. Larry Tabb's favourite example here concerns the question of short selling, which involves a security that seems to exist in two places at once. Blockchains would impose a degree of ontological parsimony here, which some might say was much needed: "What I see is what you see, and we both know that we see the same thing, and we both know that this is what has been reported to the regulator."

The point is that the loaning, selling and repatriation of securities, which takes place in the T+2 trading window (something else that blockchains are charged with addressing) has to stay the way it is, or otherwise critical competitive information will be leaked to the market's most sophisticated investors.

Unsurprisingly, things like short selling windows and large scale netting of complex securities are not the first choice for a budding blockchain. It seems more and more people are concluding that the simple and rather unsexy concept of reconciliation can be updated, saving billions in the process. There is a basic need to overcome issues whereby one firm will match and run to six decimal places and the other will do a valuation and run to 12 decimal places − ultimately creating some sort of break or out-trade in respect of the contract.

This is because agreements that exist between firms share a common problem: "the agreement is typically recorded by both parties, in different systems and very large amounts of cost are caused by the need to fix things when these different systems end up believing different things. Multiple research firms have postulated that tens of billions of dollars are spent each year on this problem".

Perhaps the sorts of use cases we can expect to see going forward from R3 will included things like trade finance. For example, where an importer's bank may supply a letter of credit to the exporter's bank providing for payment upon presentation of certain documents, such as bill of lading.

Returning once again to the problem of privacy, the CIOs of banks would probably also have a gut resistance to trusting encryption of their data when it is being circulated among competitors. An interesting anecdote in this regard concerns the early days of CREST, the central securities depository for the UK, which was at the time a huge IT project. Apparently a lot of the early participants of CREST were concerned about having a single place in which all of this transaction information would be collected. They thought it would be visible to certain service providers, whoever was providing the infrastructure or the communications lines, and this would undermine their confidentiality.

Gideon Greenspan of MultiChain pointed out: "It was a very big issue early on, and then people got used to it, and realised it wasn't really a problem. Maybe something similar will happen with blockchains. All the participants in a chain will lose some of their sense of confidentiality. But because they are all in the same boat, overall it might not make that much difference. As is often the case, people may realise that their confidential data isn't worth as much as they thought."