Smart contract risk: what the CFO actually owns

A smart contract is, in operational terms, a deterministic program that executes when its conditions are met. In economic terms, it is a contract whose performance is enforced by code rather than by the legal system. Both descriptions are accurate. Neither is sufficient for a finance leader who needs to understand what could go wrong, how badly, and who owns the consequence.

The CFO is not the engineer who writes the contract. She is also not entitled to delegate the entire question to the engineers who do. The boundary between technical risk and finance risk is what this piece is about.

Where the risk actually sits

The exposure produced by a smart contract has three components. The first is the code — whether the contract does what it was designed to do under all foreseeable inputs. The second is the design — whether what the contract was designed to do is what the business actually needs. The third is the integration — whether the contract behaves correctly when called by, or interacting with, other contracts and systems in production.

Each component fails in a different way. The code can have a bug — an arithmetic overflow, an unchecked external call, a re-entrancy vulnerability. The design can be sound but wrong — the contract performs as specified but the specification did not anticipate the business case. The integration can be the source — a contract that works in isolation behaves incorrectly when called by a contract whose interface assumptions differ.

For the finance function, the consequence of any of these failures is the same: an unintended economic outcome that the accounting has to recognise and the audit has to explain. The CFO must therefore care about all three, even though the technical work to address them is not hers.

Three categories of smart contract exposure

The entity's exposure varies by how the contract relates to the business.

• Contracts the entity has authored. A native token contract, an on-chain retirement contract, a custom settlement contract. The entity is responsible for the design, the code, and the integration. The exposure is total — economically, legally, reputationally.
• Contracts the entity interacts with. A stablecoin contract operated by an external issuer, a decentralised exchange the entity uses to convert positions, an external custody contract. The entity is exposed to the failure of the contract but is not, generally, the controller. The risk is more like counterparty risk than authorship risk, with a different governance shape.
• Contracts the entity holds positions in. A staking contract that receives the entity's tokens in exchange for a yield. A liquidity pool the entity provides to. The exposure mixes counterparty risk with code risk, often with limited ability to exit on demand.

The governance for each category is different. Treating them as one population produces a policy that is either too restrictive for the easy cases or too permissive for the hard ones.

What the CFO owns, what she delegates

The CFO owns:

• The decision to deploy or interact with a contract that produces a material financial exposure.
• The economic case for the deployment — what is gained, at what cost, with what alternative considered.
• The risk limits — the maximum exposure the contract can hold, the conditions that trigger pause or exit, the reporting cadence to the board.
• The audit relationship — ensuring that the contract is subject to independent technical review by competent engineers, that findings are documented and remediated, and that the financial audit team has the technical inputs it needs.
• The incident response framework for the case where the contract fails — who decides, on what timeline, with what authority to halt or migrate.

The CFO does not own:

• The choice of programming language, framework, or deployment chain.
• The technical review itself — performed by qualified independent reviewers, not by the finance team.
• The day-to-day monitoring of contract behaviour — performed by the operational team with defined escalation triggers.

The line between these two lists is the line between economic responsibility and technical execution. Both lists need an owner. They are not the same owner.

The governance pattern that works

The pattern that survives audit and incident has the following components.

Pre-deployment review. No contract that produces a material financial exposure is deployed without an independent code audit by a qualified firm. The findings are documented, the remediation is verified, and the audit report is retained.

Risk classification. Contracts are classified by exposure category — authored, interacted-with, position-bearing — and by financial materiality. The classification drives the governance.

Monitoring. Active contracts are monitored for unexpected behaviour with defined alerting thresholds. A balance change outside expected parameters triggers human review.

Pause and exit. Where the contract design permits, a pause function is implemented and the conditions for invoking it are documented. Where the design does not permit, the inability to pause is itself an exposure that the policy must acknowledge.

Incident response. A pre-agreed sequence for the case where the contract behaves unexpectedly — who is called, who decides, who communicates externally. The first time the sequence is invoked should not be the first time it is rehearsed.

Periodic re-review. Contracts are not deployed and forgotten. Material contracts are subject to periodic review as the environment changes — new dependencies, new attack patterns, new regulatory expectations.

The audit conversation

The external auditor will ask, for any material smart contract dependency, whether the contract has been independently reviewed, what findings were identified, how they were remediated, and what ongoing monitoring is in place. The auditor will also ask whether the financial reporting process accurately captures the economic effects of the contract's behaviour during the period — including any incidents.

The CFO who has the documentation ready will have a short audit conversation. The CFO who does not will have a long one, with disclosure consequences. The first time this conversation happens is rarely the last.

This piece sits inside the CFO in blockchain framework. See also proof-of-reserves and the audit function and CFO's role in blockchain governance. Lorna writes from practice at IMPT. The verified page records what is and isn't published here.