Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?

This response has been endorsed by the ECSG Board which represents five card payments industry sectors (PSPs, schemes, retailers, vendors and processors). We are responding to questions 1,2,4 and 5.

1.1. General comments

The ECSG is of the opinion that establishing a workable balance between the need for payment security and end user convenience (consumer, merchant) is critical to ensure the establishment of an innovative and competitive digital single market in Europe. Such a balance should be based on the key principles defined in Article 98 of PSD2.
In respect of this, the ECSG’s concerns include:

- the lack of ability to apply a risk based assessment before deciding on whether to trigger a strong authentication (SCA) or not. Today many risk based models allow to ensuring maximum security when needed and maximum convenience when possible. For instance, a major European bank, using more than 100 variables, manages to authenticate the payer in 95% of the cases without having to rely upon strong customer authentication, while maintaining fraud at very low levels. Another example of are so-called “one click” check-out processes which achieve similar results.

- the need to clarify that mail order and telephone order related payments are out of scope.

- the fact that whereas most card payments are payer initiated, for a large number of card based payments the payment is initiated by or through the payee (e.g. card on file transactions, recurring payments, instalment payments). For such payments the first transaction is authenticated after which the payee will initiate the transactions like in the case of direct debits. As such, these card based payee initiated payments must be exempted as well.

- the consultation paper limits the applicability of art. 74 (2) in relation to shifting the final loss to the party who did not apply SCA to the so-called transition period, i.e. until the RTS are fully in force. The ECSG questions the legal basis for this and believes that this is a departure from the PSD2 level 1 provision in art. 74. Moreover, it must be anticipated that in some environments it will not always be possible to fully meet the requirements, for instance in the case of European cards used at non-EEA POS terminals or on-line merchants or toll ways where relatively large amounts are applicable ( see also response to Question 4). In such case, it cannot be envisaged that the issuer would have to decline the transaction. If so, the European consumer could be severely impacted. It also raises the question on the extent to which EEA regulation can be imposed on non-EEA PSPs and their clients. If non-European authorities would be imposing various but potentially diverging requirements on European PSPs it would result in a completely impossible situation which very serious trade implication.

- the ECSG would like to see confirmation in the text that biometric verification on a mobile device, PIN and signature are valid second factors to establish a strong authentication. Moreover the text should make it possible for new innovative authentication methods to be introduced as technology evolves very quickly.

1.2. Specific comments

- Art. 1.1. - One time usage of authentication codes
Even in an EMV chip based card ecosystem, sometimes transactions have to be supported in fall back mode, i.e. when there is card or card reader failure. The fallback option benefits the payer and payee alike and must be maintained. In such case the authentication procedure cannot provide the generation of an authentication code. The RTS should accommodate these (exceptional) situations.

- Article 1.2.(b)

Generation of an authentication code from a previous one from whatever payer
The term “generated for the same payer” should be deleted given that an authentication code should not be derivable from a previous one independent of the payer.

- Article 1.3.(b)

In some authentication implementations the user is promptly informed when a wrong PIN is entered, for instance at the POS. By conforming to Art 1.3.b the user would only be informed that the PIN is wrong near the end of the procedure. The ECSG is of the opinion that it cannot be the intention of the RTS to avoid communicating to a payer at the POS that the PIN is incorrect straight after the PIN entry.

- In article 1-3-e of the RTS there is confusion between security operations which are carried out in the authentication phase and in the phase requiring the authorisation of a payment operation by an ASPSP. Customer authentication and transaction authorisation are two complementary but different processes which need to be managed separately In most instances, certain elements of information, such as the black list of stolen or compromised cards or a transaction history cannot technically be systematically made available to the organisation responsible for the authentication.
Proposed wording:
“which, when combined with other ASPSP processes such as authorisation, must forewarn, detect and block fraudulent payment operations before the PSPs final authorisation. These mechanisms shall take into account, but not be limited to … (existing wording I,ii,iii,iv,v)”

- In article 1.3 d, the ECSG strongly recommends to remove the mention to HTTP over TLS as it is right now.
Some early versions of TLS are considered insecure at this time, since they have security flaws that could compromise the security of an HTTPS communication. In respect of this PCI SSC, the global standardisation body specifies in their recommendations from April 2015: “To date, SSL and early TLS no longer meet minimum security standards due to security vulnerabilities in the protocol for which there are no fixes. It is critically important that entities upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.”
Therefore, in this paragraph, it could be more appropriate to provide examples of what is considered to be secure communication sessions at this point in time, as they do other standardisation bodies such as PCI SSC .

- Article 1.3.(e).iv

The term “customer device” should be clarified. It is assumed that this clause refers to “payer’s device”.

- Article 3.1

Various issues in relation to the article must be considered.

PINs security features.

PINs, used in conjunction with magnetic cards or chip cards cannot comply with all the requirements of Article 3.1

Expiration Time

In respect to expiration time, although bank cards do have an expiration date, PINs usually don’t. One might consider that when the cards expire the PINs also expire. Some banks actually maintain the PIN from one card to its replacement (in the card expiration process) so as to avoid having PIN’s being transported through our mail services.

Non-repeatable characters

Present day implementations of banking PIN’s guarantee that PINs are solely processed in the clear inside FIPS 140-2 Level 3 or higher HSM’s. The ECSG has no recollection of there being an HSM in the market that may detect and avoid PINs that have repeating characters. Moreover, cardholders have often the option to set their own PINs over which issuers have no control.
Conclusion: the constraints regarding “security features” in article 3-1 are not sufficiently explicit so as to guarantee a level playing field. What is more, the fact that there are 2 authentication factors should allow constraints regarding the knowledge factor to be lessened.

Therefore, paragraph 1 in article 3 of the draft RTS should be deleted, and paragraph 2 should become:

“The use of elements of strong customer authentication categorised as knowledge shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties, to limit the number of attempts at unauthorised access, and to provide the ability to modify the value in case of compromise”.

- Article 5.2
One of the conclusions of the European Commission project BEAT¹, which defined both an evaluation methodology and carried out an evaluation of deception methods on biometric sensors, is that the designated requirement described in article 5-2 of the Draft RTS is unattainable with any biometric sensor available today.

Though the ECSG supports the intention of the article, we believe that it therefore should be removed as the requirement is unattainable.

- Article 6.3

Trusted Execution Environments (TEE) as referred to in article 6-3-a have not yet reached maturity on devices available to consumers and the general public, and the required business models are even less developed. The RTS should avoid being too detailed with regard to security technologies, since these are constantly evolving. The RTS should deal with principles and remain technologically neutral.

Therefore, Article 6.3 should be modified as follows:

“3. For the purposes of paragraph 2, the mitigating measures s̶h̶a̶l̶l could include, for example, but would not be limited to:
a. the implementation of separated t̶r̶u̶s̶t̶e̶d̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ secured environments inside the multi-purpose device;
b. mechanisms to ensure that the software or device have not been altered by the payer or by a third party or mechanisms to mitigate the risks related to such alteration where this has taken place.”.

¹https://www.beat-eu.org/

Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.

- In its current form article 2.2-b is unclear and could be interpreted as requiring two physically independent channels (typically one to initiate a payment operation and a separate device on which data linked to the authentication is received). It is clearly not practical for consumers to have (for example) two mobile phones and this could be an obstacle to the development of m-commerce & t-commerce
The article should address the issue of logical independence" of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device in areas such a m-commerce and t-commerce.

Either the last sentence of article 2-2b of the draft RTS should be deleted, or, at the very least, the word “logically” should be added so that the sentence becomes:

“The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be logically independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”"

Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?

-

Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?

- As stated under Question 1, and as defined in PSD2 article 99, transaction risk assessments must be one of the criteria on which basis authentication decisions are taken. However, the proposal by EBA does not withhold the possibility for issuers and/or merchants to perform a risk based analysis before deciding on whether or not to require a strong authentication. The proposed amount based limits (10/100 euro) for remote transactions are a one-dimensional, rigid approach which will highly impact European consumers and merchants and is likely to result in high transaction abandonment rates.

- The transaction limits proposed for contactless are supported as the ECSG believes they will meet most transaction environments. However, it must be noted that issuers will not always be able to fully keep track of the cumulative amount which, when reached, should trigger a PIN based transaction. Moreover, the transaction that would bring the cumulative amount above 150 euro may take place at a device where there is no PIN support (example public transport – to be noted that in that environment the amount of the fare is not always known beforehand either).

- The proposal totally omits a large category of POS transactions whereby the card is read but a PIN check is impossible or not deemed appropriate (e.g. to minimise queues). Typical examples include tollways and selected parkings. For instance, in France there are annually about 140.000.000 tollway payments with a card without a PIN check. The lack of exemption for such transactions would for instance mean that the many millions car drivers on French motorways would no longer be able to pay by card at the toll booths. An exemption aligned to the one proposed for contactless transactions is therefore necessary to avoid such unthinkable scenario. The existence of this type of environments and the resulting non-PIN transactions also plead in favour of the usefulness of Article 74 (2), also after the coming into force of the RTS.

Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?

Whereas exemptions are clearly required, the ECSG does not see a need to mandate them. PSPs, issuers and acquirers; have varying risk and authorisation policies and as such should be free to decide for which transactions to require strong authentication, regardless of the amount.

Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?

-

Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?

-

Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?

-

Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?

-

Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.

-

Please select which category best describes you and/or your organisation

[Other "]"

If you selected "Other", please provide details

The ECSG is a multi-stakeholder association (representing Retailers, Vendors, Processors, Card Schemes and Payment Service Providers) which aims to support and promote European cards standardisation.

Please select which category best describes the services provided by you/your organisation

[Other"]"

If you selected "Other", please provide details

The ECSG is a multi-stakeholder association (representing Retailers, Vendors, Processors, Card Schemes and Payment Service Providers) which aims to support and promote European cards standardisation.

Name of organisation

European Cards Stakeholders Group