Geld in Programmierbaren Anwendungen Seite 2

Geld in programmierbaren Anwendungen Branchenübergreifende Perspektiven aus der deutschen Wirtschaft*

Frankfurt am Main, 21. Dezember 2020

* Die AG Programmierbares Geld hat auf Initiative des Bundesministeriums der Finanzen und der Deutschen Bundesbank einen Fach- diskurs zum Themenkomplex „Programmierbares Geld“ geführt. Auf Grundlage einer Konsultation von Spitzenverbänden der Kredit- wirtschaft, der Industrie und des Handels sind mit der Zielstellung einer breiten praxisnahen Analyse des Bedarfes und der Ausgestal- tungsmöglichkeiten von programmierbaren Geldformen Mitarbeiter folgender Unternehmen in der Arbeitsgruppe vertreten: Bundesdruckerei GmbH, DB Systel GmbH, Deutsche Bank AG, Deutsche Börse AG, DZ BANK AG, Evonik Digital GmbH, Frankfurt School of Finance & Management gGmbH, generic.de software technologies AG, Helaba Landesbank Hessen-Thüringen, IBM Deutschland GmbH, ING-DiBa AG, Landesbank Baden-Württemberg, Main Incubator GmbH (Commerzbank AG), MARKANT Services International GmbH, Robert Bosch GmbH, SAP SE, Siemens AG, Volkswagen AG, Zalando Payments GmbH. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 2

Inhalt

Executive Summary...... 3

1 Motivation...... 4

2 Begriffsklärung ...... 4

3 Mögliche Anwendungsfälle der DLT...... 5

4 Formen programmierbarer Zahlungen...... 6

5 Mögliche Lösungsansätze für die stilisierten Anwendungsfälle...... 9 Übersichtstabelle Lösungsansätze für stilisierte Anwendungsfälle...... 12

6 Anforderungen an programmierbare Zahlungen...... 14

Teilnehmerliste der AG Programmierbares Geld...... 17 Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 3

Executive Summary

Die digitale Transformation lässt neue Geschäfts- wickeln. Insbesondere aufgrund ihrer fehlenden Wert- modelle entstehen und ändert bestehende Geschäfts- stabilität, eingeschränkter Interoperabilität und offenen prozesse grundlegend. Viele Prozesse werden in Fragen zur Rechtssicherheit, werden sie in der Praxis Zukunft noch viel automatisierter erfolgen. Die Dis- aber als ungeeignet betrachtet. tributed Ledger Technologie, auf der reale Güter und Dienstleistungen als Token abbildbar sind und digital Um die Nachfrage nach programmierbaren Zahlungs- gehandelt werden können, ermöglicht programmier- lösungen erfüllen zu können, bedarf es deshalb neuer bare, autonome und automatisierte Leistungsflüsse. und innovativer Lösungen. Kurzfristig denkbar wären Dadurch werden die gegenwärtigen Zahlungssysteme Trigger-Lösungen, mit denen sich die Abwicklung vor neue Herausforderungen gestellt. Inwieweit die Smart Contract basierter Geschäftsfälle in den kon- Vorteile der digitalen Abwicklungstechnik realisiert ventionellen Zahlungsverkehr integrieren ließe. Zwar werden können, hängt in hohem Maße davon ab, sind Einschränkungen in der Umsetzung und Anwend- ob die dazugehörigen Geldflüsse gleichermaßen pro- barkeit zu erwarten, ihr Vorteil läge jedoch in der grammierbar werden und mit den Leistungsflüssen schnellen Realisierbarkeit. synchronisiert werden können. Der größte Funktionsnutzen bei der Abwicklung pro- Denkbare Geschäftsfälle, für die es innovative Lösun- grammierbarer Zahlungen wird tokenisiertem Ge- gen zur geldseitigen Abwicklung bedarf, basieren schäftsbankengeld und digitalem Zentralbankgeld größtenteils auf der Distributed Ledger Technologie beigemessen. Die noch ausstehende Entwicklung und können Smart Contracts enthalten, die die Aus- beider Zahlungslösungen bietet ausreichend Gestal- führung der Geschäftsfälle steuern. Machine-to- tungsspielraum, den Bedarf zur Umsetzung pro- Machine-Zahlungen, Internet-of-Things-Zahlungen und grammierbarer Zahlungen umfassend zu berücksich- Pay-per-Use-Zahlungen sind beispielhafte Anwen- tigen. Beide Lösungen eignen sich insbesondere dungsfälle, die programmierbare Zahlungen für die aufgrund der zu erwarteten Glaubwürdigkeit ihrer geldseitige Abwicklung erfordern. Emittenten und der Anwendung innerhalb eines ver- bindlichen Rechtsrahmens als vertrauenssichernde Mit dem konventionellen Zahlungsverkehr, privaten Lösung zur Abwicklung programmierbarer Zahlungen. Krypto-Token und Stable Coins existieren gegenwär- tig drei in Frage kommende Zahlungslösungen. Da Darüber hinaus gibt es weitere allgemeingültige der konventionelle Zahlungsverkehr technisch nicht Anforderungen an programmierbare Zahlungen, zu in der Lage ist, Smart Contracts in den Zahlungsvor- denen etwa Interoperabilität, Innovationsfähigkeit, gang zu integrieren, stößt er für zukünftige Bedürf- Cyber Resilience und Datenschutz zählen. Eine um- nisse an seine Grenzen. Der Bedarf nach 24/7-Zah- fassende Berücksichtigung dieser Anforderungen ist lungen kann mit Instant Payments bereits heute Voraussetzung für eine universelle Akzeptanz etwai- hinreichend abgedeckt werden. Viele Krypto-Token ger Implementierungsmaßnahmen als funktionsge- und Stable Coins sind technisch zwar in der Lage, rechte und effiziente Zahlungslösung für die Real- eine Vielzahl an DLT Anwendungen geldseitig abzu- und Finanzwirtschaft. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 4

1 Motivation

Mit zunehmender Digitalisierung verändern sich Neuere Technologien, insbesondere die Distributed Handelsprozesse, Geschäftsmodelle und Arbeitsab- Ledger Technologie (DLT), bieten die Chance, die läufe. Dies gilt gleichermaßen für die Real- wie für Transaktionskosten für real- und finanzwirtschaftliche die Finanzwirtschaft. In der entstehenden Digital- Transaktionen signifikant zu senken und zusätzliche ökonomie werden viele Güter und Dienstleistungen Mehrwerte durch neue und verbesserte Dienstleis- als Token darstellbar und digital handelbar. Die zu- tungen sowie Produkte zu generieren. nehmende Tokenisierung der Wirtschaft wird zu einer intensiveren Prozessautomatisierung und -integration Um die Potentiale von Industrie 4.0 zu heben, muss führen. auch die geldseitige Abwicklung der Transaktionen in die neuen Prozesse integriert werden. Erst dann können Leistungs- und Geldflüsse vollständig synchronisiert, determiniert und automatisiert stattfinden.

2 Begriffsklärung

Die Arbeiten wurden aufgenommen mit dem Ziel, nen dies regelmäßige Zahlungen sein, die z. B. per programmierbares Geld zu untersuchen. Program- Dauerauftrag ausgeführt werden. Darüber hinaus mierbares Geld wird als eine digitale Ausprägung kann damit auch die geldseitige Abwicklung von von Geld definiert, bei welcher der Nutzer auf der komplizierten Geschäftsprozessen unter Berücksich- Basis der Attribute des digitalen Geldes selbst inhä- tigung der Erfüllung vorgegebener Bedingungen er- rente Logiken für bedingte Verwendungen program- folgen. Veranlasser der Zahlung müsste eine juristi- mieren kann. Um wirklich von programmierbarem sche oder eine natürliche Person sein, unmittelbarer Geld sprechen zu können, müsste das Programm in Auslöser kann jedes messbare Ereignis (z. B. Güter dem jeweiligen „digitalen Geldstück“ hinterlegt wer- kommen am Zielort an, Dienstleistung wurde er- den. Dies würde in der Tat eine vollständige Synchro- bracht, Erfüllungszeit ist abgelaufen) sein. Nicht alle nisierung von Waren- und Geldfluss ermöglichen, Formen programmierbarer Zahlungen erfordern den erfordert aber erhebliche technische Neuerungen. Einsatz von programmierbarem Geld.

Programmierbare Zahlungen werden als Überträge Ähnlich motiviert wird der Begriff Zahlungsauslöse- von Geld definiert, bei denen Zeitpunkt, Betrags- system1 genutzt. Ein Zahlungsauslösesystem beschreibt höhe und/oder Art des Übertrags durch vorher, nicht die technische Infrastruktur, auf der Zahlungsvorgän- ad hoc beim Zahlungsvorgang, vorgegebene Bedin- ge ausgelöst werden. Dem Zahlungsauslösesystem gungen bestimmt werden. Im einfachsten Fall kön- werden die relevanten Informationen für den Zah-

1 Alexander Bechtel, Jonas Gross, Philipp Sandner und Victor von Wachter ordnen Zahlungsauslösesysteme in ihrem Aufsatz „Program- mable Money and Programmable Payments“ in den Kontext programmierbarer Zahlungen und programmierbaren Geldes ein und schlagen einen detaillierten Definitionsrahmen vor. Siehe: https://philippsandner.medium.com/programmable-money-and-programmable-payments-8038ed8fa714 Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 5

lungsvorgang übergeben. Bei Erfüllung bestimmter Der aktuelle Bedarf nach Geld in programmierbaren Bedingungen wird vom Zahlungsauslösesystem die Anwendungen kann in vielen Fällen hinreichend geldseitige Abwicklung des Geschäfts initiiert. Defi- durch eine programmierbare Zahlung erfüllt werden, nitorisch sind Zahlungsauslösesysteme und Zahlungs- die nicht zwingend programmierbares Geld erfordert. systeme voneinander zu trennen. Daher fokussiert sich die folgende Erörterung auf programmierbare Zahlungen.

3 Mögliche Anwendungsfälle der DLT

Im Folgenden werden neun stilisierte potentielle An- • Beispiel: Eine Person bezahlt ihre Nachbarn wendungsfälle für programmierbares Geld und pro- für die Mitbenutzung deren Photovoltaikanla- grammierbare Zahlungen dargestellt. Die Liste der ge; Zahlung für den partiellen Konsum aus Anwendungsfälle erhebt keinen Anspruch auf Voll- einem Energienetzwerk. ständigkeit, repräsentiert aber Fälle, die für die Real- als auch für die Finanzwirtschaft von Interesse sind.  Automated Settlement Payments: DLT-basierte Gleichwohl kann es in der Praxis vorkommen, dass Abwicklung eines Geschäftes inklusive der Geld- mehrere Anwendungsfälle zusammenfallen, da eine seite. Dabei kann z. B. ein Smart Contract die klare Abgrenzung in Abhängigkeit der Realbedin- Steuerung der Vertragsabwicklung (z. B. event- gungen nicht immer gegeben sein wird. In seiner getriggerter Zahlungsfluss) übernehmen oder als Gesamtheit spiegelt die Beschreibung der verschie- virtueller Treuhänder zur Eliminierung des Erfül- denen Anwendungsfälle in Verbindung mit einem lungsrisikos fungieren. idealtypischen Beispiel den Bedarf an innovativen • Beispiel: Wertpapiergeschäft in der Börsenab- Zahlungslösungen wieder. Gleichermaßen bietet die wicklung. Sobald der Smart Contract den Darstellung eine Grundlage für die Zuordnung mög- Geld- bzw. Stückeeingang registriert, gehen licher und geeigneter Zahlungslösungen. das Wertpapier bzw. Geld im Sinne einer Delivery-versus-Payment Abwicklung an den  M2M-Zahlungen: Vollautomatische Abrechnung Kontrahenten über. zwischen Maschinen (Machine-to-Machine) • Beispiel: E-Auto bezahlt selbstständig die Lade-  Pay-per-Use-Zahlungen: Unmittelbare Beglei- säule im Parkhaus oder die Parkgebühr. Es ist chung eines Betrages in Abhängigkeit des Ver- der Zahlungsvorgang „Auto an Parkhaus“ brauchs/der Nutzung. oder „Auto an Ladesäule“ denkbar. • Beispiel: Eine geleaste Maschine stellt Kosten für individuelle Nutzungseinheiten in Rech-  IoT-Zahlungen: Zahlungen im Internet of Things nung und wickelt die Zahlung selbstständig (IoT), die anders als o.g. M2M-Zahlungen durch ab. Interaktion mit dem Endkunden ausgelöst werden können. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 6

 Bidirektionale Verrechnungen: Abwicklung morgen. Die Verfügbarkeit rund um die Uhr von vielen wechselseitigen Forderungen/Ver- senkt das Kredit- und Adressatenausfallrisiko. bindlichkeiten zwischen Geschäftspartnern. Alternatives Beispiel: Bedienung von Margin • Beispiel: Zwei Unternehmen verrechnen gegen- Calls eines Clearinghauses nachts um zwei Uhr seitig ohne Zeitverzug, wobei im Zahlungs- zur weiteren Ausführung von Geschäften. prozess eine eindeutige, automatische Rech- nungszuordnung und Buchführung durchge-  Zahlungen mit Informationsfunktion: Integra- führt wird. tion von Zahlungs- und Informations- bzw. Kommunikationssystem: Zahlung soll zur unter-  Auslandsgeschäfte: Geldseitige Abwicklung nehmensübergreifenden Prozess- und Datenin- von grenzüberschreitenden Wirtschaftsleistungen. tegration beitragen. Die Verringerung der eingebundenen Intermedi- • Beispiel: Erweiterte Nutzung des digitalen Gel- äre, eine bessere Standardisierung und mehr des durch „Verwendungsattribute“ (coloured Transparenz sind für Auslandsgeschäfte notwen- coins), die z.B. eine Geldwäscheprüfung und dig. White-Listing direkt durch die Zahlung er- • Beispiel: Für Exportabwicklung erforderliche möglichen, da der Sender daraus eindeutig Akkreditive werden digital abgebildet. Ein identifizierbar ist. Smart Contract steuert die Zahlung, welche erst erfolgt, wenn die in den Akkreditiven  Offline-Zahlungen: Technische Überbrückung enthaltenen Bedingungen vollumfänglich er- von temporären oder dauerhaften Abkopplungen füllt sind. des Internetzugangs sowie zur Integration nicht- internetfähiger Maschinen.  24/7-Zahlungen: Zahlungen außerhalb der Ver- • Beispiel: Einbindung einer Produktionsmaschine fügbarkeitszeiträume oder Betragsgrenzen der ohne Internetanbindung in programmierbare „konventionellen“ Systeme. Zahlungen. Alternatives Beispiel: Zahlung mit • Beispiel: Rückzahlung einer Wertpapieremis- dem Smartphone im Supermarkt bei unter- sion mit Fälligkeitsdatum an einem Samstag- brochener Internetverbindung. 4 Formen programmierbarer Zahlungen

Die oben beschriebene Aufzählung von Anwendungs- Konventioneller Zahlungsverkehr: Der konventio- fällen zeigt beispielhaft die vielfältigen Möglichkei- nelle Zahlungsverkehr basiert auf der Abwicklung ten, in denen programmierbare Zahlungen benötigt von Zahlungen mithilfe bereits existierender Zahlungs- werden. Je nach Anwendungsfall unterscheiden sich instrumente (u.a. Lastschrift, Überweisung, Instant das Ausmaß der Komplexität und die Art der Pro- Payment), bei denen Zahler und Zahlungsempfänger grammierbarkeit der Zahlung. Den unterschiedlichen einander bekannt und per IBAN adressierbar sein Anwendungsfällen lassen sich grundsätzlich ver- müssen. Hierbei kommen etablierte Instrumente wie schiedene Zahlungsformen zuordnen. terminierte Überweisungen, Daueraufträge und Last- Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 7

schriften mit festen Ausführungsdaten zum Tragen. wendungsfall wäre der Wertpapierübertrag auf einer Damit lassen sich einfache Anforderungen an die DLT-Plattform, welche simultan eine Buchung auf „Programmierbarkeit“ erfüllen, da es nur um termin- TARGET2 auslöst. gerechte Ausführung ohne komplexe Bedingungen geht. Zudem eröffnet Instant Payment die Möglich- Neben diesen auf klassischer Infrastruktur aufbauen- keit, Zahlungsszenarien abzubilden, die eine fast den Lösungsansätzen, gäbe es noch die Option, auf zeitgleiche Ausführung erfordern. Ein Beispiel wäre, privat geschaffene Krypto-Token zurückzugreifen. dass der Lieferant die Ware erst dann auf dem Hof Darunter versteht man Krypto-Token privater Emit- ablädt, wenn der Käufer die Ware geprüft und per tenten2, die in einem marktgetriebenen Austausch- Instant Payment bezahlt hat. Erst nach erfolgreichem verhältnis zu offiziellen Währungen stehen. Bitcoin Geldeingang wird die Ware übergeben. und Ether gelten als prominente Beispiele für Krypto- Token. Die meisten dieser Krypto-Token weisen eine Trigger zum konventionellen Zahlungsverkehr: nur geringe Wertstabilität auf, was ihre Nutzbarkeit Unter einem „Trigger“ (Auslöser) versteht man eine als Zahlungsmittel erheblich einschränkt. Zudem ver- technologische Brücke, die als Zahlungsauslösesys- fügen sie in der Regel über keinen intrinsischen Wert tem zwischen dem konventionellen Zahlungsverkehr und keinen haftenden Emittenten, sodass die Inhaber und einer DLT-basierten Anwendung agiert. Dieser allein auf den Marktwert vertrauen müssen. Die Pro- Trigger ermöglicht es der DLT-Anwendung durch grammierbarkeit von Zahlungen mit Krypto-Token entsprechende Informationsweitergabe eine Zah- hängt stark vom Funktionsumfang der DLT-Struktur lung im konventionellen Zahlungsverkehr auszulösen ab, etwa von der Frage, ob und in welchem Maße (zu „triggern“). Der Vorteil einer solchen Lösung ist, die Ausführung von Smart Contracts ermöglicht wird. dass die Notwendigkeit entfällt, spezielle tokenisier- Mithilfe von Smart Contracts können Bedingungen te Geldeinheiten zu schaffen, die innerhalb der DLT- definiert werden, unter denen Werteinheiten trans- Umgebung genutzt werden können und im Zweifel feriert werden. Zudem erfordert die Nutzung von durch eine Parallelität zu bestehenden Zahlungsmit- Krypto-Token eine entsprechende Bereitstellung se- teln die Notwendigkeit des Tausches mit sich brin- parater Liquidität auf dem DLT-System. Ein Beispiel gen. Solange der konventionelle Zahlungsverkehr für eine Anwendung wären auf einer [Ethereum-] keine 24/7-verfügbare Abwicklung bietet, wäre aller- Blockchain nutzbare Werteinheiten, welche dort dings die Nutzung des Triggers zeitlich eingeschränkt. auch in Smart Contracts verwahrt und von diesen Diese Einschränkung könnte gegebenenfalls durch gesteuert werden können. Nutzung einer Instant Payment Anwendung aufge- hoben werden, wenn es sich unter Annahme der Um den Nachteilen von Krypto-Token, insbesondere aktuell geltenden Instant Payments Vorgaben um der hohen Volatilität, zumindest teilweise zu begegnen, Zahlungen unter 100.000 Euro handelt oder die bei- wurden Stable Coins 3 geschaffen. Diese sind in ihrer den Zahlungsdienstleister bilateral die Abwicklung Art in vielen Fällen eng verwandt mit Krypto-Token. höherer Summen per Instant Payments miteinander Es sind in der Regel Krypto-Token, deren Austausch- vereinbart hätten. Ein Beispiel für einen solchen An- verhältnis zu offiziellen Währungen durch Anbindung

2 Es kann sich dabei um klar identifizierbare Personen als Emittenten handeln, aber auch um eine dezentrale anonyme Herausgabe wie bei Bitcoin, das aber ebenfalls auf einer privaten Initiative beruht, aber ohne einen Emittenten im rechtlichen Sinne auskommt. 3 Mit dem für 2022 avisierten Inkrafttreten der „Markets in Crypto-Assets“ (MiCA)-Verordnung in der Europäischen Union, mit der eine einheitliche regulatorische Behandlung von Krypto-Assets über die Mitgliedsstaaten hinweg erreicht werden soll, ergibt sich unter Um- ständen eine neue Bewertung bzw. Kategorisierung von Stable Coins. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 8

an eine offizielle Währung oder andere reale Vermö- zielt auf die bis dato nicht realisierte Idee eines vom genswerte (durch Hinterlegung der Token mit realen Bankensektor gemeinschaftlich emittierten tokeni- Werten) stabilisiert werden soll. Die regulatorische sierten Geschäftsbankengeldes in der offiziellen Behandlung dieser Token ist gegenwärtig Gegen- Währung des betreffenden Währungsraumes. Die- stand des politischen Diskurses. Dabei wird auch dis- ses würde auf einem gemeinsam akzeptierten Stan- kutiert, ob derartige Stable Coins stets zu einem de- dard basieren, welcher die Akzeptanz innerhalb des finierten „Nennwert“ in gesetzliche Zahlungsmittel Währungsraums sicherstellt. Banken würden eine rücktauschbar sein müssen. Die nutzbaren Funktionen Eintauschverpflichtung von tokenisiertem Geschäfts- hängen eng mit der Ausgestaltung der zugrundelie- bankengeld als Kontogutschrift akzeptieren. Der genden Infrastruktur zusammen. Stable Coins können Funktionsumfang für programmierbare Zahlungen das bestehende Ausfallrisiko im Vergleich zu sonstigen würde auch hier wieder von der zugrundeliegenden Krypto-Token durch die Hinterlegung mit Sicherheiten Infrastruktur abhängen. Da es eine neue Entwicklung reduzieren. Das wohl prominenteste Beispiel für einen wäre, kann aber davon ausgegangen werden, dass Stable Coin ist Diem, ein ursprünglich unter dem alle aktuellen Markterfordernisse dargestellt werden Namen Libra von Facebook angestoßenes Projekt, könnten. Geklärt werden müsste bei einem solchen das sich noch im Planungsstadium befindet. Sein ge- Modell, inwieweit bestehende Regeln des Gläubiger- nauer Funktionsumfang und seine Merkmale sind im schutzes, bspw. die Einlagensicherungssysteme, an- Detail noch nicht veröffentlicht. wendbar wären. Damit verbunden ist die Frage, gegen- über wem der Halter seine Forderungen durchsetzen Ein anderer Ansatz wäre die Konzeption von tokeni- kann, sollte er seine Bank wechseln oder es zum siertem Geschäftsbankengeld. Damit würde Geld Ausfall seiner Hausbank kommen. Dazu ist vorstell- nicht nur auf den Konten von Geschäftsbanken bar, dass sich die Forderungen an eine von Banken speicherbar und von dort transferierbar sein, sondern betriebene Zweckgesellschaft richten, die für die He- auch in tokenisierter Form nutzbar werden. Es ist rausgabe des tokenisierten Geschäftsbankengeldes denkbar, dass tokenisiertes Geschäftsbankengeld zuständig wäre. entweder eine Form programmierbaren Geldes dar- stellt oder aber in Verbindung mit einem Zahlungs- Eine ausfallsichere und zudem wertstabile Variante auslösesystem lediglich für programmierbare Zahlun- wäre digitales Zentralbankgeld (DZBG)4. Emittent gen verwendet werden kann. Tokenisiertes Geschäfts- wäre hierbei die Zentralbank, welche Zentralbank- bankengeld birgt grundsätzlich immer ein Ausfallrisiko, geld in tokenisierter5 Form zur Verfügung stellt. Auch so dass die Übertragung großer Summen zwischen hier ist wie bei tokenisiertem Geschäftsbankengeld Kunden verschiedener Geschäftsbanken risikobehaf- sowohl die Variante eines programmierbaren Geldes tet wäre. Um das zu mitigieren, wäre ein zeitnahes als auch die einer Verwendung in programmierbaren untertägiges Clearing gegebenenfalls mit Spitzen- Zahlungsprozessen denkbar. Der Aufbau eines von ausgleich in Zentralbankgeld denkbar. Die weitestge- der Zentralbank betriebenen operativen Systems zur hende Vorstellung zur Lösung dieser Problematik Abwicklung von Zahlungen in digitalem Zentral-

4 Verzichtet wird im weiteren Verlauf auf die Unterscheidung zwischen möglichen Teillösungen von DZBG, etwa der Bereitstellung eines digitalen Wholesale-Tokens, der zwar digitales Zentralbankgeld wäre, aber nur für einen begrenzten Nutzerkreis (v.a. Banken) zur Verfügung gestellt würde. Die Verwendung von DZBG impliziert im Folgenden die sogenannte Retail-Variante, einer Bereitstellung von DZBG für jedermann. 5 In der Literatur hat sich der Begriff „Digitales Zentralbankgeld“ etabliert. Im engeren Sinne und zur Verwendung in programmierbaren Anwendungen wird von digitalem Zentralbankgeld in tokenisierter Form ausgegangen. Grundsätzlich ist aber auch eine kontenbasierte Ausgestaltung von DZBG denkbar. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 9

bankgeld kann eine erhebliche Ausweitung der Akti- Zahlungen herauszustellen. Grundsätzlich sind bei vitäten der Zentralbank in bisher den Geschäftsbanken DZBG vor allem aus technischer Sicht kaum Ein- vorbehaltenen Sphären bedeuten. Wie bei den vor- schränkungen zu erkennen. Aus ökonomischer Sicht genannten Beispielen hängt auch hier der Leistungs- müssten jedoch etwaige Implikation einer Einfüh- umfang in Hinblick auf Programmierbarkeit an der rung von DZBG hinreichend analysiert werden. Dies letztendlichen Ausgestaltung des Systems. Es ist daher umfasst u.a. Auswirkungen auf die jeweilige Rolle notwendig, die erforderlichen Elemente für die Nut- der Geschäftsbanken und der emittierenden Noten- zung der DZBG-Infrastruktur für programmierbare bank. 5 Mögliche Lösungsansätze für die stilisierten Anwendungsfälle

Der vorliegende Abschnitt bringt die stilisierten An- ger-Lösung mit Einbindung von Smart Contracts ist wendungsfälle mit den Lösungsansätzen für deren technisch denkbar und daher grundsätzlich geeignet. geldseitige Abwicklung zusammen und nimmt eine Sie hätte zudem den Vorteil, auf dem bestehenden Bewertung der grundsätzlichen Eignung der jeweili- Zahlungsverkehr aufzusetzen. Der absolute Nutzen gen Zahlungslösung im idealtypischen Anwendungs- hängt in hohem Maße von der tatsächlichen Ausge- fall vor. Die Ergebnisse der Auswertung werden in staltung ab, insbesondere von der Fähigkeit zur An- einer Eignungsmatrix am Ende des Kapitels zusam- bindung an Echtzeitzahlungssysteme, die rund um menfassend dargestellt. die Uhr zur Verfügung stehen würden. So gesehen liegt eine potentielle Einschränkung der Trigger- M2M-Zahlungen, IoT-Zahlungen, Automated Sett- Lösung in den Betriebszeiten der konventionellen lement Payments und Pay-per-Use-Zahlungen lassen Zahlungssysteme. Private emittierte Krypto-Token und sich aufgrund ihrer gemeinsamen Eigenschaft als Stable Coins können aus technologischer Sicht für Smart Contract-basierte Anwendungsfälle bei der die Abwicklung DLT-basierter Geschäftsfälle ange- Bewertung einer dafür geeigneten Zahlungslösung wendet werden. Jedoch mangelt es nicht zuletzt zusammenfassen. Der konventionelle Zahlungsver- aufgrund hoher Volatilitäten, mangelnder Interope- kehr, für den nur bargeldlose Zahlungsinstrumente rabilität und offener rechtlicher Fragestellungen an berücksichtigt wurden, ist gegenwärtig nicht in der der Anwendbarkeit in der Praxis, sodass diese Instru- Lage, Smart Contracts in den Zahlungsvorgang zu mente praktisch ungeeignet erscheinen. Tokenisiertes integrieren. Zwar lassen sich programmierbare Zah- Geschäftsbankengeld und digitales Zentralbankgeld lungen geringerer Komplexität mithilfe von Dauer- sind unter der Annahme einer rechtlich sicheren, aufträgen oder Lastschriftverfahren durchführen, je- technisch zuverlässigen und mit DLT-Anwendungen doch stoßen diese Instrumente für automatisierte interoperablen Lösung rein aus Sicht des Zahlungs- und nicht diskretionäre Anwendungsfälle zunehmend verkehrs uneingeschränkt anwendbar. Allerdings an ihre Grenzen. Dies gilt insbesondere für DLT- bringen diese Instrumente die weitestgehenden Im- basierte Geschäftsfälle, deren geldseitige Abwicklung plikationen für die Rolle der Zentralbank und erfor- nicht synchron und automatisiert über den konven- dern eine weitergehende Bewertung. tionellen Zahlungsverkehr durchführbar ist. Eine Trig- Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 10

Die bidirektionalen Verrechnungen lassen sich die währungspolitische Souveränität einzelner Staaten über den konventionellen Zahlungsverkehr (mit implizieren. Selbst im Fall einer Einführung von toke- meist 140 Zeichen als Limit für Verwendungszweck nisiertem Geschäftsbankengeld und digitalem Zentral- oder Nutzerinformation) nur unter Effizienzverlusten bankgeld sind Effizienzgewinne im währungsraum- abwickeln. Denn hier müsste mit Medienbrüchen überschreitenden Zahlungsverkehr unsicher, da es umgegangen werden (neben der Zahlungsnachricht fraglich ist, ob Institute und Notenbanken aus ver- wäre eine ergänzende Erklärnachricht notwendig), schiedenen Währungsräumen kooperieren würden. die vielfach unvollständige Referenzdaten für die Zahlungsverbuchung zur Folge haben und häufig Mit Instant Payments verfügt der konventionelle manuelle Nacharbeit erfordern. Die Anwendung einer Zahlungsverkehr – und damit grundsätzlich auch die Trigger-Lösung sollte solchen Medienbrüchen entge- Trigger-Lösung – bereits über ein geeignetes Instru- genwirken. Private Krypto-Token und Stable Coins ment zur geldseitigen Abwicklung von 24/7-Zahlun- sind für die Abwicklung bidirektionaler Verrechnungen gen. Diese sind technisch zwar auch mit privaten zwar grundsätzlich geeignet. Da es sich dabei aber Krypto-Token abwickelbar, jedoch führen volatile nicht um allgemein akzeptierte, volatilitätsfreie Token Austauschverhältnisse zu offiziellen Währungen und handelt, können sich solche Lösungen im B2B-Sektor rechtliche Unsicherheit auch hier zu eingeschränkter kaum durchsetzen. Tokenisiertes Geschäftsbanken- Anwendbarkeit. Eine Integration von 24/7-Standards geld und digitales Zentralbankgeld werden als geeig- für tokenisiertes Geschäftsbankengeld und digitales nete Lösung für bidirektionale Verrechnungen gese- Zentralbankgeld ist aufgrund der heute bereits be- hen, da maximale Datenqualität durch geschlossene stehenden Verfügbarkeit von 24/7-Zahlungen wahr- Datenkreisläufe gewährleistet werden kann. Die scheinlich. Nachrichtenübermittlung sowie die Wertübermittlung erfolgen hier nämlich nicht nur synchron, sondern in Zahlungen mit Informationsfunktion können heute einem System ohne Medienbrüche. schon über den konventionellen Zahlungsverkehr aus- geführt werden, jedoch ist die Informationsmenge Währungsraumüberschreitende Auslandsgeschäfte stark eingeschränkt. Die Trigger-Lösung greift auf lassen sich zwar über den konventionellen Zahlungs- selbige Nachrichtenformate zurück, weshalb kein verkehr darstellen, werden aber als wenig effizient bzw. nur ein geringer Zusatznutzen gegenüber dem und kostenintensiv (für kleinere Beträge) angesehen. konventionellen Zahlungsverkehr zu erwarten ist. Der Insofern kann für diesen Geschäftsfall dem konventi- Zusatzbedarf an Informationen müsste dann außer- onellen Zahlungsverkehr nur eine eingeschränkte halb des konventionellen Zahlungsverkehrs separat Eignung attestiert werden. Selbiges gilt für die Trigger- übermittelt werden. Während private Krypto-Token Lösung, die eine technische Schnittstelle zum kon- zwar technisch anwendbar sind, sind sie für eine ventionellen Zahlungsverkehr herstellt und daher Verwendung in der Realwirtschaft aus den bereits unter Rückgriff auf identische Netzwerke zu gleichen genannten Gründen ungeeignet. Tokenisiertes Ge- Einschränkungen führen würde. Private Krypto-Token schäftsbankengeld und digitales Zentralbankgeld kommen im Ergebnis zu gleicher Bewertung. Fehlende werden aufgrund geschlossener Datenkreisläufe und Standards und mangelnde Interoperabilität führen verlässlicher Systembetreiber als geeignete Instrumen- zu verschiedenen Insellösungen, die wenig Mehrwert te für Zahlungen mit Informationsfunktion gesehen. gegenüber dem konventionellen Zahlungsverkehr bieten. Stable Coins könnten, je nach zugrundelie- Bargeldlose Offline-Zahlungen könnten insbeson- gender Sicherheit, Risiken für die Finanzstabilität und dere bei Peer-to-Peer-Zahlungen und teilweise am Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 11

Point-of-Sale nachgefragt werden. Über den kon- Zusammenfassend: ventionellen Zahlungsverkehr sind Offline-Zahlungen gegenwärtig zwar möglich, bspw. mittels Prepaid  Die geldseitige Abwicklung Smart Contract-ba- Geldkarten, stoßen aber mit steigenden Transaktions- sierter Geschäftsfälle ist mit dem konventionellen volumina und längeren Offline-Funktionalitäten an Zahlungsverkehr nicht darstellbar. ihre Grenzen. Selbiges gilt für Offline Angebote pri-  Grundsätzlich können 24/7-Zahlungen mithilfe vater Anbieter von Krypto-Token, deren Anwendung von Instant Payments im Euroraum hinreichend darüber hinaus unter Fragen der Rechtssicherheit abgedeckt werden. und Wertstabilität eingeschränkt wird. Eine Trigger-  Mit Trigger-Lösungen lässt sich die Abwicklung Lösung ist ohne Netzwerkverbindung gegenwärtig Smart Contract-basierter Geschäftsfälle in den nur mittels sogenannter „Second Layer-Technologien“6 konventionellen Zahlungsverkehr integrieren. denkbar, da die Verfügbarkeit verschiedener Schnitt- Zwar sind Einschränkungen in der Umsetzung stellenfunktionen durchgehend gewährleistet sein und Anwendbarkeit zu erwarten. Dennoch sind muss. Während die umfangreichen Gestaltungs- Trigger-Lösungen grundsätzlich als Zahlungs- möglichkeiten bei digitalem Zentralbankgeld auch lösung geeignet – insbesondere, wenn sie an Möglichkeiten für Offline-Zahlungen beinhalten, gilt TARGET2 oder TIPS angeschlossen sind. dies für tokenisiertes Geschäftsbankengeld nur ein-  Teilweise sind private Krypto-Token und Stable geschränkt. Für Geschäftsbanken könnte insbeson- Coins technisch in der Lage, die dargestellten dere der damit verbundene Standardisierungspro- Anwendungsfälle geldseitig abzuwickeln. Auf- zess eine größere Herausforderung sein als für eine grund fehlender Wertstabilität, eingeschränkter Zentralbank. Interoperabilität und offener Fragen zur Rechts- sicherheit, erscheinen sie in der Praxis gegen- wärtig eher als ungeeignet.  Tokenisiertes Geschäftsbankengeld und digitales Zentralbankgeld lassen sich im idealtypischen Fall als geeignete Zahlungslösungen für die dargestellten Anwendungsfälle klassifizieren. Insbesondere digitales Zentralbankgeld kann jedoch mit er- heblichen Implikationen für die Rolle der Zentral- banken verbunden sein und erfordert eine weitergehende Bewertung.

6 Sogenannte Second-Layer-Technologien werden eingesetzt, um die Skalierbarkeit von Blockchainlösungen zu erhöhen. Dabei baut man auf die Blockchain (First Layer) eine zweite Schicht (Second Layer), die nicht ständig mit der ersten Schicht kommuniziert, aber die Abwicklung einzelner Prozesse übernimmt. Solche Technologien können Offline-Zeiten überbrücken helfen. Vgl. https://assets.bosch.com/media/global/research/eot/bosch-eot-direct-state-transfer_de.pdf. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 12

Übersichtstabelle Lösungsansätze für stilisierte Anwendungsfälle

Konventioneller Trigger zum Private Krypto- Tokenisiertes Digitales Zahlungsverkehr7 konventionellen Token (z.B. Ether) Geschäftsbanken- Zentralbankgeld Zahlungsverkehr und private Stable geld Coins (z.B. Diem)

M2M-Zahlungen Nicht für Smart Geeignet, wenn Aus technischer Uneingeschränkt Uneingeschränkt Contracts geeignet. Zahlungen in Sicht geeignet. geeignet unter der geeignet unter der Echtzeit oder Eingeschränkte Annahme einer Annahme einer Fast-Echtzeit Interoperabilität, Standardlösung, Standardlösung, möglich sind. fehlende Wert- die Sicherheit, die Sicherheit, stabilität und Effizienz und Effizienz und offene Fragen der Interoperabilität Interoperabilität Rechtssicherheit gewährleistet. gewährleistet. erschweren die Anwendung in der Praxis.

IoT-Zahlungen (siehe oben) (siehe oben) (siehe oben) (siehe oben) (siehe oben)

Automated Settle- (siehe oben) (siehe oben) (siehe oben) (siehe oben) (siehe oben) ment Payments

Pay-per-Use- (siehe oben) (siehe oben) (siehe oben) (siehe oben) (siehe oben) Zahlungen

Bidirektionale Medienbrüche Medienbrüche (siehe oben) (siehe oben) (siehe oben) Verrechnungen führen oft zu führen oft zu falschen oder falschen oder unvollständigen unvollständigen Referenzdaten Referenzdaten für den Verrech- für den Verrech- nungsprozess; nungsprozess; erfordert manuelle erfordert manuelle Nacharbeit. Nacharbeit.

Auslands- In begrenztem In begrenztem (siehe oben) Es ist nicht klar, ob Es ist nicht klar, geschäfte 8 Umfang möglich Umfang möglich alle europäischen ob Zentralbanken (z. B. über SWIFT), (z. B. über SWIFT), Banken teilnehmen unterschiedlicher aber ineffizient und aber ineffizient würden. Daher Währungsräume kostenintensiv. und kostenintensiv. möglicherweise zusammenarbeiten Zudem ist kein Op- grenzüber- würden. Daher timierungspotenzial schreitend nur möglicherweise gegenüber dem eingeschränkt grenzüber- konventionellem einsetzbar. schreitend nur Zahlungsverkehr eingeschränkt vorhanden. einsetzbar.

7 Nur bargeldlose Zahlungen 8 Es werden nur währungsraumüberschreitende Zahlungen betrachtet. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 13

Konventioneller Trigger zum Private Krypto- Tokenisiertes Digitales Zahlungsverkehr9 konventionellen Token (z.B. Ether) Geschäftsbanken- Zentralbankgeld Zahlungsverkehr und private Stable geld Coins (z.B. Diem)

24/7-Zahlungen Instant Payments Instant Payments (siehe oben) Uneingeschränkt Uneingeschränkt als Basis für 24/7 als Basis für 24/7 geeignet unter der geeignet unter der Zahlungen. Zahlungen. Annahme einer Annahme einer Standardlösung, Standardlösung, die Sicherheit, die Sicherheit, Effizienz und Effizienz und Interoperabilität Interoperabilität gewährleistet. gewährleistet.

Zahlungen mit Mit eingeschränkter Mit eingeschränkter (siehe oben) (siehe oben) (siehe oben) Informations- Informationsmenge Informationsmenge funktion möglich. möglich.

Offline-Zahlungen Eingeschränkt Sehr eingeschränkt Eingeschränkt Bisher sind keine Entscheidung über möglich. möglich, z. B. möglich, z. B. über konkreten Pläne zur Ausgestaltung unter Anwendung Offline-Lösungen Ausgestaltung be- von digitalem von Second-Layer- (Prepaid-Karten, kannt, daher kann Zentralbankgeld Technologien. Voucher, auflad- die Umsetzung von noch offen, Offline- bare Wallets). Offline-Funktionen Zahlungen aber nicht garantiert vorstellbar. werden.

 Grün hinterlegt: Zahlungslösung ist für den entsprechenden Anwendungsfall geeignet; Text erklärt Farbwahl

 Gelb hinterlegt: Zahlungslösung ist für den entsprechenden Anwendungsfall eingeschränkt geeignet; Text erklärt Farbwahl

 Rot hinterlegt: Zahlungslösung ist für den entsprechenden Anwendungsfall nicht geeignet; Text erklärt Farbwahl

9 Nur bargeldlose Zahlungen Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 14

6 Anforderungen an programmierbare Zahlungen

Aus der Bewertung der Zahlungslösungen und der heiten für die jeweilige Zahlungslösung garantiert. Eignungsmatrix lassen sich allgemeingültige Anfor- Sollten sich Lösungen für programmierbare Zahlungen derungen ableiten, die für alle Formen programmier- nicht in bestehende rechtliche Rahmenbedingungen baren Geldes und unabhängig vom jeweiligen Emit- einordnen lassen, bestünde gegebenenfalls Ergän- tenten gelten sollten. Eine umfassende Berück- zungsbedarf. sichtigung der Anforderungen innerhalb etwaiger Implementierungsmaßnahmen ist Voraussetzung für Die Diskussion über neue Abwicklungstechnologien eine universelle Akzeptanz als funktionsgerechte und und Formen programmierbaren Geldes wird von ver- effiziente Zahlungslösung für die Real- und Finanz- schiedenen Interessen und unterschiedlichen Markt- wirtschaft. Die Grundprinzipien des gegenwärtigen bedürfnissen geleitet. Dennoch ist eine einheitliche Geldsystems sollten dabei keinesfalls verändert, und Standardlösung wünschenswert. Sollten mehrere das geldpolitische Instrumentarium nicht angepasst Lösungen zur Abwicklung programmierbarer Zah- werden. lungen koexistieren, hängt der Anwendungsnutzen von der Interoperabilität der jeweiligen Lösung ab. Die Geldwertstabilität als Leitgedanke eines effekti- Die Interoperabilität lässt sich dabei in verschiedener ven Zahlungs- und Geldsystems muss auch für pro- Hinsicht definieren. grammierbares Geld und die Ausführung programmierbarer Zahlungen erhalten bleiben. Die von einer (a) Interoperabilität zwischen verschiedenen Geld- institutionellen Entität zu wahrende Wertstabilität formen, z.B. DZBG zu Bargeld und Sichteinlagen programmierbaren Geldes ist die Basis für das Ver- trauen der Akteure in das Geldsystem und Grundlage (b) Interoperabilität zwischen Zahlungsauslösesystem für die Verwendung für Transaktionen innerhalb eines und der Geldform, z.B. Trigger-Lösung zu Zentral- ökonomischen Kontexts. bankgeld

Diese Betrachtungsweise gilt gleichermaßen für die (c) Interoperabilität zwischen rechtlich verschiedenen Einhaltung eines fixen Nominalwertes. Dieser er- Ausprägungen innerhalb einer Klasse von Zah- möglicht eine 1:1-Konvertierbarkeit aller Geldformen lungslösungen, z.B. DZBG unterschiedlicher in der gleichen Währung. So kann Geld ohne Wert- Währungsräume verlust von einer Form in die andere konvertiert werden und die Funktionsfähigkeit als Zahlungsmittel, (d) Interoperabilität zwischen unterschiedlichen Wertaufbewahrungsmittel und Recheneinheit bleibt DLT-Protokollen, z.B. Corda und Hyperledger ohne Abstriche gewährleistet. Fabric

Gleichermaßen von Relevanz ist die Anwendung von Allgemein gilt, dass eine höhere Interoperabilität den programmierbaren Zahlungen innerhalb eines regu- Nutzen und den Anwendungsbereich einer jeden latorischen Rahmens, der eine technisch verlässliche Zahlungslösung erhöht. Unter der Annahme einer und formal rechtssichere Übertragung von Wertein- stetigen Weiterentwicklung von DLT-Systemen, ist ein Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 15

hohes Maß an Interoperabilität Voraussetzung für Dazu zählen auch die Wahrung von Datenschutz Anpassungsfähigkeit und Langlebigkeit der Zahlungs- und Privatsphäre der Nutzergruppen. Grundsätzlich lösung. müssen alle Transaktionen und Zahlungsvorgänge in Einklang mit den bestehenden rechtstaatlichen Vor- Die technologische Infrastruktur für die Anwendung gaben zur Einhaltung der individuellen Persönlichkeits- programmierbarer Zahlungen und für die Übertragung rechte und der geltenden Datenschutzverordnungen programmierbaren Geldes soll ferner mit hinreichen- stehen. Programmierbare Zahlungen und Transaktionen der Innovationsfähigkeit implementiert werden. mit programmierbarem Geld müssen diese Anforde- Die Dynamik der digitalen Transformation sowie die rungen gleichermaßen erfüllen. Gleichzeitig muss si- Innovationsfähigkeit der Wirtschaft bedingen ein chergestellt werden, dass der Grad der Anonymität hohes Maß an Flexibilität sowie die Möglichkeit, auf nicht die Regeln zur Bekämpfung von Geldwäsche kurzfristig geänderte Nutzer- und Anwendungsbe- und Terrorismusfinanzierung unterläuft. Analog dürfnisse reagieren zu können. Die Anwendung soll zum Bargeld wird aus Sicht der Real- und Finanzwirt- daher technische Weiterentwicklungen bedarfsgerecht schaft ein gewisses Maß an Anonymität bevorzugt. ermöglichen sowie die Ergänzung um technisch ver- Unterschieden werden sollte zwischen verschiedenen schiedenartig konstruierte Lösungen nicht verhindern. Gegenparteien, gegenüber denen Transparenz oder Denkbar wären bspw. Umsetzungsmöglichkeiten, Anonymität erforderlich sind: die auf Open Source Software beruhen. Vermieden werden sollten spezialisierte Insellösungen mit ein- (a) Geschäftspartner: Transparenz bezieht sich auf geschränktem Lebenszyklus. personenbezogene Daten, die vertragsrelevant sind und zum Zustandekommen eines Zahlungs- Es gelten höchste Qualitätsanforderungen an die vorgangs benötigt werden. Informations- und Cybersicherheit der operativen Systeme. Dies umfasst nicht nur einen hochgradig (b) Zahlungsinfrastruktur: Eingeschränkte Anony- wirkungsvollen Schutz gegenüber unautorisierten mität gegenüber dem Betreiber der Zahlungsin- Systemeingriffen, sondern auch die Resilienz gegen- frastruktur. Die Einschränkung muss sich aus Be- über systemseitigen Störungen und Ausfällen. Inno- treiberpflichten und operativen Überlegungen vationsfreundlichkeit und die Anwendung neuer begründen lassen. Diese Teil-Anonymität ist aus Technologien dürfen keinesfalls zulasten der System- wettbewerbsrechtlichen Gründen elementar, sicherheit gehen. Die Erfahrungen aus dem Betrieb und insbesondere wenn die Betreiberrolle einem pri- das Schutzniveau gegenwärtiger Zahlungssysteme vatwirtschaftlichen Unternehmen obliegt. Gleich- können als Vorbild für die Implementierung neuer wohl ist der Zugang zu teil-anonymisierten In- Zahlungsinfrastrukturen herangezogen werden. formationen erforderlich, um Pflichten zur Mel- dung geldwäscherelevanter Vorgänge ausüben Erforderlich ist in jedem Fall die Zuweisung einer ein- zu können. Eine sonstige Weitergabe sollte deutigen Betreiberverantwortung. Dazu muss sicher- strafbewehrt untersagt sein. gestellt werden, dass ein eindeutig identifizierbarer Betreiber die Verantwortung für die Funktionsfähig- (c) Staatliche Institutionen: Grundsätzliche Ano- keit, Sicherheit und Rechtskonformität des operati- nymität gegenüber staatlichen Institutionen. Aus- ven Netzwerks übernimmt und die Auflagen der nahmen können bei berechtigtem staatlichen Aufsichts- und Regulierungsbehörden erfüllt. Interesse insbesondere zum Zweck der Zahlungs- verkehrsaufsicht, der Bekämpfung von Geldwä- Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 16

sche und Terrorismusfinanzierung und bei Straf- Globalisierung und digitale Vernetzung dehnen die verfolgung definiert sein. Geschäftszeiten international aktiver Unternehmen aus. Eine 24/7 (Near-Time/Real-Time) -Verfügbarkeit (d) Unbeteiligte Dritte: Volle Anonymität gegen- zur geldseitigen Abwicklung von Transaktionen ist über unbeteiligten Dritten. erforderlich, um Geschäftsprozesse synchronisieren zu können. Programmierbare Zahlungen sollten per Design mög- lichst allgemein und uneingeschränkt zur Verfügung Neben allgemeinen Anforderungen sollten program- stehen. Die Inklusion darf sich jedoch nicht nur auf mierbare Zahlungen und programmierbares Geld spe- die ökonomische Teilhabe von Personen ohne Zu- zifische Charaktereigenschaften aufweisen, die insbe- gang zum Zahlungsverkehr beschränken, sondern sondere den Gebrauch als Transaktionsmedium stützen: sollte möglichst auch Menschen mit körperlichen Einschränkungen die Nutzung ermöglichen. Zu er- (a) Micropayments: Fähigkeit zur vielfachen Teil- wägen sind daher zusätzliche haptische, optische barkeit, um Zahlungen mit Betragswerten unter oder akustische Erkennungsmerkmale. Damit einher einem Cent abwickeln zu können. gehen generelle Überlegungen der Nutzerfreundlich- keit, die eine einfache und praktikable Benutzung in (b) Feedbackfunktion: Fähigkeit zum Abrufen von das Zentrum des Designs stellen. Statusmeldungen der Transaktion, z.B. Introduc- tion, Pending, Success, Decline. Deutsche Bundesbank Geld in programmierbaren Anwendungen Seite 17

Teilnehmerliste der AG Programmierbares Geld

Initiatoren: Dr. Jens Weidmann, Präsident der Deutschen Bundesbank Olaf Scholz, Bundesminister der Finanzen Burkhard Balz, Mitglied des Vorstands der Deutschen Bundesbank Dr. Jörg Kukies, Staatssekretär im Bundesministerium der Finanzen

Institution Name

Bundesdruckerei GmbH Sven Marsing Florian Peters DB Systel GmbH Claudia Plattner Deutsche Bank AG André Bajorat Alexander Bechtel Deutsche Börse AG Thomas Wißbach Deutsche Bundesbank Dr. Martin Diehl Constantin Drott Marcus Härtel Dr. Heike Winter DZ Bank AG Claus George Evonik Digital GmbH Heinz-Günter Lux Frankfurt School of Finance & Prof. Dr. Philipp Sandner Management gGmbH Generic.de software technologies AG Sebastian Betzin Helaba Landesbank Hessen-Thüringen Philipp Kaiser IBM Deutschland GmbH Elke Kunde ING-Diba AG Jürgen von der Lehr Landesbank Baden-Württemberg Joachim Erdle Main Incubator GmbH (Commerzbank AG) Michael Spitz MARKANT Services International GmbH Rene Clasani Robert Bosch GmbH Ricky Lamberty SAP SE Alessandro Gasch Siemens AG Ramin Ghafari Volkswagen AG Benjamin Sinram Zalando Payments GmbH Kai-Uwe Mokros Deutsche Bundesbank Wilhelm-Epstein-Straße 14 60431 Frankfurt am Main

Postfach 10 06 02 60006 Frankfurt am Main

Telefon 069 9566-0 Telefax 069 5601071 Internet https://www.bundesbank.de