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?

We, the MRC EU, agree with the EBA that security measures are required to authenticate bona fide payers when a payment transaction is taking place, however the provisions proposed in Chapter 1 are over-reaching and, in some cases, impossible to implement by one single party, i.e. the payee and / or their payment service provider (PSP). For instance, Article 6.3.b requires the PSP to ensure a payer’s payment device (e.g. mobile phone, tablet, etc.) has not been altered by the payer. There is no suggestion how this might be done by a remote third party. There is also a lack of clarity around authorities, e.g. Article 7.1 refers to ‘certified auditors’ but does not confirm by whom the auditors are certified. Similarly 7.3 refers to ‘competent authorities’ but does not clarify which ones.

More clarity, on all points, is required here to facilitate any semblance of compliance.

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.

This requirement is not consumer friendly.

There is a requirement here (Article 2.1 (b)) to link the amount of a transaction to the security code provided via the authentication methods described, however were the amount to change during the transaction, a new code – ergo a new authentication process – is required of the payer. This appears to be generating a cumbersome and laborious process for a payer and for a merchant there is a risk of cancellation of the given transaction by the frustrated payer.

In our opinion, the rules should allow:-
• For a maximum rather than absolute value in relation to a single transaction in certain circumstances (e.g. a hotel or card hire, where the amount to be charged will only be known at the end of the interaction)

• For recurring transactions to be enabled, where the initiation of the sequence of transactions is secured with a dynamic link to a fixed recurring amount (e.g. a fixed price magazine subscription) or a maximum value per recurrence (e.g. a maximum cap for utility bill payment). The second and subsequent occurrences of a recurring transaction should not require a consumer interaction to provide an authentication.

Regarding Article 2.2 (b), requiring a separate device for displaying the transaction amount to that used to make the payment appears to suggest a mobile phone cannot be used to make a single purchase. In ecommerce, there is considerable growth in the use of in-app shopping on smart phones and website based mobile phone transactions. The EBA needs to clarify the position for merchants that use these tools in growing numbers for the convenience of consumers.

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?


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?

Exemptions are required in this regard given the nature of some payments such as direct debits, credit transfers, standing orders and other recurring card payment transactions. The exemptions described herein lack clarity. The MRC asks that the status of merchants whose core business consists of recurring transactions be clarified.

Regarding Article 8.1.ii, it refers to SCA not being exempt where a payer accesses the information of its payment account online, etc. later than one month after the last day in which SCA was applied. Where is the rationale for the period of one month? This appears to contradict the exemption around access to an account after the first access by a payer.

Article 8.2 (a) refers to payers initiating online credit transfers to trusted beneficiaries, however in the case of a recurring transaction by a utility service or subscription service, it is not the payer that initiates the transfer, rather the payee collects the funds based on a prior agreement with the payer. Does this article mean a payer is required to initiate all recurring transactions for such payments?
This is not consumer friendly. Such transactions are also low risk and do not require similar authentication to one-off payments.

Article 8.2 (b) refers to an exemption for recurring transactions from a payer to a trusted payee for the same amount in an ongoing series of transactions. It goes on to say transactions are not exempt when the credit transfer is amended which will be the case for, e.g. a merchant such as a Telephone Company where the value of the transaction will vary for each credit transfer.
Utility merchants, subscription services, charities, etc. will be required to rebuild their business models in this instance or cease trading in a consumer-convenient way.

Article 8.2 (c) refers to an exemption on SCA being used for a credit transfer between a payer’s own payment accounts. This suggests the EBA considers bank accounts less important or at less risk than payment card accounts.
Without SCA in this instance, in the case of Account Takeover Fraud occurring, a criminal could establish an account that appears to be that of the genuine payer and make transfers between, what appears to be the payer’s ‘own’ accounts, rendering the bona fide account holder at a loss.
There is no rationale for making this process exempt from SCA.

We also have concerns that a risk based approach to profile transactions for SCA is not included within the exemptions. Merchants should be able to proceed with risk based profiling and decide whether or not to present SCA; provided that they are liable for any fraud relating to that transaction. Ideally, this SCA presentation should be at the discretion of the merchant in conjunction with the issuer; with the merchant being able to decide whether to present an SCA challenge (in line with the model being proposed by the PCI for 3DS 2.0 initiative).

Setting the maximum amount for remote electronic transactions is too prescriptive and restrictive. The standards should not set out an amount within the regulations.

The rules relating to the cumulative amount of non SCA transactions is unclear.

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?

Our concern relates to the lack of clarity on the exemptions. A PSP will require clearer terms under the exemptions.

In line with risk based analysis, merchants should be able to present an SCA challenge where their profiling indicates a suspicious transaction, even though the transaction would be exempted by the conditions in Chapter 2. (e.g. a suspicious transaction with a value less than €10).

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?

Clarity is sought on Article 9.1 (a) referring to data on personalised security credentials being masked when displayed and not readable in their full extent, i.e. masked from whom and at what stage of the transaction. Depending on the credentials, they will need to be verified by an individual or PSP tool at which point they can’t be masked. Further clarity is required here.
Where a merchant refuses, or does not uphold, the contractual provisions between acquirer and merchants as outlined in Article 10, it is unclear who would be liable as the technical standards are not aimed at merchants (payees).

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?

There is certainly a requirement to secure communication between payers and payees and with the bodies operating between those two entities.

We require clarity on a number of things in this Chapter.

Article 17.2 refers to PSPs being required to ensure that mobile applications and other payment services user interfaces offering electronic payment services are protected against misdirection of communication to unauthorised third parties. It seems an impossible task here for a PSP to control the actions of a consumer or their device. Where is the onus on the consumer? Should liability lie with the PSP when the consumer acts negligently?

Similarly in Article 21.1 the requirement on the PSP is entirely dependent on the actions of the consumer, which are beyond the control of the PSP in the referred instance, e.g. the PSP can provide secure internet from their end however they can’t control all the security measures used by the payer. There is more clarity required here.

Article 21.2 also appears to be consumer-dependent, i.e. a PSP is expected to know when a consumer has completed a sale and does not wish to make another purchase at the same merchant and is required to terminate the session. What is the rationale for this, if SCA is required in any case to complete further sales, in the event the session remains open for a third party to use?

In general, PCI-DSS provides existing and proposed requirements that are effective in this area and the RTS should acknowledge the use of PCI-DSS as consistent with the RTS requirements.

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?

We have no further comments here.

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 ?

We have no comment in this regard.

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.

Article 22.5 (b) refers to a service provider requesting information from designated payment accounts but limiting that request to ‘no more than 2 times a day’. The rationale for this limit is unclear. Any activity of a service provider that affects the availability to their customer of their service should be a matter for that organisation and not come under industry standards-based limits.

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

[Other "]"

If you selected "Other", please provide details

Global Ecommerce Merchant Association

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


If you selected "Other", please provide details

MRC Fraud & Payments EU Ltd is a Global Trade Association for ecommerce merchants, providing advisory services, networking roadshows, events and training on all things relating to payments, risk, fraud and building an ecommerce business. Our membership includes the majority of top brand global ecommerce merchants and service providers, acquirers, issuers and law enforcement agencies.

Name of organisation

MRC Fraud & Payments EU Ltd.