Digital euro pilot: most of what banks need for 2029 is already in scope

The ECB’s digital euro pilot is a beta, not a sandbox. We analyzed the full scope of the pilot and found it already covers about 70% of the functionality a bank will need for regular operation. The choice is increasingly clear: build once or build twice.

The pilot covers more than you might think

The digital euro pilot starts in the second half of 2027 and runs for 12 months. It will involve 36 payment service providers, selected merchants and everyday payments by Eurosystem staff using a beta version of the digital euro.

For most euro-area banks, the pilot is something that happens to others.

The date that matters to them is 2029, when a first issuance could follow, provided the EU regulation is adopted and the ECB’s Governing Council decides to issue the digital euro.

That framing leads to a seemingly sensible plan: watch the pilot, learn from it, then build regular operations later.

But this approach overlooks one important number.

We mapped the functionality required for the pilot against the functionality required for regular operation, capability by capability, across access, liquidity and transaction management.

Our analysis indicates that the pilot scope already covers roughly 70 percent of the functionality in the full scope. The remaining 30 percent are additions, not rewrites. In other words, whoever is pilot-ready has done most of the work for 2029, and whoever waits for the “final” scope will build the same 70 percent later, under more time pressure.

What’s in the pilot and what comes later

Three capability areas carry a digital euro implementation. Here is how they split between pilot scope and the delta to full scope, based on the current interim draft of the rulebook.

Area	In the pilot scope	Additional scope
Access management	Onboarding, link to the current account, offboarding, user lifecycle management	Switching (moving a digital euro wallet to another PSP)
Liquidity management	Funding, defunding, waterfall, reverse waterfall	No further core functions; parameters such as the holding limit depending on the regulation and the final rulebook
Transaction management	Transaction initiation, refund, chargeback and dispute	Recurring payments, reservation

Two points stand out here.

First, many of the technically demanding parts are in the pilot. This includes the DESP connection, the second ledger that keeps position and holding limits synchronized with the current account, waterfall and reverse waterfall logic, and refund flows.

Second, much of the remaining functionality builds on this foundation. Switching, recurring payments and reservations extend the working system rather than requiring a different architecture.

The 70 percent figure we mentioned earlier is a measure of functional coverage, not implementation effort.

We aren’t claiming that a pilot-ready bank will be 70 percent production-ready or that 70 percent of implementation person-days will be complete.

Production requires additional work, including performance and availability requirements, certification and operational processes. Furthermore, the pilot only has 36 participants, not an entire market.

The scope can also change. The rulebook remains an interim draft that will only be completed after the regulations is adopted. That means parameters like the holding limit are still open.

So, 70 percent is an estimate and we present it as one. But the broader pattern is clear from the rulebook versions we’ve analyzed: the pilot is not just the foundation stone. It’s the foundation and walls. The additional scope (delta) is the roof and the front garden.

Why 70 percent changes the build decision

If the pilot covered only 20 percent of the eventual scope, waiting might make rational sense because it would be a throwaway prototype for the few and a proper build for everyone later.

But at roughly 70 percent functional coverage, the math flips and the decision looks different.

A bank that builds for the pilot can easily extend that foundation as the remaining requirements become clear, only building once. A bank that waits watches and then decides to build for 2029 will get left behind. They’ll still need to build much of the same functionality, but will be 12 months behind.

There are three reasons “build once” matters:

• The rulebook is still a draft. Several sections are still open and the first complete version will only follow adoption of the regulation. A custom implementation has to absorb each change in its own code. A standard solution, however, absorbs it all once for every bank running it. The difference compounds over the pilot year.
• The DESP interface is still being finalized. The ECB has said feedback from pilot PSPs can influence the technical specifications. So whoever builds their own connector today will have to rebuild for the production specification. A standard solution has only one component that talks to the DESP, which is the vendor’s to keep current.
• Much of the remaining 30 percent scope is additive. Switching, recurring payments and reservations plug into access and transaction management that already work. There’s no architectural reason to wait before building the foundation.

This is what we mean by “build for the pilot once”. The pilot scope is not a reduced version of the digital euro. It’s the digital euro’s core, running on a beta of the scheme.

A bank that is ready for it is ready for most of 2029.

What this means for banks outside the pilot

Even if your bank isn’t taking part in the pilot, its scope can help shape your roadmap.

• Treat the pilot scope as your scope definition. Access, liquidity and transaction management as listed above are the requirements document most banks are still waiting for. It exists today. 
• Choose your implementation approach based on the core scope. Decide who will absorb future rulebook changes: your engineering team, an implementation partner or a standard solution.
• Plan the 2027 budget for the foundation. Working backward from a potential 2029 issuance means implementation activity could fall in 2027 and the first half of 2028, followed by production hardening, certification and additional functionality.

A side-by-side architecture can support this approach without touching the core banking system. A second ledger runs alongside the core, synchronized with the current account in real time, with a dedicated component connecting to the DESP. Additional functionality can then be added to that foundation as the scope develops. Nothing is replaced. Nothing is paused.

Go deeper with our whitepaper “How to make banks digital euro ready”

Our whitepaper, co-authored with Senacor, covers three capability areas, reference architecture and the implementation path in detail.

Access the whitepaper here.