Project Meridian FX APAC Shows Why Atomic Settlement Still Needs Legal Finality

Project Meridian FX APAC has demonstrated that three central-bank settlement environments built on different technologies can coordinate foreign-exchange payments so that all linked legs settle together or none of them does. On 13 November 2026, the Bank of England, the Monetary Authority of Singapore and the Bank of Thailand published the results of an experiment that connected simulated wholesale systems across currencies, infrastructures and time zones. The trial successfully executed bilateral payment-versus-payment transactions, extended the model to multilateral net settlement and tested several failure scenarios. That is meaningful progress toward safer cross-border finance.

It is not, however, the same as proving that a production service can create one legally final event across jurisdictions. The project’s most important contribution is precisely this distinction. Software can coordinate instructions, reserve funds and prevent one payment leg from escaping without the other. Law still determines when each domestic system regards a transfer as final, which entity carries responsibility for the coordination layer, how an outage is handled and what claim a participant has if systems disagree. Project Meridian FX APAC therefore turns interoperability from a ledger-selection debate into a governance problem. The question is no longer whether real-time gross settlement systems and distributed ledgers can communicate. It is whether institutions can make that communication dependable enough to carry wholesale money.

What the experiment actually proved

The project was a collaboration among three central banks, with Partior acting as the delivery partner for the Synchronisation Operator prototype. According to the joint Bank of England announcement, the experiment connected environments representing materially different architectures and operating models. It included conventional real-time gross settlement structures, centrally operated tokenised systems and a tokenised environment in which participants controlled wallets. The objective was not to force those systems onto one shared ledger. It was to test whether a common coordination service could make them behave as parts of one settlement process.

Two use cases mattered. The first was atomic foreign-exchange payment-versus-payment, usually abbreviated as PvP. In an ordinary currency trade, one party delivers one currency and expects another currency in return. If the two legs do not settle together, the party that pays first can be exposed to the other party’s failure. PvP reduces that principal risk by making settlement conditional: both currency legs complete, or neither completes.

The second use case was multilateral net FX PvP across three systems. Instead of settling every obligation gross, the design grouped eligible transactions and calculated a smaller set of net payments. The executive summary says this arrangement preserved atomic outcomes while potentially reducing the amount of liquidity that banks needed to commit. That combination matters. Gross settlement can reduce credit exposure but consume substantial intraday liquidity. Netting can reduce liquidity requirements but create dependencies among several participants. A synchronized process tries to capture both benefits without allowing partial completion.

The experiment also tested insufficient funds, invalid account identifiers and temporary infrastructure outages. In those scenarios, the coordination logic preserved the integrity of the linked transaction: settlement either completed under the defined conditions or unwound without leaving only one leg settled. That result is encouraging because a payment design should be judged by its behavior when an instruction is late, invalid or unavailable, not only by its performance in a clean demonstration.

The limits are equally important. The trial used test environments rather than live central-bank systems. It did not reproduce the full FX trade lifecycle, production participants, every non-overlapping operating window or every legal arrangement that would bind a real service. Successful execution is evidence that the model can work. It is not evidence that every market, currency and institution is ready to use it.

Synchronisation changes the interoperability question

Financial-market interoperability is often framed as a choice between consolidation and fragmentation. One side imagines a common ledger on which every asset and payment should settle. The other accepts multiple systems but relies on messaging, bridges and reconciliation to connect them. Project Meridian FX APAC offers a third approach: preserve different domestic settlement systems, then coordinate the conditions under which each one changes state.

This is a significant architectural idea because central banks are unlikely to modernise in the same way or on the same timetable. One jurisdiction may upgrade an established RTGS platform. Another may build a tokenised settlement ledger. A third may allow commercial participants to control wallets within a centrally governed system. Requiring every central bank to adopt the same technology would make interoperability dependent on global convergence that may never arrive. Synchronisation instead asks whether the systems can expose a compatible set of functions.

The project identified several such functions. The operator needs timely status information. It needs a reliable way to determine that funds are available and reserved for the coordinated transaction. It needs authority to initiate settlement when the linked conditions have been met. Ideally, it can perform these tasks without taking custody of participants’ money. Where a domestic system supports authorised third-party access, earmarking and settlement initiation, the operator’s role can remain relatively narrow.

Where those capabilities are missing, the architecture becomes less elegant. The technical report explains that the Singapore-dollar test environment used a dedicated bank-owned wallet managed by the Synchronisation Operator under the bank’s authorisation to replicate funds reservation. That arrangement made the experiment work, but it also shifted more operational responsibility toward the coordinator. The difference is not cosmetic. A service that only transmits and matches conditions presents one risk profile. A service that manages an escrow-like wallet, initiates transfers or becomes necessary for reconciliation may present another.

This is the broader lesson behind Block2Learn’s earlier analysis of sovereign-network interoperability and verification. Connecting heterogeneous systems does not remove trust; it changes what must be verified. Participants have to trust not only their domestic ledger, but also the messages, permissions, adapters and operating rules that make several ledgers act as one transaction.

Payment-versus-payment solves a specific risk

Atomic PvP is powerful because it addresses principal risk directly. If a bank pays away pounds but does not receive the expected Singapore dollars or Thai baht, the full value of the delivered leg can be exposed. The risk is particularly serious when transactions cross time zones, operating hours and infrastructures. Even a creditworthy counterparty can fail operationally at the wrong moment.

Synchronisation reduces that risk by linking the payment conditions. Each system prepares its leg. The operator observes readiness, coordinates the final step and permits completion only when all required legs can proceed. If one condition fails, the process should release or unwind the prepared positions without allowing a stranded payment.

That mechanism should not be overstated. PvP does not eliminate every risk attached to FX. Banks may still face replacement-cost risk if a trade fails and market prices move. They may face liquidity risk when funds are reserved but settlement is delayed. They may face operational risk from bad data, cyber incidents or unavailable systems. They may face legal risk if jurisdictions disagree about finality or insolvency treatment. They may also face concentration risk if one synchronisation service becomes a common dependency for many currencies.

The distinction matters because financial infrastructure is often evaluated through a single success metric. A demonstration that prevents principal loss is valuable, but it does not prove continuous availability, economic efficiency or legal certainty. Good market design separates these questions so that one successful property does not conceal another unresolved one.

Netting saves liquidity by creating coordination demands

The multilateral result may be more economically important than the bilateral result. A bank active across several currencies can hold offsetting obligations. Settling every trade individually requires it to fund each payment at the required moment. Netting compresses those obligations, allowing incoming and outgoing positions to offset before the final transfers occur.

Consider three banks with linked obligations across pounds, Singapore dollars and Thai baht. Gross settlement may require each bank to supply the full amount of every payment. A multilateral process can calculate net positions and settle only the residuals. Less cash needs to be reserved, fewer movements occur and intraday liquidity can be used elsewhere.

The saving is not free. The more transactions that enter one cycle, the more the group depends on every participant meeting its obligation. One bank with insufficient funds can affect several otherwise valid payments. The system needs rules for removing transactions, recalculating positions, extending deadlines and communicating failures. It also needs a clear answer to a difficult question: when does a liquidity-saving mechanism become a systemically important financial-market infrastructure rather than a technical service?

Project Meridian FX APAC used negotiation and recalculation logic to manage the tested scenarios. The technical report notes that support for the ISO 20022 pacs.029 message could simplify reconciliation when a bank lacks sufficient funds for a multilateral settlement instruction. That detail illustrates how interoperability depends on operational semantics, not only on connectivity. Two systems can exchange messages and still disagree about what a status means, whether an instruction is final or which action should follow a failure.

Liquidity efficiency will therefore depend on standardisation below the headline layer. Account identifiers, status messages, reservation states, expiry rules and error codes must be consistent enough for machines and operators to reach the same conclusion. Adapters can translate differences, but every translation creates another place where meaning can be lost.

Technical atomicity is not legal finality

The central distinction in the project is between coordinated execution and legal settlement finality. Technical atomicity means that software links several state changes so that they occur together under the defined protocol. Legal finality means that a transfer is irrevocable and enforceable under the law governing the relevant system, including during insolvency.

Those concepts often align inside one infrastructure because the operating rules and governing law define the authoritative ledger and the moment at which settlement becomes final. They are harder to align across jurisdictions. A pounds payment may become final under the rules of one system at a different procedural point from a Singapore-dollar or baht payment. One ledger may treat a reservation as an internal state with no proprietary effect. Another may give an earmarked balance stronger protection. One jurisdiction may recognise an operator’s instruction directly; another may require action by the account holder or domestic system.

The policy report therefore focuses on functions rather than labels. The appropriate treatment of a Synchronisation Operator depends on what it actually does, how material it becomes and whether it holds funds, controls instructions or influences settlement outcomes. Calling the service “non-custodial” does not settle the question if an implementation gives it operational control over a dedicated wallet or makes it indispensable to releasing funds.

This is where public-blockchain language can create confusion. Smart-contract platforms commonly describe an operation as atomic when all contract calls complete or revert inside one transaction. That property is defined by one consensus system. Cross-system atomicity is different. No single ledger necessarily controls the complete event. Coordination logic can make partial completion unlikely or recoverable, but the legal result still depends on separate systems and jurisdictions.

Institutions should therefore resist the claim that code alone creates settlement certainty. Code can enforce preconditions and sequence. Law defines rights, discharge and finality. Operations determine whether the process is available. Governance decides who can change it. A production design must make all four layers coherent.

The Synchronisation Operator becomes the new control plane

The operator is the organizing institution in this model. It receives or verifies transaction information, monitors the readiness of linked payment legs, coordinates reservation, initiates settlement and manages exceptions. Even if it never owns participant funds, it can influence whether those funds move and when they are released.

That role creates several governance questions. The first is authorization. A participant must know which instructions the operator may issue and under what conditions. Permissions should be narrow, auditable and revocable. The second is data integrity. If the operator receives conflicting status messages, it needs a deterministic rule for deciding whether to proceed. The third is resilience. A temporary operator outage should not strand reserved liquidity indefinitely or force domestic systems into contradictory states.

The fourth question is change control. Settlement systems evolve. Message standards are revised, ledger software is upgraded and central banks alter operating windows. A coordinator that connects many systems can become the place where those changes collide. Version management and backward compatibility are therefore financial-stability issues, not ordinary software maintenance.

The fifth is oversight. A service coordinating several jurisdictions may not fit neatly into one domestic category. Its home supervisor may observe the company, while participating central banks observe the effects on their systems. If it becomes material, authorities need clear rights to obtain information, require remediation and coordinate incident response. International principles could create a common assessment baseline without forcing every service to adopt the same design.

The project does not prescribe one institutional answer, and that restraint is appropriate. A central-bank-operated service, an industry utility and a regulated private operator would distribute incentives and liabilities differently. The correct structure depends on scope, scale and function. What matters is that the governance follows the risk instead of the marketing label.

DLT was one component, not the product

Project Meridian FX APAC belongs in the blockchain and digital-finance conversation because some test environments were based on distributed-ledger technology. It should not be interpreted as evidence that central banks have selected one public blockchain, token or universal ledger. The experiment was intentionally technology-diverse.

That point has two implications for investors. First, institutional adoption of DLT can grow without producing direct demand for a public crypto asset. A central bank or bank consortium may use permissioned ledger software, controlled wallets and private networks. Economic value may accrue to infrastructure providers, integration specialists and financial institutions rather than to a network token.

Second, conventional systems do not become obsolete merely because tokenised environments join the architecture. The trial treated RTGS and DLT-based systems as peers that could be coordinated. The market opportunity lies in connecting them safely, not declaring one side the winner.

Block2Learn’s analysis of DTCC’s planned Solana tokenisation service reached a related conclusion from another direction. A public network can add transfer and programmability while the central securities depository retains the authoritative ownership record and control framework. Meridian shows that the payment side may evolve similarly: new ledgers can participate while domestic central-bank money systems keep their legal and operational roles.

This separation is healthy. It forces every token or network thesis to identify the value-capture route. More synchronized settlement may increase demand for cryptography, digital identity, programmable workflows and ledger integration. It does not automatically imply higher transaction fees or monetary demand for a specific public-chain token.

Time zones remain an economic constraint

The APAC extension matters because cross-border settlement is not only a technology problem. It is a clock problem. London, Singapore and Bangkok do not share the same business day. Domestic systems can have different opening hours, maintenance windows and cut-off rules. Banks also manage liquidity against local market conditions and central-bank facilities.

The experiment covered different time zones but did not reproduce every production condition involving non-overlapping operating hours. That limitation is material. A synchronized transaction can complete only when all required systems and participants are able to act. If one system is closed, the operator must delay the transaction, rely on prefunding, use a liquidity provider or move settlement into a common operating window.

Each option changes the economics. Prefunding reduces settlement risk but ties up cash. Extended hours improve availability but increase staffing and resilience costs. Liquidity providers can bridge time gaps but introduce credit exposure and fees. Tokenised central-bank money could operate for longer periods, but its legal, operational and monetary-policy framework still has to support those hours.

This is why a production service should publish more than throughput. Participants need expected settlement windows, liquidity requirements, reservation durations, failure-release times and service availability across jurisdictions. A fast protocol can still be an expensive market if capital waits inside it.

Exception handling is where trust becomes visible

Normal-flow demonstrations establish feasibility. Exception handling establishes credibility. The project’s tests of insufficient funds, invalid identifiers and temporary outages were therefore essential. They show that the designers treated failure as part of the system rather than as an external event.

The next tests should be harsher. A prolonged outage may outlast an earmark. A participant may become insolvent after one domestic system regards a step as final but before another does. A cyber incident may compromise the operator’s credentials or corrupt a message without changing the underlying ledger. A central bank may suspend a participant while a transaction is being coordinated. Two systems may recover from an outage with different views of the last completed instruction.

These scenarios require a common evidence trail. Every reservation, status update, authorization, retry, expiry and release should be time-stamped and attributable. Domestic systems need enough information to reconstruct what the operator saw and why it acted. Participants need a dispute process that does not depend on reverse-engineering three ledgers during a crisis.

The operating model also needs safe degradation. If the synchronization service is unavailable, systems should know whether to pause linked settlement, revert to a bilateral process or allow only lower-risk activity. Improvised fallback is dangerous because it can weaken the atomic property precisely when operators are under pressure.

The same principle applies to the broader tokenised-finance stack. Block2Learn’s examination of digital-euro and wholesale settlement infrastructure showed that individual platforms create limited value when cash, collateral, custody and legal records remain isolated. Exception handling must therefore span the complete workflow. A securities ledger that recovers successfully does not solve a cash-leg failure, and a functioning payment ledger does not settle a disputed ownership record.

What a live service must prove before 2028

The Bank of England plans to launch a live synchronisation interface in 2028. Project Meridian FX APAC provides practical input for that program, but moving from experiment to service requires a broader evidence package.

The first requirement is legal mapping. Every participating system must define the status of reservation, initiation, settlement and release. Agreements need to explain which law governs the linked process, how conflicts are resolved and whether the operator’s records have evidentiary standing.

The second is operational resilience. The service must show recovery objectives, redundancy, cyber controls, credential security, software-change procedures and coordinated incident management. Testing should include prolonged outages, partial connectivity, duplicate messages, delayed status updates and compromised participants.

The third is liquidity design. Multilateral netting should be evaluated across realistic transaction volumes and stressed funding conditions. Authorities and banks need to understand how much liquidity is saved, how long funds remain reserved and how one participant’s shortfall affects the group.

The fourth is access and competition. If one operator becomes the preferred route to several central-bank systems, entry rules and pricing can shape market structure. A technically neutral coordinator could still concentrate power if only a small set of banks or service providers can connect.

The fifth is data governance. Cross-border coordination creates transaction, participant and operational data. Rules should limit use, protect confidentiality and still provide supervisors with enough information to oversee systemic risk.

The sixth is interoperability governance. Common capabilities should be standardized where doing so reduces bespoke adaptations. Yet standards must leave room for domestic systems to preserve legitimate differences. The objective is compatible function, not forced uniformity.

Three paths from experiment to market infrastructure

Base case: limited corridors prove the operating model

The most plausible path is a phased launch involving a small number of central-bank systems, currencies and highly regulated participants. Bilateral PvP may precede broad multilateral netting. Operating hours may overlap by design, and transaction types may be limited while legal and operational evidence accumulates.

This outcome would still be valuable. It would reduce principal risk for selected flows, create real data on liquidity use and clarify which domestic capabilities matter most. Expansion would follow demonstrated reliability rather than a promise of universal connectivity.

Favorable case: coordination becomes a shared interoperability layer

In the favorable scenario, several jurisdictions expose compatible reservation, third-party access and settlement-initiation functions. Synchronisation Operators can connect without holding funds or building bespoke escrow arrangements. Common oversight expectations make it easier to assess services across borders, while multilateral netting reduces liquidity needs at meaningful scale.

The model could then extend beyond FX. The same conditional-settlement logic could coordinate tokenised securities against central-bank money, collateral substitutions or other multi-ledger transactions. Block2Learn’s analysis of tokenised-loan origination and authoritative records illustrates why this matters: digital assets become more useful when ownership, cash and servicing events can connect without creating uncontrolled duplicate records.

Adverse case: the operator becomes another fragmented dependency

In the adverse scenario, every jurisdiction requires a different adapter, escrow structure and legal agreement. Costs rise with each connection. Participants must prefund across long operating gaps. One operator accumulates broad responsibility without a coherent oversight framework, or several operators create incompatible networks.

Transactions may remain technically atomic inside each implementation while the market becomes operationally fragmented. Liquidity savings fail to compensate for integration costs, and only the largest banks can participate efficiently. The project would then have proved a protocol pattern without producing scalable market infrastructure.

What institutions and investors should monitor

The first indicator is the scope of the Bank of England’s 2028 interface. Market participants should watch which functions it exposes, which currencies or asset types can connect and whether authorized third parties can reserve and initiate payments without taking custody.

The second is legal documentation. Technical diagrams will attract attention, but rulebooks, participation agreements and finality opinions will determine whether banks can assign capital and operational responsibility with confidence.

The third is production evidence on liquidity. Useful disclosure would compare gross funding requirements with net requirements, show reservation times and explain how failed participants are removed from a cycle.

The fourth is operator structure. Ownership, governance, pricing, access and oversight will reveal whether synchronization develops as public infrastructure, a competitive service or a concentrated private utility.

The fifth is system diversity. A service that connects RTGS and several tokenised designs without custom risk accumulating at the operator would support the project’s strongest thesis. A growing library of bespoke adapters would weaken it.

The sixth is exception performance. Completion rates matter, but release times, reconciliation quality and the handling of prolonged outages will say more about resilience.

The seventh is real adoption. Memoranda and pilots should eventually give way to live transactions, recurring volumes and measurable reductions in settlement exposure. Until then, the evidence supports technical feasibility rather than market transformation.

The Block2Learn assessment

Project Meridian FX APAC is a serious result because it rejects the false choice between one global ledger and permanent fragmentation. Three central-bank test environments with materially different designs coordinated bilateral PvP, multilateral netting and defined failure scenarios. That is practical evidence that interoperability can be built around common functions rather than identical technology.

The experiment also makes the next constraint clearer. Atomic execution is not a universal legal event. The Synchronisation Operator can prevent one payment leg from proceeding alone, but it cannot by software alone harmonize settlement-finality law, insolvency treatment, operating hours or supervisory authority. As the service gains functions, its responsibilities and systemic importance can grow even if it never formally owns the funds it coordinates.

The correct interpretation is therefore neither that wholesale finance has been solved nor that the trial is merely another pilot. It has retired one uncertainty and exposed the next. Diverse systems can be coordinated. The remaining work is to make that coordination legally final, operationally resilient, liquid under stress and governable across borders.

That sequence is how durable financial infrastructure develops. Technology proves a mechanism. Markets test its economics. Law defines its effect. Governance decides whether the whole system deserves trust.

Continue Through the Block2Learn Learning Path

Understanding Project Meridian FX APAC requires more than recognizing that several ledgers exchanged messages. The deeper concepts include settlement risk, payment-versus-payment, liquidity netting, legal finality, financial-market infrastructure, central-bank money and the difference between a tokenised record and an enforceable claim.

The Block2Learn Learning Path builds those ideas progressively. Free Start introduces the language of markets and digital assets. Foundation develops risk, liquidity and capital-allocation concepts. The Investor Operating System turns evidence into a repeatable decision process. Trading explains market structure and operational execution. Crypto connects ledgers, wallets, tokenisation and on-chain systems to the financial institutions around them. Wealth Strategy places those tools inside a broader balance-sheet framework, while Framework integrates them into one coherent system.

That structure helps readers evaluate institutional blockchain announcements without reducing them to enthusiasm or dismissal. A successful prototype can be technically important while remaining legally incomplete. A DLT deployment can improve settlement without creating value for a public token. A liquidity-saving mechanism can reduce cash needs while increasing coordination dependence. Learning to hold those ideas together is more useful than memorizing the latest project name.

Information is abundant. Structure is rare.