The Danish Bankers Association

In general, the Danish Bankers Association (the DBA) agrees with the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1.

However, we believe that a clarification is needed as to whether Article 1 applies to electronic transactions in general or specifically remote electronic transactions.

Article 1 refers to initiation of an electronic transaction, while recital 2 of the draft RTS states: “as electronic remote payment transactions are subject to a higher risk of fraud, it is necessary to define additional requirements for the strong customer authentication applied to these transactions.” This is supported by the EBA’s reasoning in paragraph 22b of the CP: “For electronic remote payment transactions, PSPs have to ensure that a valid combination of authentication elements, as described above, results in the generation of an authentication code to the payer’s PSP”. This indicates that SCA and the use of an authentication code is only required when initiating a remote electronic payment.

In our opinion, the determining factor should be the proximity between the payment service user and the POS-terminal, meaning that a remote payment is when the payment service user is not physically present at the point of sale. Payments at the point of sale are in our opinions more low-risk and should therefore not be subjected to strong customer authentication and the use of an authentication code as described in Article 1.

The definition of what constitutes a remote electronic payment - and therefore when application of SCA and an authentications code is necessary - needs to be dynamic. This needs to be taken into account by the EBA when reviewing the RTSs (in accordance with Article 98 (5)) in order to recognize the development of new, innovative payment solutions, consumer convenience as well as maintaining a high level of security.

Finally, Article 1 (3) (e) seems to go beyond the mandate given by the PSD2. This article should be limited to mechanisms that prevent, detect or block authentication fraud, rather than fraudulent payment transactions in general.
The DBA agrees with the EBA’s reasoning that the requirements should remain neutral, and we welcome the reasoning about the flexibility offered on where and when the dynamic linking can take place.

We very much welcome the clarification regarding dynamic linking and the independence or segregation of the channel, mobile application or device. This is very important for the continued use of mobile banking and –payments. And we do believe that it is possible to have adequate security around a software solution, making e.g. a mobile device a truly independent possession element even when the mobile device is also used for payment initiation. However, we are convinced that additional techniques and technologies, than the ones mentioned, can be used to create this adequately secured and protected environment to display transaction details, while assuring the integrity of these data towards the PSU, on a single smart phone with a single online banking app.

Finally, we would suggest that the EBA consider using a different wording in Article 6 (3) than “trusted execution environments”, which can be construed as referring to a specific defined term in the Global Platform standard. We would prefer a more technologically neutral wording to underline, that the requirement relates to an independency and separation which for instance can be achieved via a software solution, but could as well be achieved via a hardware solution.
In our opinion, the protection of authentication elements is an ongoing process that is closely and continuously monitored by ASPSPs in cooperation with the FSAs. This is a more dynamic approach than a listing of threats.

Hence, we also think that the requirement related to elements of strong customer authentication and the understanding of what can be considered as standalone elements, i.e. inherence elements, needs to be dynamic. While the technology may (as yet) be too immature, we strongly believe that behaviour-based characteristics have the potential to fill the role as the inherence element in strong customer authentication.

In a number of articles the draft RTS use the wording “included, but not limited to” or “characterized by, but not limited to”, which indicates that the ASPSP have to use all the elements listed as a minimum. The RTS should avoid imposing a minimum set of characteristics to e.g. knowledge, possession and inherence, as these might not ensure technology and business-model neutrality. They also make it difficult for ASPSPs to rapidly adapt to any new security threat and could hinder the user experience or future innovation.

This can be exemplified by the reference to expiration time in Article 3 (1). In our opinion, regular password changing is a weaker solution and represents a number of vulnerabilities. Experience show, that when users are forced to change a password chances are that the new password will be similar to the old one, may have been used elsewhere, and that the new password is also more likely to be written down or be forgotten.

We would therefore advocate that the elements listed are viewed as examples rather than minimum requirements.

In regards to Article 5 we seek a clarification on the use of fingerprints. Would the EBA deem non-proprietary fingerprint registration (Touch ID or similar solutions) as compliant with the standards set as inherence given that the fingerprint is not biometrically authenticated to a PSU but rather, is linked to the device?
In general, we find the list of exemptions useful. We do however still believe there is a need to allow exemptions based on transaction risk analysis observing the principles of PSD2 and adhering to well-defined risk methodologies. This would allow the ASPSPs to adjust security requirements according to the risks and user situation at hand, ensuring a proper balance between convenience and security.

In addition to PSU-specific whitelists, we also believe that the setting up of national whitelists would be a possibility, e.g. payments to mortgage accounts, tax authorities and other highly trusted beneficiaries.

We would propose to harmonise the limits in article 8 to avoid favouring some payment methods over others, and create a consistent consumer experience. We would therefor suggest also having a procedure and timeline for reviewing the limits in accordance with developments in the payment services market.

In respect of contactless electronic payment transactions there may also be a need to consider how to handle situations where the requirement to use strong authentication arises in an environment where such authentication cannot occur e.g. certain public services or parking facilities.
We strongly believe that the ASPSPs should solely be able to decide whether or not to make use of exemptions contained in chapter 2, since the ASPSPs holds the main liability for unauthorised payment transactions.
We generally agree with the EBA’s reasoning and the provisions proposed in chapter 3 of the draft RTS.

We would however propose an adjustment in Article 9 (1) (a), and replacing the word “displayed” with “entered”. The sentence would the read: “Data on personalized security credentials are masked when entered and not readable in their full extent.”

This will allow the authentication code to be displayed to the PSU, but being masked when the code is entered by the PSU during the authentication process.
We generally agree with the EBA’s reasoning and the provisions in chapter 4.

We especially welcome the clarification that an interface is required for the communication between ASPSPs and TPPs, which creates secures and equal access, and the clarification in Article 21 (5) that reads: “Account information service providers and payment initiation service providers shall make sure that when transmitting personalised security credentials and authentication codes, these are not accessible to any of their staff at any time.” We understand this to be both their staff, outsourced parties and machines, is this correct?

Although, we would prefer that a reference to the protection of the personalised security credentials is also made in the recitals. We suggest using the reasoning stated in paragraph 19b of the CP: “In accordance with Article 97(5), PISPs have the right to rely on the authentication procedures provided by the account servicing payment service provider (ASPSP) to the user. In such cases, the authentication procedure will remain fully in the sphere of competence of the ASPSP.“

We welcome the clarification in Article 19 of the draft RTS, stating that the TPPs must identify themselves towards the ASPSP, especially the wording in paragraph (2) (a) which reads: “In particular the interface shall enable a payment initiation service provider or an account information service pro-vider to instruct the account servicing payment service provider to start the authentication procedure.”

But we do also believe that the RTS should contain requirements regarding the PSU consent. It is essential, that the ASPSPs are made aware of the PSU consent and its content (i.e. which TPPs and services), and more importantly, if a consent has been revoked by the PSU. We favor an opt-in solution. This gives the PSU the ability to control e.g. which TPPs are and are not allowed access to its data or to initiate payments through the ASPSP systems.

We would also advocate for a flexible approach to the requirement in Article 19 (5) stating that changes to the interface must be made publicly available as soon as possible and, except for emergency situations, not less than 3 months before the change is implemented. We would suggest a minimum threshold, so that minor changes can be made available closer to the implementation ate than 3 months.

We think that the application of the use of ISO 27001 in article 21 (6) needs to be clarified. ISO 27001 does not apply to specific processes of a company but rather requires business wide compliance. Therefore, we do not support a requirement that all ASPSPs, that perform PISP or AISP functions, shall ensure ISO 27001 compliance and would suggest that Article 21 (6) is clarified to reflect this.

Finally, we would propose to also have dispute handling covered by the draft In practice there will be a requirement to securely message between ASPSPs and TPPs in order to carry out payment investigations to resolve disputes, and the identification/authentication methods for this kind of ad hoc data exchange is not sufficiently addressed in the draft RTS.
We agree.
We generally agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable.

However, there is a need for procedures for revocation of certificates, for security or other reasons, and allowed actions if the qualified trust provider is compromised.

Also as the market for qualified trust service providers is only just emerging it would be prudent to include alternatives that can be used until the market for qualified trust service providers has matured and can provide services to the market as a whole.
In order for the limitations to be useful, the communication interface needs to be able to separate the active requests from the not active request. It should therefore be a requirement for the TPPs to prove whether they are acting on an active request from the PSU or not, when using the communication interface.

We would advocate for a more flexible approach as to when and how the AIPSs can request information in accordance with Article 22 (5) (b) to en-sure a good and consistent experience for both consumers and AISPs. This could for instance be achieved by making it possible for the ASPSP to push information to the AISP or for the ASPSP to process the requests for information in batches in order to avoid problems with capacity and access to the interface when requesting information.

We also think that a clarification is needed in regards to the scope of the information that the TPP can request. Can they request all historic infor-mation from the PSU, i.e. information generated before the application of requirements of PSD2 and the RTS? Or can they only request information generated after the RTS enters into force? And finally, is the request for information limited to new information generated since the TPPs last request?
[Other "]"
The Danish Bankers Association. We are a professional organisation representing the banks in Denmark. Members are ordinary banks, savings banks, cooperative banks, and Danish branches of foreign banks.
[Other"]"
We closely monitor the political processes and play an active and specific role in political decision-making that is relevant for the banks' business platform. In so doing, we target our efforts and communication at, for example, the Danish Parliament, the government and the EU.
Louise Fjord