It's been a while since strong customer authentication (SCA) has been in the spotlight. For those who do not immediately remember what SCA is about: the rules for SCA aim to reduce fraud and make online and contactless offline payments more secure by integrating additional layers of authentication into the payment process - something that is not well received by all market participants, including customers, who generally find the additional authentication requirements onerous and time-consuming. Authentication under SCA consists of at least two of the following elements: knowledge (something only the user knows, such as a password), possession (something only the user possesses, such as a mobile phone) and inherence (something the user is, such as fingerprints).
It is therefore not a surprise that payment service providers have been always eager to avoid SCA requirements to improve the user experience, which is not an easy task since Art. 97 PSD2 generally provides – subject to certain exemptions – that SCA is to be applied when the payer
(a) accesses its payment account online;
(b) initiates an electronic payment transaction;
(c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
In the past, SCA requirements have raised several issues that have not been sufficiently addressed by the EBA in its RTS on SCA (Delegated Regulation (EU) 2018/389). This is particularly true for payments which are initiated through digital wallets. Digital wallets such as ApplePay or GooglePay have been on the rise for years and have become an integral part of everyday life as they provide a frictionless shopping experience.
So, how does a digital wallet work?
When activating digital wallets on a mobile device, payers must upload credit or debit card information to the digital wallet app which is subsequently replaced by a token. The tokenisation is the process of turning the card information including the account number, expiration date or security code into a string of random numbers and letters. When the customer makes a payment, only the token is verified by the merchant, but the actual card details are not exposed. The tokenisation process makes it impossible to identify the payment card used. It is a security measure that has not been developed to provide authentication means to the payer but to mitigate risks derived from keeping actual card details from environments where data can be vulnerable and, if breached, used for illegal purposes.
Nevertheless, creating a copy of the credit or debit card as a “token” has also led the path to “digital wallet scam”. Fraudsters can e.g. move payment card information that were previously stolen to a new digital wallet even if the offending wallet is blocked. This is particularly easy when the user does not have to authenticate that she or he is the legitimate owner of the payment cards added to the wallets. Lost or stolen digital wallet passwords or other credentials, e.g. if they are used for other accounts, can be used to hijack the digital wallet.
Adding stronger customer authentication requirements may be an answer to the question how digital wallets can be made more secure.
How must SCA be applied in relation to digital wallets?
Against this background, the EBA has recently published three new Q&As providing clarification regarding the application of SCA to the enrolment of a payment card to a digital wallet and to the initiation of payment transactions with digitised versions of a payment card.
Regarding the enrolment of a payment card to a digital wallet, i.e. the process that leads to the creation of a token, the EBA clarifies that SCA must be applied pursuant to Article 97(1)(c) of PSD2, because it is an action that may imply the risk of fraud or other abuses. By applying SCA, the payment service provider verifies remotely that the payment service user is the rightful user of the payment card and associates the payment service user and the digitised version of the payment card with the respective device (Q&A 2020_5622).
When it comes to the initiation of electronic payment transactions, it is also clarified that the initiation of transactions with the created token also requires the application of SCA under Article 97(1)(b) of PSD2, unless one of the specific exemptions from the application of SCA set out in the RTS on SCA apply.
Furthermore, as the EBA has taken the stance that the SCA should be applied at the time of the issuance of the token, the previous unlocking of a mobile phone with biometrics (e.g. a fingerprint) or with a PIN/password should not be considered a valid SCA element for the purpose of the subsequent adding of a payment card to a digital wallet. The only exemptions from this rule are, is (1) if the screen locking mechanism of the mobile device is under the control of the issuer (which seems rather unlikely to be given by the firm operating the mobile device software) and (2) if the payer has been – in accordance with Art. 24(2(b) of the RTS – associated previously through an SCA with the credential used for unlocking the phone. For instance, if the fingerprints has been previously associated for purposes of the SCA, then unlocking the mobile phone with face recognition would not be sufficient (Q&A 2021_6145).
The EBA further clarifies that the issuance of a new token, replacing a previously existing one, and binding it to a device/user always requires the application of SCA pursuant to Art. 97 (1)(c) PSD2, even if these changes happen automatically in the background. This includes cases where e.g. a tokenized payment card is replaced and the new card has a different bank identification number (BIN), the token is expired or technical changes to the issuer’s BIN configuration (such as migrating from 6 to 8 digit BINs) make the issuance of a new token necessary (Q&A 2021_6464).
Creating a “token” of a pre-existing debit or credit card does not necessarily result in establishing a new payment instrument. Therefore, in general, the issuer of the pre-existing debit or credit card remains responsible for compliance with the SCA obligations. However, only the digital wallet (and mobile device) operator will have the technical means to do so. EBA therefore acknowledged that the issuer has the right to outsource the technical services related with the provision and verification of SCA elements to others, including the digital wallet operator.
The EBA's responses will probably find only few ardent admirers in the market as SCA must be applied to additional use cases and therefore impose further requirements on payment service providers respectively digital wallet operators. On the other hand, enhanced SCA requirements increase customer protection and contribute to a safer payment environment which ultimately should be in the interest of all market participants.
The three new Q&As come on top of already 50+ Q&As on SCA. Moreover, the EBA had issued their Final Report on the amendment of the RTS one year ago (Link). In addition, the EBA has made some suggestions in its Call for Advice regarding the review of PSD2 and recommends several clarifications regarding, among others, the regulatory treatment of merchant-initiated transactions, outsourcing of SCA to third parties or the inherence SCA elements (see our blog post). So one thing is clear: SCA continues to be work in progress.
