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.

General Comment to all questions: It is expected that all requirements concerning the strong customer authentication of the PSU must hold for all payment service providers to ensure a level playing field.

-------------------------------------------------------------------------------------------------------------

Response to Question 1: The CSG agrees no additional items need to be considered

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?

The use of data will be a key element in the future of authentication. Examples include any consumer device related data that can be used as a possession element. In addition, data based profiling will be core for the risk analysis of a transaction (web, customer spending, with whom, for how much, etc.). The RTS should include principles related to possession elements rather than a list of examples so as not to impact future innovation and technical enhancement

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 are appropriate to be considered as input to a risk-based authentication model in the context of customer authentication. These provide more flexibility and are more resilient to social engineering (where the customer is persuaded to compromise their own details), however existing privacy legislation should be respected

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 challenges for any particular device differ widely based on the payment context. There is an increased risk when using a single device for all aspects of the transaction, such as using a mobile phone. This risk can be mitigated using inherent elements as described in the response to question 3. In addition, the independence of the channel is only one of multiple parameters to be taken in to consideration when assessing the risk of a payment transaction. However, there is a clear and strong market need for allowing a single consumer device to deliver strong customer authentication.

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

The concept of dynamic linking should be clarified in the RTS, taking into consideration criteria on dynamic codes. It is important to avoid prescription of a specific solution. Any criteria being established related to dynamic linking should not hinder the use of international standards.
Another challenge with respect to dynamic linking is for instance when the mobile payment service provider differs from the issuer of the authentication mechanisms (e.g. fingerprint).

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

The CSG cannot comment on specific industry solutions but supports the ideal that any solution should be industry neutral.
Solutions based on logical separation of the password entry and the generation of the transaction code by different apps on the same mobile device fulfil both the objective of independence and dynamic linking already today.
Solutions based on a special device like a dynamic transaction code (TAN, Transaction Authentication Number) generator implemented as a separated device with a second element 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?

Yes, they are useful however they should not be portrayed as an exhaustive list, nor should they prescribe the use of a specific solution or system.
Whether the risk assessment is effective should be based on monitoring the performance of the actors involved in the payments chain, not on evaluating the system’s capability to analyse an exhaustive list of elements.
The assessment of the risk could also be performed on the acquiring side i.e. by the merchants and/or their Payment Service Providers. In such cases the elements of the risk assessment will be different from those used by the issuers and hence different from those used in the clarifications of the EBA.

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

The RTS should consider the critical factor of balancing security with Customer convenience. It should be acknowledged that it is possible to comply with strong customer authentication requirements through processes that eliminate any potential friction in the process of authentication whilst preserving security, for example using data analytics and behavioural profiling.

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 previous responses

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

Yes however it must ensure that it is aligned with other European and global standards on data security.
Security requirements for the protection of card data already exist through the enforcement of PCI DSS and do not need further regulation.

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

Article 66.3 and 67.2 appear to be contradictory and would need clarification as the personalised security credentials (PSC) of the PSU should never be exposed to anyone (except user and the Issuer) whereas authentication codes which could be exposed to a PISP should be based on a specific payee and a specific amount.
The introduction of third parties into the payment chain increases the risk situation for the affected ASPSPs and for the financial sector in general. Compromise of third party systems and processes, fraudulent third party provider and insider attacks at third parties are possible. By attacking a single PISP or AISP the probability of attacks on accounts of many different ASPSPs will increase substantially (risk of concentration of information).

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 CSG considers this to be within the competitive space.

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?

The CSG does not identify any available alternative.

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?

The PSU is unable to guarantee or control the security of their devices. Neither are they able to preserve control over their credentials if these are not enabled through simple and natural behaviour rules.
If PSCs are given to third parties, the transmission to the third party and the storage and usage by the third party increase the risk to the confidentiality and integrity of the PSC.

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?

The CSG has concluded that Chapter 4.4 (in relation to Article 98, 1d of the PSD2) fell outside the scope of the current release 7.1 of the SEPA Cards Standardisation Volume, and therefore have no comment on this section.

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?

The CSG has concluded that Chapter 4.4 (in relation to Article 98, 1d of the PSD2) fell outside the scope of the current release 7.1 of the SEPA Cards Standardisation Volume, and therefore have no comment on this section.

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?

The CSG has concluded that Chapter 4.4 (in relation to Article 98, 1d of the PSD2) fell outside the scope of the current release 7.1 of the SEPA Cards Standardisation Volume, and therefore have no comment on this section.

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 CSG has concluded that Chapter 4.4 (in relation to Article 98, 1d of the PSD2) fell outside the scope of the current release 7.1 of the SEPA Cards Standardisation Volume, and therefore have no comment on this section.

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.

Chapter 4.5 relates to the synergy with e-IDAS. The CSG has concluded that this could be a possible solution but not the sole solution, and therefore have no comment on this section.

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.

Chapter 4.5 relates to the synergy with e-IDAS. The CSG has concluded that this could be a possible solution but not the sole solution, and therefore have no comment on this section.

Name of organisation

Cards Stakeholders Group

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

[Other"]"

If you selected ‘Other’, please provide details

The CSG is a multi-stakeholder body representing retailers, vendors, processors, card schemes and the EPC

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

[Other "]"

If you selected ‘Other’, please provide details

the CSG is a multi-stakeholder body representing retailers, vendors, processors, card schemes and the EPC