Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Nevertheless, in many countries public sector solutions for authentication (PKI based authentication certificates on smart card chip, mobile SIM-card related solutions, etc) and electronic identification infrastructure are shared - used for authenticate into bank services (for example Estonia with national ID-card and mobile-ID), and vice versa (for example Sweden) bank solutions used for public services. Different bank standards for authentication would create the need for lateral and separate infrastructures from existing ones. From Estonian perspective, it would raise the costs for users, bank service providers and also authentication solution providers (which is also qualified trust service provider under e-IDAS regarding e-signature certificates) unreasonably high and would knock down existing social infrastructure and working co-operation between state and banking sector.
Regarding various existing authentication solutions, underlying infrastructures and online bank services on the European market would be wrong to talk in the context of specific authentication solution (behavioral characteristics etc), rather the discussion should be concentrated on the framework that would ensure necessary assurance level, trust and interoperability. eIDAS provides such a framework already, no need to re-invent it. If you feel that it should be complemented from payment service providers perspective, better to adjust eIDAS framework than create the parallel universe of authentication standards.
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.
NA2. 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?
See answer to question 19.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?
See answer to question 19.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)?
See answer to question 19.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
See answer to question 19.6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
See answer to question 19.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
See answer to question 19.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
See answer to question 19.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?
NA10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
See answer to question 19.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
See answer to question 19.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?
See answer to question 19.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?
NA14. 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?
NA15. 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?
See answer to question 19.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?
See answer to question 19.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?
See answer to question 19.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)?
See answer to question 19.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.
e-IDAS regulation should be considered as important facilitator for strong customer authentication. Moreover it gives a common ground to assess very different existing/future authentication credentials and models according to specific criteria (identity proofing of person during registration and issuance of authentication means, security level of issuing organization and etc), make them interoperable. High level assurance criteria are ensuring security, integrity and confidentiality of identification in electronic environment. As assurance level criteria are not referring or tied directly to any specific technology, it should be not hinder the innovation and future technologies.Nevertheless, in many countries public sector solutions for authentication (PKI based authentication certificates on smart card chip, mobile SIM-card related solutions, etc) and electronic identification infrastructure are shared - used for authenticate into bank services (for example Estonia with national ID-card and mobile-ID), and vice versa (for example Sweden) bank solutions used for public services. Different bank standards for authentication would create the need for lateral and separate infrastructures from existing ones. From Estonian perspective, it would raise the costs for users, bank service providers and also authentication solution providers (which is also qualified trust service provider under e-IDAS regarding e-signature certificates) unreasonably high and would knock down existing social infrastructure and working co-operation between state and banking sector.
Regarding various existing authentication solutions, underlying infrastructures and online bank services on the European market would be wrong to talk in the context of specific authentication solution (behavioral characteristics etc), rather the discussion should be concentrated on the framework that would ensure necessary assurance level, trust and interoperability. eIDAS provides such a framework already, no need to re-invent it. If you feel that it should be complemented from payment service providers perspective, better to adjust eIDAS framework than create the parallel universe of authentication standards.