Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
It is not clear why this latter possibility would require a prior contractual agreement between PIS and ASPSP and such agreement be outside of the scope of PSD2.
In fact, the presence of wallet solutions unifying more payment methods under a single user interface and authentication today is allowing consumers to simplify their user experience and electronic transactions to grow.
Wallet solutions under PSD2 seem to be provided by PISs (if not, who provides?), for which the agreements with ASPSPs would be difficult and slow to be defined one by one, with the consequence of reducing electronic payment transactions.
As an alternative solution, the PIS could ask the ASPSP for the first authentication of the user in order to manage the payment method of the ASPSP to the PIS wallet and then for the following payments involving that ASPSP, the strong authentication could be provided by the wallet solution which would be fully compliant with strong authentication requirements of the Consultation Paper; in this case one to one agreements would not be necessary.
As a note, also an eIDAS strong authentication solution (for example eIDAS substantial and/or high assurance level) where also fulfilling strong authentication requirements of the consultation paper could be a promising strong authentication usable for a PSD2 wallet without one to one and slow agreements with ASPSPs.
In the case additional liability requirements could be put in place for PISs providing wallets which unify the strong authentication of the user.
The same mechanism could also be provided to link the wallet to a credit/debit card, where the issuer of the card could provide the first authentication and then the wallet strong authentication would be used for the following payment transactions.
In addition, it is not clear whether in the article 10 the storage of the PAN of the credit/debit card is made by the acquirer or by the payee and whether the strong authentication of the issuer (or of the bank) has to used or if it is allowed that:
1. the payees stores the PAN of the card and provides the user with a strong authentication provided directly by the payee, where the strong authentication is compliant with RTS.
2. the issuer at the point above has necessarily to request the ASPSP for knowing the availability of the amount on the bank account
However, in order to prevent from man-in-the-middle and man-in-the-browser attacks, at least in the case where the transaction signing is used as strong authentication, it could be possible to display amount and payee also on the channel used to initiating the payment to allow the user matching said information present on the two different channels.
In any case we agree with the fact that the means (for example a mobile app) used by the payer to authenticate must be different from the means (ecommerce web page, merchant app …) used to view goods to buy or manage banking accounts; in particular the authentication means shouldn’t allow SDKs to be integrated client side to provide segregation.
In addition it is not clear whether:
• card issuers have always to use ASPSPs strong authentication, even when it is not required to know the coverage of the payment amount in the user’s account.
• Usual home/mobile banking services not interconnected with PIS and AIS have to comply with the RTS
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?
In the paragraph 3.2.1 at point 19 the authentication procedure is described to be within the sphere of competence of the ASPSP except when the PISP issues its own personalised security credentials to the user, in place of the credentials issued by the ASPSP.It is not clear why this latter possibility would require a prior contractual agreement between PIS and ASPSP and such agreement be outside of the scope of PSD2.
In fact, the presence of wallet solutions unifying more payment methods under a single user interface and authentication today is allowing consumers to simplify their user experience and electronic transactions to grow.
Wallet solutions under PSD2 seem to be provided by PISs (if not, who provides?), for which the agreements with ASPSPs would be difficult and slow to be defined one by one, with the consequence of reducing electronic payment transactions.
As an alternative solution, the PIS could ask the ASPSP for the first authentication of the user in order to manage the payment method of the ASPSP to the PIS wallet and then for the following payments involving that ASPSP, the strong authentication could be provided by the wallet solution which would be fully compliant with strong authentication requirements of the Consultation Paper; in this case one to one agreements would not be necessary.
As a note, also an eIDAS strong authentication solution (for example eIDAS substantial and/or high assurance level) where also fulfilling strong authentication requirements of the consultation paper could be a promising strong authentication usable for a PSD2 wallet without one to one and slow agreements with ASPSPs.
In the case additional liability requirements could be put in place for PISs providing wallets which unify the strong authentication of the user.
The same mechanism could also be provided to link the wallet to a credit/debit card, where the issuer of the card could provide the first authentication and then the wallet strong authentication would be used for the following payment transactions.
In addition, it is not clear whether in the article 10 the storage of the PAN of the credit/debit card is made by the acquirer or by the payee and whether the strong authentication of the issuer (or of the bank) has to used or if it is allowed that:
1. the payees stores the PAN of the card and provides the user with a strong authentication provided directly by the payee, where the strong authentication is compliant with RTS.
2. the issuer at the point above has necessarily to request the ASPSP for knowing the availability of the amount on the bank account
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.
In the paragraph 3.2.1 at point 26 seems that the channel where amount and payee are displayed is different from the channel used for initiating the payment.However, in order to prevent from man-in-the-middle and man-in-the-browser attacks, at least in the case where the transaction signing is used as strong authentication, it could be possible to display amount and payee also on the channel used to initiating the payment to allow the user matching said information present on the two different channels.
In any case we agree with the fact that the means (for example a mobile app) used by the payer to authenticate must be different from the means (ecommerce web page, merchant app …) used to view goods to buy or manage banking accounts; in particular the authentication means shouldn’t allow SDKs to be integrated client side to provide segregation.
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 our reply to question Q2.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?
See our reply to the question Q1.In addition it is not clear whether:
• card issuers have always to use ASPSPs strong authentication, even when it is not required to know the coverage of the payment amount in the user’s account.
• Usual home/mobile banking services not interconnected with PIS and AIS have to comply with the RTS