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

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

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

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.

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).

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.