Last week saw the second R3 smart contract template contract summit, following on from June’s summit and Barclays demonstration at the London O2 in April.

Dr. Lee Braine from Barclays stated in April that what we saw would take time to build and that further industry collaboration would be required.  So it’s good to see from the latest summit that more firms seem to be collaborating in this project.

The April demo reminded me, from a pure functional point, of working on Swapswire (later MarketWire and MarketSERV) projects some years ago. SwapsWire provided a service for trade matching and confirmation service with real-time messaging and trade resolution. Trades would be entered by both counterparties and transmitted to SwapsWire for matching. You could use a SwapsWire interface for trade entry which could efficiently deal with trade negotiation e.g. on-screen flashing of changes to deal parameters, or enter trades in existing systems, which meant building in such negotiation features, which was often complex or not possible.

I mention Swapswire, because the user interface at the time lacked many of the features also missing in the Barclays demo; Features related to a traders workflow such as being able to price a trade, assess the impact on their book, check trading limits, hedge the trade etc.  Without such features, or integration into existing systems and workflows, a trader will be forced to enter trades into two applications which introduces scope for errors and a reconciliation problem that smart contracts are trying to solve. A lot of the projects focus seems to be concentrated on providing a framework for legally enforceable contracts and being able to map the code to the legal prose, but this part of the workflow will be important in the future.

Agreeing trades using smart contracts can reduce a lot of time and cost spent in affirmation/confirmation processes, and ensure that each counterparty has the same view of what they have traded, on a shared distributed ledger. But each counterparty will have many other systems not using that ledger, from back office to risk management and collateral systems, each of which need to be reconciled to ensure that there are no discrepancies.  The forthcoming open sourcing of R3’s Corda DLT will open up their platform to non-consortium members such as vendors and FinTech’s, which will surely help to increase adoption and use throughout banks systems and processes.

One interesting aspect of the latest summit was Thomson Reuters involvement in the project, in which they are focusing on Oracles. Oracles are essentially third parties that deliver trusted data that can be used by smarts contracts and which may automate otherwise manual processes. Such data could be benchmark prices such as LIBOR rates, holiday calendars or credit ratings. Such data often needs to be entered and approved before it can be processed, and in many different systems.  This creates manual inefficiencies and the potential for post trade discrepancies between each counterparty’s view of what has happened. Oracles would enable such data to be automatically processed and trigger further events, such as the settlement of a cash flow or the exercise of an option.

ISDA’s continued participation is important too, as they should have a central role in defining the smart contracts, ensuring that they are correct, valid and conform to their master agreements. ISDA believes that FpML can have a role to play too stating in a recent whitepaper that “much of the work already undertaken by ISDA to develop standard forms of documentation, including definitional booklets and confirmation templates, coupled with FpML, has the potential to form the basis of these smart contracts”.

One of the interesting concepts in Corda is the fact that transaction data is shared only between the counterparties and other entities that have a vested interest and are allowed to see the data, an obvious example being regulators. This potentially opens up the possibility of simplifying regulatory transaction reporting which is rife with errors – in the last couple of years  Deutsche Bank and Merrill Lynch were fined by the FCA for incorrectly reporting approximately 65m transactions between them. Part of the problem is that firm’s transactions for different asset classes have different representations between different banks and often in different systems within the banks themselves. And firms have to report these transactions in a standardised format for different regulatory requirements eg MIFID and EMIR.  Moving to a shared ledger with agreed shared transaction formats defined by a trusted third party such as ISDA, in the form of smart contracts, would go some way to simplifying the process. But the transactions still need to be reported in a format prescribed by the regulators. This could be done in similar way to which the smart contracts map the code to the legal prose; the mapping could be done once per contract type (eg IR SWAP) by a trusted party such as ISDA in collaboration with the regulators, to ensure correctness. This would eliminate all the complexity, cost, errors and inefficiencies that exist in transaction reporting today, and move discussion from single v double reporting to shared (ledger) reporting.

So are smart contracts getting smarter? Progress is definitely being made and a legally enforceable shared set of transaction facts at the time of execution is the right place to start. But to be really smart more standardisation is required and we have to use those shared facts more widely instead of duplicating and transforming them countless times in countless different systems.