Your Controls Weren’t Built for This: Extending Financial Governance to Digital Assets

Where Traditional Controls Come Under Strain

The control frameworks most businesses operate, whether formally documented or simply embedded in habit, rest on a set of assumptions about how money moves. Money sits in bank accounts. Institutions verify identities. Transactions are processed through regulated systems. If something goes wrong, there are mechanisms that may allow investigation or recovery. These assumptions are so fundamental that they are invisible. They are the load-bearing walls of the finance function, and most businesses do not realise how much weight they are carrying until something removes them. We have written about the hidden risks that grow invisibly inside finance functions, and the pattern here is similar: the danger is not dramatic. It is structural.

Crypto changes several of these assumptions at once. Settlement is typically final. There may be no intermediary institution holding the assets on your behalf unless you choose a custodial arrangement, and even then the custody model works differently from banking. Transactions are pseudonymous by default. And the speed of settlement, one of crypto’s genuine advantages, means an unauthorised or erroneous transaction can complete and become irrecoverable within minutes.

For crypto-native businesses, none of this is news. But knowing the theory and having governance frameworks that actually prevent losses are very different things. A common and instructive risk pattern looks like this: a business at £2–5m in revenue where a single person effectively controls the keys to wallets holding six-figure sums, with no tested recovery process and no documented authorisation. Or a reconciliation routine that relies on manual matching between blockchain explorers and accounting software, introducing errors that compound month after month. These are not exotic problems. They are governance gaps that an experienced Finance Director would identify and close before they become incidents.

Wallet Management and Custody Governance

The first question any FD should ask when digital assets enter the picture is: who controls the assets, under what model, and what happens if that control is lost?

Control of crypto is not a single thing, and it is a mistake to picture it as a shared login to an account. Depending on the setup, control may rest on private keys, seed phrases, hardware signing devices, multi-signature arrangements, institutional custody, administrative permissions on a platform, or the credentials to an exchange account. Each of these carries a different risk profile and a different set of governance requirements. A hot wallet, connected to the internet, offers convenience for frequent transactions but a larger attack surface. A cold wallet, held offline, offers stronger security but less accessibility. A custodial arrangement places the assets with a third party, which introduces counterparty risk: the security of your assets depends on the security and solvency of their systems. Each model has legitimate uses. What matters from a governance perspective is that the choice is deliberate, documented, and reviewed.

Whatever the model, there is usually a point of ultimate control, and losing it can be catastrophic. There is typically no password reset and no account recovery in the sense a bank offers. If the means of control is lost, the assets may be permanently inaccessible. If it is stolen, the assets may be gone. If the person who holds it leaves the business unexpectedly and nobody else can access it, the assets may be effectively frozen.

Because of this, simply backing up a recovery phrase is not a custody policy. Robust custody governance covers a broader set of safeguards, appropriate to the scale and value involved:

• Controlled recovery procedures, with backups stored securely and separately from the primary means of control.
• Multi-signature or distributed signing arrangements, so that no single individual holds unilateral control of material assets.
• Institutional custody, where the scale, risk profile, or regulatory context justifies it.
• Periodic recovery testing, to confirm that backups and procedures actually work before they are needed in anger.
• Access removal when personnel leave, treated with the same rigour as revoking bank mandates or system credentials.
• Documented emergency escalation, so everyone knows what happens, and who acts, if something goes wrong.
• A board-approved custody policy, so that the arrangements reflect a considered decision rather than an accident of history.

A wallet controlled by one person, with an untested backup and no succession plan, is not a treasury arrangement. It is a single point of failure with real money sitting on top of it. The FD’s job is to see this before it becomes an incident.

Segregation of Duties and Authorisation Frameworks

In traditional finance, segregation of duties is a foundational control. The person who raises a purchase order should not be the person who approves the payment. The person who processes payroll should not be the person who sets salary levels. These separations exist to prevent fraud and to catch errors before they become losses.

In a crypto environment, the same principle applies, but the implementation is more challenging, particularly for smaller businesses. A £3m crypto-native firm might have a finance team of two or three people. Designing segregation into a team that small requires deliberate thought. Who initiates a crypto transfer? Who approves it? Are there value thresholds that trigger additional sign-off, just as they would for a large bank payment? Is the approval process documented and auditable?

Multi-signature wallets offer one strong technical answer for material holdings: they require more than one key-holder to authorise a transaction, which is the crypto equivalent of dual authorisation on a bank payment. But multi-signature is not a universal default, and it is not the right answer in every case. Whether it fits depends on the custody model, transaction frequency, asset value, the technical capability of the team, and the business’s risk appetite. A business making frequent small operational payments may need a different balance between security and speed than one holding a large strategic position it rarely moves. The point is to choose deliberately, and to build the governance around whatever mechanism is chosen: who holds each key, under what authority they can approve, what the escalation process is, and how the whole thing is documented.

The FD’s role here is to design the authorisation hierarchy before it is needed, not after the first problem. This mirrors the approach we described in our article on building financial controls in a growing business: the time to build the framework is before the business is large enough for its absence to cause damage.

Smart Contract Governance: The Gap Nobody Discusses

Smart contracts, self-executing code that automates business logic on a blockchain, are increasingly embedded in crypto operations. They govern token distributions, automate payment flows, manage escrow arrangements, and enforce the terms of decentralised protocols. They are efficient. They can also, from a financial governance perspective, be deeply problematic, because they commit the business to outcomes encoded in code that few finance teams can read.

The FD does not need to read Solidity. But the finance function does need to understand what a contract commits the business to before it is relied upon, and to treat that understanding as a governance requirement rather than a technical afterthought. A practical set of questions to work through with whoever does understand the code:

• Is the contract upgradeable, and if so, by whom?
• Who controls the administrative keys?
• Can it be paused, and who has that authority?
• Can assets be frozen, redirected, or recovered if something goes wrong?
• Has it received an independent security audit, and what did that audit find?
• What external contracts, bridges, or oracles does it depend on?
• What financial exposure could arise from failure or manipulation?
• Who has authority to approve changes to it?

These are governance questions, and they belong in the finance function’s field of view, not solely in the development team’s. A contract that can move or freeze assets under conditions the FD has never reviewed is a financial exposure the board has not knowingly accepted.

Reconciliation: Bridging Two Systems That Do Not Speak the Same Language

One of the most persistent operational challenges for any business handling digital assets is reconciliation. On-chain activity exists on the blockchain: timestamped, immutable, and visible to anyone who knows where to look. Accounting records exist in the business’s bookkeeping system: coded, categorised, and structured for financial reporting. The two systems record the same transactions, but in fundamentally different ways, and bridging the gap requires deliberate process design.

In a bank-based environment, reconciliation is relatively straightforward. The bank statement provides an authoritative record, and matching it against the accounting records is well understood. In a crypto environment, the equivalent record is the blockchain itself, and extracting the relevant data, matching it to accounting entries, handling conversions, fees, and timing differences, and producing a reconciled position requires either specialist tools or significant manual effort.

For crypto-native businesses processing high volumes, manual reconciliation is not sustainable, and the process needs to be designed, documented, and, where possible, automated. For established businesses handling occasional crypto transactions, the volume may be manageable manually, but the process still needs to be defined: who reconciles, how often, what constitutes a discrepancy, and who reviews the output. The discipline is the same one that underpins any well-designed management information system: clean data in, reliable reporting out.

A Practical Controls Framework

Most businesses do not need to start from scratch. If you have a functioning controls framework for your fiat operations, the crypto addendum is an extension, not a replacement. The framework below is a starting point: a set of control areas and the questions each one needs to resolve. It can be scaled up to meet regulatory expectations for a crypto-native business, or kept proportionate for a business making occasional operational payments.

Working through these questions produces a crypto controls addendum tailored to the business. For most established companies, this is a focused piece of work that an experienced FD can scope and implement within weeks, not a six-month programme. The approach we take is always to design the framework around the decisions that matter and the risks that are real, at a depth proportionate to what the business actually does.

Crypto does not need a new control philosophy. It needs your existing one extended thoughtfully, with the same rigour you would apply to any other asset class, and with someone asking the hard questions before the first transaction clears.

Governance First, Technology Second

The businesses that get digital assets right are rarely the ones with the most sophisticated technology. More often they are the ones with the clearest governance. They know who controls the assets and under what model. They know who can authorise a transfer and on what authority. They know how to reconcile on-chain activity against their books. And they have someone in the finance function who designed the framework before it was needed.

If your business handles digital assets, or is about to, and your controls framework has not been extended to cover them, that is a conversation worth having. It does not need to be long. It just needs to happen before the gap becomes a problem.