Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
• Regarding the password policy criteria, by not allowing repeatable characters within passwords does not bring a significant benefit to the overall security level, considering that other more efficient controls are in place in order to ensure strong password selection (user lockout after N unsuccessfull login attempts, password length and special characters use, periodic password change, etc.). This control will reduce the password keyspace. Therefore we propose that this requirement should be eliminated.
• Additional details are required for Art. 2 (4) - the authentication code generated in accordance with Article 1 shall be specific to the total amount of the batched electronic payment transactions and to the payees of the batch of transactions considered collectively.
Could you please explain what is your understanding of the payees of the batch of transactions considered collectively. What is/are the elements that should be considered in this exact scenario as part of the dynamic linking process?
• Additional details must be included in Art. 6(3).b - mechanisms to ensure that the software or device have not been altered by the payer or by a third party.
Software:
- Does this concern the device’s operating system?
- Does this concern the application or process that handles the respective security function? (2 factor authentication)
Device:
- Does “device” translate to the hardware device (ex: mobile phone, tablet, etc.)?
If it does, then the device is not under the control or administration of the PSP, thus this environments’ integrity cannot be guaranteed by the PSP.
Related to art. 8(1,a,ii), rather than using “one month”, it should be “30 days”.
We don’t consider to be a good idea to make this information public to everyone, as this could be considered a security risk. This information should be disclosed only based on a contractual agreement between the PSP and the interested parties (PISP, AISP, etc).
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?
Yes, we mostly agree, with the following exceptions:• Regarding the password policy criteria, by not allowing repeatable characters within passwords does not bring a significant benefit to the overall security level, considering that other more efficient controls are in place in order to ensure strong password selection (user lockout after N unsuccessfull login attempts, password length and special characters use, periodic password change, etc.). This control will reduce the password keyspace. Therefore we propose that this requirement should be eliminated.
• Additional details are required for Art. 2 (4) - the authentication code generated in accordance with Article 1 shall be specific to the total amount of the batched electronic payment transactions and to the payees of the batch of transactions considered collectively.
Could you please explain what is your understanding of the payees of the batch of transactions considered collectively. What is/are the elements that should be considered in this exact scenario as part of the dynamic linking process?
• Additional details must be included in Art. 6(3).b - mechanisms to ensure that the software or device have not been altered by the payer or by a third party.
Software:
- Does this concern the device’s operating system?
- Does this concern the application or process that handles the respective security function? (2 factor authentication)
Device:
- Does “device” translate to the hardware device (ex: mobile phone, tablet, etc.)?
If it does, then the device is not under the control or administration of the PSP, thus this environments’ integrity cannot be guaranteed by the PSP.
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.
Yes, we fully agree and we understand that the authentication and the transaction authorisation may take place at the same time as long as SCA is ensured.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?
No, we consider the enumeration to be sufficient.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?
Yes, we understand that the exemptions mentioned are also applicable for dynamic linking process, as this process is executed in close relation with the strong authentication.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?
No, we don't have any concerns.Related to art. 8(1,a,ii), rather than using “one month”, it should be “30 days”.
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?
Yes.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?
Art. 19 (4) - Account servicing payment service providers shall make sure that the technical specification of their communication interface is documented, the documentation made available for free and publicly on their website.We don’t consider to be a good idea to make this information public to everyone, as this could be considered a security risk. This information should be disclosed only based on a contractual agreement between the PSP and the interested parties (PISP, AISP, etc).