Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?

ING agrees with the reasoning yet would like to propose an amendment to allow a sufficient level of flexibility for current and future means of payment.
ING understands and supports the conclusion that risk measurements can be part of the SCA procedure. However, ING is strongly against prescribing any concrete mechanisms to prevent, detect and block fraudulent payment transactions since this is the full responsibility of the ASPSP who is ultimately liable for the cost of fraud. Furthermore, ING is of the opinion that Article 1.3(e) in its current form hampers innovation and does not cater for future developments. ING is of the opinion that the RTS can be technology neutral in this respect while not compromising security.
Therefore, Article 1.3(e) should be amended as follows:
prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation.

Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.

Yes, since ING understands that EBA has drafted Article 2.2 with the objective to prevent man-in-the-middle attacks, it is important that the RTS are future proof, technologically neutral and principle based. Our suggestion is therefore to leave all technical options open and not to prescribe just one particular mechanism to ensure the confidentiality, authenticity and integrity of the information displayed to the payer. ING proposes to delete the last sentence of Article 2.2(b) which prescribes that the channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction. The requirement of an independent or segregated channel implies a certain solution, however other broadly used market solutions to prevent man-in-the-middle attacks are available with at least the same level of security but are more user-friendly.

Therefore, Article 2.2(b) should be amended as follows:
(b) the confidentiality, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code.

Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?

In our view Article 3.1 is currently too prescriptive and does not respect the principle of technical neutrality due to the wording “features including but not limited to”. The wording should rather read “features that may include, but are not limited to,”. Furthermore, clarification is requested on what is meant by ‘non-repeatable characters’. In line with the EPC we suggest removing these words, since their most likely meaning is already covered by the term “complexity”. The important issue is that the PSP has a password management policy in place that ensures an adequate level of protection. Beside measures ensuring a certain entropy against guessing attacks (brute force), the maximum number of erroneous trials must additionally be limited by the implementation in order to exclude exhaustive trial attacks. The reference to “expiration time” should be deleted since this is less and less considered as a best practice in security policies.

Therefore, Article 3.1 should be amended as follows:
The elements of strong customer authentication categorised as knowledge shall be characterized by security features that may include, but are not limited to, length, complexity and a maximum number of erroneous trials, ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties.

Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?

ING agrees with the EBA on the resultant provisions as a logical consequence of the PSD2 mandate and understands the rationale leading to the exemptions. Nonetheless, clarification is required on: (i) the treatment of corporates (non-consumers) PSUs and (ii) the applicability of SCA in case of suspected fraud.
(i): for corporates (non-consumers) PSUs, ING is of the opinion that applying the exemptions on a mandatory basis is not suitable. These PSUs may have implemented authorisation matrixes which are integrated in the authorisation procedures/SCA of the ASPSP and apply to all of their payments and access to electronic channels. All with the objective to enhance security and protect against internal and external fraud, taking into consideration the interests at stake. As a consequence PSPs should be able to apply SCA for non-consumer PSUs to facilitate the authorisation procedures as requested by corporates (non-consumers) in relation to payments initiated through or access to electronic payment channels at all times.
(ii): for consumer PSUs, ING agrees to force the application of the exemptions on an integral basis to ensure a level playing field. However in case of (a suspicion of) fraud ING wants to be able to apply SCA. Applying SCA on transactions with high risk is in most of the cases much better than blocking them: it avoids extra traffic that comes from re-initiation of the transaction and is much more customer friendly, while maintaining a high level of security.

Furthermore, we question the usability of the proposed period of one month for a PSU to access the information of its payment account online after the last time SCA has been performed. From our user data information ING has evidence that the vast majority of our PSUs check their information from the same location and via the same device. From a security perspective this should provide sufficient safeguards that would allow a period of at least once every year. By means of methods to detect, prevent and block fraud, ASPSPs can force PSUs to apply SCA more often in case of suspected fraudulent attempts.

Finally, clarification is needed on whether a PSP is allowed to implement a lower threshold at its own choice as long as it remains within the limits as stated in Chapter 2. For example, a PSP may have reasons to introduce a threshold of 30 EUR for contactless payment transactions above which a PSU needs to apply SCA, and not only above 50 EUR as mentioned in Article 8.1(b).

Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?

Referring to the answer given to question 4 clarification is required on: (i) the treatment of corporates (non-consumers) PSUs and (ii) the applicability of SCA in case of suspected fraud.
(i): for corporates (non-consumers) PSUs, ING is of the opinion that applying the exemptions on a mandatory basis is not suitable. These PSUs may have implemented authorisation matrixes which are integrated in the authorisation procedures/SCA of the ASPSP and apply to all of their payments and access to electronic channels. All with the objective to enhance security and protect against internal and external fraud, taking into consideration the interests at stake. As a consequence PSPs should be able to apply SCA for non-consumer PSUs to facilitate the authorisation procedures as requested by corporates (non-consumers) in relation to payments initiated through or access to electronic payment channels at all times.
(ii): for consumer PSUs, ING agrees to force the applications of the exemptions on an integral basis to ensure a level playing field. However in case of (a suspicion of) fraud ING wants to be able to apply SCA. Applying SCA on transactions with high risk is in most of the cases much better than blocking them: it avoids extra traffic that comes from re-initiation of the transaction and is much more customer friendly, while maintaining a high level of security.

Furthermore, we question the usability of the proposed period of one month for a PSU to access the information of its payment account online after the last time SCA has been performed. From our user data information ING has evidence that the vast majority of our PSUs check their information from the same location and via the same device. From a security perspective this should provide sufficient safeguards that would allow a period of at least once every year. By means of methods to detect, prevent and block fraud, ASPSPs can force PSUs to apply SCA more often in case of suspected fraudulent attempts.

Finally, clarification is needed on whether a PSP is allowed to implement a lower threshold at its own choice as long as it remains within the limits as stated in Chapter 2. For example, a PSP may have reasons to introduce a threshold of 30 EUR for contactless payment transactions above which a PSU needs to apply SCA, and not only above 50 EUR as mentioned in Article 8.1(b).

Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?

ING agrees with the intention of the text, however ING argues a more principle-based approach should be used. The RTS should refer to existing international standards.

Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?

Yes, ING understands the EBA’s reasoning behind these requirements and agrees with most of the provisions proposed in Chapter 4 of the draft RTS. In particular, ING welcomes the EBA’s view that ASPSPs shall offer at least one communication interface to be used by AISPs, PISPs and PSPs issuing card-based payment instruments. However, as explained in our answers to the next questions, ING does have some concerns regarding certain aspects of the provisions.

On a general note, ING sees a risk that a lack of (further) interface standardisation in the RTS will lead to market fragmentation, which may hamper innovation and competition by posing a challenge for new parties willing to enter the market to provide TPP-services. In the end this may potentially limit consumer choice, user friendliness and the creation of a digital single market.

As regards the authentication of PSUs, ING understands that the draft RTS only caters for TPPs to rely on the authentication procedures provided by the ASPSP to the PSU. However, ING believes such a reliance will restrict TPPs in creating viable business models as well as enhancing the customer experience with corresponding customer benefits. ING is of the opinion that the final RTS should also cater for models in which TPPs can issue their own credentials to perform their own SCA instead of SCA by the ASPSP without TPPs having to enter into agreements with ASPSPs. In fact, the PSD2 level 1 text allows such models without further conditions in this respect. Therefore, ING does not agree with the statement as included in Rationale 19(a) of the draft RTS that for such models a contract would be required as this statement is not supported by the PSD2 level 1 text. In addition, requiring such a contract would open the door for potential anti-competitive behaviour from the side of ASPSPs, something which certainly does not fit with the objectives to promote competition and innovation.
Allowing for such business models would not increase payment security risks as TPPs choosing to issue their own credentials would have to comply with the RTS SCA-requirements themselves.

Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?

ING agrees that standardisation is key to ensure interoperability. However several standards are available in the market and/or will be developed which can be used in the communication between PSPs. ING proposes that the RTS remains neutral in prescribing industry standards with one clear exemption: the usage of ISO 20022 data definitions should be the basis. ISO20022 is the only industry standard data definition for payments and can be used in several message definitions (e.g. JSON, XML).

Therefore, Article 19.3 should be amended as follows:
Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 data definitions as well as standards of communication which are developed by international or European standardisation organisations.

Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?

ING agrees that certificates issued by a qualified trust service provider under an e-IDAS policy provide a suitable solution for mutual authentication between PSPs. Note that the PSU would play no role in this scheme as it would be applied in the connection between the systems of the TPP and the ASPSP, as such it has no relation to aforementioned devices.
However as stated in the rationale there might not be a qualified trust service provider on the market at the time of implementation of the RTS. We would like to stress the importance and key role of qualified trust service providers in the communication between TPPs and ASPSPs. In case no qualified trust service provider is on the market, we would like EBA to take up that role as part of the registration of TPPs and/or appoint a party in this role.

Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.

ING agrees on the frequency of no more than two times a day as specified in Article 22.5(b).

ING is of the opinion that the proposed limit of clause 22.5(b) is satisfactory, provided that article 22.5(a) is phrased in such a way that the effect is that the AIS PSP will only request the information if the PSU actively in the secure (online) electronic system/application requests the AIS PSP to do so. For ING it is very important to be able to meet all requests from TPPs without excessive demands being made that may have a negative impact on the performance/availability of our communication interface. Such excessive demand could occur if a PSU via the contract instructs the AIS PSP to retrieve information many times a day, e.g. to provide a (near) real time status of its accounts.

Therefore, Article 22.5(a) should be amended as follows:

(a) Every time the payment service user actively requests such information electronically through the application, online environment or similar electronic environment of the account information service provider,

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

[Credit institution"]"

Please select which category best describes the services provided by you/your organisation

[Other"]"

If you selected "Other", please provide details

ASPSP

Name of organisation

ING Bank NV