Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
More clarity, on all points, is required here to facilitate any semblance of compliance.
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.
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.
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).
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).
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 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?
NoQuestion 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.