Über programmierbares Geld wird zunehmend in Verbänden und der Politik diskutiert. Allerdings fehlt es derzeit noch an einer klaren Definition und einem gemeinsamen Grundverständnis zu programmierbarem Geld. In diesem Beitrag ordnen Philipp Sandner, Jonas Groß, Alexander Bechtel und Victor von Wachter den Begriff „programmierbares Geld“ ein und definieren diesen. Insbesondere grenzen sie „programmierbares Geld“ klar von „programmierbaren Zahlungen“ ab. Hierbei unterteilen sie den Zahlungsprozess in drei Bestandteile: Contract Execution System, digitale Infrastruktur und Geldeinheit.
Programmierbare Zahlungen
Die Begriffe „programmierbares Geld“ und „programmierbare Zahlungen“ werden oft synonym verwendet, auch wenn sie unterschiedliche Bedeutungen haben. Programmierbare Zahlungen werden automatisch ausgeführt, wenn bestimmte Bedingungen erfüllt sind. Diese Zahlungen sind daher in großem Maße automatisiert und folgen einer vorgegebenen Logik. Programmierbare Zahlungen gibt es bereits im heutigen Bankensystem, zum Beispiel in Form von Daueraufträgen und Lastschriften.
Allerdings ist die Flexibilität dieser programmierbaren Zahlungen bislang begrenzt, da komplexere Logiken nur sehr mühsam implementiert werden können. Vor diesem Hintergrund bieten Smart Contracts, die auf der Distributed-Ledger-Technologie (DLT) basieren, deutlich mehr Freiheitsgrade. Mit Hilfe von Smart Contracts können selbst komplexe Geschäftsprozesse relativ einfach automatisierte Zahlungen auslösen.
Ein Beispiel: In der Economy of Things (EoT) könnten beispielsweise autonome, an eine DLT angebundene, E-Autos komplett autonom zur nächsten Ladestation fahren, einen Preis zum Laden aushandeln, den Ladevorgang durchführen und dann eine Zahlung durchführen. Die Zahlung wird anschließend direkt aufgeteilt und nach einem vordefinierten Schlüssel an alle Beteiligten überwiesen (z.B. 70 Prozent an den Stromanbieter und je 10 Prozent an den Hersteller der Ladestation, den Tankstellenbetreiber und den Autohersteller). Diese Zahlung wird durch einen Smart Contract ausgelöst, ist daher automatisiert und äußerst flexibel anpassbar.
Contract Execution System, digitale Zahlungsinfrastruktur und Geldeinheit
Der beschriebene Prozess lässt sich in der in Abbildung 1 illustrierten Taxonomie zusammenfassen. Hierbei unterteilen wir den Zahlungsprozess in drei Teile: Contract Execution System, digitale Zahlungsinfrastruktur und Geldeinheit. Diese Taxonomie basiert auf einem gemeinsamen Forschungsprojekt mit Agata Ferreira, dessen Ergebnisse Ende dieses Jahres veröffentlicht werden.
Ablauf eines typischen Zahlungsprozesses
Im ersten Schritt programmierbarer Zahlungen müssen Regeln festgelegt werden, die automatische Zahlungen auslösen sollen. Diese Regeln werden anschließend auf einer DLT (d.h. durch einen Smart Contract) implementiert. Wir nennen die Umgebung, in der die Regeln definiert werden, „Contract Execution System“. Beispielsweise kann jede Geschäftslogik oder jeder Geschäftsprozess solche Regeln festlegen. Im obigen E-Auto-Beispiel sind die Preisverhandlung, der Verrechnungsprozess und die Auslösung der finalen Zahlung Teil des Contract Execution Systems, da all diese Prozesse durch Smart Contracts implementiert werden.
Die eigentliche Zahlung kann schließlich über zwei Kanäle abgewickelt werden: Sie kann entweder direkt über eine DLT oder – mit Hilfe einer „Brückenlösung“ – über konventionelle Zahlungsinfrastrukturen wie Sepa, Target2 oder TIPS abgewickelt werden. Diese Kanäle sind Teil der „digitalen Zahlungsinfrastruktur“. Die Zahlungsinfrastruktur ist entscheidend für die Programmierbarkeit und legt fest, ob die Zahlung über ein Konto oder einen Token abgewickelt wird. Konten-basierte Bezahlmöglichkeiten erfordern die Legitimierung des Kontoinhabers, während token-basierte Bezahlmöglichkeiten lediglich die Legitimierung des Bezahlmediums (Tokens) an sich erfordern. Tokens entfalten erst dann ihr volles Potenzial, wenn sie gegen andere Tokens, wie z.B. tokenisierte Vermögenswerte, eingetauscht werden können. In diesem Fall ist ein Austausch mit sofortiger Zahlungsabwicklung (Settlement) möglich, auch bekannt als „Delivery vs. Payment“.
Schließlich muss in der digitalen Zahlungsinfrastruktur die zu transferierende Geldeinheit festgelegt werden. Konventionelle Zahlungssysteme basieren auf Fiat-Währungen, wie dem Euro und dem US-Dollar. Auf einer DLT können Zahlungen auch in alternativen Währungen, wie z.B. Bitcoin und Ether, abgewickelt werden. Mittlerweile werden Fiat-Währungen auch immer häufiger auf DLTs abgebildet und somit „tokenisiert“. Im Wesentlichen gibt es fünf Möglichkeiten, Fiat-Währungen auf eine Blockchain zu bringen:
- Digitale Zentralbankwährungen (CBDCs): Werden von einer Zentralbank als gesetzliches Zahlungsmittel ausgegeben.
- Synthetische digitale Zentralbankwährungen (sCBDCs): Werden von Geschäftsbanken oder E-Geld-Instituten ausgegeben. Kein gesetzliches Zahlungsmittel, aber zu 100 Prozent durch Zentralbankreserven gedeckt. Verpflichtung zum jederzeitigen Umtausch in ein gesetzliches Zahlungsmittel.
- DLT-basiertes Geschäftsbankengeld: Wird von Geschäftsbanken ausgegeben. Kein gesetzliches Zahlungsmittel und nur teilweise durch Zentralbankreserven gedeckt (d.h. Fractional-Reserve-System). Verpflichtung zum jederzeitigen Umtausch in ein gesetzliches Zahlungsmittel.
- DLT-basiertes E-Geld: Wird von E-Geld-Instituten ausgegeben. Kein gesetzliches Zahlungsmittel. Vollständig durch E-Geld auf Konten gedeckt. Verpflichtung zum jederzeitigen Umtausch in ein gesetzliches Zahlungsmittel.
- Stablecoins: Werden von regulierten (z.B. Geschäftsbanken, Zahlungsdienstleistern) oder nicht regulierten Finanzorganisationen (z.B. Unternehmen, die nicht in allen erforderlichen Ländern über alle erforderlichen Lizenzen verfügen) ausgegeben. Stablecoins sind nur „Fiat-Derivate“. Sie bilden den Preis einer Fiat-Währung nach, sind aber weder gesetzliche Zahlungsmittel noch besteht die Verpflichtung, sie in ein gesetzliches Zahlungsmittel umzutauschen. Aus diesem Grund weisen sie Gegenpartei-, Wechselkurs- und Liquiditätsrisiken auf. Die EU-Kommission strebt unter dem Gesetzesentwurf „MiCA“ derzeit an, einen einheitlichen europäischen regulatorischen Rahmen für Stablecoins zu schaffen.
Programmierbares Geld
Nun zu „programmierbarem Geld“. Wenn Geld wie eben beschrieben auf einer DLT ausgegeben wird, wird es programmierbar gemacht, d.h. es kann ein entsprechender Token geschaffen werden, der eine inhärente Logik besitzt. Zum Beispiel kann dieser Token so programmiert werden, dass er im Laufe der Zeit an Wert gewinnt oder verliert (z.B. zur Implementierung von Zinszahlungen). Alternativ könnte sichergestellt werden, dass dieser Token nur für bestimmte Dinge ausgegeben werden kann, z.B. für Nahrungsmittel.
Unsere Einordnung zeigt, dass klar zwischen programmierbarem Geld und programmierbaren Zahlungen unterschieden werden muss. Ersteres betrifft die Möglichkeit, DLT-basierte Token mit einer inhärenten Logik auszustatten. Letzteres bezieht sich auf automatisierte Zahlungen, die – selbst wenn sie durch DLT-basierte Smart Contracts ausgelöst werden – über programmierbares (DLT-basiertes) Geld oder nicht programmierbares Geld abgewickelt werden können. Langfristig liegt der große Vorteil von programmierbaren Zahlungen in Netzwerkeffekten: Wenn auch weitere Assets auf DLT-Systemen implementiert werden (z.B. Aktien, Immobilien, Rohstoffe) wird ein sehr einfacher Austausch zwischen den verschiedenen Assets ermöglicht – und das innerhalb der gleichen Infrastruktur.
Fazit
Es ist essentiell, zwischen programmierbarem Geld und programmierbaren Zahlungen zu unterscheiden, da sie fundamental unterschiedliche Anwendungsfälle haben. Der E-Auto- Anwendungsfall ist ein gutes Beispiel für eine programmierbare Zahlung. Programmierbares Geld ist in diesem Fall jedoch nicht zwangsläufig notwendig. Stattdessen kann programmierbares Geld z.B. zur Durchführung gezielter Hilfszahlungen während Krisen wie Covid-19 genutzt werden. Es könnte sichergestellt werden, dass Subventionen rechtzeitig und nur für vordefinierte Güter wie Nahrungsmittel, Medikamente oder Kleidung ausgegeben werden, indem die Regierung für die an die Bürger auszuzahlenden Gelder eine inhärente Logik implementiert.
Prof. Dr. Philipp Sandnerleitet an der Frankfurt School of Finance & Management das Frankfurt School Blockchain Center (FSBC).Jonas Großist Projektmanager am Frankfurt School Blockchain Center und wissenschaftlicher Mitarbeiter an der Universität Bayreuth.Alexander Bechtelist wissenschaftlicher Mitarbeiter an der Universität St. Gallen.Victor von Wachterist wissenschaftlicher Mitarbeiter an der Universität Kopenhagen.
