Project Meridian Securities

1: Executive summary

Robust and efficient market infrastructure is essential for financial stability and confidence. As global markets adopt tokenisation and Distributed Ledger Technology (DLT) for securities settlement, the UK faces an important opportunity: to harness innovation while safeguarding trust in settlement. Achieving this balance is critical for maintaining effective and competitive securities markets.

This report presents the findings of Project Meridian Securities, a series of experiments led by the Bank of England with technical advice from the BIS Innovation Hub (BIS IH) London Centre. The project explores how synchronisation can act as a bridge between existing real-time gross settlement (RTGS) infrastructure and emerging tokenised securities settlement solutions using Distributed Ledger Technology (DLT).

The primary objective of Project Meridian Securities was to test whether a synchronisation interface can enable atomic settlement in central bank money for tokenised securities transactions, including those recorded on external DLT-based ledgers offering programmable functions. Building on insights from earlier Meridian projects, the experiments also sought to demonstrate that the synchronisation operator model is ledger-agnostic, capable of co-ordinating settlement across diverse asset classes and platforms. In doing so, the project aimed to address two critical challenges:

• Accelerating the mobilisation of collateral and central bank money to improve liquidity management and reduce settlement risk.
• Achieving interoperability between conventional systems and emerging digital infrastructures based on DLT.

To explore these questions, the experiments tested three capabilities:

• Orchestrating atomic transactions between central bank money and tokenised securities.
• Supporting automated liquidity management through programmable triggers for repurchase agreements (repos) and unwind logic.
• Enabling cross-platform settlement across multiple tokenised securities platforms to reduce fragmentation risk.

Today’s Central Securities Depositories (CSDs) underpinned by RTGS settlement in central bank money already offer an efficient infrastructure for settling securities and managing cash liquidity. Nonetheless, private sector innovation is driving the emergence of advanced tokenised securities platforms aimed at further improving in the efficiency of financial markets. For tokenised securities platforms to gain the widespread trust and adoption required to realise these benefits, they must be supported by a safe and trusted settlement asset – central bank money.

Synchronisation has the potential to support a close integration between tokenised securities platforms and central bank money. The experiments in this report have shown that this integration can enable innovative use cases in securities settlement and liquidity management, delivered in a safe and trusted manner. This innovation would unlock new functionalities for liquidity management and cross-platform interoperability, reducing operational friction and settlement risk. In turn, this could support more resilient, efficient, and competitive financial markets – reinforcing the UK’s position as a leading global financial centre.

The experiments show that synchronisation can combine the programmability of DLT, with the trust and familiarity of settling in central bank money through conventional RTGS systems, enabling a hybrid environment that supports both manual and automated transactions. This can be achieved without implementing any programmability features into the central bank money held in RTGS beyond allowing earmarking.

Specifically, the experiments highlight three transformative capabilities:

• Extending programmability to traditional infrastructures: By building on the strong foundations of existing infrastructure, synchronisation offers a practical and incremental path to innovation – one that does not require building new cash settlement systems but instead provides an effective bridge between existing settlement infrastructure and tokenised asset platforms.
• Improved liquidity management: By embedding the terms of repos and liquidity preferences into smart contracts, a synchronisation operator can enable real-time validation and settlement, reducing operational friction and improving responsiveness to intraday liquidity needs.
• Cross-platform interoperability: Synchronisation offers a practical solution for bridging diverse systems, enabling atomic settlement and liquidity co-ordination across multiple platforms.

These experiments have raised questions around the optimal architecture of a future synchronisation ecosystem, and whether the approach tested can deliver the same speed and efficiency as single-ledger systems.

Project Meridian Securities demonstrates that synchronisation can deliver significant improvements in securities settlement and liquidity management. Importantly, these experiments highlight important policy questions, including:

• how best to achieve atomic settlement and interoperability across multiple tokenised securities platforms;
• how to balance operational efficiency with flexibility in liquidity management; and
• what architecture and governance model best support synchronisation operators and market scalability.

Addressing these questions will be critical as the UK explores the next generation of its financial market infrastructure, through initiatives such as the Digital Securities Sandbox (DSS), the forthcoming Synchronisation Lab, and the Bank’s broader programme of wholesale payments experiments.

The findings from these experiments lay the groundwork for further exploration of synchronisation models and their role in supporting next-generation settlement systems. This ensures innovation continues to support safe, effective, and resilient financial markets.

2: Background

Private sector innovation is uncovering new technologies and business models – such as tokenised assets and deposits, stablecoins and digital platforms – that have the potential to transform how financial markets operate. Realising this potential requires collective action to improve our wholesale payment systems – the infrastructure that settles large value transactions between financial institutions. Across jurisdictions, the drivers are clear. In securities markets for example, features such as Delivery versus Payment (DvP) functionality and programmability can enable institutions to mobilise cash and collateral more efficiently and securely across multiple platforms.

While these innovations promise significant benefits, they also raise a fundamental question: how can we use tokenisation to overcome the persistent challenges in securities settlement today such as operational friction and settlement risk, while preserving the trust in money that underpins those markets.

One answer lies with settlement in central bank money, which provides a key foundation of trust and stability for existing financial market transactions. Connecting central bank money within innovative asset solutions is essential to unlock their full potential, ensuring confidence in their resilience and safety. Further background to this is set out in our approach to innovation in money and payments.

In response to private sector innovation, central banks and public authorities are exploring new approaches to improve the payments infrastructures they operate to ensure they continue to meet the changing needs of the users. One approach is synchronisation, which uses earmarked central bank funds to co-ordinate the movement of funds and assets across ledgers so they are completed atomically. An alternative option would be a unified ledger, where both assets and payments are settled on the same platform, potentially supported by a wholesale Central Bank Digital Currency (wCBDC). Both solutions aim to reduce settlement risk, improve cross border settlement, and prepare critical market infrastructure for the future by addressing the limitations of legacy systems. This is further described in Wholesale central bank money in the context of technological innovation published by BIS.

Our wholesale experiments programme – announced in our discussion paper, The Bank of England’s approach to innovation in money and payments – is designed to explore and compare emerging models for settling wholesale payments. This programme aims to understand if planned enhancements to our infrastructure can sufficiently support new wholesale payment needs and innovative use cases, or if any further innovation – such as new RTGS features or a wCBDC – will be needed. The programme is focusing on two areas.

• Further experimentation with synchronisation, by exploring additional use cases and running experiments in environments closer to live operation.
• Assessing whether wCBDC offers meaningful advantages over synchronisation (and other planned RT2 enhancements such as extended settlement hours), particularly in terms of programmability, liquidity management, and cross border interoperability.

The programme is designed to generate actionable insights to inform our decisions on future settlement infrastructure. This paper examines the first area, exploring synchronisation use cases for tokenised securities.

Synchronisation: from concept to delivery

Synchronisation is a new RTGS capability designed to give payment infrastructures an innovative way to access settlement in central bank money that we are developing in a close partnership with industry. In response to our 2022 consultation on the Future Roadmap for RTGS, industry indicated a clear appetite for this to be one of the enhancements prioritised by the Bank.

Now we have completed delivery of a renewed RTGS service, RT2, the foundational capability to deliver a synchronisaton service is available and we are now transitioning towards the delivery stage, with a Synchronisation Lab planned for 2026. The Synchronisation Lab will provide a non-live environment for potential synchronisation operators to test their flows within the RTGS synchronisation functionality. The Synchronisation Lab will serve as a collaborative environment for testing how synchronisation operators – third parties that orchestrate synchronised transactions by connecting key actors – could be integrated into existing financial market infrastructures. The intention is to fold the insights from this Lab into a live synchronisation service that we hope to make operational in 2027.

Over the last two years, we have been running a set of focused experiments in collaboration with industry and international partners to assess the potential of synchronisation:

• Project Meridian, a joint project by the Bank of England and the BIS IH London Centre, demonstrated how a synchronisation operator could orchestrate atomic transactions involving both funds and assets, using housing transactions as a test case. The synchronisation operator acted as a bridge between the RTGS system, enabling more automated and transparent settlement processes. The project showed that a simple interface into RTGS could support sophisticated synchronisation functionality, with potential applications also extending to a variety of asset classes.
• Building on this, Project Meridian FX extended the experimentation on the synchronisation concept to foreign exchange (FX) transactions. This initiative involved the Bank of England, BIS IH London and European Centres, European Central Bank (ECB), Banque de France, Banca d’Italia, and the Deutsche Bundesbank. It successfully demonstrated that wholesale payment infrastructures – such as RTGS systems – can settle atomically across jurisdictions. The project connected an emulated UK RTGS system, with a synchronisation interface, with three experimental Eurosystem solutions (DL3S, TIPS Hash-Link, and the Trigger Solution), enabling payment-versus-payment (PvP) FX settlement. Project Meridian FX showed that synchronisation could help reduce FX settlement risk and improve liquidity management.

Ahead of the launch of our Synchronisation Lab, we are prioritising experiments on tokenised securities. Securities markets are undergoing rapid innovation and offer substantial scope for improvements – particularly for issuance, trading and settlement. To support this, we have already introduced initiatives in this space. The Digital Securities Sandbox (DSS) – run by the Bank of England and the Financial Conduct Authority – provides a regulatory environment for firms to test new use cases for digital securities under modified regulatory conditions, enabling real-world activity while safeguarding financial stability.

The experiments carried out as part of Project Meridian Securities will help us assess how central bank money could be integrated into emerging models for settling digital securities. The focus is on understanding how the existing RTGS infrastructure and a future synchronisation interface can support these developments effectively.

Securities settlement use case

Securities settlement today relies on a mix of centralised infrastructure and bilateral co-ordination, typically on a DvP basis. These systems span multiple platforms (trading venues, CSDs, Central Counterparties (CCPs), RTGSs, etc) and have been shaped by decades of collaboration between central banks, market infrastructures, and financial institutions. As a result, they are trusted, resilient, and represent the state of the art in conventional settlement design. However, they face structural constraints, such as fragmented liquidity, multi-day settlement cycles and manual processes, which can introduce delays and operational risk.

Our initial engagement with industry stakeholders has highlighted specific pain points, particularly in processes such as intraday repo and collateral substitution. These challenges underscore the opportunity for innovation to streamline and modernise settlement workflows. Key inefficiencies include:

• Intraday liquidity constraints, driven by the difficulty of mobilising and substituting certain collateral quickly and efficiently.
• Limited interoperability between some asset ledgers and cash settlement systems, particularly where DLT is involved.

Tokenised assets offer significant potential benefits, including faster settlement, improved transparency and greater programmability and are expected to become increasingly mainstream as adoption accelerates. A global survey conducted by State Street in October 2025, covering 324 institutional investors, revealed that the majority anticipate their digital asset exposure will double within three years, with over half expecting 10%–24% of their investments to be tokenised by 2030. Similarly, a 2025 survey by the Value Exchange, in partnership with the International Securities Lending Association, the International Swaps and Derivatives Association, and the International Securities Services Association, revealed that 94% of the 203 firms sampled believe that tokenisation will improve collateral mobility, while 30% identified repos as the highest-priority activity for tokenisation.

The DSS supports the exploration of tokenisation use cases on the asset side by providing a controlled environment for firms to develop and test tokenised financial instruments. As these innovations gain momentum, we are committed to adapt our infrastructure to support and scale them through different settlement models, as outlined in our DSS policy statement.

Tokenised markets, however, also require suitable cash settlement assets to function effectively. To address this, we are exploring synchronisation as a complementary solution, offering a safe and efficient way to settle across diverse platforms.

How synchronisation can help

Synchronisation offers a powerful settlement model that links the movement of central bank money with asset transfers across different ledgers. It enables atomic settlement – where both legs of a transaction occur simultaneously or not at all.

In the context of digital securities settlement, synchronisation could:

• Support new forms of intraday secured lending using central bank money, enhancing and automating liquidity mobilisation.
• Enable programmability, allowing settlement conditions and preferences to be embedded directly into transaction workflows.

Synchronisation can improve efficiency by supporting DvP RTGS transactions, reducing the reliance on intermediaries and manual reconciliation typically required for central bank money settlement. It could also reduce the need for financial institutions to set aside additional cash or collateral to manage settlement risks such as timing mismatches or operational errors. By reducing the need for this cash or collateral to be set aside, synchronisation could enable institutions to use their resources more efficiently.

Crucially, our model of synchronisation builds on existing RTGS infrastructure, offering a practical and cost-effective path to innovation. A generic synchronisation interface into RTGS allows third-party operators to orchestrate settlement without holding funds. Synchronisation operators act as neutral co-ordinators to ensure atomic settlement across multiple ledgers, reducing fragmentation and settlement risk. Their functions can range from basic orchestration of cross-platform transactions to advanced roles such as liquidity management, smart contract execution, and compliance monitoring. This supports a more diverse ecosystem – including smaller firms and fintech, while aligning with our objective of maintaining broad access to central bank money.

3: Project Meridian Securities objectives

The primary purpose of Project Meridian Securities is to test whether a synchronisation interface can enable atomic settlement in central bank money for transactions involving tokenised securities – specifically, those recorded on external financial ledgers based on DLT that offer programmable functions.

Project Meridian Securities builds on the technology and insights developed in Projects Meridian and Meridian FX. It tests the hypothesis that the synchronisation operator model is agnostic to both the type of asset being transacted and the underlying ledger technology. This means the synchronisation should be capable of co-ordinating settlement across diverse asset classes and platforms.

To fulfil that primary purpose, the project must achieve certain objectives.

This first objective addresses two key challenges:

• Accelerating the mobilisation of collateral and central bank money, enabling more efficient liquidity management and reducing settlement risk;^{footnote [1]}
• Achieving interoperability between systems based on conventional technology and emerging digital infrastructures based on DLT.

This includes:

• Using time-based triggers (eg, time locks, smart contracts) to initiate atomic settlement at predefined intervals or deadlines.
• Using conditional triggers activating settlement based on real-time liquidity conditions, such as an automated repo when a shortfall is detected on RTGS accounts.

This includes allowing users to source liquidity via a repo transaction on one platform to facilitate a securities payment on another, with both payments linked and settled atomically.

4: Experiment design

An experimental environment was developed to test how atomic settlement could be achieved across systems that do not natively interoperate. The project sought to fulfil its objectives via four experiments using the following emulated systems:

• a TSP operating a DLT environment; and
• a RTGS system emulating the planned synchronisation capability being developed for the Bank of England’s RTGS featuring an earmarking capability.

TSP – design and key functions

A simulated version of a tokenised securities platform, referred to as a TSP, was developed. It mimics the role of a traditional CSD that carries out settlement functions related to transferrable securities such as government bonds. Similar to a conventional CSD, this entity operates a securities settlement system, but for tokenised securities. This TSP operates a DLT, which means that instead of securities being recorded in a central location, they are represented as digital tokens on a network that multiple parties can access and verify in real time. Similar models are being piloted elsewhere – for example, there are strong parallels between TSPs and the Digital Securities Depositories (DSDs) being trialled in the DSS,^{footnote [2]} and with the DLT Settlement Systems being developed under the EU DLT Pilot.

What makes this system particularly innovative is its use of smart contracts – automated digital agreements that can carry out instructions like transferring ownership or paying dividends without manual intervention. This allows for greater efficiency, transparency, and flexibility in how securities are managed and settled.

In this experiment, the TSP also carries out the activities of the synchronisation operator – for example, sending earmark requests to RTGS to earmark funds for synchronised settlement. This is a different approach compared to the earlier Meridian FX experiment.

Previously, the synchronisation operator functioned as a third-party orchestrator, responsible for managing conditional settlement across multiple RTGS systems. The operator achieved this by interacting directly with each RTGS system to earmark the necessary funds and subsequently release them, only after confirming that all pre-defined settlement conditions had been satisfied.

Given that prior projects successfully demonstrated that an independent synchronisation operator model could ensure atomic settlement, we adopted a dual role. The synchronisation operator would also host a tokenised asset platform to test alternative synchronisation models.

However, in a real-world implementation, these roles could be separated. The synchronisation operator could act as a neutral orchestrator, co-ordinating settlement across multiple platforms and participants, while securities settlement infrastructures (such as CSDs, DSDs or other securities registries) might be responsible for the settlement of the securities. This separation supports operational independence – especially in multi-party or cross-border contexts – and could support regulatory clarity, subject to further work around a potential regulatory regime for synchronisation operators.

The modelling choice allowed the experiment to focus on the technical feasibility and benefits of synchronised, programmable settlement, while acknowledging that real word implementation might require additional considerations about a potential role separation and governance.

The TSP has been modelled using a bifurcated architecture, with processes divided between ‘on chain’ and ‘off chain’ components. This division needed for the TSP to bridge the tokenised platform it operates, and the more traditional infrastructure it interfaces with. On chain processes refer to operations executed within the DLT, while off chain processes are handled by conventional application logic outside the DLT.

Figure 1: Tokenised Securities Platform: on chain and off chain components

On chain components (Figure 1)

• Tokenised securities: Either tokenised representations of real-world financial instruments (eg bonds, equities) or digitally native assets issued and managed directly on DLT. These assets are governed by smart contracts that define their lifecycle, ownership, and transfer rules.
• User wallets: Allowing users (RTGS account holders) to set programmable logic that enables the creation and automation of repurchase agreements.

Off chain components (Figure 1)

• Communication logic: Handles interactions between the DLT and external systems, such as RTGS platforms or other financial infrastructure. It enables synchronisation, messaging, and orchestration of settlement processes that cannot be executed natively on chain.
• User interface: The front-end application through which users interact with the system. It provides access to account information, transaction history, and configuration of parameters (eg repo rates), while abstracting the complexity of underlying blockchain operations.

RTGS emulator

In addition to the ‘TSP’, this experiment incorporates an emulated RTGS system, jointly developed by the Bank of England and the BIS Innovation Hub London Centre as part of Project Meridian FX. This RTGS emulator provides core functionality for funds reservation and transfer between hypothetical RTGS accounts, enabling the simulation of synchronised settlement flows.

The emulated RTGS system supports key features such as:

• Earmarking of funds for conditional settlement,
• Real-time balance updates,
• Interoperability with external systems, including DLT-based platforms like the ‘TSP’.

5: Experiments conducted

To assess the potential of synchronisation in bridging traditional settlement systems and tokenised platforms, Project Meridian Securities conducted four experiments.

• Atomic settlement of tokenised securities: Demonstrated the ability to execute Delivery-versus-Payment (DvP) transactions in central bank money for tokenised securities, validating the core principle of atomic settlement.
• Intraday repo execution: Simulated collateralised credit facilities between commercial banks using smart contracts to automate eligibility checks, collateral allocation, and settlement – showcasing how automation can streamline repo processes and enhance intraday liquidity management.
• Programmable liquidity management: Explored advanced features such as auto-repo and auto-unwind, enabling participants to embed liquidity preferences directly into RTGS accounts. Smart contracts triggered transactions based on predefined conditions, reducing operational friction and improving responsiveness to liquidity shortfalls.
• Multi-TSP co-ordination: Tested synchronised settlement and liquidity optimisation across multiple TSPs, addressing fragmentation risk and enabling banks to dynamically source liquidity and execute atomic DvP transactions across platforms.

Security purchase

We started by simulating the settlement of a purchase of a security by a commercial bank in central bank money, assuming that the terms of the security purchase have been previously agreed between the counterparties.

The commercial bank – who is an account holder in RTGS – initiates the purchase by entering the details in the TSP interface. The security is then escrowed, and a notification is sent to RTGS to earmark the necessary funds for the transaction.

RTGS confirms the earmarking of funds, and the TSP proceeds to transfer the ownership of the security from the seller to the buyer. This transfer is recorded on the distributed ledger. The TSP then sends a confirmation message to both the buyer and the seller, indicating that the transaction has been successfully completed.

Figure 2: Security purchase – overview

Transaction steps – security purchase (Figure 2)

Step 1 – end user requests sale: counterparties agree upon transaction details, and the seller requests a transfer from the tokenised securities platform (TSP).

Step 2 – earmark/reservation: the TSP escrows bond(s) from the seller and asks that RTGS earmarks (or reserves) funds from the buyer.

Step 3 – settlement: the TSP transfers bond(s) to the buyer and asks RTGS to settle the earmarked funds.

In our set-up, the escrowing process is a technical mechanism used to temporarily hold securities during a transaction. Importantly, this does not involve a transfer of ownership. Instead, the securities are placed in a controlled state – similar to a suspense account in traditional cash systems – where they are isolated from the seller’s wallet but not yet transferred to the buyer. This ensures that the assets are securely reserved for settlement without prematurely changing hands. Escrow acts as a safeguard, allowing the system to verify that all conditions for settlement are met (eg funds earmarked in RTGS) before completing the transaction. This approach supports atomic settlement and reduces the risk of failed or partial transfers.

Intraday repo creation

This experiment simulates an intraday repo between two commercial banks in central bank money. The repo functions as a collateralised credit facility, enabling secured access to liquidity within the day. In this model, both counterparties have previously entered into a legal agreement outlining the terms of the repo, including eligible collateral, interest rates, haircuts, limits, and other relevant conditions. This setup reflects a realistic bilateral arrangement, while allowing the experiment to focus on the technical feasibility of automating repo flows using DLT.

To initiate the intraday repo, it is assumed that the repo seller – who is borrowing central bank reserves – and the repo buyer – who is providing those reserves – have already agreed on the transaction terms. These terms are then encoded into a smart contract owned by the repo buyer.

Figure 3: Intraday repo creation – overview

Transaction steps – intraday repo creation (Figure 3)

Step 1 – end user requests repo: counterparties agree upon repo details, and the repo seller requests a repo from the TSP – this specifies the securities to be pledged as collateral, the amount to be borrowed, the selected counterparty, and the intended duration of the repo.

Step 2 – seller validation: the TSP validates that the report meets the standards/conditions defined in the buyers’ smart contract. This validation ensures that the seller is authorised to transact, that the proposed transaction falls within the facility’s usage limits, and that the pledged securities meet the eligibility criteria. The smart contract also contains the applicable repo rate and haircut schedule offered by the buyer.

Step 3 – earmark/reservation: once validated, the TSP escrows the pledged securities from the repo seller’s wallet, and ask RTGS to earmark (or reserve) funds from the buyer.

Step 4 – settlement: once the earmark has been successfully placed, the TSP transfers the escrowed securities to the repo buyer and asks RTGS to settle the earmarked (or reserved) funds.

Intraday repo unwind

The closure – or unwind – of a repo transaction refers to the return of collateral to the repo seller and the repayment of funds (plus interest) to the repo buyer. This process marks the end of the repo lifecycle and restores the original asset and cash positions of both parties.

Figure 4: Intraday repo unwind – overview

Transaction steps – intraday repo unwind (Figure 4)

Step 1 – end user requests unwind: when desired, the repo seller asks the TSP to unwind the repo transaction

Step 2 – earmark/reservation: the TSP validates that the repo is active and eligible for closure and then escrows securities from the repo buyer, and asks RTGS to earmark/reserve the repayment amount from the seller

Step 3 – settlement: to complete the repo unwind, the TSP transfers securities to the repo seller and asks RTGS to settle the earmarked/reserved funds.

The process ensures that both legs of the transaction – collateral return and cash repayment – are executed in a synchronised and atomic manner, reducing settlement risk and maintaining operational integrity.

Alternative scenario – time triggered unwind (scheduled)

In addition to seller initiated unwinds, the unwind process can be configured to occur automatically at a set time during trade creation.

• The initiator specifies a fixed intraday term (eg five hours) in the TSP request; the TSP records an expiry timestamp and an unwind instruction linked to the repo.
• At expiry, the TSP initiates the unwind by validating eligibility, escrowing the securities from the buyer’s wallet and instructing RTGS to earmark the repayment amount (principal plus accrued interest) in the seller’s account.
• Once both confirmations are received, the TSP completes settlement atomically, restoring the original asset and cash positions. If preconditions are not met at the scheduled time (eg, insufficient funds or securities unavailable), the instruction fails safely without partial settlement, after which policy defined behaviours (such as a grace period, retry window or fallback to manual instruction) can apply.

Programmable repo agreements

This experiment explores how programmable logic can be applied to repo agreements to automate liquidity management in RTGS systems.

In this context, ‘auto-repo’ refers to the automatic initiation and unwinding of repo transactions based on pre-configured liquidity preferences set by RTGS account holders. The goal is to allow participants to programmatically access high quality liquidity – central bank money – without manual intervention, enhancing both operational efficiency and responsiveness to intraday liquidity needs.

Today, intraday liquidity is typically provided through:

• the Bank, via CREST, through repo transactions backed by assets held directly with us; and
• CSD auto-repo services, like the one offered by CREST for instance. In a CSD, the auto-repo is limited in scope to supporting settlement activity within the CSD itself.

This experiment explores how similar functionality could be extended to assets held at other institutions, using programmable auto-repo facilities. In this model:

• intraday liquidity could also be provided by other eligible participants operating standing repo facilities.
• These facilities would be governed by smart contracts and bilateral agreements, enabling automated collateralisation and liquidity provision across a broader range of asset locations. RTGS account holders wishing to access liquidity through this facility would configure their preferences directly within the RTGS system. These preferences would include thresholds for minimum and upper preferred account balances, the minimum repo transaction size and which TSP and buyer should be used for an auto-repo.
• Once configured, the RTGS system could continuously monitor account activity and send a message to the synchronisation operator that would initiate repo transactions automatically when conditions are met, providing timely access to liquidity without manual processes.

Unlike traditional intraday repo arrangements, the auto-repo workflow is fully automated and governed by smart contracts deployed on the TSP. These smart contracts define the operational parameters of a standing repo facility, including eligible counterparties, acceptable collateral types, haircut schedules, and applicable repo rates.

By allowing participants to source liquidity from the market, this solution supports the mobilisation of a broader range of securities, and potentially more dynamic and efficient repo pricing. The programmable auto-repo model described above is capable of providing liquidity for a wider range of use cases, as it is not restricted to assets or transactions within a single settlement platform.

Figure 5: Automatic intraday repo triggered by shortfall in RTGS balance – overview

Transaction steps – automated repo triggered by shortfall in RTGS balance (Figure 5)

Step 1 – RTGS requests repo: upon receipt of an earmark request which would move the account balance below the minimum balance set, RTGS will request a repo from the TSP to source the full amount of the earmark/reservation.

Step 2 – seller validation: TSP validates that the report meets the buyers’ standards.

Step 3 – earmark/reservation: TSP escrows securities from the repo seller and asks RTGS to earmark/reserve funds from the buyer.

Step 4 – settlement: TSP transfers securities to the repo buyer and asks RTGS to settle the earmarked/reserved funds.

Figure 6: Automatic repo unwind – overview

Transaction steps – automatic repo unwind (Figure 6)

Step 1 – RTGS requests unwind: upon receipt of funds that would take the account above the maximum balance set, RTGS will ask for all outstanding repos associated with the account to be unwound by the TSP.

Step 2 – earmark/reservations: the TSP escrows securities from the repo buyer, and asks RTGS to earmark/reserve funds from the seller.

Step 3 – settlement: the TSP transfers securities to the repo seller, and asks RTGS to settle the earmarked/reserved funds.

To minimise the cost of holding repo positions for sellers, it is desirable for these transactions to be unwound as soon as excess liquidity becomes available. The auto-unwind feature enables the RTGS system to actively manage this process by monitoring account balances against user-defined liquidity thresholds.

This process allows liquidity to be returned promptly, reducing the duration of repo exposure and associated costs for the seller. The unwind operation is fully automated and does not require manual intervention, supporting more efficient intraday liquidity management.

Liquidity management across multiple TSPs: chained DvP transactions

In this experiment, we explore how transactions can be co-ordinated across multiple TSPs, demonstrating the potential for synchronised settlement and liquidity optimisation across different financial infrastructures. In particular, we look at co-ordinating a DvP securities purchase (Asset DvP), against a DvP repo transaction used to fund that initial purchase (Repo DvP).

Asset DvP: The process begins when an asset buyer (repo seller), who is an account holder on RTGS, places an order to purchase a security X listed on TSP1. However, they lack sufficient cash in RTGS and do not hold repo-able securities on TSP1 to support the transaction as described in the previous programmable securities use case experiment. Following the initiation from the asset buyer, TSP1 earmarks the desired securities to reserve them for the participant. Earmarking messages are sent to the RTGS system to reserve the necessary funds, preparing for synchronised settlement.

Repo DvP: After detecting the cash shortfall, the RTGS system signals to TSP2 (previously set-up as another preferred counterparty for generating liquidity) that a repo transaction is required to generate liquidity. In response, TSP2 identifies and earmarks suitable security Y to serve as collateral for the repo. Once the repo is executed on TSP2, the required cash is transferred from the RTGS account of the repo buyer on TSP2 to the repo seller’s (asset buyer’s) RTGS account.

This enables the original purchase, the Asset DvP, on TSP1 to proceed. With both the cash and securities earmarked, the transaction is completed: security X is transferred to the asset buyer (repo seller), and the earmarked funds are released to finalise the settlement.

Figure 7: Auto-repo for DvP – overview

Transaction steps – auto-repo for DvP (Figure 7)

Step 1 – Asset DvP initiated on TSP: a buyer and seller submit instructions for a DvP transaction into TSP.

Step 2 – Reservations: the asset platform reserves the asset, and requests the RTGS to place a reservation.

Step 3 – Reservation failure: the asset buyer has insufficient funds for the transaction.

Step 4 – Repo initiation: the RTGS requests the TSP to place an ‘auto-repo’ to source liquidity.

Step 5 – Reservation (repo): the TSP earmarks/reserves the asset and RTGS reserves funds.

Step 6 – Settlement (repo): the TSP settles the asset and RTGS settles funds.

Step 7 – Reservation: with the new funds, the RTGS places a reservation.

Step 8 – Settlement: the asset platform settles the asset and RTGS settles funds.

6: Key insights

This section summarises the key insights from the experiments. It is important to stress that this work is exploratory. Its findings will contribute to the wider discussion on the future of settlement infrastructure; and will inform the Bank's strategic thinking and progress towards delivering a live synchronisation capability for RT2.

The successful implementation of synchronisation mechanisms would require active involvement from private sector firms acting as synchronisation operators, and appropriate operational, regulatory and legal frameworks.

The experiments described above successfully demonstrated that synchronisation mechanisms can support both manual and automatic execution of repo transactions in a hybrid environment combining DLT-based securities settlement systems with a RTGS system based on conventional technology. By embedding bilateral repo terms and liquidity preferences into smart contracts, the system enabled real-time validation and execution, significantly reducing the need for manual intervention. The findings highlight that this model offers high automation, little operational friction, and responsiveness to intraday liquidity needs. Importantly, by building on RTGS, organisations can retain existing infrastructure while layering in synchronisation logic to enable atomic settlement and programmable liquidity management – supporting a gradual transition toward enhanced financial market infrastructure that accommodates both established and emerging technologies.

Extending programmability to traditional infrastructures and supporting innovation

The experiments demonstrated that repo creation and unwind can be automated using time triggers or pre-configured liquidity thresholds, without requiring all components to operate on the same ledger or technology stack. Smart contracts embedded in the TSP enabled real-time validation of eligibility, collateral, and pricing, streamlining the end-to-end transaction flow.

Crucially, this shows that programmability is achievable even in heterogeneous environments, where legacy systems and newer platforms coexist. Rather than replacing existing infrastructure, synchronisation logic can be layered on top, enabling automation and conditional execution without the need for infrastructure redevelopment. By building on existing infrastructure, financial institutions are able to modernise their securities settlement and liquidity management processes at speed, underpinned by the trust and safety of central bank money. This approach supports cost-effective innovation, allowing institutions to modernise while preserving the reliability and regulatory familiarity of existing systems.

Improved liquidity management

Liquidity preference configurations allowed for automatic adjustment of liquidity provisioning based on account balances and transaction flows. This supports more responsive intraday liquidity management, tailored to individual account needs.

While the liquidity management experiment did not explicitly explore cost optimisation, the architecture suggests potential for dynamic matching between buyers and sellers based on cost preferences, which could enable more efficient repo pricing and reduce liquidity fragmentation. This potential is fundamentally a data-driven capability: by collecting and analysing real-time data on participants’ cost preferences, transaction histories, and available liquidity, a TSP could automatically pair buyers and sellers whose requirements align most closely. Smart contracts play a central role in this process. They allow trade terms to be programmed and executed automatically, enabling near-instant validation, settlement, and adjustment as market conditions evolve.

However, the experiment also highlighted limitations – particularly the repo initiator’s (in this experiment, RTGS) lack of visibility into outstanding repo positions. Without the ability to monitor active repo transactions in real time, the RTGS cannot effectively manage exposures or assess liquidity across the system. This information gap may complicate risk management and hinder efficient liquidity allocation.

In today’s traditional arrangements, a CSD typically oversees both the securities and the associated cash legs of a transaction. This dual visibility allows the CSD to co-ordinate the end-to-end settlement process, ensuring that securities transfers and corresponding cash payments are matched and executed simultaneously. Achieving similar oversight in a synchronised environment will require proportionate data sharing and effective co-ordination between systems.

A possible area for future exploration could involve testing additional functionality in the synchronisation interface that would allow synchronisation operators and RTGS systems to exchange queries on cash and securities balances. In theory, this could enable a liquidity optimiser to access the information needed to manage liquidity across all of an institution’s accounts, supporting more effective liquidity management and providing greater interoperability across multiple tokenised securities accounts. This concept, however, remains exploratory and would require careful consideration of technical complexity, governance, and operational implications.

Interoperability and scalability

The experiment used a combined TSP/synchronisation operator model, raising important questions about how this architecture would work in a multi-platform environment. In a future ecosystem with multiple TSPs and tokenised asset platforms, a neutral synchronisation operator may be preferred to co-ordinate across ledgers and maintain consistent settlement logic, reducing fragmentation risks where asset platforms compete with limited interoperability.

Synchronisation might offer a practical alternative to the unified ledger concept, enabling atomic settlement and liquidity co-ordination across diverse systems without full integration or uniform technology.

A key question, however, remains – can synchronisation mechanisms match the speed and efficiency of unified ledger models, particularly under high volume conditions involving thousands of transactions in rapid succession. Testing performance at scale will be critical to ensure that interoperability does not come at the expense of throughput or operational resilience.

7: Potential areas for further exploration

Our wholesale experiments programme has been designed to answer a fundamental question: how can the Bank support new and efficient forms of settlement using central bank money, to harness the real-world benefits these settlement mechanisms bring and meet the changing needs of industry? This includes assessing whether enhancements to RTGS – such as synchronisation – are sufficient, or whether a wCBDC would provide additional flexibility and resilience that would be desirable to participants.

The Meridian Securities experiment provided initial insight by testing synchronised settlement in a simplified environment with tokenised securities hosted on DLT platform(s), and central bank money held separately on RTGS. We are yet to explore more complex configurations, where both cash and assets are held on chain, incorporating various forms of cash such as a wCBDC and potentially involving multiple DLT platforms. These experiments could help assess how interoperability between DLT-based ledgers might support liquidity management and whether liquidity generation can be streamlined based on participant preferences.

We also plan to further explore synchronisation by extending Project Meridian FX with the Monetary Authority of Singapore and the Bank of Thailand. This will enable experimentation in an environment that more closely mirrors live conditions. The next phase will test synchronised FX settlement across a range of ledger configurations, helping to evaluate how synchronisation interfaces can support evolving industry requirements. Operating within a more complex and realistic cross-border context, the experiment aims to generate deeper insights into the liquidity, interoperability, and operational benefits of synchronised settlement.

Finally, our Synchronisation Lab will, when launched in 2026, provide an avenue for industry to engage directly with the concepts explored in this paper. Operating as a non-live environment, the Lab will enable participant firms to test settlement flows involving digital securities and sterling central bank money using synchronisation. For participants in the DSS, the Synchronisation Lab offers a pathway to explore synchronised settlement of digital-security transactions in sterling central bank money. While not a regulatory sandbox, the Lab complements other innovation initiatives by enabling firms to assess how synchronised settlement could be integrated into their use case designs.

Annex

• Annex: Open questions for implementation

  Having TSP and synchronisation operator as the same organisation versus separate organisations

  The experiment adopted a simplified architecture by combining the TSP and the synchronisation operator into a single entity. This design choice reduced messaging complexity and streamlined the transaction flow. However, it raises important questions about interoperability in a future ecosystem where multiple TSPs may operate across different asset classes. In such a scenario, banks would need to maintain relationships with multiple synchronisation operators, potentially increasing operational overhead. A separate, neutral synchronisation operator could offer a more scalable solution by co-ordinating across diverse asset ledgers. The synchronisation model we are developing for RTGS is flexible in that respect and would support both approaches – either combined or separate entities. This will allow market participants and system designers to select the arrangement that best fits their operational needs and ecosystem requirements.

  Auto-repo design

  The experiment adopted a specific approach to auto-repo design by introducing a minimum transaction threshold (eg, £100,000) for auto-repo operations. This threshold was intended to prevent operational inefficiencies caused by frequent, small-value repos, thereby ensuring that liquidity top-ups are meaningful and system activity is optimised.

  Another key design choice was the logic for determining the auto-repo amount. The experiment triggered repos based on the full transaction value that would breach the minimum balance, rather than sourcing only enough liquidity to restore the minimum. This approach reduces the likelihood of repeated, immediate repos but may result in larger, less frequent liquidity injections. Conversely, a more granular approach could offer finer control but at the cost of increased system activity and potential operational burden.

  The final design choice for auto-repo initiation was the decision to trigger the check for liquidity needs only upon receipt of an earmark request. In practice, this means that whenever there is insufficient cash to fulfil an earmark – of the underlying importance or urgency of the associated securities purchase – a repo is automatically initiated to source the required liquidity. The model does not differentiate between reservations based on their criticality; all earmarks are treated equally in terms of liquidity provision. As a result, even less significant or lower-priority earmarks could trigger auto-repo activity, rather than queuing or being deprioritised.

  Alternatively, a more sophisticated approach could be developed in which only earmarks deemed more critical – for example, those relating to time-sensitive or high-value transactions – would trigger an immediate liquidity check and possible repo. Less critical earmarks, on the other hand, could be placed in a queue or even rejected, rather than prompting automatic liquidity sourcing. This would enable the system to allocate liquidity more selectively, prioritising the most important transactions and reducing unnecessary operational activity. However, implementing such a prioritisation mechanism would require further research to determine appropriate criteria for assessing transaction criticality and integrating this logic into the auto-repo workflow.

  The exclusion of payment requests from this model ensured that existing Liquidity Saving Mechanisms within our RTGS would continue to be used as they are today. Alternatively, the system could be designed to check for liquidity for certain high priority payments, but this is an area that will require further research.

  The system was also designed to unwind all outstanding repos when an account’s balance exceeds the preferred maximum, which required the buffer between minimum and maximum preferences to be larger than the total possible repo position taken by a participant. This design ensured that RTGS was not required to track outstanding repo positions, and that the TSP/synchronisation operator did not require knowledge of the accounts balance. This arrangement could be desirable, but may not suit all liquidity management strategies, especially in more complex or dynamic environments.

  These choices highlight the trade-offs between operational efficiency, system simplicity, and the ability to tailor liquidity management to diverse participant needs. As automated liquidity mechanisms evolve, operators will need to assess these design features in the context of their own operational requirements and risk appetites.

  Availability

  Currently, our RTGS service operates within predefined hours, which shapes the implementation of interoperability and automated liquidity management innovations. By contrast, DLT platforms are, in theory, capable of near-continuous (24/7) settlement. This creates a potential operational gap, as extending RTGS settlement hours to match the availability potential of DLT platforms would require substantive changes to participant procedures, and risk management frameworks. As an initial milestone, an extension of RTGS settlement hours is planned for the second half of 2027, which is intended to support the broader objective of near-continuous settlement by the end of the decade.

  Standardisation

  While standardisation was not a primary focus of this experiment, it is a critical area for future development. In our experiment, we used ISO 20022 for messaging between the TSP and RTGS. Standardised messaging formats and interface protocols will be essential to ensure interoperability across platforms. This includes defining how liquidity preferences are expressed, how synchronisation instructions are communicated, and how settlement confirmations are handled. Establishing such standards will be key to enabling cross-platform co-ordination, reducing integration costs, and supporting broader market adoption.