Nigel Farmer, solutions director, Capital Markets at Software AG

My previous blog about smart contracts highlighted how they could create efficiencies in trade affirmation/confirmation and throughout the trade lifecycle. However, there are still many open questions and concerns about how smart contracts operate in the real world.

After all, how do you see and understand the finer details of a smart contract when the terms of the contract are expressed in code? For example, if you are trading bonds using a smart contract how do you find and trade the right bond when there are different issuers with different maturities and different coupon rates?

There must be some metadata and/or description of these characteristics and this needs to be validated and verified against the coded implementation to ensure that the smart contract does exactly what is says on the tin.

On the subject of issuers, how do you verify and trust the issuer and the smart contract itself? Will we start talking about smart contract issuer risk in the near future?

How do you integrate smart contracts with existing systems such as back office, trading, risk? You need to detect when life cycle events have occurred such as an interest rate reset, so that these can be processed in external systems. Trusted data sources need to provide that data, and there should be agreed and standardized processes in which external data is applied to the smart contract. Whose responsibility is it?

Legacy systems will not be able to magically use a blockchain as their repository, so integration, data transformation and reconciliation will be crucial to ensure that those systems’record of a transaction mirrors that of the blockchain. Systems will also need to query and search the blockchain for transactions based on all manner of criteria, with response times equivalent to existing technologies.

How do you ensure that smart contracts function as expected? How do you ensure that fractions are not getting syphoned off, such as happened with Richard Pryor’s character in Superman III.

A smart contract’s logic could contain bugs, or there may be unforeseen and therefore untested conditions, such as negative interest rates, or buying and selling at the wrong price (such as when Knight Capital’s algorithm lost it $440m in 30 minutes). The impact of such conditions may reveal themselves months, or even years, after a transaction was executed.

If a smart contract has bad code that is immutable and distributed on the blockchain, the potential for damage could be huge, especially if that code is intentionally malicious. How do you monitor and detect such rogue code? And how do you stop it, how do you pull the plug?It is early days for smart contracts, which have great potential, but there are clearly questions that need to be answered.