Skip to main content
Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back1. 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.
No further examples2. 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?
The adequacy of possession elements in the contexts of strong customer authentication depends on the architecture of the service i.e. the combination of elements used for authentication. Hence, each combination shall be assessed separately using a risk-based approach. Possession elements may evolve over time (e.g. wearable devices). The specific use of possession elements or combinations of possession elements shall be left to the service provider and supporting entities.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?
Behaviour based characteristics have the potential to support strong customer authentication. However, the use of behaviour-based characteristics shall be considered in combination with privacy issues of the PSU. Hence these elements need to be considered by the industry once they have matured in the context of concrete services.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)?
Independence of authentication elements is largely linked to the question whether critical transactions should be sent from a single device combining all elements of customer authentication or whether two devices should be used. There is no simple answer to this question. Risk evolves with the evolution of technology (may increase or decrease) and the capabilities of the fraudsters. A dynamic risk based assessment of service architecture seems to be advisable.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Dynamic links are a valuable element of strong customer authentication. Since they are part of many technical communication standards, there should be no strong hurdle for the implementation of such features.6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Mobile devices offer already today a variety of combinations of software and hardware security features. Depending on the risk to be mitigated, it might be advisable to combine software and hardware (SIM, eSIM, SE) security elements.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The clarifications are useful. Eventually the PSP shall make a conscious risk assessment and decide on mitigation measures accordingly.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Assuming that the PSP is in the lead for the determination of exemptions in the framework of the given legislation, the EBA should consider how to get evidence of the decision making process of the PSP and how to assess the adequacy of the considerations.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?
Due to the fast evolution of technical solutions, it seems to be advisable to leave it to the PSP to use transaction risk analysis features. EBA should refrain from setting RTS standards.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
The EBA’s clarifications are in line with IT security requirement, i.e. stating that data shall be secured during creation, storage and transmission. However, PSPs need to decide on each component and transmission channel individually when creating a payment service. As stated by the EBA this requires a risk based approach by the PSP. Certification of components and channels might be a desirable information for the PSP. For example, EBA could invite potential providers of components and channels to certify their components. However, a heavily formalized process might slow down time to market and might even increase the risk if the certification process slows down the implementation of security upgrades of new securer components.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The personal behaviour of the user and particularly the exposure to social engineering causes additional risk.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?
Standards and products for enrolment processes are available on the market (TLS, CAs, electronic signature, SE, SIM, …). What matters is that standards, components and processes form a secure end-to-end process. The security level should be consistently high throughout the whole processing chain. Trusted Service Management undertaken by MNOs is an example of such an “end-to-end Ecosystem”. Solutions should be open for the seamless integration of new and securer components.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?
Certification made on behalf of the vendor might be a supporting sales argument. However due to the skills and resources of potential fraudsters certification cannot protect completely against vulnerabilities and security loopholes. It should be emphasized that eventually the security assessment and the risk appetite of the service provider matters.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?
See 11. The end user should be technically protected to the largest possible extent.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?
Security levels determined within standards and compatibility between standards are issues that require industry cooperation and willingness to invest in implementation of such standards. Requirements for such standards are evident and should not go beyond general descriptions unless there is a clear market failure. Eventually the PSPs and other supporting parties have the duty to combine tools and standards in the most appropriate way in line with the criticality of the business and threat analysis. Open standards like OpenID Connect and Mobile Connect are examples of successful standardisation efforts of the industry.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?
Based on standards and secure vendor products, the PSPs and supporting entities should cater for optimal solutions. There is little need for regulatory intervention.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 15. E.g. Open ID Connect, Mobile Connect.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)?
The requirements should stay on a rather generic level (see also 15). Implementation should be left to the industry. To foster trust services, it might be one desirable solution to design a high-level process that allows PSPs to act as a trusted party in between end user and bank i.e. agreeing on specific credentials for each communication channel (end user PSP/PSP bank) separately but covering the whole processing chain.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.
In order to minimize regulatory overhead there should be strong efforts to (re)use the e-IDAS regulation to the largest extent possible.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.
See 19Name of organisation
University of Applied Sciences KaiserslauternPlease select which category best describes you and/or your organisation.
[Academic"]"Please select which category best describes you and/or your organisation.
[Other "]"If you selected ‘Other’, please provide details
Research