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.

Registering payment details on commercial web sites, online signing of e-mandates, enrolling on third party providers...

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?

Data encryption keys downloaded or incorporated on devices that are used to electronically sign, digital certificate ...

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?

Yes, although those behavior-based patterns can also be considered as basis for exemptions.

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 use of a one time use passwords sent to the phone should not be used alone

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

Dynamic linking should also apply when a OTP is given, once the PSP takes note of the details of the operation, not necessarily linking both things on the same message.
Dynamic linking should be understood as applied to the messages being sent, so that compromise in the communication media is protected, not necessarily internally to the device.

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

The downloading of a private key to the app so that communication is protected by a dynamic seal" or "signature" being added to the message.
Two objectives are fulfill: the device is acknowledged and the message can not be compromised if captured out the device.
Thus, the use of such key may be regarded as no necessarily preventing the independence between two criteria."

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

Absolutely. The idea of low payments and some others like customer track record could also be dependent on the customer profile at the discretion of the PSP.

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

Certain legacy practices (offline payments with cards, non 3D Secure...)

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?

The enrolment process should also lean of strong authentication, even if it is to substitute it for other method.

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?

In any case, the PSP issuing the credentials should be responsible for proper care

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?

Intervention of third party providers.

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?

Third party providers should be prevented to use any component they may have control on (e.g. NFC antenna or biometric in a smartphone by a smartphone supplier) to be exclusively retained for their use, preventing diversity of app or solutions to be offered to same client, and getting that way strong position before PSPs to become PIS

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?

If Third Party Providers (specially when supply smartphone operating system or hardware, email software, etc.) want to be eligible, they should be prevented from retaining other key components at their exclusive use, forcing and driving the behavior of customers and other PSPs

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?

Web services accesses, and specially digital certificates of the Third Party Providers as issued by the authority (ECB or EBA) so as to be properly acknowledged by PSPs

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.

Yes to some extend, both to be used by customers and to be used by Third Party Providers to become identifiable in a trusty way.

Name of organisation

Cecabank

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

[Credit institution"]"

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

[Execution of payment transactions"]"