BIS Project Meridian FX: Inventing Distributed Assumption Technology
The project set out to demonstrate how to enable interoperability with new technologies like distributed ledger technology (DLT). Instead, it demonstrated how to get rid of them.
“Meridian FX shows that synchronisation can be agnostic to both the asset or fund of the transaction involved and the technology of the ledgers, highlighting its potential use in other markets.”
That sentence is not a conclusion drawn from evidence. It’s a self-deception created by design. They didn’t prove synchronisation is technology-agnostic — they forced it to be by abstracting away everything that defines distributed ledgers in the first place.
Here is why.
This morning, I had the pleasure of listening to a speech by Burkhard Balz, Member of the Executive Board of the Deutsche Bundesbank, discussing the digital euro here in London. He mentioned Project Meridian FX as a positive example of collaboration involving the Bundesbank.
Project Meridien was an initiative by the Bank for International Settlements (BIS) and the Bank of England, carried out by the BIS Innovation Hub London Centre. There is a report from 2023, but I have not read it. Project Meridian FX is more recent and explores synchronised settlement in FX. The website states 'Updated 24 April 2025,' so I suppose I'm not too late for this one.
I say this with the best intentions and in the nicest way I possibly can — but Project Meridian FX is a total car crash.
There is hope, though. Meridian (Russian: Меридиан) is also the name of a series of Russian military satellites developed in the 2000s, which were initially plagued by repeated failures. But if the internet is to be believed, they eventually got a handle on them.
Доверяй, но проверяй — Trust, but verify.
The BIS say this about their initiative:
“The project demonstrates how operators of wholesale payment infrastructures can enable interoperability with new technologies, such as distributed ledger technology (DLT), with a focus on FX transactions.”
The problem, however, is that nothing they describe has anything to do with distributed ledger technology. There are three alternative models:
🇮🇹 Italian Model (Hash Matching – Banca d’Italia)
Assumption: “There is a DLT on the other side. E andiamo! Chi vivrà, vedrà. Let’s go! Whoever lives, will see.”
Uses hashes of payment details to coordinate across a DLT boundary.
Acknowledges the existence of an external DLT system.
But the actual matching is probabilistic and not verifiable unless both sides agree on the input format and structure — a fragile handshake at best. It’s not a distributed ledger. It’s a distributed assumption.
🇫🇷 French Model (DLT Takeover – Banque de France)
Assumption: “We run both sides on our DLT, Pourquoi pas, why not.”
Proposes a “hub” model where they control the infrastructure and the execution logic.
Claims atomicity via orchestration — but it's synthetic, not cryptographic.
True atomic settlement requires that all parts of a transaction succeed or fail together within the same system — enforced by consensus, not coordination. In contrast, Meridian’s design relies on external platforms “locking” funds and a sequencing oracle (SO) to trigger release. This introduces external dependencies, breaks the finality guarantees of distributed ledgers, and replaces trustless execution with trust in orchestration. It simulates atomicity, but does not deliver it — which makes the label misleading.
Effectively substitutes one DLT for another, which contradicts the idea of interoperability.
🇩🇪 German Model (Trigger – Bundesbank)
Assumption: “I don’t care if you’re a DLT. Here’s a message. Na also, geht doch. Ah, there you go.”
Communicates via APIs and off-chain logic only.
Treats DLT participants like traditional financial endpoints.
Ignores the need for synchronised state or consensus.
The “blockchain” becomes a passive log — not a state machine.
The report describes something akin to "mini-CLS" models for DLT settlement based on a fundamental mischaracterisation of both market incentives and the technical realities of distributed systems. While well-intentioned, the models are commercially unviable, operationally inconvenient, and philosophically incoherent from a DLT perspective.
Off-Chain Break in Finality:
The proposed model forces prefunding outside the native DLT network. This creates a break in transaction continuity: the DLT cannot finalise a trade unless it goes off-chain thereby negating the very premise of atomic, trustless settlement. It’s a regression to trusted intermediaries under a new label.
No Real-Time Settlement:
Pre-funding across multiple isolated CLS-like systems undermines liquidity optimisation. Market participants won’t adopt a fragmented system when current solutions already centralise and net more efficiently. And it does not remove the need to be an RTGS participant which remains the bottleneck in all these models and limits potential users to exactly where we are today.
The model fails to answer a simple question:
Why would banks switch to something more expensive, more fragmented, and less interoperable?
These proposals rebrand old mechanisms as DLT-friendly without solving the finality gap or liquidity fragmentation. This is not DLT-enabled infrastructure design. If DLT settlement cannot offer a complete, on-chain, real-time solution, it should not be pursued under false pretences.
A DLT node can’t detect the state of a prefunding arrangement. There’s no canonical, cryptographically verifiable way for a smart contract or on-chain process to know:
If funds were successfully prefunded in the external system;
If netting occurred;
If the prefunded amounts are still valid;
Whether the transaction was approved off-chain.
This forces the system to introduce an off-chain oracle or messaging layer, undermining DLT's independence and introducing new risks (latency, downtime, manipulation, disputes).
DLT is supposed to enable atomic, trustless settlement. If a transaction needs to pause, check whether prefunding happened elsewhere, and then resume—it’s no longer atomic.
That means:
It’s not final on-chain until an external process completes.
Counterparty risk re-enters the picture.
Rollback mechanisms must be introduced for partial failure.
This breaks composability and predictability—core strengths of DLT.
If some transactions settle on-chain and others require off-chain routing to RTGS systems:
Who decides?
Based on what logic?
How do nodes coordinate?
Where’s the shared truth?
This introduces centralised logic gates or routing rules, meaning someone (a platform or institution) is effectively dictating system behaviour—making it DLT in name only.
Every participant would need off-chain infrastructure to track funding status, handle exceptions, resolve disputes, etc. Banks now need a hybrid tech stack with constant reconciliation.
🇮🇹 Hash Matching (Banca d’Italia)
Even though this is the most DLT-conformant model, it ultimately removes the need for using DLT at all.
The idea is as follows:
“We’ll use a hash as a cryptographic reference to confirm the transaction happened ‘somewhere else’.”
A hash proves nothing — except, perhaps, that something happened. But it doesn’t prove what happened. Unless both systems mutually understand and interpret the structure of the original transaction, the hash is meaningless. You can’t derive transaction intent, value, or compliance from it.
No native linkage = no atomicity. Even if both systems "see" the same hash, it doesn’t mean they executed the transaction in sync. One system could fail or reject it, and there's no enforcement mechanism based on the hash alone.
Hashes don’t eliminate the off-chain coordination problem. Referencing the hash on both sides still requires messaging to align timing and intent. You’re back to trusting someone (or something) to say: “Yes, we’re good to go.”
No trustless link = no guarantee. Even if someone later reveals the input and it matches the hash, you’re trusting their system executed it. The hash alone doesn’t prove anything happened on-chain or in a system you can verify.
Pre-funding ≠ Payment Execution. It’s Treasury Management.
When you pre-fund a payment in an external system (e.g. by moving money to a special account or intermediary before execution), you’re not settling a payment—you’re positioning liquidity. That’s a treasury operation—not the final leg of a payment.
This disrupts the existing treasury function. With what priority does the bank allocate intraday liquidity to this model?
DLT promises atomic settlement—simultaneous and final transfer of assets and funds. But if the proposed model requires prefunding outside the DLT environment, then:
The transaction can’t complete on-chain.
The system breaks atomicity.
It reintroduces correspondent banking friction in new clothing.
What the System Actually Does:
The synchronisation operator (SO) node receives full payment details.
It stores those details locally (off-chain).
It hashes key fields (e.g. amount, payer/payee, timestamp).
Only the hash is sent to the blockchain for “matching purposes.”
Let’s be clear:
The node becomes a single point of compromise.
Hashing is not encryption.
If the only on-chain trace is a hash, you’re relying entirely on the honesty of the node to say, “this hash matches my local confidential data.”
That means you're not verifying anything on-chain about the actual payment. You’re trusting off-chain actors—again.
This system pretends to be DLT, but all real logic, data, and validation happens off-chain. The blockchain becomes a meaningless collection of unverifiable claims. This is not secure, not transparent, and not DLT-native.
Critical Security Flaw
Storing blockchain signing keys locally on each SO node—as suggested—is a massive risk.
If a node is breached:
Attackers can sign false hashes.
They can spoof confirmations.
The system cannot distinguish fraud from fact—because the “fact” is just a self-hash.
They say they’re running a BFT (Byzantine Fault Tolerant) consensus protocol... on hashes.
What does this mean practically?
The actual payment details — amount, currency, sender, receiver — never go on the blockchain.
Only hashes of those details are broadcast to the ledger.
The consensus (QBFT) is used to agree that a hash was submitted and ordered—not that a real-world settlement took place.
So What Is the Network Really Doing?
“Node X says it has payment Y.”
“Here’s the hash of payment Y.”
“Let’s all agree we’ve seen this hash.”
And even to do this, the system must either:
Mandate a standardised message format with strict field order, encoding rules, and field-by-field normalisation—and hope everyone adheres perfectly (unlikely and brittle).
Designate one party to create the hash and send it to the other for echo confirmation—which defeats the point of “independent” agreement and reintroduces trust and timing dependencies.
The system must not allow freeform message construction. It has to:
Rely on predefined templates or schemas;
Use deterministic field ordering and formatting (timestamps, decimal points, capitalisation);
Only allow data selection from agreed-upon values or enumerated options.
And then you’re running a heavyweight Byzantine consensus… on what is essentially a sealed envelope.
No Atomicity
You cannot guarantee real-world coordination (e.g. PvP) since nothing on-chain proves that two hashes refer to properly funded, mutually dependent transactions.
No Validation
You can't detect inconsistencies, duplicates, or fraud unless every node voluntarily plays fair—defeating the purpose of DLT.
No Trust Minimisation
You’re replacing centralised messaging with decentralised notarisation—but the content still requires trust outside the chain.
And then we get transaction modification via CAMT.048 or cancellation via CAMT.049.
This breaks the core principle of DLT immutability.
A blockchain isn’t supposed to:
Overwrite transaction state,
Restart time logic,
Or erase previously confirmed entries.
What they’re describing is stateful off-chain logic pretending to be on-chain—effectively turning the ledger into a synchronisation artefact, not a source of truth.
It’s like calling a blockchain to record hashes of spreadsheet rows… while the actual business logic runs in the spreadsheets themselves.
Why would this be a good idea?