DESP – Digital Euro Service Platform

Last updated: 14 September 2026

The Digital Euro Service Platform (DESP) is the Eurosystem’s central technical platform for the digital euro. The Eurosystem glossary defines it as “the technical platform enabling the issuance and redemption of digital euro and providing functions (e.g. settlement) that cannot be accomplished by an individual intermediary on its own”. That is its whole role: it pools what has to be collective and leaves everything else with the payment service providers.

How it differs from what exists

The DESP is not a bank product and not an end-user application – the customer sees their institution’s app, never the platform. Nor is it a TARGET service: T2, T2S and TIPS remain what they are and are still reached through the Eurosystem Single Market Infrastructure Gateway, while the DESP runs on its own infrastructure with its own connectivity. Finally, it has to be kept apart from the scheme: the Digital Euro Scheme Rulebook sets out who may and must do what, and the DESP is the technology that carries it out.

Timeline and current state

Decided and delivered. After the investigation phase, the Commission tabled its proposal for a regulation in June 2023. The Eurosystem’s preparation phase ran from November 2023 to the end of 2025; since then the Eurosystem has been working on technical readiness. The platform components have been awarded, the rulebook exists as a draft that keeps being developed, and a binding interface specification for the pilot has applied since April 2026.

The pilot itself is planned for the second half of 2027 over twelve months, with a possible first issuance during 2029. Both depend on the legislative process: only once the regulation is in force can the Governing Council decide on issuance.

What the platform does

The interface specification for the pilot divides the platform into five service domains: Access Management, Alias Lookup, Secure Exchange of Payment Information, Settlement and Data Exchange. Added to these are the services institutions use inside their own applications: risk and fraud management, app and SDK, and the offline solution.

Sourcing is split in two. Issuance, redemption and settlement are provided by the Eurosystem itself, with the components built by a consortium of six national central banks, among them the Deutsche Bundesbank. Five further components were procured externally by the ECB: alias lookup, risk and fraud management, app and SDK, the offline solution and the secure exchange of payment information. Connectivity is the subject of a separate procurement – it covers the link from external actors to the platform and the link between platform components.

Three services need to be handled in daily operations of an PSP:

• Access management. Every payment account receives a unique identifier, the DEAN (Digital Euro Access Number), generated by the platform at the institution’s request. End users themselves are held against the platform only under a hashed identifier created by the institution.
• Alias lookup. The directory service maps an easily remembered alias – the mobile phone number in the pilot – to the institution servicing the account. The payer does not need to know the counterparty’s DEAN.
• Risk and fraud management. A cross-scheme component adds to the institutions’ own controls a view no single house has: patterns across institutional boundaries.

How institutions connect

Communication between an institution’s back end and the platform runs over synchronous REST interfaces in JSON. The platform acts as the hub: it routes between the institutions involved, and no direct institution-to-institution link is provided for. Business rejections and technical errors are handled separately – a rejected booking comes back with a reason code through the regular response, a malformed call with an HTTP error code.

The data models are not newly invented. They derive from ISO 20022, the Mobile P2P Interoperability Framework of the Berlin Group and CPACE. The vocabulary is therefore familiar, even if the transport is not.

Settlement and liquidity

Holdings are recorded in the Eurosystem’s central ledger, and settlement is atomic: a payment either completes in full or not at all. Funding, defunding, payments, combined transactions and refunds are all covered.

For liquidity, each participating institution holds a dedicated cash account for the digital euro. This DCA is a TARGET account in central bank money and is maintained in TARGET’s central reference data – but it is held on the DESP, not in CLM. That follows the familiar pattern of the TARGET services: CLM holds the main accounts, each settlement service its own DCAs.

Transfers between the two sides run across a pair of transit accounts and are always initiated from CLM, in push or pull mode. CLM debits the main account and credits the transit account for the DESP; on the DESP the mirror booking debits the transit account for CLM and credits the DCA.

On the TARGET side this brings further adjustments – inclusion of the DCAs in minimum reserve and interest calculation, maintenance of the accounts in central reference data, and the feed of general ledger data into reporting.

Privacy architecture

Processing is deliberately spread across several components and kept separate. End-user identities are not visible to the Eurosystem: onboarding, identity verification and anti-money-laundering stay with the institution, which passes only pseudonymised identifiers to the platform. Technical service providers engaged by an institution likewise access only pseudonymised data – responsibility stays with the institution.

Relevance for banks and payment service providers

• A new connection, not a new format. Institutions that connect today over EBICS and SWIFT get another channel with its own technology: synchronous REST calls instead of file transfer, dedicated connectivity instead of ESMIG.
• The DCA is treasury work. Another account in central bank money means funding decisions, cover checks and reconciliation – and it feeds into the minimum reserve calculation.
• The identifiers are the quiet effort. DEAN, hashed user identifier and alias have to be held permanently and maintained across their life cycle. An institution that merely passes them through will later be unable to reconcile or resolve incidents.
• Things are still moving. Rulebook and specifications keep being developed and the regulation is not adopted. Interfaces should be designed to be versionable.

Sources for specifications

• ECB – Digital euro glossary (PDF): definition of the DESP
• ECB – Digital euro pilot: back-end implementation specifications (PDF)
• ECB – FAQs on the digital euro pilot
• ECB – Preparation phase of a digital euro, closing report
• ECB – T2 adaptations due to the digital euro, change request (PDF)
• ECB – DESP-T2 interactions in the context of the digital euro (PDF)
• ECB – procurement: network service provider connectivity for the digital euro service platform (PDF)