Digitaler Euro: Banken brauchen jetzt eine State Machine statt SEPA-Flickwerk

Der digitale Euro führt ein zweites „System of Record“ ein. Statt wie bisher zwischen verschiedenen Konten Geld zu verbuchen, müssen Banken für einen zentralen Ledger erfassen, wer digitale Euros empfängt oder sendet. Diese Transaktionen liegen jenseits der eigenen IT-Hoheit, was ein eigenständiges Betriebsmodell erforderlich macht.

von Florian Bongartz und Jens Dittmer

Banken bekommen eine Vermittlerrolle für den digitalen Euro zugewiesen. Ähnlich wie bei klassischen SEPA-Zahlungen müssen sie ihre Kunden identifizieren (KYC), Geldwäsche und Betrug vereiteln (AML/Fraud) und – im Falle von Unternehmen, die in digitalen Euros zahlen möchten – auch überwachen, ob die Person, die eine Zahlung auslösen möchte, berechtigt ist und eventuelle Limits einhält.

Der zentrale Ledger oder die „Digital Euro Service Platform“ (DESP) speichert dagegen die finalen Zustände sowie die Transaktionen zwischen Wallets, vereinfacht gesagt also den jeweils aktuellen Kontostand von digitalen Euros und wer wem Geld geschickt hat.“

Kunden verwalten ihre digitalen Euros über das digitale Portemonnaie, das von den Banken bereitgestellt wird.

Operativ muss eine Bank also sämtliche Vorarbeiten leisten, bevor auf dem zentralen Ledger gebucht werden kann. Sie beantwortet vornehmlich die folgenden Fragen:

1.Wer ist mein Kunde und was macht er?
2.Will ich eine Transaktion erlauben oder nicht?
3.Wie kommuniziere ich mit dem zentralen Ledger?
4.Und wie mache ich die Wallet für Verbraucher und Firmenkunden zugänglich?

Eine Architektur für den digitalen Euro

Aus den klar getrennten Rollen zwischen Bank und Ledger ergibt sich ein Design-Prinzip, dem eine Architektur für den digitalen Euro folgen muss:

Die Bank entscheidet, der zentrale Ledger bucht.“

Benötigt wird praktisch ein Layer, der zwischen der DESP, den bankfachlichen Umsystemen und den Wallets vermittelt und dabei nachhält, in welchem Zustand sich eine gewünschte Transaktion derzeit befindet.

Beispiel: Ein Kunde möchte etwas kaufen und mit digitalen Euros bezahlen. Seine Wallet initialisiert daraufhin eine Zahlung (INIT). Anschließend prüft die Bank auf AML und Fraud und gibt die Zahlung vorläufig frei (PRE_APPROVED). Falls die eingesetzte Wallet über keine ausreichenden Mittel mehr verfügt, muss der fehlende Betrag auf dem Konto reserviert (RESERVED) werden, um ein Funding vorzunehmen (FUNDED). Danach erst kann die Zahlung tatsächlich freigegeben (AUTHORIZED) und ans Eurosystem (DESP) übergeben werden (COMMITTED). (Vgl. Abb. 1.)

Digitale Euros und Wallets managen

Freilich kann es während des Vorgangs jederzeit zu einem Fehler kommen oder ein Abbruch herbeigeführt werden. Auch auf solche Ereignisse muss der Layer reagieren. Bleibt etwa eine Rückmeldung aus, kommt es zu einem Timeout. Nutzer könnten das Bezahlen auch von selbst abbrechen oder bewusst einen Timeout herbeiführen. Hinzu kommt, dass die einzelnen Schritte, die eine Zahlung durchläuft, in einer anderen Reihenfolge ablaufen, je nachdem wie die Zahlung ausgelöst wird. Wird etwa im Geschäft via NFC-Schnittstelle bezahlt, liegt die SCA bereits vor, wenn die Zahlung initialisiert wird. Bei einer Wallet-to-Wallet-Transaktion unter Privatleuten dürfte eine zusätzliche Bestätigung durch den Nutzer erforderlich sein.

Die Architektur muss darüber hinaus berücksichtigen, dass auch die einzelnen Wallets selbst unterschiedliche Zustände annehmen können.

Neben dem technischen Angebot, das die Bank in ihr Online-Banking oder die Banking-App integriert, wird das zu entwickelnde IT-System aber auch ein „Wallet Lifecycle Management“ zu bieten haben.“

Der Grund: Die Bank wird für ihre Kunden Konten für den digitalen Euro auf dem zentralen Ledger eröffnen und muss die vom Ledger vergebene Kontonummer (DEAN) mit dem Girokonto verknüpfen, bevor Geld darauf geladen oder damit bezahlt werden kann (vgl. Abb. 2). Weil regulatorische Vorgaben oder Sanktionslisten dazu führen könnten, dass eine Wallet kein Geld mehr empfangen darf, müssen die Systeme mit einem entsprechenden Status (SUSPENDED) umgehen können.

Kein Empfang: Offline bezahlen

Das ist aber noch bei Weitem nicht alles. Mit dem digitalen Euro soll auch offline bezahlt werden können.

Mobiltelefone im Flugmodus oder Funklöcher, von denen Bahnreisende hin und wieder berichten, sollen niemanden daran hindern, digital zu bezahlen.“

Die beschriebene und den Banken einzurichtende State Machine sieht in solchen Fällen die Transaktionsdaten jedoch erst, wenn die Wallets wieder online gehen. Erst dann lassen sich die offline getätigten Zahlungen nachvollziehen und auf dem Ledger nachträglich verbuchen. Sowohl Bank als auch Eurosystem müssen also mit verspätet eingereichten und womöglich inkonsistenten Daten umgehen. Dies ist zwingend notwendig, weil die Bank nachprüfen können muss, ob eine Wallet, die im Offline-Zustand Transaktionen getätigt hat, eventuell kompromittiert oder manipuliert worden ist.

Offline-Transaktionen

Wer offline bezahlen möchte, wird seine Wallet vorher aufladen („funden“) müssen. Offen ist aber, wie Banken damit umgehen sollen, falls AML- und Fraud-Systeme bei einer offline getätigten Transaktion anschlagen. Das Problem:

Offline-Transaktionen gelten genauso als final wie online vorgenommene. Darum dürfte wohl ein eigener Status (PAID_OFFLINE) eingeführt werden, um Auffälligkeiten bei solchen Zahlungen zu dokumentieren und an die Aufsicht melden zu können.“

Eine bankfachliche Architektur, welche den digitalen Euro abbilden soll, besteht folglich aus mindestens drei Komponenten (vgl. Abb. 3):

1.Einer State Machine, welche sowohl Zahlungen als auch auf die Wallet bezogene Zustände verarbeitet und mit dem Eurosystem kommuniziert.
2.Einer Art „Offline Manager“, der die offline getätigten Transaktionen überprüft und für die State Machine bereitstellt, um sie einheitlich zu verarbeiten.
3.Einem eventorientierten Archiv, das jeden Verarbeitungsschritt einer Transaktion fortschreibt.

Eventorientiertes Archiv unverzichtbar

Eine Komponente, die sich leicht unterschätzen lässt, ist das Archiv. Weil sich die DESP darauf verlässt, dass die Banken zulässige Vorgänge melden, muss die Bank sicherstellen, dass sie die bereits besprochenen Vorarbeiten wie AML, Fraud oder auch Sanktionslisten erledigt hat und dies revisionssicher dokumentieren. In der Praxis wird dies auch operative Anpassungen erforderlich machen. Beispielsweise muss die Bank eine Wallet suspendieren, sobald der Wallet-Inhaber auf einer Sanktionsliste auftaucht.

Ähnlich wie durch die IPR (Instant Payment Regulation) vorgegeben, werden die Institute deshalb ihren Kundenstamm regelmäßig überprüfen und nachweisen müssen, ob und wann sie tätig geworden sind.“

Das Archiv stellt insoweit eine lückenlose Historie zu den von der Bank gemeldeten Zustandsänderungen am Ledger dar.

Darüber hinaus bietet es für die Bank eine Möglichkeit, den jeweils aktuellen Zustand von Wallets und Zahlungen zu bestimmten Zeitpunkten zu rekonstruieren. Dies erlaubt, Daten- und Informationsverluste zu kompensieren oder granulare Reports auf sämtliche Aktivitäten der State Machine zu erstellen.

Wenn die Bank in diesem Archiv zusätzlich ihre Events aus der SEPA-Kernverarbeitung abspeichert, entsteht so ein Datenpool, der eine konsistente Sicht auf den gesamten Euro-Zahlungsverkehr innerhalb der Bank ermöglicht.“

Darauf sollte keine Bank verzichten, weil sich aus diesen Daten ableiten lässt, wie sich der eigene Kundenstamm im Alltag verhält. Daraus lassen sich Prognosen erstellen, die dem Treasury dabei helfen, für alle Zahlungssysteme die entsprechende Liquidität am Zentralbankkonto bereitzustellen.

Digitaler Euro und Liquiditätsmanagement

Liquidität am Zentralbankkonto sauber zu steuern, wird in der Echtzeitwelt immer wichtiger, um Engpässe und darauf resultierende Zahlungsausfälle zu verhindern. Dafür pflegen die Institute Dedicated Cash Accounts (DCA), über die sie stets ausreichend Mittel bereitstellen, um beispielsweise Instant Payments über TIPS (TARGET Instant Payment Settlement) zu buchen. Beim digitalen Euro wird es wahrscheinlich ebenfalls einen eigenen DCA geben, jedoch mit einem entscheidenden Unterschied:

Anders als bei den übrigen DCAs werden über den D€-DCA keine Zahlungen gesettled, sondern das Funding der Wallets.“

Die Zentralbank wird den D€-DCA einer Bank belasten, sobald ein Kunde seine Wallet „funded“ und dadurch Giralgeld in Zentralbankgeld tauscht. Die Zahlungen werden direkt am Ledger verbucht.

Zwar bleibt offen, ob Kunden wirklich jedes Mal ihre Wallet „funden“, bevor sie einkaufen gehen, oder ob es in den meisten Fällen zum automatischen Funding während des Bezahlens kommt. Welches Szenario tatsächlich eintritt, kann die Bank aber nicht voraussehen. Sie muss strukturell damit rechnen, dass das Funding asynchron zum Bezahlen stattfinden kann. Darum – und auch wegen der Offline-Transaktionen, die bereits „gefundete“ Wallets voraussetzen – entsteht dadurch aber ein zusätzlicher Liquiditätskreislauf, der sich anders verhalten kann als bei klassischen SEPA-Zahlungen.

Die Banken müssen folglich lernen, wie sich ihre Kunden verhalten, damit sie beide Liquiditätskreisläufe sauber bedienen können.“

Hier entsteht sogar ein möglicher Anwendungsfall für KI, weil sich mit den Modellen Muster schneller erkennen und Szenarien viel einfacher durchspielen lassen als bislang.

Haltelimits
Aktuell ist ein Haltelimit von 3.000 Euro in den Wallets von Verbrauchern geplant. Wer einen höheren Betrag bezahlen möchte, löst dadurch automatisch ein Funding über seine Bank beziehungsweise das verbundene Girokonto aus. Händler auf der anderen Seite sollen keine digitalen Euros halten dürfen, weshalb – durchgesetzt über ein Haltelimit von null – deren Wallets permanent „defunded“ („Auto-Sweep“) werden dürften. Beides beeinflusst maßgeblich die erforderliche Liquidität am Zentralbankkonto.

Einlagengeschäft bedroht?

Kritiker gehen sogar noch weiter und warnen, dass der digitale Euro möglicherweise das klassische Einlagengeschäft der Bank bedroht. Wenn Kunden ihre Einlagen in digitale Euros umwandeln und bei der Zentralbank statt bei den Geschäftsbanken halten, fließt Guthaben aus den Bankbilanzen ab (vgl. Abb. 4), das die Institute bislang dafür unter anderem verwenden, um sich zu refinanzieren oder Kredite zu vergeben. Wie wahrscheinlich solche Szenarien sind und ob sich „Bank-Runs“ durch den digitalen Euro unter Umständen beschleunigen könnten, soll hier nicht geklärt werden. Wohl aber sollten sich die Banken darauf einstellen, dass sich der digitale Euro auf ihr übriges Geschäft auswirkt. Aus diesem Grund ist ein unverstellter Blick auf das Kundenverhalten unabdingbar für die Gesamtbanksteuerung.

Insgesamt zeigt sich, dass es sich bei dem digitalen Euro um weit mehr handelt als eine weitere Währung oder ein zusätzliches „Payment Scheme“ für die bereits bestehende IT im Zahlungsverkehr. Konto-Welt und Wallet-Welt arbeiten dafür zu unterschiedlich. Aber: Aus IT-Sicht bedeutet dies, dass sich der digitale Euro gut kapseln lässt.

Das bedeutet für jene Banken, die parallel ihre Kernverarbeitung modernisieren wollen, dass sie sich durch den digitalen Euro keine unlösbaren Probleme einhandeln werden.“

Eine Verarbeitungsschicht für den digitalen Euro lässt sich vielmehr auch als eigenständiges Modul betreiben, mit einer eher geringen technischen Integrationstiefe. Eine solche Architektur eignet sich zudem, um sie als eigenständigen Service zu modellieren.Florian Bongartz und Jens Dittmer, PPI