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.
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.
n/a
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.
Comment 9:
Yes. This may lead to higher numbers of fraud.
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.
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.
n/a
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)?
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).