From Tokenised Assets to Tokenised Markets: What Europe Needs to Build Between the Ledgers

Aug 31

10 min read

Tokenisation is moving beyond the issuance of digital assets. The next challenge is building the legal, operational and settlement infrastructure that allows those assets to trade, move and remain enforceable across platforms.

For much of the past decade, tokenisation has been treated primarily as an issuance problem. Could a bond be represented on distributed ledger technology? Could a fund interest be issued digitally? Could collateral move on-chain? Could commercial or central bank money become programmable?

Those questions are increasingly being answered. The more difficult issue now is what happens after the asset has been tokenised.

A functioning financial market requires more than digital representation. It needs legally recognised ownership, reliable custody, access controls, settlement money, collateral arrangements, secondary-market liquidity, operational resilience and procedures for dealing with failures, corrections and exceptions.

Europe is now moving into that phase.

In August 2026, the European Central Bank described the transition as one from vision to delivery, warning that the development of tokenised finance could either support a more integrated European market or reproduce existing fragmentation across a new generation of platforms.

That distinction is becoming central to the next stage of regulatory and infrastructure design. Tokenisation can simplify financial-market processes. It can also create new silos if assets, settlement arrangements and operating rules remain platform-specific.

Issuance is only one layer of the market

Traditional financial instruments already sit within a dense legal and operational infrastructure.

There is an issuer. Ownership is recorded under defined legal rules. Transfers follow established procedures. Custody arrangements determine who holds assets on behalf of whom. Settlement infrastructure supports the exchange of securities and cash. Corporate actions, reconciliations, collateral and failed transactions are handled through established processes.

Tokenisation does not remove those functions. It changes how some of them may be performed.

Recent ECB work describes tokenised finance as a set of interconnected layers covering the underlying network, the asset recorded on that network, the services and smart contracts through which the asset is used, and the access arrangements that determine who may participate.

That points to an important distinction.

A tokenised product may exist once an asset has been successfully represented and transferred on DLT.

A tokenised market requires the infrastructure around that asset to operate with the same degree of legal certainty and operational reliability.

The relevant chain is therefore broader:

asset → ownership → custody → identity → collateral → settlement → servicing

Each connection introduces its own regulatory, legal and operational dependencies.

Growth in issuance does not yet mean market scale

Tokenised finance is expanding, but it remains small relative to conventional capital markets.

ECB analysis published earlier this year estimated that tokenised assets recorded on public blockchains had reached approximately €38 billion globally by February 2026, up from around €7.4 billion at the beginning of 2024.

The growth is significant, but secondary-market activity remains limited. That matters because issuance alone does not create liquidity.

A market may support successful digital bond issuances while still lacking deep secondary trading, efficient repo markets, interoperable custody, reliable collateral mobility or scalable settlement.

The next phase of tokenisation is therefore less about demonstrating that financial instruments can be issued digitally and more about building the infrastructure required to support them after issuance.

Settlement money remains a critical part of the architecture

A tokenised asset still needs to be paid for.

For institutional markets, the choice of settlement asset is particularly important.

One of the ECB’s central policy concerns is that tokenised markets should remain anchored in central bank money rather than become dependent on a fragmented set of private settlement assets with different credit, liquidity and convertibility characteristics.

This is the role of Pontes. Pontes is intended to connect market DLT platforms with TARGET Services, allowing the cash leg of tokenised transactions to settle in central bank money.

The significance is not limited to payment technology. The quality of settlement affects the risk profile of the transaction itself.

A tokenised security may move successfully on one ledger, but the transaction is not equivalent to traditional delivery-versus-payment if the cash leg introduces additional credit or liquidity risk.

A functioning tokenised market therefore needs both sides of the transaction to be reliable: tokenised asset + trusted settlement asset

Work such as Project Agorá reinforces the same point. The project has explored atomic settlement using tokenised central bank reserves and commercial bank deposits, demonstrating how programmable settlement could reduce some of the frictions created when asset and cash legs move through separate infrastructures.

The project remains experimental, but the policy direction is increasingly clear. Tokenised markets will need settlement arrangements that preserve the protections expected in wholesale finance.

Interoperability is becoming a legal and governance issue

The next major challenge is interoperability.

It is easy to describe interoperability as the ability of two networks to exchange data or transfer tokens. For regulated financial markets, that definition is too narrow.

Two systems may be technically connected while applying different rules to ownership, transfer restrictions, settlement finality or asset servicing.

The ECB has increasingly framed interoperability in broader terms.

Assets need to retain their legal meaning across platforms. Their rights and obligations must remain identifiable. Issuers and authorities must retain appropriate control. Transfers need to achieve operational and legal finality. Programmability must operate inside a framework that remains governable and enforceable.

This makes interoperability a combination of:

technology + identity + data + asset representation + governance + risk controls + supervision

That is a much more demanding requirement than connecting two ledgers.

Legal portability matters as much as technical portability

Consider a tokenised bond moving from one infrastructure to another.

The technical transfer may complete successfully. That does not resolve several questions that matter to regulated institutions.

Does ownership transfer at the same point under applicable law?

Does the receiving infrastructure recognise the same investor rights and issuer restrictions?

Which record prevails if the two systems diverge?

When does settlement become irrevocable?

Who bears responsibility if the technical state and the legal state no longer match?

These questions become particularly difficult in cross-border markets. A token can move between infrastructures in seconds, while the underlying legal analysis may involve different property-law concepts, settlement rules and contractual frameworks.

The policy implication is increasingly difficult to avoid:

technical interoperability without legal compatibility can accelerate transactions without improving certainty.

This is one reason why the ECB has placed legal harmonisation alongside technical standards in its work on the future tokenised financial ecosystem.

Custody becomes more complex when assets move across infrastructures

Custody is often treated as a separate component of tokenisation. In practice, it becomes more closely connected to interoperability as assets begin to move between networks.

A custodian needs to understand:

where the authoritative ownership record sits;
which wallet or account represents the client’s entitlement;
who controls the relevant private keys;
which infrastructures may be used;
how transfers are reconciled;
how corporate actions are reflected;
what happens if a network becomes unavailable;
whether client rights remain enforceable after migration to another infrastructure.

The greater the portability of the asset, the more important the portability of the control framework around it. Otherwise, technical flexibility may increase operational complexity.

Collateral provides a practical test of integration

Collateral is one of the clearest use cases for testing whether tokenised infrastructure works beyond issuance.

A tokenised collateral asset needs to be legally valid, identifiable, eligible, transferable, valued, controlled and capable of being returned or realised when required.

The ability to move a token quickly does not automatically make it usable as collateral.

Eligibility rules must recognise the asset. Ownership must be clear. Settlement must be final. Valuation must remain reliable. The receiving institution must be able to control or realise the asset if the counterparty defaults.

This is why collateral sits at the intersection of several layers of tokenised-market infrastructure.

The ECB has already begun accepting certain DLT-issued marketable assets at European CSDs as eligible Eurosystem collateral, while the Appia programme includes work on collateral management and mobility.

Collateral therefore provides a useful test of whether tokenisation is producing an integrated market rather than a series of isolated issuance environments.

Appia moves the debate from connectivity to market design

Pontes addresses an immediate settlement problem. Appia addresses the broader architecture.

The Eurosystem’s long-term objective is to develop a blueprint for an integrated European tokenised financial ecosystem by 2028.

Its scope includes interoperability, standards, central bank money, collateral, cross-border transactions, legal and regulatory arrangements, operational resilience and governance.

Importantly, the Eurosystem has not concluded that Europe must operate on one single DLT infrastructure.

A common network could reduce fragmentation and mutualise some costs.

A model based on multiple connected networks could support competition and innovation.

But the second approach places far greater weight on common standards and interoperability. Without those elements, multiple networks risk fragmenting assets and liquidity across separate ecosystems.

That makes Appia less a technology initiative than a market-architecture project.

Governance becomes more difficult at the point where systems meet

Governance is relatively straightforward to define within a single infrastructure.

It becomes more complex when several infrastructures are expected to interact.

Connected systems need common arrangements for technical standards, reference data, release management, incident coordination and operational escalation.

They also need answers to more difficult questions.

Who is responsible when a transfer is valid on one infrastructure but rejected on another?

Who may suspend an interoperable service during an incident?

How are incompatible software releases managed?

What happens when one participant follows an emergency procedure that creates a different ledger state elsewhere?

Who has access to the information required to reconstruct the event?

The Eurosystem selected 61 public- and private-sector participants for the Appia contact group in August 2026. Its work will cover user requirements and technical design, but also risk management and change and release management.

That is significant.

The infrastructure problem is no longer simply whether systems can connect.

It is whether they can remain controlled when they change, fail or disagree.

Exception handling is where production infrastructure is tested

Tokenisation is usually illustrated through the successful transaction.

The asset moves.

The payment settles.

The smart contract executes.

The ledger updates.

Production financial infrastructure also has to deal with transactions that do not follow the expected path.

A network may become unavailable during settlement.

A smart contract may behave incorrectly.

Reference data may be wrong.

A transaction may be accepted on one platform and rejected on another.

Collateral may cease to be eligible while a transaction is being processed.

A corporate action may be reflected differently across connected systems.

The legal outcome may diverge from the technical state.

Traditional financial markets have developed extensive procedures for settlement failures, reconciliation breaks, corrections, defaults and operational incidents.

Tokenised markets will need equivalent arrangements. Some may be automated.

Others will continue to require legal interpretation, escalation and human intervention.

Programmability does not remove governance. It increases the importance of defining what happens when the automated process is no longer sufficient.

Regulation also needs to move beyond the pilot stage

Europe already has a regulatory framework for DLT-based financial-market infrastructures through the DLT Pilot Regime.

But the regime was designed as a controlled environment for experimentation.

The European Commission has proposed amendments intended to make that framework more scalable, including broader eligibility and higher market-value thresholds for assets admitted to DLT market infrastructures.

Those changes remain proposals and should not be treated as final law. The direction, however, is important.

Europe is beginning to consider how regulatory frameworks designed for experimentation can support materially larger tokenised markets.

That transition raises a different set of supervisory questions.

A pilot may operate successfully with bespoke technical links and manual workarounds.

A market operating at scale cannot.

Hybrid infrastructure will remain a regulatory reality

The transition from traditional infrastructure to DLT-based markets will not be immediate.

Conventional and tokenised systems are likely to coexist for a considerable period.

This creates another source of operational complexity.

A firm may need to reconcile:

on-chain records ↔ internal books ↔ custodian records ↔ traditional market infrastructure

Different systems may operate on different timetables.

A corporate action may originate in one environment and need to be reflected in another.

Traditional infrastructure may remain authoritative for some records while DLT becomes authoritative for others.

In the short term, tokenisation may therefore add complexity before it removes it.

The operating model must govern the boundary between old and new infrastructure as carefully as the DLT environment itself.

What institutions should be testing now

Institutions assessing tokenisation projects should therefore look beyond issuance.

The more useful question is whether the operating model around the asset is sufficiently complete.

Asset and legal rights

What does the token legally represent? Where is ownership recorded? Which record is authoritative? Do rights remain enforceable when the asset moves between infrastructures?

Access and identity

Who may hold or transfer the asset? How are permissions maintained? What happens when eligibility changes?

Custody

Who controls the asset and its private keys? How are client entitlements recorded and reconciled? Can custody arrangements follow the asset across networks?

Settlement

What is the settlement asset? When is the transaction final? Is delivery-versus-payment effective in both technical and legal terms?

Interoperability

Can connected infrastructures interpret the same asset, transaction state and lifecycle event consistently?

Collateral

Can the asset be recognised, valued, mobilised and realised across systems?

Operational resilience

What happens when a network, validator, oracle, custodian, bridge or smart contract fails?

Governance

Who approves changes? Who may suspend activity? How are incidents coordinated across connected infrastructures?

Evidence

Can participants reconstruct the transaction, decision and control trail after an exception or failure?

These questions determine whether tokenisation is producing functioning financial infrastructure rather than simply a digital representation of an existing asset.

Lynsora perspective

Tokenisation is entering a more demanding phase.

Creating digital assets is becoming easier.

Building markets around them remains difficult.

The next stage will depend on whether ownership, custody, identity, collateral, settlement money, operational controls and legal finality can remain coherent as assets move across infrastructures.

Europe’s current policy direction reflects that shift.

Pontes addresses the settlement anchor. Appia addresses architecture, interoperability and governance. The proposed changes to the DLT Pilot Regime address the question of scale. But the decisive test will be operational.

Can assets move without losing their legal meaning?

Can liquidity develop without becoming trapped inside individual platforms?

Can settlement remain final across connected systems?

Can participants manage incidents and exceptions without creating new control gaps?

Tokenised financial markets will not emerge simply because more assets are placed on distributed ledgers.

They will emerge when the infrastructure connecting those assets becomes reliable enough to support regulated financial activity at scale.