The digital euro scheme rulebook explained (v0.91)

The scheme rulebook is what turns "the digital euro" from a policy position into something a PSP can implement. If you only read one primary source, read this one — carefully, and with its status firmly in mind.

What it is for#

The rulebook establishes a single set of rules, standards and procedures for digital euro payments and related activities.

The purpose is harmonisation. PSPs participating in the scheme must offer consistent, standardised basic digital euro services, so that a user gets the same private, secure experience anywhere in the euro area, regardless of country or PSP.

This is the same job SEPA did for credit transfers and direct debits, and the logic is identical: a scheme is only a scheme if everyone implements it the same way. Without a rulebook you do not have a currency, you have twenty national interpretations of one.

Its status: draft, and it matters#

Version 0.91 was published on 2 July 2026. It incorporates feedback from a large-scale market consultation that ran from June to October 2025.

It is explicitly a draft. Not a release candidate, not a stable interface with a version number that happens to start with zero. A draft.

Underneath it, the regulation is still in the EU legislative process, and the decision on whether to issue the digital euro will only be considered once that process completes. The rulebook describes a scheme for a currency that has not been legally authorised into existence yet.

Who writes it#

The Eurosystem develops the rulebook with the Rulebook Development Group (RDG), which brings together:

• Senior representatives from associations covering the supply side of European retail payments — the institutions that would build and run digital euro services.
• Senior representatives from associations covering the demand side — consumers, retailers, businesses.
• The ECB and the euro area national central banks.
• Observers from EU institutions.

The supply/demand pairing is deliberate. A scheme written only by implementers optimises for what is cheap to build. One written only by policymakers discovers the cost at launch. Putting both in the room is an attempt to fail in neither direction.

The RDG publishes progress reports as work proceeds. For a PSP trying to see round the corner, those reports are the best early signal available — they show what is being worked on before it appears in a published draft. Work in the last quarter of 2024, for instance, covered the alias look-up service and the SEPI service, including QR-code and pay-by-link tokenisation.

What is inside#

Roughly, the rulebook moves from rules to requirements to annexes:

Area	What it covers
Functional requirements	Account management, aliases, switching, funding and defunding, waterfall, holding limit, transaction management
Technical implementation	Split by role — distributing PSP and acquiring PSP — covering front end and DESP interfaces
Risk management	Requirements on scheme participants
Dispute management	Eligibility, supporting documentation, process
Annexes	Certification/testing/onboarding, illustrative user journeys, end-to-end process flows, reporting requirements

The annex map#

The annexes are where the implementable detail lives, and they are easy to overlook:

• A1 — Certification, testing and onboarding. The gate between having code and being a scheme participant. Plan it as a phase with a duration.
• B1 — Illustrative user journeys. How the thing is meant to feel.
• B2 — End-to-end process flows. The authoritative description of how flows actually sequence. When the prose and the flows disagree, the flows are what you implement.
• C1 — Reporting requirements. The obligation that outlives the build.
• D1/D2 — Implementation specifications. Front-end and back-end specifications for the roles.

What is still missing#

This is the most useful thing to know about v0.91, because it tells you where the risk is.

The holding limit. The section on how the holding limit functions and is enforced is explicitly left to be detailed in later iterations. This is the most consequential parameter in the entire design — the dial governing how much deposit funding could migrate from commercial banks to central bank money — and it is not specified. Any figure quoted publicly today is speculation.

Offline. Implementation specifications for areas including the offline wallet SDK, the offline distribution service, and integration with the DESP offline issuance component are expected in future versions.

Internal consistency. The draft itself flags areas where sections have not yet been aligned with the latest end-to-end flows, with consistent versions promised in future releases. Where you find a contradiction, you have probably found a known one rather than a misreading.

How to read it#

Three rules that will save you money.

Read for shape, not for detail. The architecture — centralised settlement on the DESP, the role split, the liquidity mechanics — is stable enough to plan against. Field-level specifics are not.

Trust the flows over the prose. Where B2 and the narrative diverge, the end-to-end flows are the thing being implemented.

Track the gaps, not just the content. The unfinished sections are where your estimate is wrong. A plan that assumes the holding limit mechanics are a small addendum is a plan built on the one section nobody has written yet.