Geld in programmierbaren Anwendungen - Branchenübergreifende Perspektiven aus der deutschen Wirtschaft* - Deutsche ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Geld in programmier- baren 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Deutsche 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 synchro-
nisiert, 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-programma-
ble-payments-8038ed8fa714Deutsche 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 amDeutsche 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 dargestell-
ten Anwendungsfälle klassifizieren. Insbesondere
digitales Zentralbankgeld kann jedoch mit er-
heblichen Implikationen für die Rolle der Zentral-
banken verbunden sein und erfordert eine weiter-
gehende 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 ZahlungenDeutsche 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 program-
mierbarer 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 wer-
den 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 einDeutsche 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 MokrosDeutsche 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
Sie können auch lesen
