Digital euro technical architecture — DESP, APIs, ISO 20022

Let us deal with the question everybody asks first, because until it is answered nothing else lands.

No, it is not a blockchain#

The digital euro is not blockchain-based. Settlement is centralised on the Eurosystem's DESP — the Digital Euro Service Platform. There is no distributed ledger. There is no consensus protocol. There is nothing being mined, staked or validated by a network of peers.

This disappoints people, and it should not. A central bank issuing its own currency has no need for the one thing a blockchain provides — agreement among parties who do not trust a central authority. There is a central authority. It is the central bank. Introducing a consensus mechanism to a system with a single trusted issuer would add cost, latency and complexity in exchange for solving a problem that does not exist here.

So the correct mental model is not "crypto". It is: a large, centrally operated payments platform with a REST API in front of it.

The integration surface#

Every layer of the stack is an existing European standard:

Read that as a whole and the strategy is unmistakable. Nothing was invented. Every layer is something European payments teams have already met.

That is a deliberate reduction of the integration burden — and, in the case of CPACE, a deliberate reduction of dependence on infrastructure controlled outside the EU.

What the DESP owns, and what you own#

The division of responsibility is the architecture. Get this right and the rest follows.

The DESP owns:

• Settlement. The transfer of digital euro between accounts happens on the platform, not in your ledger. You do not move the money; you instruct the platform that moves it.
• Identifiers. Every DEAN is generated by the Eurosystem. You request an account and receive the identifier back. You never allocate one.

You own:

• Onboarding, KYC and the customer relationship.
• The front end.
• Compliance and regulatory responsibility — which stays with you even if you use a TSP.
• Your side of the liquidity mechanics.

The consequence worth internalising: a DEAN, unlike an IBAN, does not encode which institution holds the account. It cannot, because the institution is not where the account settles. The Eurosystem is.

Identifiers: DEAN and BEAN#

The DEAN is 18 alphanumeric characters:

EU  97  0  1234567890123
│   │   │  └── serial (13 digits)
│   │   └───── indicator: 0 = individual, 1 = business
│   └───────── check digits (ISO/IEC 7064 MOD 97-10)
└───────────── literal "EU" prefix

The check digits use ISO/IEC 7064 MOD 97-10 — the same family as the IBAN. That is a gift to implementers: you can validate a DEAN offline, client-side, before submitting anything, using an algorithm most payments engineers have already written once. Try it here.

Positions 5–18 — indicator plus serial — are the BEAN.

The liquidity mechanics are where the real work is#

If you are estimating this integration, do not estimate the happy-path payment. Estimate these.

The holding limit is enforced not by rejecting payments but by moving money automatically:

• Waterfall — digital euro exceeding the holding limit is automatically converted into commercial bank money on the user's linked non-digital euro account.
• Reverse waterfall — commercial bank money is automatically converted into digital euro when holdings are insufficient to execute a payment.

A payment bundled with one of these is a combined transaction — one operation, not two calls you sequence yourself.

The subtlety that catches teams out#

Waterfall is not always triggered by the up-front check. Two incoming payments arriving close together:

1. Transaction 1 arrives. Check: would it breach the limit? No. Waterfall not triggered.
2. Transaction 2 arrives before transaction 1 settles. Check: would it breach? At this instant, no. But after transaction 1 settles, it would.

To guarantee the limit holds, an additional waterfall step is performed after settlement. If you assume one pre-settlement check is sufficient, you have a bug that only appears under concurrency — the worst kind to find in production.

Offline is a different architecture#

The offline digital euro does not just relax the online design. It replaces it.

Value is stored on a secure element — a tamper-proof chip with pre-installed software that can store cryptographic data and run secure applications — on the user's own device. Payment happens device-to-device over NFC, with cash-like privacy, and no connection to anything.

That last clause is the architectural bombshell. With no connection, there is no central platform to arbitrate double-spending. The tamper-proof hardware is the integrity guarantee. This is why offline depends on a secure element rather than an app database, and why it is bounded by what device hardware supports.

Privacy is implemented, not promised#

Privacy works by pseudonymisation: the Eurosystem cannot directly identify individuals from payment data. The mechanisms behind that claim are concrete:

• Aliases — a pseudonymous identifier resolvable to a person only by the distributing PSP or the user themselves.
• SEPI — substituting payer, or payee and transaction, data with a surrogate value that carries no information itself, while still letting the authorised PSP retrieve what it needs to instruct settlement.
• Offline — cash-like privacy, because the transaction never traverses a central platform.

The honest summary#

The digital euro is a conventional, well-specified, centrally settled payments platform with a REST API, standard data semantics and one genuinely novel component in the offline hardware story.

For an engineering team, that is good news and bad news. Good: you already have these skills. Bad: you cannot justify the timeline by claiming the technology is exotic. It is not. The difficulty is in the liquidity edge cases, the certification, and building against a specification that is still moving.