From experimentation to scale: rethinking Europe’s tokenized market infrastructure

Working thesis: Scaling tokenized securities is not mainly a question of replacing existing systems with DLT. The question is which market functions genuinely require separate institutional and system boundaries, and which boundaries can safely be merged once participants share programmable state.

Europe is beginning to move beyond asking whether securities can be issued, traded and settled using distributed ledger technology. ESMA’s DLT Pilot Regime has tried out three different types of DLT market infrastructure.² The regulator’s October 2026 workshop is framed as a move “from experimentation to scale”.¹ Its first panel asks a more consequential question: from trading to settlement, should the market-infrastructure chain itself be rethought?

The question is not about “which blockchain should Europe use?” It asks where the boundaries between trading, clearing, settlement, custody and servicing should be set if several market participants can share a programmable transaction state.

The existing market and system architecture

A securities-market framework separates functions for good reasons. Each institution operates systems designed around its legal role, risk controls, and operating responsibilities. For example, trading venues execute transactions; clearing infrastructure manages obligations and counterparty risk where applicable; CSDs support settlement and securities records; and custodians maintain client positions and assets.

From a software-architecture perspective, this is a set of separately governed domains joined by interfaces. Each boundary creates integration work: messages must be mapped, identifiers aligned, failures handled, and records reconciled. While this calls for communication and cooperation between different systems, it also gives the institutions operating each domain a degree of independence. A failure or change in one domain need not automatically become a failure or change everywhere else.

The question Europe seeks to answer is whether the boundaries exist because the market needs independent control and risk management, or because historically separate systems have had no better way to coordinate.

The pilot program that compares different models

ESMA’s Pilot Regime permits three structures: a DLT multilateral trading facility (DLT MTF), a DLT settlement system (DLT SS), and a combined DLT trading and settlement system (DLT TSS). These three authorized infrastructures make materially different architectural choices, giving the Pilot three contrasting operating models to observe.³

CSD Prague’s DLT settlement system runs in parallel with its traditional settlement environment. This introduces a new settlement technology while retaining continuity and an exit path back to conventional book-entry infrastructure. Running alongside the traditional system should not be read as evidence that the dual infrastructure is the intended end-state. It is a controlled way to test DLT while preserving continuity and reversibility. ESMA explicitly describes procedures for migrating DLT-registered instruments back to traditional form if the DLT business ceases.⁴

360X illustrates another hybrid. Its DLT MTF relies on Clearstream infrastructure for issuance and settlement. ESMA notes that this creates a clear separation between the trading and settlement environments and that, in the current model, the potential benefits of DLT financial instruments are correspondingly limited.⁵

21X goes further. Its DLT TSS integrates trading, clearing and settlement on one DLT-native platform. ESMA calls the TSS a novel type of market infrastructure and suggests that lawmakers could eventually consider functional requirements focused on outcomes such as risk controls, access rights and settlement finality rather than relying only on traditional role-based distinctions.⁶

This does not mean ESMA prefers one model over another. Its own report says the comparisons are not endorsements of any particular model.⁷ But the TSS is the Pilot architecture that most directly tests whether some of today’s market boundaries remain necessary.

Mapping market structure to system architecture

The current structure can be read as a set of bounded system domains:

Trading → trade event → clearing → settlement instruction → CSD/ownership state → custody and servicing.

Each arrow is an interface contract. Developers must agree message formats, identifiers, timestamps, acknowledgements, retry behavior, and exception handling. Operational teams then need controls to detect mismatch between states on either side of the interface.

An integrated DLT design changes the shape of that problem. Trading and settlement may become state transitions inside one governed platform rather than messages between separately maintained transaction stores. That can remove an interface and some reconciliation, but it also puts more functions inside the same failure and governance boundary. If cash remains external, or another CSD or venue sits outside that platform behind another integration boundary, distributed coordination is still required.

For developers, the design question is not simply whether to use a smart contract. They need to understand where the transaction state resides, who is allowed to mutate it, which state transitions must be atomic, which events must cross boundaries, and how the system recovers when messaging fails. The market-structure decision and the software-architecture decision are two descriptions of the same boundary problem.

What would a software architect ask?

The first question should probably be: what problem requires a distributed ledger at all?

Martin Kleppmann’s general design rule is useful here: use the simplest technology that fits the problem. If a conventional database controlled by a trusted market infrastructure can provide the required consistency, scale and auditability, adding distributed consensus needs a separate justification.⁸

Clemens Vasters’ argument gives us a useful architectural starting point. He notes that features often associated with blockchain such as append-only records, cryptographic signatures and non-repudiation can also be implemented using conventional distributed systems. The implication is that DLT needs a stronger justification than the presence of these features alone.⁹ From that, we can infer a more specific test for market infrastructure: does the problem require multiple independent institutions to maintain and update shared state without assigning unilateral control to one participant? If the answer is no, a conventional architecture may be simpler. If the answer is yes, distributed consensus becomes more relevant.

That is why Richard Gendal Brown’s experience with enterprise DLT is especially relevant. Brown originally expected enterprise projects to converge on large shared networks. Instead, successful projects tended to create separately governed networks because institutions wanted control over security, privacy, upgrades and governance. His later conclusion was that interoperability between those networks becomes the next architectural problem.¹⁰

Applied to Europe, these three views produce a useful test. Ask which cross-institution boundary becomes simpler because participants share state, and whether removing that boundary creates more coupling, concentration or failure impact elsewhere.

A plausible hybrid architecture

The Eurosystem is already approaching the problem this way. Appia is examining whether a future European tokenized market should use a single shared ledger, multiple interconnected networks, or some combination. It also starts from an unusually fragmented existing market: the ECB counts 31 CSDs, 14 CCPs and 323 trading venues in the EU, while more than 95% of securities settlement volume and value in 2023 remained within the same individual CSD.¹¹

One plausible scale architecture is a hybrid model, combining integrated DLT domains with interoperable links to other DLT networks and conventional infrastructures. ECB/Appia has not selected this model; it is one inference from the options currently under examination.

In system terms, that is a design principle:

Integrate where shared state genuinely removes repeated coordination; preserve boundaries where they provide necessary legal, risk, or operational independence; standardize the interfaces between the two.

Why geographies will not all build the same market

Jurisdictions differ on who maintains the authoritative ownership record, when ownership transfers, what constitutes settlement finality, what happens in insolvency and who is accountable when automated execution conflicts with legal rights. Regulators broadly converge on principles such as market integrity, asset protection, finality and resilience, while implementing them through different institutional structures.

The same is visible outside Europe too. In the United States, under DTC’s proposed service, tokenized DTC-custodied assets are designed to carry the same entitlements, investor protections and ownership rights as their traditional form.¹² The US approach therefore looks evolutionary: tokenization is being connected to an established central-market infrastructure rather than used immediately to redraw the entire chain.¹³

Singapore is pursuing coordinated commercial networks and common infrastructure through Project Guardian and Global Layer One, explicitly covering business, governance, risk, legal and technology requirements.¹⁴ Hong Kong takes another continuity-oriented approach: its SFC says tokenized securities are fundamentally traditional securities with a tokenization wrapper and applies the principle “same business, same risks, same rules,” with additional controls for tokenization-specific risks.¹⁵

The thesis for scale

Europe’s question is not whether DLT can replicate today’s trading-to-settlement chain. The Pilot has demonstrated technical feasibility across several models. The scale question is which links in that chain no longer need to exist as separate system boundaries, without discarding the protections those boundaries were built to provide.

That gives regulators and architects a common test for every proposed change:

What existing hand-off, duplicated record or reconciliation boundary disappears if DLT is implemented? What safeguard did the old boundary provide? Where does that safeguard move in the new architecture? Does the new design reduce more complexity than it creates?

If the answer to the first question is “nothing”, tokenization may simply be another technology layer, without adding much value. If the answer is that two previously separate market functions can safely operate against the same state while preserving finality, resilience, and accountability, then the architecture begins to justify the investment.

This also explains why ESMA’s second panel turns to cash, settlement and interoperability: the next test is whether these new market domains can exchange assets, money and state reliably with everything outside them.