Response to discussion on RTS on strong customer authentication and secure communication under PSD2

Go back

1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.

2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?

3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?

4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?

The addressed complication of compliance under article 4.1.32 related to the independence of the authentication elements is justified but needs an in-depth view. A clear distinction is necessary between:

1.) in-APP authentication elements without Out-of-Band functionality
2.) Authentication elements with OOB capabilities.

In-APP authentication elements without Out-of-Band functionality
There is no full independence of authentication elements based on Mobile device installed authentication elements, such as passwords, biometrics etc, as there is only one single mobile device (one channel). The breach of one authentication element potentially compromises the reliability of the other authentication element. As mentioned under article 4.1.32, if the mobile device contains the credential a compromise of the mobile device itself compromises the reliability. Under the segment “in-APP authentication elements without Out-of-Band functionality” credentials are always contained or created by the mobile device only. A potential non-compliant proposition considering the SCA requirements and a less secure authentication proposition in general.

Authentication elements using OOB
The receipt or retrieval of the credential through the telecom infrastructure provides an authentication element via an additional channel (infrastructure). The telecom infrastructure delivers the credential with the following characteristics :
• A secure end-to-end delivery pipeline through a VPN
• Regulated environment
• No open infrastructure, access for regulated parties only
• The credential is a message from and originated by the payment provider
The telecom infrastructure channel can identify a security breach for the mobile device as it can provide extra context checks, such as divert detection, location-based GEO checks, and SIM Swap detect.

It is imperative to identify and separate authentication elements which do not offer Out-of-Band functionality and do not operate in a regulated environment, and credentials are contained and/or created by the mobile device. Authentication elements retrieving/receiving credentials from an additional channel are offering compliancy, as the breach of one authentication element does not compromise the other. The latter should there for be regarded as more secure and compliant with the SCA requirements. In addition, the telecom infrastructure is capable of providing security to determine possible security risks concerning possession of the authentication element.

The inclusion of authentication elements using OOB is there for required to be compliant with the definition for a SCA as described by PSD2.

5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?

6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?

7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?

8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?

9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?

10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?

11. What other risks with regard to the protection of users’ personalised security credentials do you identify?

12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?

13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?

14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?

15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?

16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?

17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?

18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?

19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.

20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.

Name of organisation

CM Telecom

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

[IT services provider"]"

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

[Payment initiation services"]"

Organisation and governance

Legal and policy framework

Careers

Supervisory convergence

Direct supervision and oversight

Information for consumers

Ad hoc activities

Risk analysis

Reporting frameworks

Data

Publications

Media centre

Response to discussion on RTS on strong customer authentication and secure communication under PSD2

1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.

2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?

3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?

4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?

5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?

6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?

7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?

8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?

9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?

10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?

11. What other risks with regard to the protection of users’ personalised security credentials do you identify?

12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?

14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?

15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?

16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?

18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?

Name of organisation

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

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