DESP – Digital Euro Service Platform

Stand: 14. September 2026

Die Digital Euro Service Platform (DESP) ist die zentrale technische Plattform des Eurosystems für den digitalen Euro. Das Glossar des Eurosystems definiert sie als „die technische Plattform, die die Ausgabe und Rücknahme digitaler Euro ermöglicht und Funktionen bereitstellt – etwa das Settlement –, die ein einzelner Intermediär nicht allein erbringen kann“. Darin liegt ihre ganze Rolle: Sie bündelt das Gemeinschaftliche und lässt alles andere bei den Zahlungsdienstleistern.

DESP läuft auf eigener Infrastruktur mit eigener Netzanbindung. Zu trennen ist sie schließlich vom Scheme: Das Digital Euro Scheme Rulebook regelt, wer was tun darf und muss, die DESP ist die Technik dazu.

Zeitplan und Stand

Nach der Untersuchungsphase legte die Kommission im Juni 2023 ihren Verordnungsvorschlag vor. Die Vorbereitungsphase des Eurosystems lief von November 2023 bis Ende 2025. Die Bausteine der Plattform sind vergeben und das Rulebook liegt als fortgeschriebener Entwurf vor. Seit April 2026 gilt eine verbindliche Schnittstellenspezifikation für den Pilotbetrieb.

Der Pilotbetrieb ist für die zweite Jahreshälfte 2027 über zwölf Monate vorgesehen, eine mögliche erste Ausgabe im Lauf von 2029. Beides steht unter dem Vorbehalt des Gesetzgebungsverfahrens: Erst wenn die Verordnung in Kraft ist, kann der EZB-Rat über die Ausgabe entscheiden.

Was die Plattform leistet

Die Schnittstellenspezifikation für den Pilotbetrieb gliedert die Plattform in fünf Servicebereiche: Access Management, Alias Lookup, Secure Exchange of Payment Information, Settlement und Data Exchange. Hinzu kommen Dienste, die die Institute in ihren eigenen Anwendungen nutzen: Risiko- und Betrugsmanagement, App und SDK sowie die Offline-Lösung.

Der Bezug ist zweigeteilt. Ausgabe, Rücknahme und Verbuchung erbringt das Eurosystem selbst; die Bausteine dafür entwickelt ein Verbund aus sechs nationalen Zentralbanken, darunter die Deutsche Bundesbank. Fünf weitere Komponenten hat die EZB extern ausgeschrieben: Alias Lookup, Risk and Fraud Management, App und SDK, die Offline-Lösung und den gesicherten Austausch von Zahlungsinformationen. Die Netzanbindung ist Gegenstand einer eigenen Ausschreibung – sie deckt die Verbindung der externen Beteiligten zur Plattform ab und die Verbindung der Plattformteile untereinander.

Drei Dienste prägen die operativen Abläufe der Institute:

• Access Management. Jedes Zahlungskonto erhält eine eindeutige Kennung, die DEAN (Digital Euro Access Number), die die Plattform auf Anforderung des Instituts erzeugt. Die Endnutzer selbst werden gegenüber der Plattform nur mit einer gehashten Kennung geführt, die das Institut bildet.
• Alias Lookup. Der Verzeichnisdienst ordnet eine leicht merkbare Kennung – im Pilotbetrieb die Mobilfunknummer – dem kontoführenden Institut zu. Der Zahler muss die DEAN der Gegenseite nicht kennen.
• Risk and Fraud Management. Eine übergreifende Komponente ergänzt die Betrugsabwehr der Institute um eine Sicht, die ein einzelnes Haus nicht hat: Muster über Institutsgrenzen hinweg.

Anbindung der Institute

Die Kommunikation zwischen dem Backend eines Instituts und der Plattform läuft über synchrone REST-Schnittstellen im JSON-Format. Die Plattform arbeitet als Vermittlungsstelle: Sie leitet zwischen den beteiligten Instituten weiter, eine direkte Verbindung von Institut zu Institut ist nicht vorgesehen. Fachliche Ablehnungen und technische Fehler sind getrennt geregelt – eine abgelehnte Buchung kommt mit Ablehnungsgrund im regulären Antwortweg zurück, ein fehlerhafter Aufruf mit HTTP-Fehlercode.

Die Datenmodelle sind bekannt: sie leiten sich aus ISO 20022, dem Mobile P2P Interoperability Framework der Berlin Group und CPACE ab. Die Begriffswelt ist damit vertraut, auch wenn der Transportweg ein anderer ist.

Settlement und Liquidität

Verbucht wird im zentralen Ledger des Eurosystems, und zwar atomar: Eine Zahlung wird vollständig ausgeführt oder gar nicht. Abgedeckt sind Aufladen, Zurückbuchen, Zahlungen, kombinierte Vorgänge und Erstattungen.

Für die Liquidität führt jedes teilnehmende Institut ein Dedicated Cash Account für den digitalen Euro. Dieses DCA ist ein TARGET-Konto in Zentralbankgeld und wird in den zentralen Stammdaten von TARGET angelegt, geführt wird es aber auf der DESP, nicht in CLM. Das folgt dem bekannten Muster der TARGET-Dienste: CLM führt die Hauptkonten, jeder Abwicklungsdienst seine eigenen DCAs.

Der Übertrag zwischen beiden Seiten läuft über ein Paar von Transitkonten und wird immer aus CLM angestoßen, im Push- oder im Pull-Verfahren. CLM belastet das Hauptkonto und erkennt das Transitkonto für die DESP; auf der DESP wird spiegelbildlich das Transitkonto für CLM belastet und das DCA erkannt.

Auf der TARGET-Seite zieht das weitere Anpassungen nach sich: die Einbeziehung der DCAs in Mindestreserve, die Zinsberechnung, die Führung der Konten in der zentralen Stammdatenhaltung und die Übernahme der Hauptbuchdaten in das Berichtswesen.

Datenschutzarchitektur

Die Verarbeitung ist bewusst auf mehrere Komponenten verteilt und voneinander getrennt ausgelegt. Für das Eurosystem sind die Identitäten der Endnutzer nicht sichtbar: Onboarding, Identitätsprüfung und Geldwäscheprävention bleiben beim Institut, das der Plattform nur pseudonymisierte Kennungen übermittelt. Auch technische Dienstleister eines Instituts greifen ausschließlich auf pseudonymisierte Daten zu (die Verantwortung bleibt beim Institut).

Bedeutung für Banken und Zahlungsdienstleister

• Ein neuer Anschluss, kein neues Format. Wer heute über EBICS und SWIFT anbindet, bekommt einen weiteren Kanal mit eigener Technik: synchrone REST-Aufrufe statt Dateiübertragung, eigene Netzanbindung statt ESMIG.
• Das DCA ist Treasury-Arbeit. Ein weiteres Konto in Zentralbankgeld bedeutet Disposition, Deckungsprüfung und Abstimmung (Mindestreserverechnung).
• Die Kennungen sind der stille Aufwand. DEAN, gehashte Nutzerkennung und Alias müssen dauerhaft geführt und über den Lebenszyklus gepflegt werden. Wer sie nur durchreicht, kann später weder abgleichen noch Störfälle klären.
• Es ist noch Bewegung drin. Rulebook und Spezifikationen werden fortgeschrieben, die Verordnung ist nicht beschlossen. Schnittstellen sollten versionierbar angelegt werden.

Quellen für Spezifikationen

• EZB – Digital euro glossary (PDF): Definition der DESP
• EZB – Digital euro pilot: Back-end implementation specifications (PDF)
• EZB – FAQs on the digital euro pilot
• EZB – Preparation phase of a digital euro, Closing report
• EZB – T2 Adaptations due to Digital Euro, Change Request (PDF)
• EZB – DESP-T2 interactions in the context of the digital euro (PDF)
• EZB – Ausschreibung Network Service Provider Connectivity for the digital euro service platform (PDF)