Intesa Sanpaolo S.p.A.

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."
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)."
Intesa Sanpaolo deems that no further additions are needed.
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.
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."
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
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.
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.
Intesa Sanpaolo substantially agrees. However, we ask for alternatives mechanisms to e-IDAS compliant certificates.
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.
[Credit institution"]"
[Issuing of payment instruments and/or acquiring of payment transactions"]"
Intesa Sanpaolo S.p.A.