Wenn man den Begriff Bezahl App „googelt“ stößt man auf Apple Pay, Google Pay, Payback Pay, Bluecode, PayPal Pay, Apps der Banken, wie die „Pay App“ der VR-Banken usw. Fast synonym wird der Begriff Wallet verwendet. Unter diese Begriffe fallen offensichtlich sowohl Wallets/Apps, die ein Träger oder Container sind für virtuelle Zahlungskarten (wie z. B. Apple und Google Pay), als auch proprietäre Zahlungssysteme, wie Payback Pay und Bluecode. Oft ist dort ein Zahlungsinstrument hinterlegt, das zum „Funding“ der Zahlung dient. Die Zahlung erfolgt aber auf Basis der Regel des jeweiligen Zahlungssystems, unabhängig von der Funding-Methode.
Table of Contents
Wallet ist also nicht gleich Wallet. Auch aus regulatorischer Sicht ist diese Unterscheidung wichtig. In den Vorschlägen zur PSD3/PSR vom 28. Juni 2023 wird die erste Kategorie der Container Wallets „pass-through wallets“ (im Folgenden als PT-Wallets bezeichnet), die zweite Kategorie „staged-wallets“ genannt. Im Gegensatz zum Anbieter eines „staged“ Wallets bietet der Anbieter eines PT-Wallets kein Zahlungsinstrument an, sondern nur eine technische Dienstleistung. Diese erfolgt in Form eines digitalen (man könnte sagen „statt ledernen“) Portemonnaies mit mehreren Fächern für digitale Zahlungsinstrumente, die von Dritten herausgegeben werden, z. B. eine virtuelle Kreditkarte. In der Regel führt er für den Issuer auch die erforderliche Strong Customer Authentication (SCA) durch, z.B. durch Fingerabdruck (Stichwort „delegated SCA“). Die Kommission hat im Vorfeld des neuen Regulierungspaketes ernsthaft darüber nachgedacht, diese Serviceanbieter in die neue Regulierung mit aufzunehmen, vor allem da es sich oft um BigTech (Google, Apple und Co.) handelt, aber derzeit noch davon Abstand genommen. Im Impact Assessment Report zur PSD3/PSR (S. 162-164) geht die Kommission ausführlich auf die Gründe ein.[1]
So weit, so gut. Nun taucht aber im Erwägungsgrund 24 PSR bzw. gleichlautend 13 PSD3 (im Folgenden wird nur noch der Erwägungsgrund 24 PSR genannt) ein erklärungsbedürftiger Satz (unterstrichen vom Verfasser) auf:
„So-called digital ‘pass-through wallets’, involving the tokenisation of an existing payment instrument, for example a payment card, are to be considered as technical services and should thus be excluded from the definition of payment instrument as, in the Commission’s view, a token cannot be regarded as being itself a payment instrument but, rather, a ‘payment application’ within the meaning of Article 2(21) of Regulation (EU) 2015/751 of the European Parliament and of the Council. However, some other categories of digital wallets, namely pre-paid electronic wallets such as ‘staged-wallets’ where users can store money for future online transactions, should be considered a payment instrument and their issuance a payment service.”
Ein Token ist keine Zahlungsapplikation
Der Begriff „Token“ kann im Bereich des Zahlungsverkehrs völlig unterschiedliche Bedeutungen haben, wie z. B. token-basiertes E-Geld als Inhaberinstrument (GeldKarte) oder Giralgeld-Token auf DLT-Basis. Auch in Bezug auf Kryptowerte und CBDC wird der Begriff „Token“ nicht einheitlich verwendet.[2] Im Zusammenhang mit PT-Wallets“ ist im Erwägungsgrund 24 PSR davon auszugehen, dass mit einem Token der Ersatz der PAN (Primary Account Number) einer Zahlungskarte gemeint ist, die bei einer Zahlung aus Sicherheits- und Datenschutzgründen insbesondere bei der kontaktlosen mobilen Zahlung mit einer virtuellen Karte jeweils generiert wird.[3] Tokenisierung wäre demnach der Prozess des Ersatzes der Kartenzahlungsnummer in einem Zahlungsvorgang. Die Tokenisierung ist ein technischer Vorgang, der die DNA einer Zahlungskarte als Zahlungsinstrument nicht verändert. Statt PAN wird eine einmalige Nummer (Token) generiert. Für die Einstufung einer Zahlungskarte als Zahlungsinstrument im Sinne der PSD3/PSR ist es demnach unerheblich, ob die Karte physisch oder virtuell (z. B. bei Fernzahlungen mittels der PAN) genutzt wird. Auch eine virtuelle Karte, die in einem PT-Wallet unter Verwendung eines Tokens genutzt wird, bleibt ein Zahlungsinstrument. Das Token ersetzt nur die beim Issuer gespeicherten Kartendaten und wird im PT-Wallet-Fall in der Regel vom Issuer mit Hilfe des jeweiligen Schemes als Anbieter von „Token Services“ bereitgestellt.
Im vorhin genannten Erwägungsgrund wird nun zu Recht klargestellt, dass ein PT-Wallet kein Zahlungsinstrument ist. Die Europäische Kommission ist aber weiter der Ansicht, dass nun das Token kein Zahlungsinstrument mehr ist, sondern eine Zahlungsapplikation[4] gemäß Art. 2(21) der Interchange Fee Regulation 2015/751 (IFR). Tokenisierung führt zu einer Metamorphose: Aus einem Zahlungsinstrument wird eine Zahlungsapplikation.
Wenn ein Karteninhaber im E-Commerce (card-not-present) nur die PAN seiner Karte (und andere Daten) für eine Kartenzahlung nutzt, verwendet er weiterhin ein Zahlungsinstrument. Wird die PAN nicht im Klartext verwendet, würde es sich um die Nutzung einer Zahlungsapplikation handeln. Diese Logik ist schwer nachvollziehbar.
Hintergrund laut Impact Assessment Report
Eine Begründung für dieses bemerkenswerte Verständnis liefert das von der Kommission erstellte Impact Assessment Report zur PSD3/PSR:
“Does the tokenisation of an existing payment instrument in such a wallet (for example a payment card) amount to the issuance of a new payment instrument, and if so, which party issues the new tokenised payment instrument, the PSP which issued the original payment instrument, or the operator of the wallet?
If the answer to the first question is yes and the answer to the second question is the operator of the wallet, then the wallet operator would already today need a PSP license. It will be clarified that unless it could be used as a standalone payment instrument that can be used to initiate a payment order independently from the underlying tokenised payment instrument (e.g. a card), the token cannot be considered as being itself a payment instrument but, rather, a ‘payment application’ within the meaning of Art. 2(21) of the Interchange Fee Regulation.”
Offensichtlich beantwortet die Kommission die erste Frage (“Does the tokenisation of an existing payment instrument in such a wallet (for example a payment card) amount to the issuance of a new payment instrument…?”) mit nein, weil sonst der Issuer (nach Ansicht der Kommission der „operator of the wallet“) dieses neuen Zahlungsinstruments erlaubnispflichtig wäre. Abgesehen von der Fragwürdigkeit der hier angewendeten Logik ist diese Schlussfolgerung in mehreren Hinsichten falsch.
Wie vorhin dargelegt, führt die Tokenisierung eines existierenden Zahlungsinstruments nicht zu einem neuen Zahlungsinstrument und gegebenenfalls auch nicht zu einem neuen Herausgeber. Der Herausgeber ist und bleibt der (erlaubnispflichtige) Kartenherausgeber, der in diesem Fall eine zusätzliche virtuelle Version der Karte dem Karteninhaber bereitstellt. Auch wenn der Issuer eine neue, nur virtuell existente Karte bereitstellt, ist er der alleinige Herausgeber dieses Zahlungsinstruments.[5] Die Annahme, der PT-Wallet-Anbieter wird durch Tokenisierung zum Anbieter einer Zahlungsapplikation, ist abwegig. Der von der Kommission vorgeschlagene Kunstgriff mittels der Transformation eines Zahlungsinstruments in eine Zahlungsapplikation ist nicht nur methodisch fragwürdig, sondern auch überflüssig.
Da das Herausgeben einer Zahlungsapplikation offensichtlich nicht als die Erbringung eines Zahlungsdienstes gemäß PSD3/PSR angesehen wird, stellt sich die Frage nach dem Zweck dieser von der Kommission vorgeschlagenen Metamorphose. Es ist denkbar, dass die Kommission für den Bereitsteller des Tokens (nach Ansicht der Kommission der „wallet operator“) irgendwelche Verpflichtungen, die sich aus der IFR ergeben, ableiten möchte.
Die Auffassung, eine virtuelle Karte bzw. Token in einem PT-Wallet, wäre kein Zahlungsinstrument, sondern eine Zahlungsapplikation gemäß Art. 2(21) IFR, würde mehrere neue Fragen und Widersprüche aufwerfen, die im Folgenden näher erläutert werden:
- Inkompatible Definition einer Zahlungsapplikation in der IFR
- Begrenzung auf tokenisierte kartenbasierte Zahlungsinstrumente
- Welches Zahlungsinstrument ist der Träger der Zahlungsapplikation?
1. Inkompatible Definition einer Zahlungsapplikation in der IFR
Was ist nun eine Zahlungsapplikation und welche Bedeutung hat der Begriff in der IFR?
Die Definition einer Zahlungsapplikation gemäß Art. 2(21) IFR lautet:
“computer software or equivalent loaded on a device enabling card-based payment transactions to be initiated and allowing the payer to issue payment orders”.
Diese Definition zeigt erhebliche inhaltliche Überschneidungen mit der bislang gültigen Definition eines Zahlungsinstruments der PSD2 (Art. 4(14)):
“a personalised device(s) and/or set of procedures agreed between the payment service user and the payment service provider and used in order to initiate a payment order”.
Der Gesetzgeber verzichtete in der IFR auf eine klare Begriffsabgrenzung. Die Definition einer Zahlungsapplikation ist enger gefasst, da sie nur auf die immaterielle Zahlungsanwendung abzielt und das materielle Gerät („device“) nicht inkludiert, sondern nur dessen Existenz voraussetzt. Wenn man logischerweise das technische Gerät im Fall eines materiellen Trägers unterschiedlicher Zahlungsinstrumente als völlig redundant für die Definition eines digitalen Zahlungsinstruments betrachtet, beziehen beide Definitionen sich nur noch auf die software-basierte Prozedur, die die Ausführung eines Zahlungsauftrags auslöst. Im Falle einer Plastikkartenzahlung stellt sich die Frage, ob sich das Zahlungsinstrument noch von der Zahlungsapplikation unterscheidet. Der Wortlaut der Definition einer Zahlungsapplikation führt leider nicht zu einer klaren Abgrenzung.
Anwendung im Co-Badging-Fall
Der Begriff Zahlungsapplikation findet – soweit ersichtlich – ausschließlich in der IFR Anwendung für sog. „card-based payment transactions” gemäß Art. 2(7) IFR, wenn der sog. Co-Badging-Fall (gemäß Art. 8 IFR) vorliegt.
Co-Badging bedeutet gemäß Art. 2(31) IFR “the inclusion of two or more payment brands or payment applications of the same brand on the same card-based payment instrument”. Die Zahlungsapplikation bezieht sich in diesem Kontext auf eine Funktionalität der Karte, z. B. die Funktion als Debit- oder Kreditkarte. Der Fall ist gegeben, wenn z. B. der Karteninhaber mit einer Zahlungskarte am POS entweder eine Debitkartentransaktion (gemäß Art. 2(4) IFR) oder eine Kreditkartentransaktion (gemäß Art. 2(5) IFR) initiieren kann. Dieser Co-Badging-Fall ist recht selten in der EU. In der Praxis sehen wir meistens den anderen Co-Badging-Fall: Zwei unterschiedliche Brands, wie z.B. in Deutschland eine Debitkarte mit den Brands Girocard und Maestro.
Im Fall unterschiedlicher Zahlungsapplikationen bezieht sich das Co-Badging auf eine unterschiedliche Zahlungsfrist des Karteninhabers gegenüber dem Kartenherausgeber. Die IFR verwendet für diese kartenbasierten Applikationen parallel auch den Begriff „categories“ (wie z. B. in Art. 9 und 10 IFR).[6]
Bei einer Zahlungsapplikation handelt es sich demnach um eine Funktionalität des jeweiligen Zahlungsinstruments. In der Regel ist die Funktionalität (z. B. Debit) an das Zahlungsinstrument (Karte) fest gekoppelt (Debitkarte). Unter Verwendung der IFR-Terminologie müsste man bei einer „single-badged“-Karte von einem Zahlungsinstrument, einem Brand und einer Zahlungsapplikation ausgehen. In dem beispielhaften Co-Badging-Fall hat ein Instrument eben zwei Funktionalitäten. Man kann sich (zumindest theoretisch) auch eine Co-Badging-Situation vorstellen, in der beide Funktionalitäten von unterschiedlichen Issuern herausgegeben werden. In diesem Fall sehen wir eine Chipkarte (Träger/Device), zwei Issuer und zwei Zahlungsinstrumente (eine virtuelle Debit- und eine virtuelle Kreditkarte). Die Zahlungsinstrumente verkörpern jeweils nur eine Zahlungsapplikation.
Ist eine Zahlungsapplikation ein Zahlungsinstrument?
Die gesetzlichen Anforderungen im Co-Badging-Fall sind im Art. 8 IFR festgelegt. Die co-badged bedingte Auswahloption des Karteninhabers setzt nicht nur für die Brand-Auswahl (Art. 8(2) IFR), sondern auch für die Applikationsauswahl eine vertragliche Vereinbarung zwischen dem Kartenherausgeber (Issuer) und dem Karteninhaber voraus. Bei einer systematischen Auslegung der Definition „Zahlungsapplikation“ gemäß Art. 2(21) IFR soll demnach von einer vertraglichen Vereinbarung zwischen dem „payment user“ und dem „payment service provider“ ausgegangen werden, die dem Zahlungsnutzer erlaubt, mittels der jeweiligen Applikation seines Zahlungsinstruments einen Zahlungsauftrag zu initiieren. [7]
Damit sind die Definitionen – abgesehen von den oben genannten Unterschieden in Bezug auf die Rolle eines „Device“ – nahezu deckungsgleich. Die IFR differenziert wegen der Anforderungen im Co-Badging-Fall (Art. 8 IFR) explizit zwischen Zahlungsinstrument und Zahlungsapplikation. Die Definition der Zahlungsapplikation gemäß Art. 2(21) IFR ist aber wegen der weitgehenden begrifflichen Übereinstimmung mit der Definition eines Zahlungsinstruments für die einzige Anwendung dieser Definition im Art. 8 IFR demnach nicht kompatibel. Bei einer zukünftigen Überarbeitung der IFR soll der Begriff „Zahlungsapplikation“ ersatzlos gestrichen werden und durch „category“ der kartenbasierten Zahlungsinstrumente ersetzt werden.
Zwischenergebnis: Zahlungsapplikation im Sinne der IFR ist die Funktionalität einer Karte. Schon aus diesem Grund ist die Übernahme des Begriffs „Zahlungsapplikation“ gemäß Art. 2(21) IFR für einen Token zu einer etwaig beabsichtigten Abgrenzung gegenüber einem Zahlungsinstrument ungeeignet.
2. Begrenzung auf tokenisierte kartengebundene Zahlungsinstrumente
Die Definition einer Zahlungsapplikation setzt eine „card-based payment transaction“ voraus. Gemäß dem Erwägungsgrund 24 PSR soll nach Ansicht der Kommission die Einstufung eines „Token“ als Zahlungsapplikation gemäß Art. 2(21) auch für andere tokenisierte Zahlungsinstrumente erfolgen („…tokenisation of an existing payment instrument, for example a payment card,…“). Dies setzt allerdings eine Änderung der Definition einer Zahlungsapplikation voraus, die in der PSR nicht vorgesehen ist
3. Welches Zahlungsinstrument ist der Träger der Zahlungsapplikation?
Bedingt durch die Einstufung des Tokens (und der virtuellen Karte) als Zahlungsapplikation stellt sich letztendlich die Frage, wer oder was die Rolle des Zahlungsinstruments übernimmt, das logischerweise vorhanden sein muss, weil durch Nutzung des Tokens ein Zahlungsauftrag ausgelöst wird. Da das PT-Wallet und das Token diese Funktion nicht innehaben, verbleibt nur das „Device“ (Smartphone, PC, PKW usw.) als kartengebundenes Zahlungsinstrument, das die Applikation trägt.
Innerhalb der Kommission wird diese Auffassung tatsächlich vertreten. Diese Auffassung wäre zwar gedeckt durch die Definition eines Zahlungsinstruments gemäß Art. 4(14) PSD2 bzw. der Definition eines kartengebundenen Zahlungsinstruments gemäß Art. 2(20) IFR, führt aber in einer digitalisierten Zahlungswelt, in der Träger und Zahlungsinstrument nicht nur technisch, sondern auch in Bezug auf den Anbieter entkoppelt sind, zu absurden Ergebnissen. Die Anbieter derartiger „Devices“ würden Zahlungsinstrumente ausgeben und damit erlaubnispflichtige Zahlungsdienste erbringen. Siehe auch PaySys-Report Nr. 1 (2022)[8], in dem wir die problematische PSD-Definition des Zahlungsinstruments und deren zum Teil realitätsfremde Folgen für die Regulierungspraxis ausführlich analysiert haben. Leider wird die Definition eines Zahlungsinstruments in dem PSD3/PSR-Vorschlag trotz eindringlicher Anregungen der EBA[9] von der Kommission nur marginal geändert. Das Problem wird leider nicht in Angriff genommen.
Fazit:
Wenn der betreffende Satz im Erwägungsgrund 24 PSR (bzw. 13 PSD3) ersatzlos gestrichen wird, wäre eine weitere Begriffsverwirrung vom Tisch.
[1] https://finance.ec.europa.eu/publications/financial-data-access-and-payments-package_en
[2] Siehe auch Antwort der Regierung in der Bundestagsdrucksache 20/7277 vom 14.06.2023, S. 21
[3] Für eine gute und verständliche Beschreibung dieser Tokenisierungsprozesse im E-Commerce und im Fall einer PT-Wallet-Kartenzahlung siehe z. B.: https://computop.com/payment-insights/de/credit-cards/tokenisierung-kartenzahlungen-e-commerce/
[4] Der Begriff “payment application” der IFR wird in diesem Beitrag mit „Zahlungsapplikation“ (statt „Zahlungsanwendung“ in der deutschen Übersetzung der IFR) übersetzt.
[5] Siehe auch Opinion of the European Banking Authority on its technical advice on the review of Directive (EU) 2015/2366 on payment services in the internal market (PSD2), EBA/Op/2022/06 vom 23. Juni 2022, Nr. 35, S. 13
[6] Auch aus Art. 10 (5) IFR (Pflicht des Issuers zur elektronischen und optischen Kennzeichnungspflicht der kartenbasierten Zahlungsinstrumente, damit Zahler und Zahlungsempfänger die jeweiligen Brands und Applikationen erkennen können) in Verbindung mit Art. 9 (6, Satz 2) IFR, in dem die Auswahloptionen des Zahlers und Zahlungsempfängers am POS geregelt sind, geht hervor, dass mit Zahlungsapplikationen die jeweiligen Kartenkategorien („prepaid cards, debit cards, credit cards or commercial cards“) gemeint sind. Im Art. 6 Satz 2 IFR werden sogar die „categories of cards“ explizit genannt. Im Art. 12 Abs. 1 Satz 2 wird in Bezug auf die transaktionsbezogenen Informationspflichten des Acquirers allerdings „application“ und „payment instrument categories“ separat erwähnt. Im Erwägungsgrund 40 der IFR wird der Begriff Payment Applikation auch nur in Bezug auf die „Brands“ verwendet. Auf Grund dieser textuellen Inkonsistenzen soll bei der Auslegung des Begriffs „Zahlungsapplikation“ gemäß Art. 2 (21) systematisch vorgegangen werden.
[7] Im Gegensatz zur Definition eines Zahlungsinstruments ist die Existenz einer Vereinbarung zwischen dem Zahlungsdienstnutzer und dem Zahlungsdienstleister keine Tatbestandsvoraussetzung der Definition einer Zahlungsapplikation. Aus der Definition einer Zahlungsapplikation geht allerdings hervor, dass ein Dritter die Nutzung der Applikation gegenüber dem Anwender erlauben soll („allowing the payer to issue payment orders“).
[8] Sind Smartphones, PCs oder sogar Autos Zahlungsinstrumente? Die verwirrende Definition des Zahlungsinstruments in der PSD2, in: PaySys-Report Nr. 1 (2022); Free Download unter: https://paysys.de/paysys-report/
[9] Siehe Opinion of the European Banking Authority on its technical advice on the review of Directive (EU) 2015/2366 on payment services in the internal market (PSD2), EBA/Op/2022/06 vom 23. Juni 2022, Abschnitt 1.5, Nr. 32-39, S. 13f.
Zutreffend beobachtet. Die korrekte regulatorische Einordnung der Tokenisierung im pass through wallet wäre das von der ECB im PISA Framework eingeführte ‘payment arrangement’.
Christoph, vielen Dank für Deine hilfreiche Ergänzung! /hg
Comments are closed.