Smart Contracts

Automated execution, external data, control and legal effect

Code executes a rule; people remain accountable

A smart contract is code that runs under a platform's rules and can change digital asset state when specified conditions are met. It can transfer a token, release collateral or calculate a payment without a person pressing approve at that moment. The bank must still decide who may deploy or change the code, which inputs it trusts, and how an error will be handled.

A smart contract is not automatically a legally binding agreement. Legal rights may be set by separate terms, and the effect of automated performance depends on the law and the parties' arrangements. The Law Commission of England and Wales has concluded that its legal framework can accommodate smart legal contracts while recognising questions about formation, interpretation and remedies. That analysis applies to its jurisdiction; a bank must assess its own product and location.

The execution path

A bank can describe a smart-contract transaction as five steps: an authorised customer instruction, a verified input or condition, contract execution, platform finality, and updates to the bank's books and customer state. Every step needs an identifier that can be joined later. If execution succeeds on the platform but the bank's ledger does not post, the customer has an exception, not a complete service.

The instruction, oracle input, contract execution and bank-book controls in a smart-contract transaction.

The execution environment varies. Public and permissioned networks can differ in access, governance and finality. The bank should document the actual network, contract version, upgrade authority, signing policy and settlement rule rather than treating “on chain” as one uniform operating model.

The oracle problem

Many useful conditions depend on facts outside the platform: a market price, delivery confirmation, interest rate or weather observation. An oracle is the mechanism that supplies that data. Code can execute perfectly on a wrong or delayed input. BIS analysis of the oracle problem highlights how trust and operational risk reappear at this boundary.

A bank should specify the source, timestamp, tolerance, fallback and dispute process for each material input. It should test missing data, conflicting sources and an input that arrives after a deadline. A price-triggered liquidation, for example, must be assessed for stale prices and market dislocation, not only for correct arithmetic inside the contract.

Upgrade, pause and recovery

Some contracts are deliberately immutable; others allow upgrades or emergency pauses. Each choice has a cost. Immutable code can make a defect hard to repair. Upgradeable code introduces a powerful control point that can be misused or compromised. A bank needs a documented approval and testing process, separated keys, change notice where relevant, and a rollback or migration plan. The customer should know whether a rule can change after they commit funds.

An independent code review can find defects but is not a guarantee. Testing should include normal and adverse scenarios, permission checks, integer and rounding edge cases, re-entry or repeated calls where relevant, integration failures, and the accounting state after a partial failure. The bank must also test operations: who detects a problem, who can pause the flow, how positions are reconstructed and how customers are told what happened.

Worked example: conditional supplier payment

Assume a buyer wants to pay a supplier when a delivery service confirms receipt. The bank receives the buyer's authorised instruction, reserves or otherwise controls the funds under its product rules, and a contract waits for a delivery event. When the event arrives, the contract initiates the payment leg.

The bank should ask what counts as delivery, who supplies the event, what happens if the delivery service is wrong, and whether the buyer may dispute the goods. It must distinguish release of a token from settlement of the supplier's bank claim. If the oracle sends “delivered” twice, the payment must not be duplicated. If the contract releases payment while the delivery is contested, the dispute and legal remedy need a named owner.

This example is a training design, not a universal payment rule. A conventional workflow might solve the same business problem with fewer dependencies. The bank should compare both choices against cost, control, customer outcomes and recoverability.

Release measures

Track failed or delayed executions, disputed input events, admin-key use, changes to deployed code, unmatched platform-to-bank postings, customer complaints and time to restore service. Transaction count alone does not show whether automation is safe. A useful release gate is a replayable case from instruction through external input, execution, settlement and customer communication.

Takeaway

A smart contract can automate execution but cannot make a wrong input true or define legal rights by itself. A bank should treat code, oracle, governance, books and customer remedy as one operating design.

Sources and review scope

Technical and legal examples are general. Binding contract law and payment or asset rules depend on the jurisdiction and product.