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?

See response of the Dutch Payments Association

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.

See response of the Dutch Payments Association

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?

See response of the Dutch Payments Association

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?

Rationale 53, 54 and 55
We challenge the premise in Rationale 53 that “… a consistent application of SCA by all PSPs [is required] to ensure a fair competition and to safeguard against possible discrimination between PSPs”. The application of a specific form of customer authentication, the level (e.g. weak, strong, very strong) and specific circumstances when to apply what level, is for the ASPSP to choose depending on, amongst others, its risk appetite, openness to innovation and customer service concept. For consumers these factors influence their decision when choosing whose PSP’ services to use and thus defines competition between PSPs. As long as ASPSPs apply their customer authentication policy consistently, regardless whether the PSU initiates a payment via a PISP or directly with the ASPSP, as Art.67.3(b) PSD2 requires, PISPs cannot be discriminated against by the ASPSP and the PSU is ensured of a consistent user experience, even if he wishes to use the services of several PISPs. A similar strand applies to AISPs, where Art. 66.4c PSD2 achieves the same goal. In fact, a set of predefined situations when to apply SCA and when not, as the draft RTS currently proposes, is more likely to harm competition than to ensure it.

Regarding the proposed mandatory nature of the exemptions, we like to point out that this seems contrary to what the PSD2 intends and to what is written in the level 1 text. For example Article 98.3(a) states that “the exemptions […] shall be based on the following criteria: (a) the level of risk involved in the service provided…”, which is for the PSP or PSPs involved in a specific transaction to assess as they are the ones providing the service. Recitals 91 and 96 PSD2 confirm this view. Article 98.2(a) is another example that risk consideration by the parties involved is intended to be an integral part of the RTS and in particular the exemptions when (not) to apply SCA: “The draft regulatory technical standards […] (a) ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements”. The currently proposed four exemptions (below EUR 10,-; payer and payee are the same person with the same ASPSP; payee is on payer’s trusted lists; a credit transfer as part of a series of transfers with the same payee and for the same amount), is too crude a proxy for a risk-based assessment. As a final example we point to Article 66.4(c) and 67.3(b) of PSD2. We do not read these as providing ground to a mandantory list of exemptions in order to have “a consistent application of SCA by all PSPs”. These two Articles state that an ASPSP is not allowed to discriminate between activities performed by a payer via a TPP and those performed by that payer directly with the ASPSP. Moreover, the provision in these very same articles suggest that the ASPSP is in fact allowed to, and in our view should, discriminate “… for objective reasons”; if a mandatory set would leave the PSPs no room to act upon such objective reasons, this would violate that provision in the level 1 text, thus creating compliance risks and risk of failure of the duty of care towards customers.

Article 8.1(a)ii
Choosing the period of one month is an arbitrary one. We do not foresee significant additional issues or threats when extending this to a longer period and suggest to add to the text an optional extension of the one-month period by the PSP based on a case-by-case risk-analysis.

Article 8.1(b)
The exemptions in this Article fail to include existing payment products that currently exist, such as no-CVM (Card Verification Method) debit- or credit card payments under EUR 50 for toll ways and parking. We therefore strongly suggest to amend this Article as follows:
(b) the payer initiates a contactless [add: or no-CVM (Card Verification Method)] electronic payment transaction at a point of sale within the limits of both the following conditions:
i. the individual amount of contactless electronic [add: or no-CVM (Card Verification Method)] payment transaction does not exceed the maximum amount of 50 EUR [add: or lower threshold set by the ASPSP or the payer];
ii. the cumulative amount of previous non-remote electronic [add: or no-CVM (Card Verification Method)] payment transactions initiated via the payment instrument offering a contactless [add: or no-CVM (Card Verification Method)] functionality without application of strong customer authentication does not exceed 150 EUR [add: or lower threshold set by the ASPSP or the payer].

Article 8.2(a)
Article 8.2(a) provides a good example why the list of exemptions must allow for a risk based approach by the ASPSP and should be non-limitative. In case a PSU/payer has added a certain payee on the trusted list using SCA, a payment of given amount to this particular payee might still fall outside of the ‘ordinary’ payment pattern of this particular payer, in which case the ASPSP should be allowed to apply SCA and other mitigating measures to make sure the payer is authenticated and the payment rightfully and knowingly authorised, even though an exemption to SCA could have been applied. The ASPSP’s duty of care towards their customers requires nothing less. The only alternative to the ASPSP would otherwise be to reject the payment in total, which in most real life cases would be to the detriment of the legit payer (and payee).

Article 8.2(d)
Choosing a threshold of EUR 10,- seems quite arbitrary. This particular limit is not in line with the EUR 50,- below which payment transactions by a provider of electronic communications networks provided in addition to electronic communications services for a subscriber to the network or service are excluded from the application of the PSD2 (art.3(l)); nor with the maximum liability, again EUR 50,- of the payer for unauthorised payments (art.74.1)
Ideally, we would favour a higher threshold of e.g. EUR 250,- to be set by the ASPSP which can be lowered by the PSU/payer according to his own preference. We already offer customers expendure limits to certain payment instruments, devices and/or time periods in combination with certain payment instruments, adjustable to their own preferences. Alternatively, this particular limit should in our view be set at EUR 50,- which is a level more consistent with other comparable limits in the PSD2 and likely to get recognised by customers.

Article 8.2
Notwithstanding the reference to Article 97.2 (PSD2) in Article 8.2, we can only interpret this Article in such a way that the exemptions mentioned in Article 8.2 relate to the entire SCA procedure, and not only to the dynamic linking of amount and payee. We suggest EBA to amend the text of Article 8.2 in order to clarify the ambiguity on the scope of the exemptions.

Article 8
Should the RTS persist in a mandatory list of exemptions, then it should be made clear that PSPs are allowed to deviate from this list in case of risk of fraud and in order to fulfill the obligations under Art.1.3.e of the RTS.

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?

See response of the Dutch Payments Association and our comment on Art.8 and Art.8.2(a) under Question 4.

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?

See response of the Dutch Payments Association

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?

See response of the Dutch Payments Association

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?

See response of the Dutch Payments Association

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 ?

See response of the Dutch Payments Association

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.

Our concerns are not with the frequency, which seems to be appropriate and proportionate. However, we are concerned about the amount of data that can be requested per communication session by the AISP when the PSU is not actively requesting such information. To ensure availability and stability of the communication interface, an ASPSP should be allowed to limit the amount of data that will be transferred in one request.

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

[Execution of payment transactions"]"

Name of organisation

Rabobank