The software made the trade. Is your business bound?

Automated trades can create contractual obligations. When software produces an unexpected result, can a business simply undo the transaction?

In Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 2, the Singapore Court of Appeal considered contractual responsibility for transactions executed by automated trading systems.

What happened?

B2C2 traded cryptocurrencies on Quoine’s exchange using algorithmic software. Following an operational problem, trades were executed at prices approximately 250 times the prevailing market rate.

Quoine reversed the trades. B2C2 sued.

What did the court decide?

The majority upheld Quoine’s liability for breach of contract. Its contractual arguments and defence of unilateral mistake did not justify reversing the trades. However, the separate finding of breach of trust was overturned.

The court recognised that contracts could be formed through algorithms even though the parties did not know the particular terms beforehand. In assessing knowledge of a mistake, it examined the relevant programmer’s or operator’s knowledge from programming until contract formation.

Importantly, the software was deterministic: it followed programmed rules. The case did not decide liability for a self-learning AI system or an inaccurate generative-AI answer.

What should businesses take away?

1. Decide what your system is authorised to do.

There is a practical difference between software that suggests a quotation for approval and software that sends an offer or accepts an order. Businesses should identify which steps require human approval and establish appropriate transaction limits.

2. Agree how errors will be handled before they happen.

A procurement contract should address incorrect prices, duplicate orders, failed integrations and unauthorised transactions. Specify when a transaction may be suspended or reversed, who must be notified and how resulting losses will be allocated. A general reference to “system errors” may leave important questions unresolved.

3. Separate a defective system from an unexpected outcome.

A commercially unfavourable result does not, by itself, explain whether the software failed, followed unsuitable instructions or received incorrect information. Define the intended functions, acceptance tests and responsibilities of both the supplier and the customer.

4. Preserve the records needed to explain the transaction.

Keep the applicable contractual terms, approval records, system settings, change history and transaction logs. These may be essential to establishing what the system was instructed to do and who knew about an emerging problem.

For businesses adopting AI, these are useful precautions rather than a claim that this decision answers every question about modern AI. The contractual arrangements, technology and circumstances of each deployment remain important.

The position in Malaysia remains to be judicially developed in a comparable case. Quoine nevertheless offers a useful reference for businesses adopting automated systems, particularly on contractual responsibility and the allocation of risk. How Malaysian courts would approach a similar dispute will depend on the applicable law, contractual terms and facts.

Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 2

Share this article