Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
• Considering Art.1 and points 22(b) and 24 of the rationales, it should be clarified whether the One Time Password (OTP) can be considered as one of the at least two authentication elements required for the purpose of the strong authentication, without the need to create a further unique code
• In exemption cases from the SCA provided for by the RTS, are the PSP and the payee required to refund the financial damage suffered by the payer in accordance with art. 74(2) also beyond the transitional period
• The authentication code that can be used once is required by PSD2 only for remote transactions as per Article 97.2. Therefore, to avoid misunderstandings, we suggest specifying in Article 1 of the RTS that the use of authentication codes to be used only once is required only to remote transactions (eg. Internet banking).
• Can the access methods to online payment systems that use digital certificates be equivalent to the SCA described in Article 1?
• With reference to Article 1(3e) (fraud monitoring mechanism), it should be confirmed that full compliance with the requirements is achieved only when at least all 5 mechanisms listed in the Article are implemented.
• It would be useful to distinguish between access to the authentication procedures of the ASPSP", which has to be free, and "authentication procedures used by third parties", which third parties may also buy from vendors/suppliers (including banks) not for free."
• The definition of separated trusted execution environments" should be better explained in Article 6 (3a), in order to develop solutions in accordance with the legal requirements (ie. we consider as "separated trusted execution environments" a mobile banking app and a text message received on the same device).
• With reference to bulk payments containing payments to different beneficiaries, please clarify the sentence “beneficiaries should be considered collectively”.
• We suggest to change the provision contained in Art 2.2 (a) “… Any change to the amount or payee shall result in a change of the authentication code.” into “… Any change to the amount or payee shall result in an invalidation of the authentication code.” This change will allow the development of alternative solutions based on those one currently available, as stated in section 3.2.1 - point 24 (eg. Use of digital certificates to sign the relevant information about the amount and beneficiary of the transaction)."
We suggest that exemptions should be based on how these terminals work and by defining two levels of exemption:
• Level 1 - off-line terminals:
Minimum level for SCA application: 25€
Authentication mode: none
• Level 2 – online terminals:
Minimum level for SCA application: 100€
Authentication mode: none
Transactions via this type of terminals, as well as for contactless transactions, require a user-friendly experience.
In addition to that, we consider that the rules for the application of the exemptions should be better clarified. In detail:
• To access information services (8 (1a), or as stated in the requirement to consolidated customer information", it is not clear how exemptions apply when the customer relies on an AISP (Account Information Service Provider) (see Article 22 (5a) and 22 (5b)), especially when AISP accesses autonomously;
• For contactless services (8(1b)) and low-value transactions (8 (2d)) it is not clear how to calculate the cumulative amount. For example, if the customer makes an exempted payment and then another one which falls under the SCA conditions, is the one made under the exemption regime considered in the calculation of the cumulative amount? If yes, what is the maximum time span to calculate the cumulative amount?
We believe that the proposed operation for contactless transactions in the RTS (Article 8 point b.ii), should not be applied because it would deliver a bad customer experience. We believe all contactless transactions below 50 € should be carried out without authentication."
However, we would like to draw the attention on Article 13 (b), which requires that the PSP digitally signs the software delivered to the payment service user thus excluding the use of other softwares widely available on the market.
In addition to that, we would like to ask further details on the following points:
1. As per Art. 10, in the contract between the supplier of acquiring services and the Merchant when this latter archives, process and send security credentials clauses must be provided to ensure that he activates and applies security measures to protect data, as per art. 9,. It should be clarified in the RTS that the aquirer is not supposed to play an active role in the control of the merchant's security measures
2. Can this activity control be delegated to the company managing the PCI DSS certification? Can the certification be considered as a contractual obligation?
3. RTS should clarify how authorizations withdrawals have to be handled and how should they be communicated
4. RTS should clarify that assessments and internal audits run on a regular basis be considered sufficient for the purposes of compliance under Article. 16
We believe that two requests per day may be appropriate to prevent an excessive overload of ASPSP’s systems, while ensuring an adequate service to the AISP.
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?
Clarification is requested on the following points:• Considering Art.1 and points 22(b) and 24 of the rationales, it should be clarified whether the One Time Password (OTP) can be considered as one of the at least two authentication elements required for the purpose of the strong authentication, without the need to create a further unique code
• In exemption cases from the SCA provided for by the RTS, are the PSP and the payee required to refund the financial damage suffered by the payer in accordance with art. 74(2) also beyond the transitional period
• The authentication code that can be used once is required by PSD2 only for remote transactions as per Article 97.2. Therefore, to avoid misunderstandings, we suggest specifying in Article 1 of the RTS that the use of authentication codes to be used only once is required only to remote transactions (eg. Internet banking).
• Can the access methods to online payment systems that use digital certificates be equivalent to the SCA described in Article 1?
• With reference to Article 1(3e) (fraud monitoring mechanism), it should be confirmed that full compliance with the requirements is achieved only when at least all 5 mechanisms listed in the Article are implemented.
• It would be useful to distinguish between access to the authentication procedures of the ASPSP", which has to be free, and "authentication procedures used by third parties", which third parties may also buy from vendors/suppliers (including banks) not for free."
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.
Intesa Sanpaolo substantially agrees. However, clarifications are needed on the following:• The definition of separated trusted execution environments" should be better explained in Article 6 (3a), in order to develop solutions in accordance with the legal requirements (ie. we consider as "separated trusted execution environments" a mobile banking app and a text message received on the same device).
• With reference to bulk payments containing payments to different beneficiaries, please clarify the sentence “beneficiaries should be considered collectively”.
• We suggest to change the provision contained in Art 2.2 (a) “… Any change to the amount or payee shall result in a change of the authentication code.” into “… Any change to the amount or payee shall result in an invalidation of the authentication code.” This change will allow the development of alternative solutions based on those one currently available, as stated in section 3.2.1 - point 24 (eg. Use of digital certificates to sign the relevant information about the amount and beneficiary of the transaction)."
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?
Intesa Sanpaolo deems that no further additions are needed.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?
Intesa Sanpaolo substantially agrees with the principles on which the exemptions are based and believes that RTS should identify the types of applicable exemptions providing the necessary criteria to define and implement them.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?
We believe that the list of exemptions is limited; we suggest also extending the exemption to transactions at unattended POS (unattended terminals such as eg., parking meters, vending machines, toll and gas stations, etc.).We suggest that exemptions should be based on how these terminals work and by defining two levels of exemption:
• Level 1 - off-line terminals:
Minimum level for SCA application: 25€
Authentication mode: none
• Level 2 – online terminals:
Minimum level for SCA application: 100€
Authentication mode: none
Transactions via this type of terminals, as well as for contactless transactions, require a user-friendly experience.
In addition to that, we consider that the rules for the application of the exemptions should be better clarified. In detail:
• To access information services (8 (1a), or as stated in the requirement to consolidated customer information", it is not clear how exemptions apply when the customer relies on an AISP (Account Information Service Provider) (see Article 22 (5a) and 22 (5b)), especially when AISP accesses autonomously;
• For contactless services (8(1b)) and low-value transactions (8 (2d)) it is not clear how to calculate the cumulative amount. For example, if the customer makes an exempted payment and then another one which falls under the SCA conditions, is the one made under the exemption regime considered in the calculation of the cumulative amount? If yes, what is the maximum time span to calculate the cumulative amount?
We believe that the proposed operation for contactless transactions in the RTS (Article 8 point b.ii), should not be applied because it would deliver a bad customer experience. We believe all contactless transactions below 50 € should be carried out without authentication."
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?
Intesa Sanpaolo agrees with the measures mentioned in Chapter 3.However, we would like to draw the attention on Article 13 (b), which requires that the PSP digitally signs the software delivered to the payment service user thus excluding the use of other softwares widely available on the market.
In addition to that, we would like to ask further details on the following points:
1. As per Art. 10, in the contract between the supplier of acquiring services and the Merchant when this latter archives, process and send security credentials clauses must be provided to ensure that he activates and applies security measures to protect data, as per art. 9,. It should be clarified in the RTS that the aquirer is not supposed to play an active role in the control of the merchant's security measures
2. Can this activity control be delegated to the company managing the PCI DSS certification? Can the certification be considered as a contractual obligation?
3. RTS should clarify how authorizations withdrawals have to be handled and how should they be communicated
4. RTS should clarify that assessments and internal audits run on a regular basis be considered sufficient for the purposes of compliance under Article. 16
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?
We believe that all dispositive features that fall within the scope of PSD2 should be made available to TPP, without the obligation to offer access to the TPP to the service purchase component, in other terms the component not related to payment itself. Especially for services regulated by bilateral agreements, such as mobile top-up or paying stamp / ticket for which the payment service is only part of a wider service offered to the customer.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?
Intesa Sanpaolo agrees with the use of ISO 20022, which it has already been adopted as standard for SEPA products and largely developed by banks.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 ?
Intesa Sanpaolo substantially agrees. However, we ask for alternatives mechanisms to e-IDAS compliant certificates.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.
The large number of accesses to the system has no impact on safety aspects, unless the system availability requirements.We believe that two requests per day may be appropriate to prevent an excessive overload of ASPSP’s systems, while ensuring an adequate service to the AISP.