What is a DEAN? The digital euro account number

Every payment system needs an answer to "where is the money going?" For SEPA, the answer is the IBAN. For the digital euro, it is the DEAN — the Digital Euro Account Number.

The comparison is useful, and it is also where people go wrong. The DEAN borrows the IBAN's best idea and deliberately discards its central one.

The structure#

A DEAN is exactly 18 alphanumeric characters, and every position is spoken for:

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

Positions 5–18 — the indicator plus the serial — are the BEAN, the Basic Euro Account Number.

The good idea it borrowed: check digits#

The check digits use ISO/IEC 7064 MOD 97-10. If that sounds familiar, it should: it is the same checksum family the IBAN uses.

This is a genuine gift to implementers, and it is worth being precise about why.

A checksum means a mistyped DEAN can be caught client-side, offline, before anything is submitted. No round trip. No API call. No error surfacing three systems downstream. The user typed one digit wrong, and the field goes red immediately.

Most payments engineers have already implemented MOD 97-10 once for IBAN validation. You can reuse that knowledge directly. Try it on our DEAN validator.

How MOD 97-10 works, briefly#

The mechanism is the same idea as the IBAN's:

1. Take the identifier with the check digits set aside.
2. Rearrange it into the canonical order the standard specifies.
3. Convert letters to digits (A=10, B=11, … Z=35).
4. Interpret the whole thing as one enormous integer.
5. That integer, mod 97, must equal 1.

The number is far too large for a 64-bit integer, so you process it in chunks, carrying the remainder — exactly as every IBAN implementation already does.

The property that makes MOD 97-10 worth the trouble: it catches all single-character errors and virtually all transpositions — the two mistakes humans actually make when copying an account number.

The central idea it discarded: routing#

Here is where the IBAN analogy breaks, and it breaks hard.

An IBAN tells you which institution holds the account. That is most of what an IBAN is for — the country code and the bank identifier are routing information. Given an IBAN, you know where to send the money.

A DEAN encodes nothing of the sort. There is no bank identifier. No country. Just a prefix, a checksum, one indicator digit, and a serial.

This is not an oversight. It follows necessarily from the architecture: DEANs are generated only by the Eurosystem, through the DESP, and settlement happens on the DESP. A PSP requests an account and receives an identifier back; it never allocates one from a range of its own.

There is no institution to encode, because the institution is not where the account settles. Your bank is a servicing layer over an account that lives on a central platform.

That difference has a practical edge. With an IBAN you can determine the bank offline, from the string. With a DEAN you cannot, ever. If your design assumes you can infer a counterparty's institution from their account number, it is wrong.

The indicator digit is doing real work#

Position 5 looks like padding. It is not. 0 means the account belongs to an individual; 1 means a business.

That single character separates two genuinely different rule sets:

So the indicator digit is not metadata — it tells you which physics apply. A business account has a holding limit of zero, which means every incoming payment waterfalls straight to commercial bank money on its mandatory linked account. An individual account may hold a balance and may have an alias.

If you are building validation, parse the indicator digit early and branch on it. Almost every rule downstream depends on it.

What to build#

Three things, in order of how much grief they will save you:

Validate client-side. MOD 97-10, before submission. It is cheap, offline, and it catches the error class that actually happens.

Never construct a DEAN. Not for tests you promote to fixtures, not for "temporary" placeholders, not for a demo. Only the Eurosystem generates them. A DEAN your system invented is a DEAN that will pass your checksum and fail everywhere real. Generate test values explicitly labelled as test values, and keep them out of anything resembling production.

Do not parse for routing. There is nothing in there to route on. Use the alias look-up service.

Try it#

The DEAN validator checks structure and check digits live in your browser, and generates test DEANs. Nothing is sent anywhere — the arithmetic runs locally, which is rather the point of a checksum you can compute offline.