Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Chapter 1 Strong Customer Authentication
We propose to subdivide Chapter 1 following the structure of the Art. 97(1) of PSD2.
We suggest to define requirements for the strong customer authentication (SCA) separately, it means requirements in the situation when the payer: 1a) accesses his electronic account online, 1b) initiates an electronic payment transaction, or 1c) carries out any action through a remote channel, which may imply a risk of payment fraud or other abuses.
Comment 2:
Chapter 1 Strong Customer Authentication
In line with Rationale 22b) we suggest to define “authentication code” as a result of the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of others.
Comment 3:
Article 1 Authentication procedure and authentication code
Following Art. 97(1) of PSD2 (every access to payment accounts requires SCA) and Art. 97(2) of PSD2 (initialisation of payments require SCA again), in practice SCA is applied several times during one session. To avoid multiply SCA of the PSU and to ensure that PSU is required to enter his password several times, we suggest to restructure and amend Art. 1.1 as follows:
1. For the purposes of the application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time that the payer, making use of the authentication code
a) accesses its payment account online,
b) initiates an electronic transaction
c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
d) accesses its payment account online and initiates an electronic transaction within one sequence.
Comment 4:
Article 3 Requirements related to elements categorized as knowledge
PINs used in electronic payment environments can be repeatable (card PIN number or PIN on mobile for example). It should therefore be clarified that PIN numbers used to authenticate electronic payment transactions do not fall under the required criteria of length (PIN are 4/5 digits), complexity, expiration time and non-repeatability. Art. 3.1 should be therefore amended as follows:
1.With the exception of PINs in remote environments, the elements of strong customer authentication, categorized as knowledge shall be characterized by security features including, but not limited to, length, complexity, expiration time and the use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorized parties.
Comment 5:
Article 7 Review of the SCA procedure
According to the RTS the overall security of the SCA procedure shall be periodically tested, evaluated and audited by internal or external independent and certified auditors.
We would like to draw EBA´s attention to the security measure of this provision and suggest to deal with this topic in more details in the RTS as it is not clear who can be considered as certified auditor. Criteria, details and definition of responsible authorities for the certification process are missing.
Since auditors get access to ASPSP´s data while the review procedure, it is necessary - in case of external auditors - for the ASPSP´s to have the possibility to verify the authenticity of the certificates.
On the other side in the event of reviewing by internal auditors it is necessary to know which requirements should be fulfilled to consider the review procedure in line with Art.7 of the RTS. “Internal independency” in 7.1 should also be clarified.
Article 2 Strong customer authentication procedure with dynamic linking
A “batch” of payments in Art. 2.4 are to be understood as multiple payments mostly used in corporate environments for which the PSU is not required to check each and every individual transaction. At first sight, it seems rather difficult, if not impossible, to generate a code that would be specific to each payee within one single file. This provision requires clarification from the EBA.
Article 8 Exemptions to strong customer authentication
A risk based approach is crucial when deciding about exemptions. The list of exemptions in Art.8 is too exhaustive to give ASPSP the necessary flexibility to manage their risks in an appropriate way.
Therefore the decisions regarding exemptions have to be made on the level of each independent ASPSP.
Comment 8:
Article 8 Exemptions to strong customer authentication
Art. 8.2.b) should be applied also to recurring transactions by payment card, where initial payment would be verified by SCA and next recurring transactions would be processed by merchant without SCA according to agreement with cardholder.
Yes. This may lead to higher numbers of fraud.
Article 9 Requirements for security measures
Art.9.1 (c) should not be applied to end user devices.
Comment 11:
Article 12 Association of the payer with personalized security credentials, authentication devices and software
There is a need of clarification how to apply Art.12 (b) when onboarding new client via online channel (client is opening account online, not at branch).
Comment 12:
Article 15 Destruction, deactivation and revocation of personalised security credentials, authentication devices and software
Definition of public repositories in Art.15 (c) would be essential.
Chapter 4 Common and secure open standards of communication
The whole requirement is very high level described to see technical implications for integration.
Comment 14:
We suggest to add details on governance of liabilities and claims to Chapter 4.
Comment 15:
Chapter 4 Common and secure open standards of communication
As this RTS will replace EBA Guidelines on internet payments security, detailed definition of sensitive payment data must be added to the RTS.
Comment 16:
Article 17 Requirements for identification
We kindly suggest to clarify the meaning of secure bilateral identification. Does EBA mean mutual authentication? If yes, this would create incompatibility with EMV card based payments where there is no terminal authentication required.
Comment 17:
Regarding Rationale 71 further clarification on certification process is urgently needed (e.g. how new certificate attributes will look like - one certificate per role or one certificate with multiple roles?)
Comment 18:
Article 19 Communication interface
Testing facilities should be excluded from Art.19.6 as testing environment does not fall under the same service level agreement.
Article 20 Identification
According to rationale 74 – urgent clarification and more details on this topic is needed.
It is not clear how to proceed in case that no e-IDAS qualified trust service providers will exist by October 2018. Will it be possible to use some kind of manual registration with ASPSP and only one-way TLS (no mutual authentication on API)?
Article 22 Data exchanges
For implementation of Art.22.5 in connection with Art.1.3 (e) where it is necessary to know the initiator of the request, we suggest to add a new paragraph to Art. 22 as follows:
6. Account information service provider shall inform ASPSP´s when requesting information according to paragraph 5 about the initiator of the request (either the AIS or the PSU).
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?
Comment 1:Chapter 1 Strong Customer Authentication
We propose to subdivide Chapter 1 following the structure of the Art. 97(1) of PSD2.
We suggest to define requirements for the strong customer authentication (SCA) separately, it means requirements in the situation when the payer: 1a) accesses his electronic account online, 1b) initiates an electronic payment transaction, or 1c) carries out any action through a remote channel, which may imply a risk of payment fraud or other abuses.
Comment 2:
Chapter 1 Strong Customer Authentication
In line with Rationale 22b) we suggest to define “authentication code” as a result of the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of others.
Comment 3:
Article 1 Authentication procedure and authentication code
Following Art. 97(1) of PSD2 (every access to payment accounts requires SCA) and Art. 97(2) of PSD2 (initialisation of payments require SCA again), in practice SCA is applied several times during one session. To avoid multiply SCA of the PSU and to ensure that PSU is required to enter his password several times, we suggest to restructure and amend Art. 1.1 as follows:
1. For the purposes of the application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time that the payer, making use of the authentication code
a) accesses its payment account online,
b) initiates an electronic transaction
c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
d) accesses its payment account online and initiates an electronic transaction within one sequence.
Comment 4:
Article 3 Requirements related to elements categorized as knowledge
PINs used in electronic payment environments can be repeatable (card PIN number or PIN on mobile for example). It should therefore be clarified that PIN numbers used to authenticate electronic payment transactions do not fall under the required criteria of length (PIN are 4/5 digits), complexity, expiration time and non-repeatability. Art. 3.1 should be therefore amended as follows:
1.With the exception of PINs in remote environments, the elements of strong customer authentication, categorized as knowledge shall be characterized by security features including, but not limited to, length, complexity, expiration time and the use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorized parties.
Comment 5:
Article 7 Review of the SCA procedure
According to the RTS the overall security of the SCA procedure shall be periodically tested, evaluated and audited by internal or external independent and certified auditors.
We would like to draw EBA´s attention to the security measure of this provision and suggest to deal with this topic in more details in the RTS as it is not clear who can be considered as certified auditor. Criteria, details and definition of responsible authorities for the certification process are missing.
Since auditors get access to ASPSP´s data while the review procedure, it is necessary - in case of external auditors - for the ASPSP´s to have the possibility to verify the authenticity of the certificates.
On the other side in the event of reviewing by internal auditors it is necessary to know which requirements should be fulfilled to consider the review procedure in line with Art.7 of the RTS. “Internal independency” in 7.1 should also be clarified.
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.
Comment 6:Article 2 Strong customer authentication procedure with dynamic linking
A “batch” of payments in Art. 2.4 are to be understood as multiple payments mostly used in corporate environments for which the PSU is not required to check each and every individual transaction. At first sight, it seems rather difficult, if not impossible, to generate a code that would be specific to each payee within one single file. This provision requires clarification from the EBA.
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?
n/aQuestion 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?
Comment 7:Article 8 Exemptions to strong customer authentication
A risk based approach is crucial when deciding about exemptions. The list of exemptions in Art.8 is too exhaustive to give ASPSP the necessary flexibility to manage their risks in an appropriate way.
Therefore the decisions regarding exemptions have to be made on the level of each independent ASPSP.
Comment 8:
Article 8 Exemptions to strong customer authentication
Art. 8.2.b) should be applied also to recurring transactions by payment card, where initial payment would be verified by SCA and next recurring transactions would be processed by merchant without SCA according to agreement with cardholder.
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?
Comment 9:Yes. This may lead to higher numbers of fraud.
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?
Comment 10:Article 9 Requirements for security measures
Art.9.1 (c) should not be applied to end user devices.
Comment 11:
Article 12 Association of the payer with personalized security credentials, authentication devices and software
There is a need of clarification how to apply Art.12 (b) when onboarding new client via online channel (client is opening account online, not at branch).
Comment 12:
Article 15 Destruction, deactivation and revocation of personalised security credentials, authentication devices and software
Definition of public repositories in Art.15 (c) would be essential.
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?
Comment 13:Chapter 4 Common and secure open standards of communication
The whole requirement is very high level described to see technical implications for integration.
Comment 14:
We suggest to add details on governance of liabilities and claims to Chapter 4.
Comment 15:
Chapter 4 Common and secure open standards of communication
As this RTS will replace EBA Guidelines on internet payments security, detailed definition of sensitive payment data must be added to the RTS.
Comment 16:
Article 17 Requirements for identification
We kindly suggest to clarify the meaning of secure bilateral identification. Does EBA mean mutual authentication? If yes, this would create incompatibility with EMV card based payments where there is no terminal authentication required.
Comment 17:
Regarding Rationale 71 further clarification on certification process is urgently needed (e.g. how new certificate attributes will look like - one certificate per role or one certificate with multiple roles?)
Comment 18:
Article 19 Communication interface
Testing facilities should be excluded from Art.19.6 as testing environment does not fall under the same service level agreement.
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?
n/aQuestion 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 ?
Comment 19:Article 20 Identification
According to rationale 74 – urgent clarification and more details on this topic is needed.
It is not clear how to proceed in case that no e-IDAS qualified trust service providers will exist by October 2018. Will it be possible to use some kind of manual registration with ASPSP and only one-way TLS (no mutual authentication on API)?
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.
Comment 20:Article 22 Data exchanges
For implementation of Art.22.5 in connection with Art.1.3 (e) where it is necessary to know the initiator of the request, we suggest to add a new paragraph to Art. 22 as follows:
6. Account information service provider shall inform ASPSP´s when requesting information according to paragraph 5 about the initiator of the request (either the AIS or the PSU).