Automating contracts through Electronic Data Interchange (EDI) standards, smart legal contracts and other computer programs has the potential to unlock significant business value. However, this automation can introduce a number of new risks not found in traditional paper contracts managed by humans – and the likelihood and impact of such risks can increase as automation scales.

Bugs and unintended consequences

SLCs can contain ‘bugs’ in the code aspects of the contract, or can give rise to unintended consequences where code is applied in unforeseen circumstances.

In a traditional automation process (such as EDI), each clause to be automated is implemented in-house or on an ad-hoc basis by external contractors.

The coding often occurs after the contract has been negotiated, when a business case arises that demonstrates the savings from automating the existing process. As the wheel is re-invented each time (and often under substantial time pressure) the likelihood of bugs increases. Furthermore, the removal of code implementation from negotiation increases the likelihood of unintended consequences.

SLCs can help mitigate these risks. We expect that law firms will develop well-tested suites of precedent 'smart' clauses, similar to the clause banks they use today for traditional contracts. These smart clauses will be developed using best practice, with a focus on preventing errors from occurring by enabling changes to parameters to be made predominately in the human-readable sections of the smart legal contract.

For bespoke clauses needed for complex deals, external providers (whether it be law firms or other expert organisations) will have the expertise to roll out custom-built and well tested code that internal teams may not be able to provide. And by negotiating the contractual terms carefully, and taking a risk-based approach to both the natural language and the SLC code, the end-to-end SLC process can be made more efficient, with the parties actively turning their minds to the objectives of automation, simplification and reduction in risk.

Garbage in, garbage out

Automation means that that poor quality inputs will be parsed into incorrect outputs – as programmers say, garbage in, garbage out. Data sources therefore need to be considered carefully, to ensure they are high quality and unlikely to be compromised. This is one of the reasons that SLCs have only become viable more recently; up until now there has not been a sufficient scale of high quality, trustworthy digitised data available to act as inputs and facilitate automation.

A well-crafted SLC can mitigate this risk to some extent, by requiring checks and balances in the form of multiple sources concurring before any code is executed. It can also implement a mechanism for rectifying mistakes (should they occur) despite these precautions. By providing for multiple levels of redundancy, risks can be substantially mitigated.

For example, consider the rent review mechanism described in part 2, where rent increases by 2% + CPI most years. If the source of the CPI is wrong, then the resultant output will also be wrong – resulting in a rent review that is wrong. By relying on multiple sources (eg official figures + another trusted economic statistics API) the prospect of these errors can be reduced.

However, as the economic statistic API is likely pulling its data from the RBA, there remains the possibility that an incorrect publication is reflected in both instances. Therefore, further protection can be provided by appropriately allocating contractual risk (eg that the cost of rectifying an incorrect result from a trusted third party will be shared evenly between the parties).

Support for software ending

Another risk is that over a contract's lifetime the technology stack on which the smart legal contract runs becomes unsupported. For example, consider that leases may run for many years. Using a trusted, well-established partner to support your smart legal contracts mitigates this risk, as they are unlikely to ‘go under’ and leave you unsupported.

A well drafted SLC will also have the ability to replace the underlying technology stack without requiring the contract be renegotiated. For example, it can include a clause that allows the parties, by mutual agreement, to migrate the code to another platform, and include a safeguard to ensure the original code and intent is preserved in doing so.

Code and contract mismatches

Another risk is where the code and contract are mismatched (ie the code does not capture the parties' intent). This is more likely to occur when the code is implemented after the contract is negotiated, as programmers are generally not legal experts. An SLC mitigates this risk, by ensuring that lawyers are on hand to explain the legal intent behind the contract – and by allowing for necessary changes to a contract during negotiation to avoid the need for complex programming.

Reduced commercial flexibility

Automation can reduce flexibility in businesses' ability to respond to situations off the business as usual path. For example, without a smart contract, a business might choose to waive a penalty associated with a contractual breach or accept partial performance as full performance of another party’s obligations. This can allow commercial relationships to be preserved.

An SLC changes the default state, from having to take an active enforcement approach, to contract sanctions being applied automatically – which may result in increased compliance costs, as one party seeks to ‘undo’ these automated actions.

However, where flexibility is particularly important, this, too can be negotiated into an SLC. For example, to allow a party to accept part performance, drafting could be included that in addition to automatic acceptance on certain conditions being met, either party can deem contractual obligations met at any time (and code could be included to give effect to this as well).