How tokenised collateral moves through market infrastructure

Collateral rarely moves along a single, continuous rail. A government bond pledged against a derivatives exposure may be held through a custodian, recorded at a central securities depository, valued by another service, instructed through a collateral platform and delivered into an account controlled for a clearing house. Messages, assets and cash move through different systems, often on different timetables.

Tokenisation promises to compress parts of that chain. A token can carry a programmable representation of an asset and be transferred through shared infrastructure, potentially allowing ownership, eligibility checks and settlement instructions to change together. That does not make the surrounding institutions disappear. It changes how their records and controls are coordinated.

The distinction matters because collateral is not useful merely because it is visible on a ledger. It must be legally recognisable, available to the pledgor, acceptable to the secured party, protected through custody arrangements, valued correctly and transferable with finality. If the asset and cash legs reside on different systems, their movements must also remain synchronised.

Recent work has moved beyond laboratory demonstrations. Between May and November 2024, the Eurosystem worked with 64 eligible participants across nine jurisdictions and settled almost €1.6 billion in central bank money during trials and experiments involving distributed-ledger transactions. Its detailed report records 58 completed use cases, covering activities including securities settlement, lifecycle management and collateral-related transactions. In April 2025, DTCC’s Great Collateral Experiment brought together infrastructure providers, custodians, asset managers and settlement-money initiatives to demonstrate collateral movements across different environments. These exercises show technical feasibility. They do not establish that every legal, commercial or operational dependency has been resolved.

What is actually being tokenised?

Tokenised collateral is not a separate asset class. It is an asset, or a legally defined interest in an asset, represented and managed through programmable infrastructure. The underlying collateral might be a government bond, a money-market fund unit, cash, a corporate security or another instrument permitted under the relevant agreement and risk framework.

Two structures are especially important. A digitally native security is issued directly into the new record-keeping environment. A non-native token represents an asset that already exists in another system. The second model is sometimes described as a digital twin, wrapper or receipt, although those terms can conceal materially different legal relationships.

With a native instrument, the ledger may constitute or support the authoritative ownership record. With a representation, the underlying security can remain in an account at a traditional custodian or central securities depository while a corresponding token circulates elsewhere. Transfers of the token must then remain aligned with restrictions and balances in the underlying account. Minting without locking the reference asset could create duplicate claims. Releasing the underlying asset without burning or immobilising its token could do the same.

The Financial Stability Board describes tokenisation as using technologies such as distributed ledgers to issue or represent assets as digital tokens. Its 2024 report also distinguishes discussion of digitally native instruments from representations linked to assets recorded elsewhere. The structure determines who owes what, where ownership is recorded and what a holder may recover if an issuer, custodian or platform fails.

The journey begins with issuance and eligibility

Issuance establishes the asset’s identity before it becomes collateral. For a native bond, the issuer, issuing agent or authorised market infrastructure creates the instrument, defines its terms and records the initial allocation. For a tokenised representation, an authorised party first verifies and immobilises the underlying asset, then mints an equivalent quantity of tokens under rules designed to prevent over-issuance.

The data attached to the instrument may include its identifier, issuer, denomination, maturity, governing law and transfer restrictions. Programmable controls can restrict transfers to approved participants or enforce rules associated with sanctions screening, investor status and market access. Corporate actions and lifecycle events, including interest, redemptions and substitutions, must update the tokenised record or be reliably propagated from the authoritative source.

Collateral eligibility is a separate decision. A token can faithfully represent a bond that a central counterparty or bilateral secured party will not accept. The recipient applies its own schedule covering asset type, issuer, currency, maturity, concentration, liquidity and haircut. A production workflow therefore needs dependable reference data, prices and eligibility rules, not merely a token contract.

This is one area where programmability can reduce repetitive work. A collateral instruction may query whether an asset is eligible, calculate the amount required after applying a haircut, check that it is unencumbered and reserve it for settlement. Yet each input still requires ownership, governance and an agreed fallback. An automated decision based on stale prices or an incorrect eligibility table is simply a faster operational error.

Custody still anchors control

Custody answers two different questions: who controls the technical credential and who has the legal entitlement to the asset? They may not be the same person.

A participant might hold private keys directly, use a regulated digital-asset custodian or interact through an account-based interface while the infrastructure manages keys behind the scenes. Key custody may involve hardware security modules, distributed signing or multi-party approval. These arrangements can reduce the risk that one compromised credential is sufficient to move an asset, but they introduce policies for authorisation, recovery and changes of personnel.

For tokenised representations, a conventional custodian may also hold the underlying asset. The token holder is then exposed to the legal and operational quality of the link between the on-ledger record and the custody account. Relevant questions include whether assets are segregated, whether the token represents title or a contractual claim, whether sub-custodians are involved and how insolvency would affect access.

Collateral introduces another layer: control for the secured party. Depending on the governing law and documentation, a title-transfer arrangement transfers ownership to the collateral taker, subject to an obligation to return equivalent assets. Under a security-interest structure, the provider may retain ownership while the taker obtains an enforceable interest or control. A ledger’s technical ability to freeze or redirect a token does not by itself determine which legal structure has been created.

That is why existing custody and financial-market-infrastructure principles remain relevant. IOSCO’s 2025 report on tokenised financial assets notes that self-custody can introduce distinctive custody risks, while technology and cyber risks may be amplified or materialise differently. The task is not only to keep keys safe. It is to preserve accurate entitlements, segregation, auditability and recovery across both digital and conventional records.

Settlement requires an asset leg and a money leg

Once collateral is selected, the infrastructure must transfer or perfect control over it. A delivery-versus-payment transaction coordinates delivery of the security with payment. A collateral pledge without an immediate purchase price may instead be linked to a margin obligation, a credit extension or another conditional event. In both cases, the system needs to know when the transfer becomes effective and irreversible.

When the asset and settlement money share programmable infrastructure, conditions can be bundled so that both legs complete or neither does. This is commonly called atomic settlement. The same logic can coordinate several dependent actions, such as returning existing collateral, transferring a substitute and updating the secured exposure.

Atomicity is not synonymous with instant settlement, and speed is not an unqualified benefit. Conventional netting reduces the number and value of transfers that participants must fund. Gross, near-instant settlement can lower replacement-cost exposure but require securities and cash to be available earlier. IOSCO observes that atomic settlement may reduce settlement risk while increasing the need to pre-position settlement assets. A design that saves minutes but traps more liquidity may move rather than remove the cost.

The form of money is also consequential. Settlement may use central bank money, commercial bank money, a tokenised deposit or another regulated settlement asset. Each carries a different issuer, credit profile, redemption mechanism and operating schedule. The BIS argues that bringing tokenised central bank reserves, commercial bank money and other claims into coordinated infrastructure could provide settlement finality in central bank money. This remains a blueprint rather than a universal operating model.

The Eurosystem trials demonstrate another route: interoperability between market distributed ledgers and existing TARGET Services. Transactions recorded on participating ledgers could settle their cash leg in central bank money through three interoperability-based solutions. This approach allows innovation on asset platforms without first replacing the wholesale payment system.

Legal finality is not a timestamp

A ledger may label a transaction final after a defined number of confirmations or after validation by authorised nodes. Legal finality asks a harder question: from what moment can the transfer no longer be revoked, including after insolvency proceedings begin?

The answer depends on governing law, the status of the operator, the system’s rules, the nature of the token and any applicable settlement-finality regime. Technical settlement and legal settlement can diverge. A smart contract may complete while an off-ledger legal condition remains unsatisfied. Conversely, the law may recognise a transfer even if a later technical fault requires records to be reconstructed.

The UK Digital Securities Sandbox illustrates the institutional work involved. Opened to applications on 30 September 2024, it permits approved firms to undertake specified trading-venue or central-securities-depository activities under a temporarily modified framework. The Bank of England and Financial Conduct Authority expressly addressed settlement finality and cash settlement by digital securities depositories. The Bank’s rules state that sterling cash payments must settle through accounts at the Bank of England where practical and available. Where a system lacks designation under the Settlement Finality Regulations, contractual or rulebook provisions may define finality and protect participants, but the Bank says they cannot prevent insolvency law from potentially unwinding transactions.

This does not produce one answer for every token. It demonstrates that finality must be designed across technology, contracts and public law. Market participants need to identify the authoritative record, the moment of irrevocability, the treatment of forks or reversals and the outcome if a transfer conflicts with a court order or insolvency rule.

Interoperability is a state-management problem

Collateral mobility often requires an asset to serve obligations on infrastructure other than the one where it was issued or custodied. That creates demand for connections among distributed ledgers, central securities depositories, custodians, payment systems, central counterparties and collateral-management platforms.

There are several possible patterns. A technical bridge can lock an asset on one network and create a representation on another. An infrastructure operator can maintain accounts on both systems and coordinate transfers. A common protocol can pass instructions among otherwise independent ledgers. A shared ledger can place multiple assets and participants within one governed environment. An orchestration layer can also synchronise transactions while assets remain on their original books.

Each pattern distributes trust differently. A bridge may depend on validators and smart contracts. An intermediary link introduces credit, custody and operational dependencies. A shared ledger concentrates governance and resilience requirements. Messaging standards improve semantic consistency but cannot, on their own, make assets legally equivalent or guarantee simultaneous execution.

Interoperability therefore means more than sending data. Both sides must agree on identity, asset definitions, permissions, transaction states and exception handling. They must prevent an asset from being spent or pledged twice while systems are temporarily out of sync. They also need procedures for partial completion, outages and disputes.

DTCC’s Great Collateral Experiment was designed around this fragmentation. Its participants included BNY, Euroclear, Franklin Templeton, Fnality, the Japan Securities Clearing Corporation, Société Générale and Wellington Management. DTCC reported that assets from different forms and locations were brought into a common operational model and that demonstrated settlement times compressed from hours to seconds. The result is evidence that coordinated workflows can operate in a controlled demonstration, not proof that every connected market can yet support production-scale, cross-border finality.

What greater mobility changes

Collateral mobility is the ability to identify, allocate and deliver an eligible asset where it is needed. Today, an institution may own sufficient high-quality collateral in aggregate but still face a shortfall at one venue because the asset is held in another custody chain, currency area or operating window.

A tokenised workflow can expose near-real-time inventory, reserve assets against an obligation and execute substitutions without waiting for several independent records to reconcile. That can be valuable for intraday margin calls, repo transactions and collateral optimisation. The BIS identifies repo as a natural use case because simultaneous, rapid transfer of securities and money could support intraday liquidity management.

Mobility should not be confused with reuse. Moving the same asset efficiently between approved accounts is different from allowing several parties to treat related claims as independently available collateral. Reuse and collateral chains can support market liquidity, but they also increase interconnectedness and make it harder to determine who can access an asset under stress.

Faster movement can also change behaviour. Firms may hold smaller operational buffers if they expect collateral to arrive on demand. That can release resources in normal conditions while making resilience to outages more important. A system designed for continuous transfers must therefore be assessed not only by its best execution time but by what happens when a network, oracle, custodian or payment rail is unavailable.

The operational risks move with the architecture

Tokenisation can remove reconciliations from one part of a process while creating dependencies elsewhere. The main operational risks include:

• Key and access failure. Lost, stolen or incorrectly authorised credentials can prevent or initiate transfers. Recovery controls must avoid becoming an ungoverned back door.
• Smart-contract defects. A coding or configuration error can affect many transactions simultaneously. Upgrade powers, testing, segregation of duties and emergency controls need explicit governance.
• Oracle and data risk. Prices, eligibility classifications, sanctions status and lifecycle events often originate outside the ledger. Incorrect inputs can trigger incorrect automated actions.
• Synchronisation failure. A tokenised representation can diverge from the underlying custody record, or one leg of a cross-system transaction can complete while another remains pending.
• Network and concentration risk. Shared platforms, cloud providers, bridge operators and identity services can become common points of failure across institutions.
• Operating-hours mismatch. A ledger may run continuously while custodians, payment systems, liquidity providers and support teams do not. A transferable token is not necessarily settleable collateral at every hour.
• Privacy leakage. Shared records can reveal positions, counterparties or trading patterns unless access and data design protect commercially sensitive information.
• Governance ambiguity. Participants need to know who can admit users, change code, reverse erroneous entries, suspend assets and resolve disputes.

Automation can make failures more correlated. IOSCO warns that combining automated processes across applications may leave several functions exposed to the same disruption, while automated execution can produce correlated movements of funds and liquidity demands. The FSB similarly identifies operational fragilities, interconnectedness, leverage and liquidity mismatch among the vulnerabilities that could become more important if tokenisation scales.

From demonstration to dependable infrastructure

The strongest case for tokenised collateral is not that blockchain makes collateral borderless or eliminates intermediaries. Regulated collateral cannot move independently of property law, custody, eligibility rules, settlement money and risk governance. The more credible proposition is narrower: shared programmable records can reduce the delay and uncertainty created when those functions operate through disconnected books and messages.

Progress should therefore be measured through concrete questions. Is the token the authoritative security or a claim on one? Can a recipient obtain enforceable control? Does settlement use money acceptable for the obligation? When is the transaction legally final? Can the asset cross systems without duplication? What happens during an outage, insolvency or erroneous automated transfer?

Public-sector trials and industry demonstrations have answered parts of the technical question. The next phase is institutional: aligning rulebooks, legal frameworks, operating hours, identity models, data standards and recovery procedures. Tokenised collateral becomes market infrastructure only when those arrangements remain dependable under stress, not merely when an asset moves quickly during a demonstration.