Es wird noch einige Jahre dauern, bis die EZB den digitalen Euro in Form einer digitalen Zentralbankwährung einführt. Programmierbare Zahlungen und Triggerlösungen bieten bereits heute eine Möglichkeit den programmierbaren Euro zu realisieren.
Digitalisierung und neue Technologien stellen neue Anforderungen an den Zahlungsverkehr der Zukunft.
Partner des Bank Blogs
Im ersten Teil unserer vierteiligen Artikelserie zum Zahlungsverkehr der Zukunft wurden die Grundlagen des Internet of Things und deren Implikationen für den Zahlungsverkehr der Zukunft dargestellt. Im zweiten Teil wurde erläutert, wie Zahlungen heutzutage durchgeführt werden. Zudem wurden hiermit einhergehende Probleme sowie Ineffizienzen des derzeitigen Zahlungssystems thematisiert. Heute nun geht es um Lösungsmöglichkeiten und Modelle eines modernen Zahlungssystems, das die Vorteile der Digitalisierung und Automatisierung abbilden kann.
Die zwei Arten des digitalen Euros
Um Prozesseffizienzen zu erhöhen und die im vorherigen Artikel beschriebenen Limitationen des SEPA-Systems zu adressieren, ist die Schaffung eines innovativen europäischen Geldsystems unerlässlich. So könnte beispielsweise die EZB eine digitale Zentralbankwährung (engl. Central Bank Digital Currency, CBDC) – häufig auch als „öffentlicher digitaler Euro“ bezeichnet – emittieren. Bei einem öffentlichen digitalen Euro hält der Kunde eine Forderung gegenüber der EZB. Bislang handelt es sich bei einer CBDC lediglich um ein theoretisches Konzept: Die EZB hat sich noch nicht darauf festgelegt, ob tatsächlich eine CBDC emittiert wird. Sollte sie sich dafür entscheiden, dürfte es noch mindestens fünf Jahre dauern, bis das digitale Geld den privaten und institutionellen Endkunden zur Verfügung steht.
Übersicht über die unterschiedlichen Formen des digitalen Euros. Neben dem öffentlichen digitalen Euro arbeiten Banken, E-Geld-Institute und teilweise auch nicht-regulierte Akteure derzeit an einem sogenannten privaten digitalen Euro.
Neben dem öffentlichen digitalen Euro arbeiten E-Geld-Institute, Banken, und teilweise auch nicht regulierte Akteure derzeit an einem sogenannten privaten digitalen Euro (siehe Abbildung 2) – einem DLT-basierten Euro des Privatsektors. Konkret lassen sich Zahlungsvorgänge spezifizieren, die einer bestimmten Logik folgen und automatisiert und vor allem ohne menschliches Zutun abgewickelt werden. Programmierbare Zahlungsvorgänge sind für den Bereich IoT besonders relevant.
Ein Beispiel für einen IoT-Use-Case sind Pay-per-Use-Geschäftsmodelle. Wird beispielsweise eine Maschine über eine bestimmte Zeit genutzt, könnte sie basierend auf Maschinendaten, zum Beispiel zur Wartung oder Auslastung, automatisch eine Zahlung mit dem DLT-basierten Euro auslösen – ganz ohne menschliches Zutun. Aus diesem Grund versprechen programmierbare Zahlungen enormes Automatisierungspotenzial. Daueraufträge sind bereits heute verfügbar und ebenfalls programmierbare Zahlungen, jedoch mit extrem begrenzter Flexibilität. Um das volle Potenzial von programmierbaren Zahlungen auszuschöpfen, kann eine DLT genutzt werden. In wenigen Zeilen Programmcode können selbst komplexe Geschäftslogiken durch Smart Contracts relativ einfach umgesetzt werden. Zudem sind durch die Nutzung von DLT digitale Zug-um-Zug-Geschäfte möglich. So kann über einen Smart Contract spezifiziert werden, dass die Zahlung einer Ware nur dann durchgeführt wird, wenn beispielsweise die Ware auch versendet wurde. Auf diese Art und Weise lassen sich erhebliche Effizienzgewinne und geringere Kontrahentenrisiken realisieren. Erste programmierbare eurobasierte Zahlungen sind bereits Testweise verfügbar und ermöglichen deshalb schon heute die Umsetzung von Micropayments und darauf aufbauende Geschäftsmodelle.
Die Triggerlösung für programmierbare Zahlungen
Eine sogenannte Triggerlösung, auch Brückenlösung genannt, bezeichnet eine technologische Verbindung, in diesem Fall zwischen dem SEPA-System und einer DLT-basierten Anwendung. Dieser Trigger ermöglicht es, eine Zahlung über einen Smart Contract auszulösen und über den konventionellen Zahlungsverkehr abzuwickeln, indem die entsprechenden Transaktionsinformationen weitergegeben werden. Abbildung 3 illustriert die Triggerlösung und zeigt das Zusammenspiel beider Systeme. Wohingegen das DLT-System vor allem bei der Identität der Maschine und der Interaktion mit dem Besitzer eine Rolle spielt, ist das SEPA-System erforderlich, sobald sich Zahlungsaufträge als Ergebnis der Interaktion ergeben.
Der Vorteil einer solchen Lösung besteht darin, dass keine speziellen neuartigen, tokenisierten, also DLT-basierten, Geldeinheiten zur Verwendung in der DLT-Umgebung geschaffen werden müssen. Eine solche Lösung ist deswegen auch relativ unkompliziert und kurzfristig um- und einsetzbar. Auch bei einer Triggerlösung sind keine optimalen Delivery-versus-Payment-Funktionen implementierbar. Die erstellten Tokens repräsentieren lediglich eine Forderung gegenüber der Bank und sind an eine nachgelagerte SEPA-Überweisung geknüpft. Aus diesem Grund entsteht für kurze Zeit eine Asymmetrie, da der Konten- und/oder Kreditrahmen von der Bank erst geprüft werden muss. Nach erfolgreicher Prüfung wird ein DLT-basierter Token mit der Wertgutschrift, also einem Zahlungsversprechen, erstellt, welcher dann dem Zahlungsempfänger zur Verfügung steht. Bei Einlösung dieses Tokens wird dieser technisch zerstört und löst simultan eine SEPA-Transaktion aus, bankabhängig auch in Echtzeit. Somit lässt sich zwar technisch eine DvP-Funktion abbilden, die Zug-um-Zug-Geschäfte möglich macht. Diese sorgt aber erst zu einem späteren Zeitpunkt für die Überweisung der Geldbeträge. Für die volle Besitzübergabe digitaler Assets sind sogenannte Atomic Transaction Settlements unbedingte Voraussetzung. Der Begriff beschreibt in diesem Zusammenhang die vollständige und unumkehrbare Transaktionsabwicklung und Übergabe der Assets.
Die Triggerlösung ist eine technologische Verbindung zwischen dem SEPA-System und einer DLT-basierten Anwendung.
Automatisiertes Bezahlen im Internet of Things
DLT-Umgebungen sind vor allem dann notwendig, wenn Maschine-zu-Maschine-Zahlungen, IoT-Zahlungen, automatisierte Zahlungen und / oder Pay-per-Use-Zahlungen ausgeführt werden sollen. Aufgrund der grundsätzlich automatischen Ausführung von Zahlungen im IoT-Umfeld auf Basis von Maschinen- und / oder Sensordaten ist die Datenintegrität ein wichtiger Erfolgsfaktor bei der Umsetzung. DLT hat den Charakter einer Single Source of Truth (SSOT), also einer technischen, automatischen Notarfunktion zwischen allen beteiligten Parteien. Daneben werden mittels der SSOT-Funktion für die Maschinen auch Identitäten vergeben. Das ist zwingend notwendig, um bei einem autonomen Zahlungsverkehr Transaktionen nachvollziehen zu können.
Das SEPA-System ist gegenwärtig nicht in der Lage, diese notwendige SSOT-Funktion in den Zahlungsvorgang zu integrieren. SSOT und Maschinenidentitäten sind unbedingte Voraussetzungen für automatische Zahlungen. Zwar lassen sich programmierbare Zahlungen geringerer Komplexität mithilfe von Daueraufträgen oder Lastschriftverfahren bereits heute durchführen, jedoch stoßen diese Instrumente für automatisierte und nicht diskretionäre (regelgebundene) Anwendungsfälle zunehmend an ihre Grenzen. Die derzeitigen Überweisungsformen sind auf 27 Zeichen laut Homebanking-Computer-Interface-Spezifikation (HBCI) begrenzt und können nur monatliche Überweisungen auslösen.
Durch die Triggerlösung wird der klassische Zahlungsverkehr programmierbar und funktioniert durch die nahtlose Integration von Zahlungsverkehr und Sensordaten ohne Systembrüche. Durch den hohen Grad der Automatisierung lässt sich die Effizienz von bislang häufig noch manuellen Prozessen steigern. Programmierbare Zahlungsströme erlauben die Nutzung von Abrechnungsmodellen nach unterschiedlichen Metriken. Dadurch sind auch datengetriebene Geschäftsmodelle vollumfänglich und automatisiert abwickelbar.
Zahlungen über DLT-Netzwerke
Derzeit arbeiten einige Banken in Europa an der Ausführung von Zahlungen über DLT-Netzwerke. Hierbei können oben skizzierte Triggerlösungen zum Einsatz kommen, die programmierbare Zahlungen auf einer DLT abbilden und diese über die bestehenden Zahlungsverkehrssysteme ausführen. In dem Umfeld ist unter anderem CashOnLedger gemeinsam mit der Landesbank Baden-Württemberg (LBBW) im Rahmen einer Entwicklungspartnerschaft aktiv, um die Vorteile der DLT für Unternehmen nutzbar zu machen.
Da die Triggerlösung in den bestehenden Zahlungsverkehr integriert ist, gelten neben der möglichen Programmierbarkeit von Zahlungen grundsätzlich die gleichen Limitationen wie im bisherigen Zahlungsverkehr. Die Überweisung von Kleinstbeträgen ist ökonomisch nicht effizient umsetzbar. Damit entfällt auch der Use Case von Streaming Money, bei dem während des Konsumierens beziehungsweise Nutzens von Inhalten diese Verwertung in Form von Kleinstbeträgen abgerechnet werden soll. Hier könnte lediglich mit Schwellenwerten gearbeitet werden, um Überweisungen ab einem gewissen Wert automatisch zu veranlassen.
Des Weiteren erhalten Maschinen auch bei der Triggerlösung keine Identität, was die Auslösung einer Zahlung erschwert. Beschränkungen wie etwa die Zwei-Faktor-Authentifizierung als regulatorische Hürde existieren in diesem Zusammenhang also weiterhin. Für die Praxis bedeutet dies konkret, dass eine Maschine oder ein IoT-Gerät noch nicht selbstständig abrechnen und den Betrag vom Konto abbuchen kann. Dafür wird die Bestätigung des Nutzers als Zwischenschritt benötigt. Darüber hinaus ermöglicht nur ein direkt auf DLT emittierter Euro-Token ein Echtzeit-Settlement von Zahlungen, da die Währung nativ in die Plattform eingebunden wäre. Bei der Triggerlösung liegt die Dauer für eine Transaktionsdurchführung etwa bei der üblichen SEPA-Abwicklungsdauer von bis zu einem Tag. Bei der Emittierung eines Euro-Token ohne Medienbruch direkt über ein DLT-System ist eine Transaktionsabwicklung in Echtzeit möglich. In einem solchen Fall stünde die Liquidität dem Zahlungsempfänger sofort zur Verfügung und Drittparteien wie etwa Clearing-Häuser würden nicht mehr benötigt.
Alternativen zur Triggerlösung
Die im letzten Absatz beschriebenen Limitationen der Triggerlösung lassen sich durch die im Folgenden beschriebenen nativen DLT-basierten Zahlungsmittel, Stablecoins/tokenisiertes E-Geld, tokenisiertes Giralgeld und CBDCs, adressieren. Damit sind im Gegensatz zur Triggerlösung native DvP, Micropayments, Streaming Money und die Integration von Maschinen möglich.
Stablecoins/tokenisiertes E-Geld
Bei Stablecoins handelt es sich um DLT-basierte Tokens, welche einen stabilen Vermögensgegenstand nachbilden. So kann etwa der Euro als Token auf einem DLT-System zum Einsatz kommen. Das DLT-System übernimmt dabei die Rolle der Trägerplattform, der Token die Rolle einer Werteinheit. Der Hauptunterschied zur Triggerlösung besteht darin, dass die Zahlung nicht über das SEPA-System, sondern über die DLT abgewickelt wird. Auf diese Art und Weise kann der Systembruch zur Zahlungsabwicklung vermieden werden. Bislang gibt es erste Projekte für eurobasierte Stablecoins, allerdings sind auf US-Dollar basierende Stablecoins im Hinblick auf Größe und Anwendungsbreite bei weitem überlegen. Die Regulierung von Euro-Stablecoins ist – Stand heute – nicht existent, soll aber durch die geplante EU-Regulierung „Markets in Crypto-Assets“ – kurz MiCA – geschaffen werden. In diesem Fall würde für derartige Tokens die E-Geld-Richtlinie greifen, sodass Stablecoins als tokenisiertes E-Geld bezeichnet werden können. Derzeit haben unregulierte Euro-Stablecoins ein erhebliches Gegenparteirisiko. Dies ist einer der Gründe, warum Stablecoins bisher kaum in der Industrie zum Einsatz kommen.
tokenisiertes Giralgeld und CBDCs
Neben Euro-Stablecoins besteht zudem die Möglichkeit, dass Banken Giralgeld auf DLT-Systemen emittieren könnten. Der wesentliche Unterschied zu den zuvor diskutierten Euro-Stablecoins beziehungsweise tokenisiertem E-Geld ist, dass Stablecoins im Rahmen des E-Geld-Regimes eine hundertprozentige Deckung erfordern würden, beispielsweise durch Giralgeld. Würden etwa E-Geld-Token im Wert von 100 Euro emittiert werden, so müssten exakt 100 Euro als Deckung hinterlegt werden. Für tokenisiertes Giralgeld ist keine vollständige Deckung erforderlich. Dadurch können Banken weiterhin Geld schöpfen – nur eben auf einer DLT.
Ein derart bereitgestellter digitaler Euro ließe sich ebenfalls für programmierbare Anwendungen verwenden. Die Realisierung einer solchen Lösung wird derzeit von zahlreichen Banken konzeptionell untersucht, ist aber aufgrund der notwendigen Standardisierungsmaßnahmen zur Gewährleistung der Interbankeninteroperabilität äußerst komplex. Zudem gibt es derzeit auf europäischer Ebene keine Bestrebungen zur kurz- bis mittelfristigen Umsetzung einer solchen Lösung. Allerdings ist auch tokenisiertes E-Geld mit einem signifikanten Nachteil verbunden, der sich negativ auf die Verbreitung auswirkt. Durch die Deckung mit Giralgeld ist tokenisiertes E-Geld nicht multibankfähig, weist also aufgrund seiner eingeschränkten Fungibilität je nach Emittenten ein unterschiedliches Risiko auf. Folglich ist man durch die Emission von E-Geld an eine Institution gebunden, was zur Folge hat, dass Zahlungssender wie auch Zahlungsempfänger Kunden bei derselben Institution sein müssen.
Neben Akteuren des Privatsektors, wie Banken und E-Geld-Instituten, könnte auch die Zentralbank DLT-basiertes Geld ausgeben. Im Fall der Eurozone wäre dies der öffentliche digitale Euro. Derzeit hat die EZB noch keine Entscheidung getroffen, ob sie tatsächlich einen digitalen Euro emittieren würde. Auch bleibt fraglich – und derzeit sogar unwahrscheinlich –, ob ein digitaler Euro auf DLT-Basis implementiert werden würde. Nur ein digitaler Euro auf DLT-Basis würde die Limitationen bei Micropayments, Streaming Money und Maschinenintegration tatsächlich auflösen. Aufgrund dieser Unsicherheiten erscheinen tokenisiertes E-Geld und tokenisiertes Geschäftsbankengeld kurz- bis mittelfristig die vielversprechendsten Lösungen für IoT-Zahlungen zu sein, wobei die kurzfristige Realisierung von tokenisiertem E-Geld aufgrund der in schon ein bis zwei Jahren in Kraft tretenden MiCA-Regulierung derzeit wesentlich wahrscheinlicher erscheint.
Im folgenden vierten und letzten Artikel der Artikelserie werden zwei Anwendungsfälle skizziert, um die Vorteile eines tokenisierten Geschäftsbankengeldes praktisch aufzuzeigen.
Folgende Koautoren haben an dem Beitrag mitgewirkt:
- Jonas Groß (Projektmanager am Frankfurt School Blockchain Center und wissenschaftlicher Mitarbeiter an der Universität Bayreuth).
- Mario Reichel (Managing Consultant bei PPI und seit vielen Jahren im europäischen und internationalen Zahlungsverkehr tätig).
- Serkan Katilmis (Mitgründer und CEO von CashOnLedger mit über 20 Jahre Erfahrung bei namhaften Unternehmensberatungen).
- Maximilian Forster (Co-Founder CashOnLedger Technologies GmbH und Mitglied vieler Gremien und Verbänden).
- Anja Kristina Kamping (Senior Consultant im Bereich Payments bei der PPI AG). Schwerpunktmäßig betreut sie im Bereich Payments die Themen rund um den Digitalen Euro, Kryptowährungen und Blockchain
- Philipp Schröder (Managing Consultant im Bereich Payments bei der PPI AG).
