Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Furthermore we would like to add some remarks.
Standardisation:
• We would like to stress a need for a single technical standard for implementation of the secure communication relays between the PSPs [e.g. a standardized set of APIs]
• We would like to strongly advise EBA to standardize both which transaction-related information should be exchanged and the formats and rules on which it can be exchanged between the PSPs [e.g. for the purposes of forwarding transaction-related information by transaction initiation].
• We believe that a dedicated EU body to maintain and develop the standards further is required.
We believe that these topics require further discussion.
Furthermore:
In our view, there are innovative approaches to organise access to account for PIS and AIS providers. We believe that a beneficial approach is to separate the process of PSU enrolment into AIS / PIS providers and authorisation of the AIS / PIS providers at ASPSP – on behalf of the PSU, - from the process of regular PSU authentication at a PSP in order to perform a transaction
• We advocate it should be possible for PSU to grant a long term authorisation for AIS / PIS provider to access ASPSP, for instance during the enrolment process
• We are convinced that using RESTful APIs and authorisation based on e.g. oAuth will allow for secure, effective and flexible implementation of such approach
• We believe that AIS/PIS providers should be allowed to issue their own security credentials
We believe that these topics require further discussion.
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.
See the input of The Dutch Payments Association.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?
See the input of The Dutch Payments Association.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 the input of The Dutch Payments Association.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 the input of The Dutch Payments Association.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
See the input of The Dutch Payments Association.6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
See the input of The Dutch Payments Association.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
See the input of The Dutch Payments Association.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
See the input of The Dutch Payments Association.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?
See the input of The Dutch Payments Association.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
See the input of The Dutch Payments Association.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
See the input of The Dutch Payments Association.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 the input of The Dutch Payments Association.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?
See the input of The Dutch Payments Association.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 the input of The Dutch Payments Association.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?
See the input of The Dutch Payments Association.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 the input of The Dutch Payments Association.Furthermore we would like to add some remarks.
Standardisation:
• We would like to stress a need for a single technical standard for implementation of the secure communication relays between the PSPs [e.g. a standardized set of APIs]
• We would like to strongly advise EBA to standardize both which transaction-related information should be exchanged and the formats and rules on which it can be exchanged between the PSPs [e.g. for the purposes of forwarding transaction-related information by transaction initiation].
• We believe that a dedicated EU body to maintain and develop the standards further is required.
We believe that these topics require further discussion.
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 the input of The Dutch Payments Association.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 the input of The Dutch Payments Association.Furthermore:
In our view, there are innovative approaches to organise access to account for PIS and AIS providers. We believe that a beneficial approach is to separate the process of PSU enrolment into AIS / PIS providers and authorisation of the AIS / PIS providers at ASPSP – on behalf of the PSU, - from the process of regular PSU authentication at a PSP in order to perform a transaction
• We advocate it should be possible for PSU to grant a long term authorisation for AIS / PIS provider to access ASPSP, for instance during the enrolment process
• We are convinced that using RESTful APIs and authorisation based on e.g. oAuth will allow for secure, effective and flexible implementation of such approach
• We believe that AIS/PIS providers should be allowed to issue their own security credentials
We believe that these topics require further discussion.