The metamorphosis of a payment instrument into a payment app

The metamorphosis of a payment instrument into a payment app

If you “google” the term payment app, you come across Apple Pay, Google Pay, Payback Pay, Bluecode, PayPal Pay, apps from banks, such as the “Pay App” from VR banks, etc. The term wallet is used almost synonymously. These terms obviously include both wallets/apps, which are a carrier or container for virtual payment cards (such as Apple and Google Pay), and proprietary payment schemes, such as Payback Pay and Bluecode. Often, a payment instrument is stored in these schemes to fund the payment. However, the payment is made based on the rule of the respective payment scheme, regardless of the funding method.

So not all wallets are the same. This distinction is also important from a regulatory perspective. In the PSD3/PSR proposals of June 28, 2023, the first category of container wallets is called “pass-through wallets” (hereinafter referred to as PT wallets), and the second category is called “staged wallets.” In contrast to the provider of a “staged” wallet, the provider of a PT wallet does not offer a payment instrument, but only a technical service. This takes the form of a digital (one might say “rather than leather”) wallet with multiple compartments for digital payment instruments issued by third parties, such as a virtual credit card. Typically, it also performs the required Strong Customer Authentication (SCA) on behalf of the issuer, e.g., by fingerprint (keyword “delegated SCA”). In the run-up to the new regulatory package, the Commission seriously considered including these service providers in the new regulation, especially since they are often BigTech (Google, Apple and Co.), but refrained from doing so at present. In the Impact Assessment Report on PSD3/PSR (pp. 162-164), the Commission discusses the reasons in detail.[1]

So far, so good. Now, however, a sentence requiring explanation (underlined by the author) appears in recital 24 of the PSR or, to use the same wording, 13 of the PSD3 (in the following, only recital 24 of the PSR will be referred to):

„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.”

A token is not a payment application

The term “token” can have completely different meanings in the field of payments, such as token-based e-money as a bearer instrument (German GeldKarte) or tokenized bank deposits based on DLT. The term “token” is also not used consistently in relation to crypto assets and CBDC.[2]

In the context of “PT wallets”, recital 24 PSR assumes that a token means the replacement of the PAN (Primary Account Number) of a payment card, which is generated in each case when a payment is made for security and data protection reasons, particularly in the case of contactless mobile payment with a virtual card.[3] Tokenization would therefore be the process of replacing the card payment number in a payment transaction. Tokenization is a technical process that does not change the DNA of a payment card as a payment instrument. Instead of PAN, a unique number (token) is generated. For the classification of a payment card as a payment instrument within the meaning of the PSD3/PSR, it is therefore irrelevant whether the card is used physically or virtually (e.g., for remote payments using the PAN). Even a virtual card used in a PT wallet using a token remains a payment instrument. The token only replaces the card data stored with the issuer and is usually provided in the PT wallet case by the issuer using the respective scheme as a provider of “token services”.

In the recital mentioned above, it is now rightly clarified that a PT Wallet is not a payment instrument. However, the European Commission is further of the opinion that now the token is no longer a payment instrument, but a payment application according to Art. 2(21) of the Interchange Fee Regulation 2015/751 (IFR). Tokenization leads to a metamorphosis: a payment instrument becomes a payment application.

If a cardholder in e-commerce (card-not-present) uses only the PAN of his card (and other data) for a card payment, he is still using a payment instrument. If the PAN is not used in plain text, it would be the use of a payment application. This logic is difficult to understand.

Background according to the Impact Assessment Report

A rationale for this remarkable understanding is provided by the Commission’s Impact Assessment Report on 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 wal­let?

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 mean­ing of Art. 2(21) of the Interchange Fee Regulation.”

Obviously, the Commission answers the first question (“Does the tokenisation of an existing pay¬ment instrument in such a wallet (for example a payment card) amount to the issuance of a new pay¬ment instrument…?“) with no, because otherwise the issuer (according to the Commission the “operator of the wallet“) of this new payment instrument would be subject to authorization. Apart from the questionability of the logic applied here, this conclusion is wrong in several respects.

As explained above, the tokenization of an existing payment instrument does not lead to a new payment instrument and, if applicable, also not to a new issuer. The issuer is and remains the card issuer (subject to authorization), who in this case provides an additional virtual version of the card to the cardholder. Even if the issuer provides a new, only virtually existing card, it is the sole issuer of this payment instrument. [4] The assumption that the PT wallet provider becomes the provider of a payment application through tokenization is absurd. The trick proposed by the Commission of transforming a payment instrument into a payment application is not only methodologically questionable, but also superfluous.

Since the issuance of a payment app is obviously not considered to be the provision of a payment service under PSD3/PSR, the question arises as to the purpose of this metamorphosis proposed by the Commission. It is conceivable that the Commission would want to derive any obligations arising from the IFR for the provider of the token (in the Commission’s view, the “wallet operator“).

The view that a virtual card or token in a PT wallet, would not be a payment instrument, but rather a payment application under Art. 2(21) IFR, would raise several new questions and contradictions, which are explained in more detail below:

  1. Incompatible definition of a payment application in the IFR.
  2. Limitation to tokenized card-based payment instruments.
  3. Which payment instrument is the vehicle for the payment application?

1. Incompatible definition of a payment application in the IFR.

So what is a payment application and what is the meaning of the term in the IFR?

The definition of a payment application according to Art. 2(21) IFR is:

computer software or equivalent loaded on a device enabling card-based payment transactions to be initiated and allowing the payer to issue payment orders”.

This definition shows considerable overlap in content with the previously valid definition of a payment instrument under 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”.

The legislator refrained from a clear definition of the term in the IFR. The definition of a payment application is narrower, since it is aimed only at the intangible payment application and does not include the material device, but only presupposes its existence. If one logically considers the technical device in the case of a tangible carrier of different payment instruments as completely redundant for the definition of a digital payment instrument, both definitions refer only to the software-based procedure that triggers the execution of a payment order. In the case of a plastic card payment, the question arises as to whether the payment instrument is still distinct from the payment application. Unfortunately, the wording of the definition of a payment application does not lead to a clear demarcation.

Application in the co-badging case

The term payment application is – as far as can be seen – exclusively used in the IFR for so-called “card-based payment transactions” according to Art. 2(7) IFR, if the so-called co-badging case (according to Art. 8 IFR) exists.

According to Art. 2(31) IFR, co-badging means “the inclusion of two or more payment brands or payment applications of the same brand on the same card-based payment instruction“. The payment application in this context refers to a functionality of the card, e.g. the function as debit or credit card. The case is given if, for example, the cardholder can initiate either a debit card transaction (according to Art. 2(4) IFR) or a credit card transaction (according to Art. 2(5) IFR) with a payment card at the POS. This co-badging case is quite rare in the EU. In practice, we mostly see the other co-badging case: two different brands, such as in Germany a debit card with the brands Girocard and Maestro.

In the case of different payment applications, co-badging refers to a different payment term of the cardholder towards the card issuer. The IFR also uses the term “categories” for these card-based applications in parallel (such as in Art. 9 and 10 IFR).[5]

Accordingly, a payment application is a functionality of the respective payment instrument. As a rule, the functionality (e.g. debit) is firmly coupled to the payment instrument (debit card). Using the IFR terminology, a single-badged card would have to be considered one payment instrument, one brand and one payment application. In the exemplary co-badging case, one instrument has two functionalities. One can also imagine (at least theoretically) a co-badging situation where both functionalities are issued by different issuers. In this case we see one smart card (carrier/device), two issuers and two payment instruments (one virtual debit and one virtual credit card). The payment instruments each embody only one payment application.

Is a payment application a payment instrument?

The legal requirements in the case of co-badging are set out in Art. 8 IFR. The cardholder’s co-badged selection option requires a contractual agreement between the card issuer and the cardholder not only for the brand selection (Art. 8(2) IFR), but also for the application selection. A systematic interpretation of the definition of “payment application” according to Art. 2(21) IFR should therefore assume a contractual agreement between the “payment user” and the “payment service provider” that allows the payment user to initiate a payment order via the respective application of his payment instrument.[6]

Thus, the definitions – apart from the differences mentioned above with regard to the role of a “device” – are almost congruent. The IFR explicitly differentiates between payment instrument and payment application due to the requirements in the co-badging case (Art. 8 IFR). The definition of payment application according to Art. 2(21) IFR is, however, not compatible with the definition of a payment instrument due to the extensive conceptual congruence with the sole application of this definition in Art. 8 IFR. In a future revision of the IFR, the term “payment application” should be deleted without replacement and replaced by “category” of card-based payment instruments.

Interim result: Payment application in the sense of the IFR is the functionality of a card. For this reason alone, the adoption of the term “payment application” in accordance with Art. 2(21) IFR for a token is unsuitable for any intended differentiation from a payment instrument.

2. Limitation to tokenized card-based payment instruments.

The definition of a payment application requires a “card-based payment transaction“. According to recital 24 PSR, the Commission believes that the classification of a “token” as a payment application under Art. 2(21) should also apply to other tokenized payment instruments (“…tokenisation of an existing payment instrument, for example a payment card,…“). However, this requires a change in the definition of a payment application, which is not provided for in the PSR.

3. Which payment instrument is the carrier of the payment application?

Due to the classification of the token (and the virtual card) as a payment application, the question ultimately arises as to who or what assumes the role of the payment instrument, which logically must be present because a payment order is triggered by using the token. Since the PT wallet and the token do not have this function, only the “device” (smartphone, PC, car, etc.) remains as the card-based payment instrument that carries the application.

This view is indeed held within the Commission. Although this view would be covered by the definition of a payment instrument under Art. 4(14) PSD2 or the definition of a card-based payment instrument under Art. 2(20) IFR, it leads to absurd results in a digitized payment world in which the carrier and the payment instrument are not only technically decoupled, but also decoupled with respect to the provider. The providers of such “devices” would issue payment instruments and thus provide payment services requiring a license. See also PaySys Report No. 1 (2022)[7], in which we analyzed in detail the problematic PSD definition of payment instrument and its sometimes unrealistic consequences for regulatory practice. Unfortunately, the definition of a payment instrument in the PSD3/PSR proposal is only marginally changed by the Commission despite insistent suggestions by the EBA. [8] The problem is unfortunately not addressed.

 

Conclusion:

If the relevant sentence in recital 24 PSR (or 13 PSD3) is deleted without replacement, further conceptual confusion would be off the table.

 

 

[1] https://finance.ec.europa.eu/publications/financial-data-access-and-payments-package_en

[2] See also the government’s response in Bundestagsdrucksache 20/7277 of June 14, 2023, p. 21.

[3] For a good and understandable description of these tokenization processes in e-commerce and in the case of a PT wallet card payment, see e.g.: https://computop.com/payment-insights/de/credit-cards/tokenisierung-kartenzahlungen-e-commerce/

[4] See also 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 of 23 June 2022, No. 35, p. 13

[5] It is also clear from Art. 10 (5) IFR (issuer’s obligation to electronically and visually identify the card-based payment instruments so that payers and payees can recognize the respective brands and applications) in conjunction with Art. 9 (6, sentence 2) IFR, which regulates the payer’s and payee’s selection options at the POS, that payment applications refer to the respective card categories (“prepaid cards, debit cards, credit cards or commercial cards“). Art. 6 sentence 2 IFR even explicitly mentions the “categories of cards“. In Art. 12 (1) sentence 2, however, “application” and “payment instrument categories” are mentioned separately with regard to the acquirer’s transaction-related information obligations. In recital 40 of the IFR, the term payment application is also used only in relation to “brands“. Due to these textual inconsistencies, a systematic approach should be taken when interpreting the term “payment application” in accordance with Art. 2 (21).

[6] In contrast to the definition of a payment instrument, the existence of an agreement between the payment service user and the payment service provider is not a prerequisite for the definition of a payment application. However, the definition of a payment application implies that a third party should allow the user to use the application (“allowing the payer to issue payment orders“).

[7] Are smartphones, PCs or even cars payment instruments? The confusing definition of payment instrument in PSD2 in: PaySys-Report No. 1 (2022); Free Download: https://paysys.de/en/paysys-report/

[8] See 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 of 23 June 2022, chapter 1.5, No. 32-39, pp. 13-14.

 



By continuing, you accept our privacy policy.
You May Also Like