Drei Wahrheiten, ein Problem: Warum Banken beim Digitalen Euro kein Shadow Ledger brauchen

Die deutschen Banken beginnen damit, sich auf die Pilotphase des Digitalen Euros vorzubereiten und ihre Systeme auf die neue „Wallet-Welt“ vorzubereiten. Das zweite „System of Record“ bei der Zentralbank, welches alle Konten für den Digitalen Euro hält, bereitet noch einige Sorgen: Wie sollen die Buchungen nachvollzogen werden? Dabei kommt häufig eine Schattenbuchung ins Spiel, doch es gibt eine elegante Alternative.

von Florian Bongartz, Senior Business Development Manager bei PPI

Ähnlich wie bei Tolkien gibt es beim Digitalen Euro das Äquivalent des einen Ringes – „One Ledger to rule them all“ – und das ist der zentrale Ledger bei der Europäischen Zentralbank (EZB). Auf der Digital Euro Service Platform (DESP) wird über alle Konten für den Digitalen Euro Buch geführt. Anders als beim kontobasierten SEPA-Zahlungsverkehr liegt dieses System also außerhalb der bankfachlichen IT-Hoheit. Vielmehr müssen die Banken dafür sorgen, dass alle relevanten Vorarbeiten vorgenommen werden, bevor eine Transaktion an die DESP übergeben wird. Dazu gehören…

• … Wallets eröffnen oder schließen und mit dem Girokonto verbinden
• … Geldwäsche (AML), Betrug (Fraud) und Sanktionslisten (Embargo) überwachen
• … Funding und De-Funding von Wallets vornehmen (Waterfall/Reverse Waterfall)

… und einiges mehr. Aber final buchen, das macht eben ausschließlich „der eine Ledger“.

Verlockungen der Schattenbuchhaltung

Rein praktisch stellen sich viele Banken deshalb die Frage, wie sie sich darüber auf dem Laufenden halten, was auf diesem zentralen Ledger passiert. Vermeintlich auf der Hand liegt etwas, das beispielsweise beim Wechsel von der Batch-Welt in die Echtzeit-Welt (Stichwort: „Instant Payments“) schon das eine oder andere Mal als Retter in der Not eingesetzt wurde: Eine Schattenbuchhaltung, die das Echtzeitgeschehen zwischenspeichert, bevor es in den batch-orientierten Kernbanksystemen nachvollzogen wird.

In dieser „Schattensicht“ würde nachgehalten, welche Wallets welche Bestände halten, welche Transaktionen in welchem Status stecken, welche Kunden wann ihre D€-Wallet eröffnen wollen und auch, wo welche Fehler aufgetreten sind. Das komplette Programm, einmal gespiegelt, um die Wahrheit auf dem zentralen Ledger jederzeit zur Hand zu haben. Die Bank spart sich permanente Abrufe bei der DESP, was angesichts der knappen Latenzen ohnehin nahezu zwingend vermieden werden sollte. Die eigene Plattform gerät dagegen unter Stress.

Aus eins mach drei: Was gilt?

Ein solcher Shadow Ledger würde neben dem kontoführenden System der Bank und dem zentralen D€-Ledger eine dritte Wahrheitsquelle einführen, was permanente Reconciliation nach sich zöge. Hinzu kommt der ständige Abgleich mit den bankfachlichen Umsystemen, zu denen insbesondere das Core Banking und die AML-/Fraud- sowie die Treasury-Systeme gehören. Im „Happy Case“ mag sich das alles noch gut anfühlen. Doch was, wenn etwas schiefgeht?

Wann immer eine Transaktion nicht sauber abschließt, sei es wegen eventueller Timeouts, partiell durchgeführten Buchungen oder Fehlern im Settlement, müssen die Institute alle drei Wahrheiten in Einklang bringen, um handlungsfähig zu bleiben. Dieses Unterfangen dürfte für erheblichen Betriebsaufwand sorgen, weil sich Timing, Granularität und wohl auch die Semantik der beteiligten Systeme teils stark voneinander unterscheiden.

Hinzu kommt, dass sich auch der Shadow Ledger permanent weiterentwickeln muss, und zwar mit jeder Änderung, die sich am zentralen Ledger ergibt.

Alternative: Ergebnisse statt Zustände

Glücklicherweise ergibt sich aus der Systemarchitektur eine elegante Alternative: Event Sourcing. Statt Zustände zu speichern, werden Ereignisse gespeichert. Das Rulebook zum Digitalen Euro gibt dies ohnehin indirekt vor, weil eine Bank die Statuswechsel für einzelne Transaktionen dokumentieren muss, um später nachweisen zu können, dass die geforderten Kontrollen tatsächlich durchgeführt wurden.

Jede Statusänderung, von der Zahlungsinitiierung über die Autorisierung bis hin zum von der DESP bestätigten Settlement landet bei diesem Designansatz als unveränderliches Ereignis in einem transaktionalen Archiv.“

Dies ermöglicht, jeden beliebigen Zustand zu jedem beliebigen Zeitpunkt herzuleiten. Damit wäre das Problem des Shadow Ledgers an der Wurzel gepackt: Keine Redundanz zwischen Archiv und operativem System mehr und kein drittes System, das mit einem eigenen Wahrheitsangebot mit DESP und Banksystemen konkurriert.

Was diese Idee so elegant macht: Statt die DESP zu kopieren und zu beantworten, was auf der DESP passiert, klärt das transaktionale Archiv, wie es überhaupt erst zu den „final States“ auf der EZB-Plattform kommen konnte. Es erzeugt aber keine zweite Wahrheit daneben, sondern ein komplementäres Set aus analytischen und historischen Daten. Dieser Ansatz unterscheidet sich von vielen anderen Archivsystemen, die auf das Ergebnis von Transaktionen fokussieren, nicht aber auf das, was auf dem Weg dorthin passiert ist.

Zusätzlichen Nutzen stiften

Aus den zahlreichen Ereignissen und Ereignisketten, die nach und nach das transaktionale Archiv bevölkern, ergibt sich ein vollständiges Bild über den gesamten Lebenszyklus einer Transaktion. Damit lassen sich auch andere Bereiche innerhalb der Bank mit den für sie relevanten Ereignisdaten versorgen. Konkret gerät dabei das beim Digitalen Euro etwas trickreiche Liquiditätsmanagement in den Blick, denn der kontobasierte Zahlungsverkehr unterscheidet sich erheblich vom „wallet-basierten“ Zahlungsverkehr.

Bislang stellen die Banken Liquidität über verschiedene Dedicated Cash Accounts (DCA) bereit, um das Clearing zu ermöglichen. Bei Instant Payments gibt es beispielsweise einen DCA für TIPS (TARGET Instant Payment Settlement), wo Clearing und Settlement in Echtzeit zusammenlaufen. Einen solchen DCA wird es auch für den Digitalen Euro geben, doch mit einem entscheidenden Unterschied.

Bei SEPA-Transaktionen kommt es auf die Zahlung an, welche sich auf die Liquidität am DCA auswirkt. Digitale Euros werden jedoch über eine Wallet ausgegeben, die auch vorab von den Nutzern aufgeladen worden sein könnte oder zuvor empfangenes Geld enthält. Das die Liquidität am DCA beeinflussende Momentum ist deshalb nicht die Zahlung, sondern das Funding der Wallet, also der Tausch von Guthaben auf dem Girokonto in Zentralbankgeld.

Sollen die SEPA-Rails und der Digitale Euro gemeinsam gesteuert werden, wäre eine einheitliche Sicht auf beides gleichzeitig ideal. Ein transaktionales Archiv eignet sich dafür besonders. Dadurch entwickelt es sich zum zentralen Wahrheitsscharnier zwischen der kontobasierten Welt und der wallet-basierten Welt.

Ein System mit unterschiedlichen Empfängern

Welche Vorteile sich daraus ergeben, soll ein praktisches Beispiel zeigen. Eine Großbank in Land A betreibt eine Tochtergesellschaft in Land B. Diese Tochtergesellschaft betreibt selbst ein Zahlungsverkehrssystem, obwohl die Konzernmutter zentral die Liquidität steuert. Eine ganz ähnliche Konstellation kann sich ergeben, wenn eine Bank Teile des Zahlungsverkehrs auslagern, die Liquidität aber weiterhin selbst steuern möchte.

In Konstellationen wie diesen wäre es erheblich aufwendiger, die relevanten Zustände aus dem Shadow-Ledger zu extrahieren und in Bewegungsdaten zu verwandeln. Landen diese Daten jedoch von vornherein in einem transaktionalen Archiv, lassen sich die für andere IT-Systeme relevanten Ereignisse abonnieren. Im konkreten Beispiel würden sich die Treasury-Systeme beispielsweise die liquiditätsrelevanten Ereignisse im gewünschten Format direkt abholen lassen.

Banken, die für den Digitalen Euro einen eigenen Shadow Ledger planen, sollten ein transaktionales Archiv ernsthaft prüfen, bevor sie entwickeln.

Ein solches Archiv liefert dieselben Informationen und zusätzlich eine belastbare, historische Datengrundlage, die ein reines Zustandssystem kaum bieten kann. Florian Bongartz, PPI