The Bank for International Settlements published a working paper in September 2026 that builds a working prototype on the XRP Ledger. Four of its five authors work at the BIS. They used the XRPL to anchor cryptographic fingerprints of official statistics, so anyone can check who published a dataset and whether it changed after release.
That is the whole story, and it is a bigger one than it first appears. This is not a bank commenting on blockchains from a distance. It is researchers inside the institution that central banks own choosing a specific public ledger, writing code against it, measuring it, and publishing the results with the source.
| Paper | BIS Working Papers No 1374 |
| Title | Verifiable official statistics: a blockchain-based approach |
| Published | September 2026 |
| Authors | Mario Rusev, Rafael Schmidt, Edward Lambe, Christian Schmieder, Glenn Philip Tice |
| Affiliation | Four authors at the BIS Monetary and Economic Department; Rusev at d-fine Austria GmbH |
| Ledger used | XRP Ledger DevNet (s.devnet.rippletest.net) |
| Reference code | bis-med-it/sdmx-blockchain, Apache-2.0 |
| JEL codes | C82, C88, G28, O33 |
What BIS Working Paper 1374 actually built
International organizations publish official statistics using SDMx, the Statistical Data and Metadata eXchange standard. The BIS uses it. So do many central banks and statistical agencies. The problem the paper takes on is simple to state: once a dataset leaves the publisher, a consumer has no cryptographic way to confirm it came from that publisher and has not been altered since.
The prototype closes that gap. It canonicalizes each SDMx dataset, hashes it per data series, aggregates those hashes into a Merkle tree, and writes the resulting root to the XRP Ledger as the sole payload of a transaction memo. The published file then carries the ordered Merkle leaves and a W3C Verifiable Credential signed by a publisher identity key that is bound to the publisher’s XRPL address through an on-chain attestation registry.
The consequence is the interesting part. A consumer can re-derive the anchored root and verify the publisher’s identity from the file alone plus a single ledger lookup. No call back to the publisher. No trusted intermediary. The ledger is the only thing both sides have to agree on.
Why the researchers picked the XRP Ledger
The paper states its reasoning directly. The XRP Ledger was used as a proof of concept, in the authors’ words, “because of its low nominal fees, fast consensus finality, availability of developer resources and technical analysis of the consensus protocol.” That last reason cites Chase and MacBrough’s 2018 analysis of the XRPL consensus protocol.
Read that list again, because it is unusual. Two of the four reasons are not about performance at all. One is that the developer documentation is good enough to build against. The other is that somebody published a technical analysis of how the consensus protocol works, so researchers evaluating it had something to read. Institutional builders have to justify a choice to people who will ask why. On that axis, published research about the protocol is a competitive advantage, and the XRPL had it.
The authors are careful to add that the approach “is meant to be blockchain-agnostic and to work with solutions other than XRPL as well.” The design does not require the XRP Ledger. The prototype uses it anyway, and that distinction is worth holding onto rather than glossing over.
The architecture behind the XRPL anchoring prototype
The system is organized into four layers: client, storage, external services, and blockchain operations. Each layer sits behind a narrow interface, so the identity provider, object store, or target blockchain can be swapped without touching the rest. The XRPL appears twice in the design, once as an external service and once as a dedicated gateway microservice.
The on-chain footprint is deliberately minimal. Only the hexadecimal encoding of the Merkle root goes into the memo, with no in-band prefix or framing. The structured anchor descriptor lives in the SDMx file instead. That keeps the ledger cost flat regardless of how large the underlying dataset is, which is the property that makes the economics work.
How the XRP Ledger compared with Ethereum, Chainlink and PKI
The paper includes a direct comparison of the four approaches it considered, with a published methodology for every cell. This is that table, reproduced as data.
| Criterion | This work (XRPL) | Chainlink | Ethereum | Traditional PKI |
|---|---|---|---|---|
| Verification time | About 1 to 2 seconds | Minutes to hours | Minutes to hours | Milliseconds (OCSP) |
| Transaction fee | About $0.000003 | About $0.50 | About $5.00 (L1); under $0.01 (L2) | $0.00 (amortized) |
| Integration complexity | Low (API-based) | Medium | High | Low |
| Real-time verification | Yes | Limited | Limited | Yes |
| SDMx compliance | Full | Variable | Variable | Variable |
| Scalability | High | Medium | Low | High |
| Energy efficiency | High | Medium | High | High |
The fee gap is the line that stands out. The XRPL figure comes from a median observed network fee of 10 drops, or one hundred-thousandth of an XRP, per anchoring transaction. The Ethereum figure assumes a small storage-bearing transaction at a 20 gwei gas price with ether around $2,500, and the authors note gas prices are volatile. The comparison is per transaction, not per dataset, which understates the XRPL advantage: because anchoring is batched, a batch of 1,000 datasets works out to roughly three billionths of a dollar per dataset.
A separate table positions the work against earlier efforts. Statistics Canada’s 2022 investigation and the US Department of Commerce collaboration with Chainlink each cover some of the ground. Only this system covers all five of SDMx semantics, Merkle batching, verifiable-credential binding, an explicit cost model, and an open reference implementation.
What the measured XRPL latency and fee numbers were
Publication took 3 to 5 seconds at the median, covering canonicalization, hashing, aggregation, and off-chain bookkeeping, with anchoring confirmation following XRPL finality. Verification took 1 to 2 seconds for individual datasets. A typical ledger close ran 3 to 4 seconds, and the authors note that end-to-end latency is dominated by that ledger-close cadence rather than network round-trip time.
Verification scales well. End-to-end time grows as the size of the payload plus the logarithm of the batch size, and the linear part is the parsing and canonicalization of the SDMx file, not the cryptography. The Merkle proof check adds only logarithmic overhead. Test datasets ran from 10 KB to 8 MB, generated from real BIS public structure definitions.
All reported runs used the XRPL DevNet. The authors address that directly: DevNet uses the same transaction format and ledger-close cadence as mainnet, so per-transaction latency is representative, and while absolute mainnet fees differ they “remain in the sub-cent range.”
Where the BIS prototype stops short
The paper is unusually direct about its own limits, and repeating them is what makes the rest of it credible. The authors did not run the system at sustained mainnet load, behind an enterprise web application firewall, with hardware-security-module signing in line, or under adversarial conditions. In their words, the numbers “characterise the prototype’s efficiency, not its production resilience.”
Two more limits matter. This is a BIS working paper, which carries the standard notice that the views are those of the authors and do not necessarily reflect the views of the BIS or its member central banks. It is research, not policy, and not an endorsement of any asset. And the anchoring ran on a test network, so no production official statistics are being anchored to XRPL mainnet today.
Why this matters for the XRP Ledger
Strip out the speculation and something solid remains. A team of researchers at the BIS needed a public ledger for an official-data prototype. They evaluated the options against cost, finality, documentation, and published protocol analysis. They chose the XRP Ledger, built on it, measured it, and released the code under Apache-2.0 on the BIS’s own GitHub organization. That is a use case with an institution’s name on it, which is a different category of evidence from a partnership announcement.
It also lands in a place the ledger has been building toward. On-chain attestation registries and identity binding are the same territory as the Credentials amendment, and the anchoring pattern sits close to the standards work covered in the Digital Token Identifier and ISO 20022 securities messages. The paper’s forward-looking section describes AI agents calling the verification API to make a local cryptographic decision, and refusing to act on data they cannot verify. A ledger that settles machine-to-machine data integrity checks in one to two seconds for a fraction of a cent is well shaped for that.
What nobody can tell you is whether this becomes adoption. A DevNet prototype in a working paper is a long way from a central bank anchoring live statistics on mainnet, and the authors themselves say the design would work on other chains. The honest read is that the XRP Ledger just picked up a credible, documented, independently authored use case from inside the institution known as the central bank for central banks. That is worth something. How much, the next few years decide.
Common questions
Did the BIS endorse XRP? No. This is a working paper by five researchers, four of whom work at the BIS, and it carries the standard notice that the views are the authors’ own and do not necessarily reflect those of the BIS or its member central banks. It evaluates the XRP Ledger as infrastructure for anchoring data. It says nothing about XRP as an investment.
Was this on the XRP Ledger mainnet? No. Every reported run used the XRPL DevNet at s.devnet.rippletest.net. The authors note DevNet shares the transaction format and ledger-close cadence with mainnet, so latency figures are representative, and that mainnet fees stay in the sub-cent range.
Why did they choose the XRP Ledger over Ethereum? The paper cites low nominal fees, fast consensus finality, available developer resources, and published technical analysis of the consensus protocol. Its comparison table puts XRPL anchoring at about $0.000003 per transaction against roughly $5.00 on Ethereum layer 1, and verification at 1 to 2 seconds against minutes to hours.
What is SDMx? Statistical Data and Metadata eXchange, the standard international organizations use to publish official statistics. The BIS has adopted it. The prototype binds each SDMx dataset to its source without changing how those workflows operate.
Can I read the paper and run the code? Yes. The paper is BIS Working Papers No 1374 (PDF) and the reference implementation is at bis-med-it/sdmx-blockchain under Apache-2.0.
Educational only, not tax, legal, or investment advice. Nothing here is a recommendation to buy, sell, or hold any digital asset. A research prototype is not an adoption commitment. Check primary sources and speak with a qualified professional before making financial decisions.
Part of our guide: XRP Explained.
