Digital euro, 3/6: as private as cash?

This is the third part of our six-part investigation into the digital euro. The first article followed the money from one balance sheet to another. The second reconstructed the ECB stress test producing €699 billion of deposit outflows. This third part leaves balance sheets behind and follows a different substance: data.

Status of the file as of 14 August 2026. The final regulation has not been adopted. Draft rulebook v0.91, published on 2 July 2026, is preliminary, non-binding and incomplete, particularly for offline use. The documentation for the 2027 pilot is separate. The properties described below therefore belong to the architecture currently proposed and do not describe a finished product.

You pay for a coffee in digital euros.

Your bank knows who you are. It opened the account, verified your identity and authenticated the payment.

The merchant knows what was sold. Its provider knows the amount, the acceptance terminal and the account to be credited.

The central platform must check the balance, record the transfer and return a status. An alias service may have resolved a phone number. Another component may calculate a fraud score from technical references, transaction context and, in the current draft, an IP address range.

The ECB nevertheless says it will not be able to directly link the payment to your identity.

All of those statements can be true at the same time.

The system is not designed to eliminate all data. It is designed to separate them: identity at the payment service provider, account and settlement data in the central infrastructure, surrogate values at SEPI, and cross-provider signals in the fraud mechanism.

The real question is therefore not whether a data point exists.

It is who can connect it to the others.

Eight things to remember

• Online digital euros would use an individual account and would not offer the anonymity of a digital banknote.
• A PSP would know its own customer and retain the information needed for payments, AML, fraud and disputes.
• The Eurosystem would process pseudonymised accounts and transactions without normally receiving the civil name.
• Pseudonymised does not mean anonymous: additional information can restore the link to the person.
• The alias service would currently map a mobile phone number to a digital euro account and the relevant PSP.
• The central fraud mechanism would look for anomalies across multiple PSPs and process technical metadata.
• The public documents cover the merchant, merchant category and amount. They do not establish general collection of every product in the shopping basket.
• Offline use could deliver genuinely cash-like privacy for transaction details, but the final implementation still has to be built and audited.

Private from whom?

The word “private” is close to meaningless unless the relevant observer is named.

A payment can be:

• private from the ECB;
• identifiable by the payer’s bank;
• visible to the merchant;
• analysed under a pseudonym by a fraud engine;
• accessible to a public authority in a targeted investigation;
• unavailable to advertisers;
• recorded locally on the phone.

Those conditions do not contradict one another.

The ECB’s privacy page uses a precise formula: the Eurosystem would not be able to directly link an online payment to the user. Data available to the ECB would be pseudonymised. The PSP would access the information needed to apply EU law, including anti-money laundering and counter-terrorist-financing rules.

The word “directly” carries much of the promise.

It means the central system should not ordinarily display a line such as:

Jane Smith, €4.20, café X, 08:42.

It does not mean the system receives no amount, timestamp, reference, technical account identifier or PSP identifier.

The Council mandate explicitly allows central banks and certain support services, according to their functions, to process a digital account identifier, the amount of an online transaction and an IP address range for the session. At the same time, it requires that these data cannot be attributed to a person, including through cross-checking with other information they hold.

The architecture therefore does not rely on universal blindness.

It relies on a legal and technical barrier preventing the final step back to identity.

Four words that public debate keeps mixing up

Four very different protections must be separated before following a payment.

To place those protections in the monetary architecture, our guide to reading a CBDC reviews the issuer, ledger, access, holding limits and privacy.

Anonymisation

Anonymisation reasonably breaks the link to the person.

Properly aggregated statistics can be anonymous. A stable account number for which a bank retains the mapping table is not.

Pseudonymisation

Pseudonymisation replaces or separates identity. Additional information can restore attribution.

The GDPR therefore continues to apply.

The draft rulebook describes an alias as a pseudonymous identifier that can be attributed to a person only by the distributing PSP or the user. The same broad principle applies to accounts and technical identifiers sent towards the central infrastructure.

Tokenisation

Tokenisation replaces data with a surrogate for a defined use.

SEPI can generate a token for a QR code, payment link or NFC transaction. An authorised PSP must still be able to request the underlying information in order to continue processing the payment.

A token masks the data while preserving a reversible mapping.

Encryption

Encryption makes content unreadable without the key.

The settlement service can carry encrypted objects between PSPs without needing to read all of them. Encrypted content does not remove the routing, timing or status metadata required for operation.

The transaction after identity separation

Draft rulebook v0.91 divides the system into several domains.

The PSP manages the customer relationship. The Digital Euro Service Platform, or DESP, includes services for:

• access and account management;
• alias lookup;
• settlement;
• SEPI;
• risk and fraud;
• disputes;
• data exchange;
• offline use.

The data-management document provides a simplified model. It explicitly says that it does not represent the whole information system or specify how every field will be stored.

That limitation matters.

A field in the model is not necessarily visible to every actor. A field absent from the diagram may already exist in the PSP’s own systems.

The following map describes a typical online payment without claiming that every field follows the same route in every use case.

The PSP’s data perimeter

The PSP is the least mysterious part of the system.

It opens the account, verifies identity and assigns or requests the necessary identifiers. It can manage:

• the DEAN, the account number specific to the digital euro;
• an optional alias;
• the linked bank account;
• waterfall settings;
• payment instruments and devices;
• transaction history;
• refunds;
• disputes;
• fraud alerts.

The ECB FAQ is explicit: for online transactions, PSPs would be able to identify users for compliance with AML rules.

Privacy from the Eurosystem therefore does not make the payment invisible to the bank.

It is intended to prevent the public infrastructure from receiving the final mapping table between the technical account and the civil identity.

Data required for central settlement

The settlement service cannot operate without transaction data.

It must:

• verify that an amount can be transferred;
• debit and credit technical entries;
• manage funding or defunding where the cap applies;
• guarantee atomic processing;
• return a status;
• allow a transaction to be located after an error or dispute.

The draft uses a UETR, a unique end-to-end transaction reference, together with an acceptance timestamp.

The settlement specification says DESP compiles the elements sent by the PSPs and forwards to each party only what it needs.

Some objects can be encrypted where they merely pass through DESP towards another PSP.

Other elements remain necessary to the platform:

• UETR;
• time;
• PSP identifiers;
• technical accounts or entries;
• amount;
• status;
• the presence of funding, defunding, refund or reservation objects.

A reference capable of locating an operation is not an identity.

It becomes a quasi-identifier when it can be connected to another source.

The phone number becomes a monetary address

The draft allows a payment to use either a DEAN or a simpler alias.

In the current alias-service draft, the only additional alias type currently supported is a mobile phone number.

The service must answer two questions:

• which DEAN corresponds to this number?
• which PSP should receive the request?

The number need not be exposed to the Eurosystem as a civil identity. It remains a data point closely associated with a person in ordinary life.

The directory therefore creates a sensitive chain:

phone number → DEAN → PSP.

That convenience creates familiar risks:

• can a query reveal that a number uses the digital euro?
• can an attacker test millions of numbers?
• are failed searches logged?
• what happens after a number changes?
• how is SIM swapping handled?
• how long is an old alias retained?
• who can administer the table?

The rulebook describes the API calls.

It does not yet publish complete operational answers to all of those questions.

SEPI’s protection perimeter

The Secure Exchange of Payment Information, or SEPI, service supports QR codes, payment links and NFC.

Its role includes generating surrogate values and validating cryptograms.

For NFC, SEPI creates a surrogate value and session keys during enrolment. During each payment, the device generates a cryptogram from metadata and a session key. The PSP then sends the cryptogram, token and required data to SEPI, which recalculates the result to verify authenticity.

For QR or payment links, a transaction-specific token can reduce the information directly exposed in the channel.

The SEPI procurement document also provides for detokenisation: an authorised PSP can retrieve the information associated with the surrogate value.

The decisive questions become:

• who controls the keys?
• can the SEPI operator see the underlying data?
• are tokens always unique?
• how long do they live?
• can tokenisation logs link several payments?
• who can request detokenisation?

SEPI improves transport privacy.

Its security depends on separating the visible surrogate from the table that opens it.

The technical profile produced by the fraud engine

The central Risk and Fraud Management component is the most sensitive part of online use.

The ECB procurement notice assigns it two functions.

Before settlement, it calculates a real-time score from details supplied by a PSP.

After settlement, it looks for fraud patterns using a cross-PSP view of transactions, receives statistics, stores some information related to scores and produces situational reports.

The logic is understandable.

Fraud can move money across several banks. Each provider sees only one fragment. A cross-provider system can identify patterns that no institution can observe alone.

The same property creates concentration risk.

The Risk and Fraud Management draft places the central score on the critical path for P2P and e-commerce payments. The PSP must receive the result before finalising its decision. Some point-of-sale payments may proceed without waiting in order to meet latency limits.

The public draft names fields including:

• Payment ID;
• UETR;
• payer PSP identifier;
• transaction-session IP address range;
• fraud status and type in daily feedback.

Several fields remain placeholders.

The public corpus therefore does not disclose the final feature set used by the model.

The Council mandate allows support services to process a unique account identifier, transaction amount and IP address range for fraud and dispute services. At the same time, it requires that those data cannot directly identify the user.

The serious debate begins here.

An engine does not need a name to recognise:

• repetition;
• velocity;
• a network of accounts;
• approximate geography;
• a sequence of devices;
• unusual behaviour.

That capability is useful against fraud.

It can also create a persistent technical profile.

Important questions remain unanswered in the public documents:

• score-retention period;
• depth of history;
• final variables;
• use of machine learning;
• training on real data;
• operator access;
• explanation of false positives;
• right to contest;
• granularity of reports sent to regulators;
• possible linkage with other DESP services.

The detailed scenario-based risk annex remains confidential.

The level of purchase detail

The claim that “the ECB will know your purchases” mixes three levels.

The merchant

The merchant obviously knows the basket it sold.

Its point-of-sale system can retain individual products, prices, discounts and the invoice.

The acquiring PSP

It knows the merchant, amount, terminal and information needed for the payment.

The central infrastructure

The data model includes, among other fields:

• amount;
• merchant or merchant account;
• a Merchant Category Code, or MCC;
• payment context;
• an optional reference or remittance field;
• an additional amount such as a tip.

The MCC describes a business category such as restaurants, transport, hotels or medical services.

It does not necessarily describe the shopping basket.

The current public corpus does not establish that DESP would systematically receive:

coffee, pastry, brand, ingredients and quantity.

A free or structured reference can nevertheless contain sensitive information if a PSP or merchant populates it.

The correct conclusion is:

the central infrastructure carries the amount and can route an encrypted MCC between authorised actors. The public corpus establishes neither that DESP reads this code in clear text nor general collection of every item purchased.

Static pseudonyms age badly

A pseudonym can be secure when created and become revealing later.

The CNIL and BfDI highlighted the risk of static identifiers in May 2026.

Suppose the central infrastructure sees the same technical identifier for months.

It does not know the name.

One operation may nevertheless be known from elsewhere:

• an unusual amount;
• a precise time;
• a receipt;
• an inspection;
• an incident;
• a bank funding event at the same moment.

If the match identifies the user behind the pseudonym, other operations carrying the same identifier can become linkable.

The authorities therefore recommend examining dynamic identifiers that rotate regularly or differ by context.

The current project uses several references:

• user ID;
• hashed technical proof;
• DEAN;
• UETR;
• token;
• device identifier;
• score identifier.

They serve different functions and are not necessarily visible to the same service.

The investigation needs clear answers to three questions:

1. which identifiers remain stable?
2. which services can see them together?
3. what additional information restores the person?

The privacy threshold regulators requested

As early as 2022, the EDPB proposed a threshold below which small online payments would not be traced or recorded by the intermediary for routine control purposes.

The idea is to reproduce a cash property: buying a coffee should not automatically carry the same traceability as a large transfer.

The 2023 EDPB-EDPS joint opinion also asks policymakers to:

• define transaction data precisely;
• make pseudonymisation a binding legal obligation;
• justify the need for a central fraud mechanism;
• examine less centralised options;
• clarify the responsibilities of each controller.

The online model documented in 2026 remains an account-based system with central settlement.

We did not find in rulebook v0.91 a general threshold making low-value online payments unrecorded by the PSP.

Parliament supports technologies such as zero-knowledge proofs in its negotiating position. That political objective is not yet a verified property of every technical flow.

Offline use changes the answer in a real way

Offline payment is not merely a degraded version of online settlement.

It seeks a different architecture.

Value would be loaded into a secure device. Transfer would occur directly between two nearby devices without a PSP or DESP intervening at payment time. The ECB says personal transaction details would be known only to payer and payee.

The Council mandate goes further: PSPs should process only information needed for offline funding, defunding and device authenticity. Offline transaction data should not be monitored or retained by the intermediary.

That is a meaningful difference.

It still does not mean that no data exist.

Local transaction history in offline mode

The draft end-to-end flows contain a journey for viewing offline transaction history.

The application queries secure storage on the device and displays the operations to the user.

That detail prevents another shortcut.

“The ECB does not receive the details” does not mean “no record exists on the phone”.

A local record can be needed for usability, balance updates, security or display.

The question is whether it can leave the secure domain through:

• cloud backup;
• telemetry;
• incident analysis;
• attacker extraction;
• software updates;
• legal process;
• secure-element compromise.

The public documentation does not yet settle those points.

Double spending: where cryptography meets policy

A banknote handed to somebody no longer remains in the payer’s hand.

A file can be copied.

Offline digital money must therefore prevent the same value from being spent twice without asking a central server to authorise every payment.

The expert study published by the EDPB in 2025 concludes that a system can feasibly combine privacy for honest users with double-spending resistance.

It examines tools including:

• blind signatures;
• secure hardware;
• value limits;
• delayed reconciliation;
• ex-post detection;
• identity revelation only when a user spends the same value twice.

The study does not validate the future ECB system.

It shows that solutions exist, with trade-offs.

Secure hardware can be attacked. Frequent reconciliation reduces offline autonomy. Conditional revelation requires hidden evidence. A low cap reduces risk at the expense of usefulness.

Parliament wants double-spending risk resolved before launch.

The final protocol is not public.

Losing the phone or recovering the money

Parliament’s negotiating mandate envisages that losing the device would mean losing offline digital euros without reimbursement.

That may sound severe.

It has a privacy logic.

To restore an exact balance after a device is destroyed, a system usually needs somewhere:

• a copy;
• a recent state;
• a proof;
• or the ability to reconstruct transactions.

The more complete recovery becomes, the more the central system needs to know about offline value.

The more the device resembles a banknote, the more likely loss becomes final.

This is not merely a user-experience choice.

It determines how much data the system needs in order to work.

Can public authorities recover an operation?

The project does not create a zone outside the law.

Online payments remain subject to rules on:

• anti-money laundering;
• counter-terrorist financing;
• sanctions;
• fraud;
• judicial investigations;
• payer rights;
• refunds;
• regulatory record-keeping.

The PSP holds the identity relationship.

A competent authority can request data under the applicable legal basis.

Privacy from the Eurosystem therefore does not mean targeted identification is impossible.

It seeks to prevent general, routine identification by the central bank.

The distinction between those powers must remain clear:

• systematic surveillance: a permanent central nominal payment history;
• targeted re-identification: access to information held by a PSP through a legal procedure.

The public corpus describes a prohibition on the first.

Ordinary law preserves the second.

The major blind spot: for how long?

The project has legitimate reasons to retain information:

• status tracking;
• refunds;
• unauthorised transactions;
• disputes;
• fraud;
• AML;
• sanctions;
• security;
• audit;
• PSP switching.

Public documents do not yet provide a complete retention schedule.

We do not know precisely how long the following would remain available:

• UETRs;
• DESP histories;
• fraud scores;
• IP addresses;
• alias searches;
• tokens and detokenisation tables;
• device identifiers;
• administrative logs;
• backups;
• corrected false positives.

A privacy architecture is not judged only by what it collects.

It is judged by how long those elements can be connected.

Six myths, six verdicts

Claim	Verdict as of 14 August 2026
“The ECB will see every purchase under a person’s name”	Not supported by the current design. The name remains at the PSP and central data would be pseudonymised.
“Nobody will be able to retrieve an online payment”	False. The PSP knows its customer and retains information required by applicable law.
“The system will know the exact products purchased”	Not established. Amount, merchant, MCC and references can circulate, but not necessarily the itemised basket.
“The central fraud engine is already a nominal surveillance database”	Not demonstrated. It can nevertheless create a cross-PSP technical profile without directly knowing the name.
“An offline payment produces no data”	False. Funding, device, local balance, local history and defunding produce data. Details should not reach the centre.
“Offline is already as anonymous as a banknote”	Too strong. It is the political and technical objective, but the final protocol still has to be built and audited.

Evidence status and open questions

Proposition	State of evidence
The PSP would know its customer’s identity	established by the distribution model and KYC/AML duties
The Eurosystem should not receive civil names in ordinary settlement	convergent legal and technical objective
Online accounts and transactions would be pseudonymised	provided for by the Council and supported by data-protection authorities
DESP would process amounts, technical accounts, references and statuses	documented in preliminary specifications
A phone number could be used as an alias	documented, currently the only extra alias type in the draft
RFM would analyse patterns across PSPs	documented in the procurement and draft
The final RFM data set is known	no, fields and the confidential risk annex remain incomplete
The ECB would systematically receive the itemised basket	not established
All identifiers would be dynamic	not demonstrated
A privacy threshold exists for low-value online payments	recommended by the EDPB; absent from the current rulebook
Offline payment details would not be reported centrally	explicit Council and ECB objective
The offline protocol already guarantees anonymity and prevents double spending	no, implementation is not final
Losing the device would always mean losing funds	Parliament position; legislative status remains provisional

The conclusion depends on one verb: connect

The ECB can design an infrastructure that does not receive names directly.

The PSP can retain identity.

SEPI can replace some data with tokens.

The settlement service can encrypt objects intended for other PSPs.

The fraud engine can work with technical identifiers.

The privacy of the whole system still depends on one test:

can an actor connect the fragments?

Pseudonymisation works when the key remains separate.

Tokenisation works when the mapping table is protected.

Encryption works when keys and metadata are controlled.

Offline works when honest devices can exchange value without creating a central history and without enabling double spending.

The European project has a credible architecture for preventing a central database from immediately displaying every payer’s name.

The public corpus does not yet contain all the evidence needed to show that correlation will remain impossible over time.

That boundary will need to be monitored through every new rulebook, regulation and technical contract.

Next: the legal boundary of programmable money

The fourth part addresses another common conflation.

Programmable money carries restrictions inside the monetary unit itself, such as expiry, spending categories or intrinsic conditions.

An ordinary account can already be frozen, seized or blocked under law without making the euro inside it programmable.

The next article will therefore separate:

• programmable money;
• conditional payments;
• reservation of funds;
• sanctions;
• fraud controls;
• judicial freezing;
• future changes to the law.

Sources and method

This article relies primarily on:

• the European Commission proposal;
• the Council negotiating mandate, particularly Articles 34 to 37 and Annexes III to V;
• Parliament’s ECON position and authorisation to negotiate;
• the ECB privacy page and FAQ;
• draft rulebook v0.91, particularly the annexes on data management, access and aliases, SEPI, risk and fraud, settlement, and end-to-end flows;
• the EDPB Statement 04/2022, the EDPB-EDPS Joint Opinion 02/2023, and the expert report on offline use;
• the joint CNIL and BfDI analysis;
• ECB procurements for risk and fraud, alias lookup, SEPI, and the offline solution.

The evidence register distinguishes a field present in a model, a field actually sent by an API, a field visible in clear text, a field merely routed, and a field whose retention is documented. Where the draft contains a placeholder or reserves requirements to a confidential annex, the article marks the gap instead of filling it with an assumption.