Infrastructure and Compliance for Tokenisation and Digital Assets

A product conversation sitting on top of an infrastructure question

Tokenisation, representing an asset such as money, a bond, or a fund unit as a digital token on a shared ledger, gets discussed as a product and payments question: faster settlement, programmable money, new asset classes made tradeable in ways the underlying asset never was on its own. That conversation is worth having, but it skips over something that does not change just because an asset is now a token: someone still has to host the systems that talk to that ledger, secure the keys and APIs around it, and keep the whole thing compliant with the same obligations that applied before.

For regulated businesses, that infrastructure question deserves at least as much attention as the product question, because it is where the operational and compliance risk actually sits.

Friction removal, not fashion

The strongest case for tokenisation is where it removes a genuine structural friction: slow reconciliation between separate ledgers, manual settlement, or the delay between a transaction happening and the money actually moving. Where it just recreates an existing process on newer infrastructure, it is a fashion choice rather than an improvement.

A useful filter for any tokenisation proposal: does this remove friction that was genuinely costing time or money, or does it just relocate the same process onto a different stack? If you cannot name the specific friction being removed, that is worth resolving before committing infrastructure and engineering effort to it.

A token is still just a movement that needs recording

A balance is never really stored anywhere. It is derived from the history of movements that produced it, and that has been true of ledgers for as long as ledgers have existed. Tokenising an asset does not remove that discipline: whatever runs on top of a shared ledger still has to record every movement accurately, reconcile it against what actually happened, and produce an audit trail that stands up to scrutiny.

The risk worth naming is a false sense of completeness. “The ledger is on-chain” can feel like the recording problem has been solved, when it has just moved onto infrastructure your organisation may understand less well than the systems it replaced.

Tokenised and DLT-based (Distributed Ledger Technology) systems still have to meet the same obligations as any other regulated financial infrastructure. ISO 27001, FCA expectations, and UK GDPR do not have a carve-out for “the ledger is distributed.” Immutability and shared visibility are often presented as inherently trustworthy properties, and in a narrow technical sense they can be, but an audit trail only proves something useful if the controls around it are also sound: who has access, how changes are authorised, whether duties are properly segregated. A perfectly immutable record of a poorly controlled process is still a poorly controlled process, just one you can prove happened exactly as it did.

Faster settlement raises the stakes on timing, not just speed

Any transaction has more than one meaningful point in time attached to it: when value actually changed hands, when it was recorded, and when it formally settled. These are not always the same moment, and collapsing them together loses information that is often needed later, for a dispute, an audit, or simply understanding what happened and when.

Tokenisation’s central promise is that settlement can happen near-instantly. That is a genuine benefit, but it compresses the window in which a mistake has to be caught before it becomes very difficult to unwind. Faster settlement is an argument for more rigorous infrastructure discipline around timing and reconciliation, not less.

Trust the mechanism, verify the implementation

A genuinely distributed system, where no single party controls enough of it to act unilaterally, can be trustless in a meaningful technical sense. The moment something more centralised enters that picture, an issuer standing behind a token, a custodian holding the underlying asset, a single vendor’s deployment, trust shifts back onto that party specifically. At that point you are trusting an organisation, not a mechanism, and that deserves the same scrutiny as any other counterparty.

This discipline is not particular to tokenisation. It is the same “verify, don’t assume” approach that should apply to any external dependency or vendor claim. Tokenisation does not introduce a new category of risk so much as it makes an old one, trusting a party you have not actually verified, easier to overlook because the surrounding technology looks new and rigorous.

What this means practically for infrastructure decisions

Resilience and redundancy still apply, arguably more so. Faster and less reversible settlement leaves a smaller margin for error, so failover planning deserves more weight here, not less.

Reconciliation is ongoing, not a one-off. Checking that a distributed ledger matches your own internal records, and that both match reality, is a continuous discipline, the same as reconciling any other pair of systems meant to agree with each other.

Data residency and custody questions get sharper. A ledger that is shared or replicated across nodes may not sit neatly inside the jurisdictional boundary your compliance posture assumes. Knowing where the infrastructure actually is, and who else can see or hold a copy of it, matters more here than in a conventional single-vendor arrangement.

Audit trails need to satisfy two audiences at once. A regulator wants evidence controls were followed; the technology is often sold on the promise of transparency. Meeting both means the trail has to be genuinely complete and controlled, not just technically immutable.

Where we draw the lines

Applied to our own work supporting clients building tokenised or DLT-adjacent products, this produces a consistent position: the ledger being distributed does not change our approach to the infrastructure underneath it. We apply the same ISO 27001 aligned controls, the same reconciliation discipline, and the same verification of any third party or custodian in the chain that we would for any other regulated financial system. Where a client’s proposed tokenisation genuinely removes friction, we can build for it. Where it recreates an existing process with extra infrastructure and compliance overhead attached, we would state so.

Closing thought

Tokenisation is a real shift in how value can move, and the underlying technology can solve genuine problems. But a shared ledger does not host, secure, or audit itself, and the organisations that get real value from this technology will be the ones that kept the same infrastructure discipline they would apply to any other regulated system, rather than assuming the technology had done that work for them.

Key takeaways

• Tokenisation is usually discussed as a product question, but the infrastructure underneath it, hosting, security, and compliance, still has to be built and maintained regardless of how the asset is represented
• The strongest case for tokenisation is removing genuine structural friction; recreating an existing process on new infrastructure without solving anything is not an improvement
• A distributed ledger does not remove the need to record, reconcile, and audit every movement accurately, it just changes where that discipline has to be applied
• Faster settlement compresses the window for catching mistakes before they become final, which is an argument for more infrastructure rigour, not less
• Immutability and shared visibility are not the same as good controls; an audit trail only proves something if access, change management, and segregation of duties are also sound
• Wherever a centralised party, an issuer, a custodian, a vendor, sits inside an otherwise distributed system, that party deserves the same verification as any other critical counterparty

If you’re building infrastructure for tokenised assets or DLT-based products and want to talk through where the compliance and hosting obligations sit, feel free to get in touch.