ITALIAN BANKING ASSOCIATION

1 Introduction

The Italian Banking Association (ABI), appreciates the opportunity to make observations and comments on the Consultation Paper (CP) containing the proposed Draft regulatory technical standards (RTS) specifying the requirements on strong customer authentication and common and secure communication under PSD2 (Directive 2015/2366)", which the EBA has developed, in close cooperation with the European Central Bank (ECB) and the Eurosystem, and published for consultation. Based on the experience of its members, and in the common interest of attaining and maintaining high levels of security, ABI considers that the text as proposed can be improved, by taking into account the huge variety of services and payment instruments to which the standards would be applied, and by preventing that the diffusion of e-payment services is limited by excessive restrictions.

ABI is therefore offering its contribution, in reply to the consultation, in the hope that the proposed amendments will be viewed favourably, and accepted. ABI has drafted this document after obtaining comments from its members, the ABI Lab Consortium(banking research and innovation centre), the Bancomat® Consortium (owner of the national debit card scheme) and the CBI consortium (manager of a technological infrastructure for corporate banking). We refer to the specific replies to each of the questions raised in the CP, highlighting in each answer the most important considerations as well as providing evidence to support the views expressed and proposing alternative choices/wording of the proposed RTSs.

2 Replies to question 1
We agree that, as indicated in Rationale 22, (“the draft RTS should be developed at a higher rather than granular level of detail”): the security provisions of the RTS should not be detailed in order to avoid discrimination between technologies and to incentivise innovation. A high level non-prescriptive approach is also recommended because of the continuous evolution in the threats and defence tools developed by the ASPSPs (“to allow for PSPs to be able continuously to adapt to evolving fraud scenarios”). To this, we would add that:
• developments in technology can quickly render the detailed measures obsolete (as early as October 2018), and this would require continuous alignment in the regulations in the future. We could mention, for example, the effect of the increasing use of big data to carry out predictive analysis of customer behaviours for security purposes;
• the set measures adopted in the RTS, being in the public domain, would be highly vulnerable and would involuntarily facilitate fraud.
In line with Rationale 22, the indications outlined in Chapter 1 should represent best practices and should not restrict the PSPs, in order to leave them free to:
• adopt new solutions, which are always in line with the technological state of the art;
• put in place security measures based on a risk-based approach and on behavioural analysis;
leaving the PSPs free to find the optimal balance between security levels and an efficient user experience.

The intention to maintain a high level, technologically neutral approach in defining the requirements is therefore contradicted by the fact that the RTS contain specific, mandatory security requirements and not merely examples.
In particular, the expressions "including/shall take into account, but not limited to" refer to specific elements that should be applied as a matter of course in any context in which authentication takes place, and to any e-payment instrument and e-payment transaction. These expressions are found in various articles and do not seem in line with the approach that the EBA has stated that it wishes to take. We therefore ask that this expression be eliminated, wherever it is found, and replaced by a list of the features indicated as valid best practices to be applied in the context in which the authentication is to take place.
Alternatively, we propose adding the expression “if applicable” or equivalent (for example in Article 1(3)e, Article 3(1), Article 4(1) and Article 5(1)). This addition would maintain the ASPSP's commitment to respecting the obligation, but at the same time it would exempt it, if there are insuperable obstacles in its application (for example, technical restrictions). Not all of the prescribed measures can be applied to all the payment instruments, channels and models.

Certain passages in the draft RTS on the requirements for the strong authentication procedure leave room for different interpretations. Depending on the interpretation, it is possible that there could be a significant impact on usability and on the investments made in access protection and e-transactions, not least those recently done to comply with the EBA Guidelines on the security of internet payments.
According to our reading, in some cases the “authentication code” is the result of the “authentication procedure”; in particular in physical payments it corresponds to the cryptogram used to authenticate each transaction, generated in the contact between card and terminal and verified by the issuer. In remote payments/access to online accounts, the “authentication code” sometimes may be the result of the authentication procedure, but in some other cases it may be directly and automatically generated during the authentication procedure, without the need for the payer to enter any other codes. This interpretation is not immediately obvious from the current version of Article 1(1). For the sake of greater clarity, we therefore propose that Article 1(1) be amended from “the authentication procedure shall result in the generation of an authentication code…” to “the authentication procedure shall contain or result in the generation of an authentication code …”. This wording is flexible and can be adapted to the many different usage scenarios, particularly if the dynamic link is mandatory (Article 97(1)b) or if it is not (Article 97(1)a and 97(1)c of PSD2), and is in line with the current procedures, which guarantee an appropriate balance between security and the user experience;

With reference to the Rationale 19 b) of the CP, it is unclear on what elements the EBA has based its interpretation of Article 74(2) of the PSD2, according to which the liability shift only applies in a limited period of a few months. Article 74(2), on the contrary, establishes the principle of distribution of responsibilities without any element of transition. In the context of strong customer authentication, Article 74(2) can indeed be reconciled with Article 97(1)b. The strong authentication obligation determined for the payer's PSP does not limit the beneficiary's discretion as to whether or not to use it, and to bear the risks and consequences of that decision. The interpretation proposed by the EBA would be a new obligation, not provided for by law, for the acquirer PSPs to require the beneficiaries to provide strong customer authentication support in remote card transactions, creating an issue in the relationship with the online merchants. We also note that the abolition of the liability shift would only be imposed on online merchants based in the European Union, while for e-commerce sites from non-EU nations there would be no such obligation. The imbalance in the application of the prohibition could result in the user experience -- at the time of checkout of the purchase process -- being facilitated or complicated depending on the geographical location of the merchant. This would have a potentially adverse impact on the European e-commerce sector, in favour of the large non-EU merchants; in other words, it would generate a risk of delocalising online operators outside of the European Union. For the above reasons, we therefore propose that Rationale 19 b) be deleted.

We have made other observations on the specific wording of the articles and Recitals of the RTS, below.
• Rationale 19a and Recital 10: Recital 10 does not adequately reflect the logic of Rationale 19a. According to Rationale 19a, PISPs “have the right” to rely on the ASPSPs' authentication procedures. Recital 10 establishes that the communication interface provided by the ASPSP “should” enable the PISP and AISP to rely on the authentication procedure provided by the ASPSP. We consider that, if PISPs and AISPs do not issue their own personalised security credentials according to a prior contractual agreement with the ASPSPs (Rationale 19a, second paragraph), they must use the authentication procedures of the ASPSPs in order to minimise the risk of fraud. We therefore suggest that Rationale 19a be fully reflected in Recital 10.
• Article 1(2): it may be useful to clarify that in order to attain the result of preventing the re-use of a code or the use of an old, unused code, the ”expiration time” of an “authentication code” can be guaranteed by the authentication system, not necessarily by the generating algorithm. For example, when the ”authentication code” is generated by the system and sent through a secure channel to the customer, the system can associate the time of generation of the code, and reject it if it is supplied after a pre-set time.
• Article 1(3)a: in order to avoid forcing the customer to logout after a “session time limit”, thus prejudicing the customer experience, the same security objective can be obtained by forcing the logout after a period of “session inactivity”. Instead of the logout, the customer can be asked to re-authenticate himself if she/he intends to continue the session.
• Article 1(3)c: it would be useful to clarify whether blocking the customer's actions after a maximum number of failed authentication attempts can be carried out by the PSP even without considering “a given period of time”.
• Article 1(3)e: Although the clear intent of PSD2 is to increase the security of electronic payment transactions, the Draft RTS do not seem to be the place in which to prescribe rules on how to prevent fraud, however much the stated principles may be valid. If the EBA does not intend to remove that provision, it should be amended appropriately, as we consider that making mandatory (instead of recommended) all the mechanisms listed between point (i) and point (v) would invalidate effective risk analysis systems which, for example, only use four of the five mechanisms listed but consider others in addition, which although not mentioned are no less useful (such as the IP address or the geolocalisation analysis). On the contrary, developments in fraud techniques and the development of technology can render some of the methods listed quickly obsolete and outdated. We consider that it would be more useful to have a structure in which the listed measures can be used as best practices depending on the situation, not all simultaneously to all electronic payment instruments and in any operating conditions. For example, we note that the signs of malware ((ii) “signs of malware infection in the session”) cannot be noted in situations in which the e-payment takes place without an active session.
• Article 3(1): it must be clarified that the duration of the expiration time is defined by the ASPSP, who takes into account the type of service and the instrument of payment and its usability.
• Article 3(2) requires the ASPSP to apply mitigation measures designed to prevent the circulation or unauthorised use of the "knowledge" element (e.g. password). We ask that clarification be given, also by means of example, as to which types of measure referred to. In particular, whether the mitigating measures are taken to be specific information relating to the protection of access credentials and non-disclosure to a Third Party (e.g. awareness and education of the customer). Obviously the banks are unable to control customers' behaviour regarding the proper management and protection of their passwords."
We agree with the EBA's decision to allow the ASPSP's maximum flexibility with regard to procedural and technological aspects, regarding the various methods of dynamic linking. We also consider it appropriate to use the same approach for the question of the segregation of environments (channel, device, app) in which payment data is obtained, and in which the strong authentication procedure is carried out through dynamic linking.

In this regard, Article 2(2)b appears to require that the channel/device/mobile app in which the information connecting the transaction to a specific amount of beneficiary is shown, needs to be independent or segregated from the channel/device/mobile app used to initiate the payment transactions. This requirement would remove for example the possibility of managing the generation of a token via embedded functionalities in the payment apps. This technology is currently the state of the art as regards security and user experience. Discontinuing it would have very negative repercussions and would in fact regress the user experience, as customers would have to go back to creating codes in one environment and copying them into another one.
Experience shows that in order to guarantee confidentiality, authenticity and integrity, there is no need for the separation of the channels of all the transmission and authentication codes to be added to the separation of the device or mobile applications for example, where the OTP is received via text, and payment is initiated via a mobile app on the same device).
There is also a need to bear in mind the different requirements of the corporate payments market compared to the retail customer market. Mass payments by businesses are initiated in environments protected by maximum security and with multiple authorisation levels, also through a single channel, and often without the use of a mobile device. The separation of channels would in such a case be a superfluous obligation that would not mitigate the actual risks.
In line with Rationale 26 we therefore ask that the second paragraph of the article be deleted (“The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction”).
Alternatively, it should be clarified that:
• the components needed to initiate the payment and generate/receive the authorisation code can be resident on the same hardware device and on the same application, provided they are segregated;
• with application", we refer generically to the software which may be resident on a PC and not necessary on a mobile device. We therefore propose that the term "mobile" be deleted.

Below are our observations on specific points:
• We suggest using terminology that distinguishes the authorisation phase of the transaction from the customer authentication phase. One possible way is to differentiate the “strong transaction authorization” relating to the procedure that guarantees the authenticity of the transaction, from the “strong customer authentication” which refers more specifically to the authentication of the customer's initial access. The procedures, operational contexts and user experiences of the customer authentication phase can differ considerably in the payment authorisation phase. It is therefore suggested to align the RTS terminology to different circumstances;
• Article 2(4) requires that dynamic linking is also applied to multiple payments. Article 2(1), however, indicates that the payer always has to be aware, throughout the authorisation phase, of the amount and beneficiary of the payment. In our opinion it should be clarified how these two indications can be reconciled considering that typically, multiple payments can contain thousands of payments, and making this level of detail evident to the payer at all times would not be practical.
• There is a need to clarify what is meant when Article 2(4) says that the beneficiaries of a batch should be “considered collectively” and how to connect the ”authentication code” to multiple provisions involving a number of different beneficiaries. Moreover, at the end of Article 2(4) it could be appropriate to add ‘if applicable’ for the same reasons explained in Question 1;
• We propose amending the phrase in Article 2(2)a from “… Any change to the amount or payee shall result in a change of the authentication code.” to “… Any change to the amount or payee shall result in an invalidation of the authentication code.” This would give a more neutral position in accordance with the provisions of paragraph 3.2.1 – Rationale 24, thus enabling the development of alternative solutions that would reuse those currently available (such as the use of a digital certificate to sign information about the amount and beneficiary of the transaction);
• Also in Article 2(2)a we propose eliminating the term “confidentiality”, which is onerous but not necessary to guarantee that “..any change to the amount or payee shall result in a change of the authentication code.”
• We request a better specification of the definition of “separated trusted execution environments” contained in Article 6(3)a so that solutions can be developed that meet the stated requirement."
We do not see any other threats that would have a major impact other than those represented in the articles.

As already observed in reply no. 1, we believe that the detailed indications expressed in Articles 3-5 of the Draft RTS should be considered as non-binding examples for the PSPs, so as to give them the discretion to use the most appropriate security solutions based on a risk-based approach that considers the proper balance between the level of security, risk, and the user experience. As confirmation that the indication of best practices instead of obligations, to be applied independently of the context, is the most appropriate approach to support the pace of innovation, we point out that Articles 3 and 4 appear to refer to specific technological components such as passwords or token generators and are therefore not applicable to innovative, emerging solutions such as the use of images and pattern selection. In particular, it is not clear what is added by the requirement for “non-repeatable characters”, considering that the “complexity” requirement is already sufficient. Nor has it been demonstrated that non-repeatable characters raise the security level of a password, while on the contrary, trivial sequences of different characters are not secure. One best practice in this area could be the definition by the ASPSP of its own policy on the setting of valid passwords and on the related validity checks.
Also, Article 5 does not consider the case in which the device and the software able to read the inherence" elements are not supplied by the PSP but are already in the possession of the user, as for example in the case of fingerprint readers, which have been incorporated into the latest smartphones.
Finally, we would like clarification regarding the PSPs' obligations regarding the requirement to “ensure the protection of the confidentiality and integrity of PSCs, authentication device and software” (Rationale 22 (a) and Article 6(2)). This requirement should not entail any responsibility for the PSP regarding the checking of the security status of the user's devices in order to manage the access credentials. For example, in the case of token software being used through stand-alone or embedded apps, it should not be the responsibility of the ASPSP to guarantee the security of the device or the environment in which those apps are installed. That responsibility should be given to the producers, for whom a specific certification based on the EBA's technical standards, could be required.
We acknowledge that the regulations have placed particular emphasis on the use of behavioural analysis in order to activate blocks, particularly for payments initiation. It may be useful to allow the use of behavioural analysis techniques, which could also be used to graduate security measures based on risk level."
Articles 97(1)b and 97(3) of PSD2 require the exemptions from the application of strong customer authentication to be identified also on the basis of the service risk level. In Rationale 54, the EBA, while recognising the merit in implementing a transaction risk-analysis as part of the strong customer authentication procedure" concludes that in order to ensure "fair competition among all PSPs", it would not be appropriate to propose exemptions based on a risk analysis.
ABI invites the EBA to reconsider this approach, and hopes for the inclusion of exemptions based on a risk analysis:
• In a scenario in which strong customer authentication is generally mandatory for all e-payment instruments in a wide range of operational contexts, the risk analysis of the payer's transaction executed by the ASPSP can fulfil the important task of facilitating the user experience and improving the offer of payment services. It is known that PSUs welcome easy-to-use payment instruments which do not involve complex authentication procedures. Therefore, the more sophisticated the risk analysis of the transaction, the greater the possibility for the ASPSPs to identify solutions that make the frequent use of the service more attractive to users. The objective of the "fair competition among all PSPs" does not justify the elimination of a significant element of improvement, which on the contrary should be preserved and incentivised.
• Many of the efforts involved in the technological innovation of payments are directed towards finding increasingly sophisticated, rapid ways to identify the risk of a transaction. If there is no longer the possibility of applying the results of those efforts to exempt strong customer authentication, this will inevitably reduce the propensity of PSPs to make investments in this promising area of research and development.

• Transaction risk-based analysis is by definition a dynamic process timely reacting to new threats. This technique is the most suitable to ensure the prompt upgrade of countermeasures when unexpected weaknesses appear, and to maintain the continuous safeguard of high security levels.

It is true that the set of information to be used in the risk analysis is very varied. Thanks to technology developments, the criteria are continuously evolving as they are related to the availability of new information that, when combined in a variety of ways, allows the dynamic identification of risky transactions. However, the RTS should not avoid the indication of high level parameters, preserving the ASPSPs' freedom to apply a risk analysis based on their own predefined risk propensity policies. The set of possible mechanisms could include information about the device (identification of the device or browser), the method of connection (e.g. IP geolocalization), the payer's profile and past behaviour, the characteristics of the transaction (the amount, reputation of the beneficiary, urgency, total amount and time limit since the last authenticated transaction), the analysis of big data and the reporting of suspicious transactions in the face of new types of fraud.
Also, we are in favour of an open list of exemption cases, in order neither to limit the evolution of technologies, nor lead to unjustified investments. Below we have suggested other cases in which the application of strong customer authentication does not reflect the actual security risk level, or is not feasible:
• Rationale 18. Together with the already excluded payments initiated by the beneficiary, it will also be necessary to exclude recurring credit card payments (such as use of a credit card to pay utility bills).
• All cases where the customer has not agreed to use (and does not have) online payment initiation functionality in the on line channel, but accesses to the payment account in consultation only mode, without any disclosure of sensitive payment data. In this case, the ASPSPs can avoid significant investments in making-safe payment accounts that cannot be the target of Internet fraud. As a consequence, we propose that the second part of Article 8(1)a [from “The application of strong customer authentication shall not be exempted” to “after the last day in which strong customer authentication was applied”] be applied only to online payment accounts that disclose sensitive data regarding payments, or which can be used to initiate payments.
• Payments carried out at POS with no keypad or monitor, both attended and unattended (such as parking meters, vending machines, petrol stations, systems/tolls on motorways etc.). Payment transactions at this type of terminal, which do not necessarily use contactless technology, meet the requirement for a user-friendly experience.

Starting from the assumption that the list of exemptions should neither be closed nor mandatory we consider, with reference to the exemptions already provided for in Article 8, that:
• the requirement for strong authentication to be mandatory in subparagraph 1 (a) to points i) and ii) on first access to an account and one month from the customer's last access, is overprotection compared to the risk of fraud. It introduces an impact and complexity (e.g. the system has to automatically calculate and store the time of the first access or non-access after one month of inactivity) which entails disproportionate costs and efforts, compared to the risk. Security measures that exclude strong authentication when sensitive payment data is not shown, as currently required by the EBA Guidelines on the security of internet payments, together with the requirement for dynamic OTP for each transaction, appear to be sufficient mitigating actions.
• The thresholds of €50 and €10 for individual payment transactions should be unified and be equal to the limit indicated in Articles 42 and 63 of PSD2, for low-value payment instruments. This alignment would confirm the position taken in paragraph 7.1 of the "Final guidelines on the security of internet payments" and would align the same limit of €30 with the simplified rules on low-value payment instruments and with the exemption from using strong authentication for online and via devices payment transactions, with a positive impact on user experience. In any case the €10 threshold appears to be excessively low compared to many cases in which instant payments are made via mobile telephones, where strong authentication appears to be disproportionate. The threshold of €50 for contactless payment transactions is however excessively high, considering that this is very close to the average ticket for card transactions in Italy.
• Also, the exemption for contactless transactions only, leads to a disparity of treatment compared to contact transactions done with the same cards, and therefore we do not understand the rationale behind this. We ask that the exemption for individual payment transactions can be applied on a discretionary basis for all card transactions.
• ASPSPs may -- on an optional basis -- set and offer to their customers a pre-defined “white list” of completely reliable payees (for example, electricity or gas providers). From such pre-defined list the PSU can choose the payee to which initiate the payment. Whenever an ASPSP offers such a service the scope of Article 8(2)a should be extended to the list of secure beneficiaries supplied by the ASPSP.
• With regard to the obligation of the payer's PSP to activate a strong authentication procedure if the €150 and €100 thresholds are exceeded, we consider that this could impact the most frequent users and could introduce an element of confusion into the user experience. Differentiated thresholds do not allow the payer to identify the logic underlying the requests for strong authentication.

We also require clarification of the following points:
• for access to information services (Article 8(1)a, or as it says in the requirement “to the customer's consolidated information”, it is not clear how this can be done when the customer relies on an AISP (see Article 22(5)a and 22(5)b) especially when the AISP has independent access;
• with reference to the "cumulative" amount, if the approach is confirmed we ask that clarification be given as to whether the accumulation needs to be calculated within a pre-set time period (day, month) or whether it is independent of the period of time in which the previous payment operations were executed."
We consider that the exemption from the strong customer authentication rules should be applicable on an optional basis, giving the ASPSPs maximum flexibility in determining the security level on the strong authentication procedures based on their own risk analysis, and in line with the existing procedures and methods. The ASPSP must therefore be able to apply the SCA even in exemption cases, if there is a fraud risk, and to exempt the use of the SCA in low risk conditions.
This principle should also be guaranteed in the light of the liability that PSD2 puts on the ASPSPs with regard to the execution of e-payment transactions (also in the presence of Third Parties).
The procedures for managing the life-cycle of existing credentials with banks already allow a major reduction in the risk of compromised identity or identity theft. The measures described appear to be onerous in certain parts compared to the effective risk and vulnerabilities, not very efficient with regard to the existing threats and attack methods (for example the need to mask the PSC data), technology-specific and with an adverse impact in terms of usability.
In line with the comments made on exemptions, we consider that a risk-based approach would be more effective.

Specific observations are given below:
• Article 13b The requirement for the PSP to digitally sign the software it distributes actually excludes the use of software available in other widely used stores. We therefore ask that this requirement be eliminated.
• We ask for greater precision regarding the fact that it is never possible for Third Parties to have unencrypted access to PSCs belonging to PSUs during the transit on their systems, particularly in relation to the provisions of Article 10.
• It would be appropriate to limit the provisions on the obligation to protect the user's customised security credentials (Articles 9 - 13). Leaving components of the PSCs unencrypted" is not always a risk, as is the case for example with regard to the user's ID code for accessing online banking, which is typically provided to customers and managed "unencrypted". We suggest that a specific exemption be included for this.
We also require further details on the following points:
• According to Article 10, in the contractual agreement between the provider of the acquiring service and the merchant, there should be clauses that guarantee that the merchant will activate and apply security measures to protect the data in accordance with Article 9, if the merchant archives, processes and transmits security credentials. It should be clarified in the RTS that the acquirer is not required to play an active role in checking the security measures taken by the merchant.
• Article 9(1)c EBA could explain the precise meaning of “secure and tamper resistant devices and environments”. If there is an intention to use “cryptographic devices”, also known as Hardware Security Modules (HSM), adopting this requirement could be difficult or not applicable at all, to scenarios in which cloud services are delivered and utilised. For example, we could mention devices such as mobile phones operating with NFC technology, which are not tamper-resistant (although the security is guaranteed by the overall process). Otherwise, the RTS would lose their technological neutrality."
We acknowledge that also with regard to the aspect listed in Rationale 63 of the Discussion Paper, the EBA has chosen to indicate high level principles, leaving it to the market to select solutions for the information and functionalities to be exposed, for the authentication mechanisms (especially in the case of automated access without user interaction, in the case of AISP), for the rules for the dialogue and interaction between the ASPSP and the PISP/AISP/PIISP. We consider that the proposed model is, with regard to many aspects, so complex (for example, identification) that it will cause additional difficulties in the design, implementation and delivery of innovative services instead of encouraging them, with an adverse impact on the end user.

With regard to the aspects of the draft RTS that relate to identification of the parties and the control of authorisation to operate, we note that:
• As these are technical implementing rules relating to PSD2 it is unclear, from a legal point of view, whether they have the power to bind the PSPs to fall within the scope of application of a primary regulation (eIDAS) in which there are no specific duties for them, as it is focused on public services and not on the payment services sector. Also from an operational point of view, the reference to eIDAS introduces additional elements of uncertainty because:
o the processes relating to the provision of certificates by qualified trusted service providers have not yet been defined (and we are not certain that they will be by 2018).
o The certificates would guarantee the identity of the Third Party but would not give any guarantee at all about the security processes they manage.
o The allocation of a registration code/number by the competent authorities in each Member State would be a fragmentation that would hamper standardisation.
o The certificates issued by the qualified trust service providers do not fulfil the function of ensuring that the Third Party (PISP/AISP) is authorised to operate at the time of the request. As the competent authority can revoke the authorisation at any time, it is not clear in the RTS whether the qualified trust service providers also have to accept responsibility to ensure to ASPSPs the real time validity of the authorization issued by the national competent authority, i.e. that the certificate is owned by a Third Party which is legally authorised to operate at that very moment that it makes a real-time access request to the ASPSP. This means that the qualified trust service providers would perform 24/7 online controls and monitoring PISP/AISP status on the national registers, or on a single register of PSPs, liaising with the competent authorities in that respect and would revoke the certificate as soon as the authorisation has been revoked. We consider that the eIDAS regulations need to be amended in this regard, for qualified trust service providers operating in the payments sector.
o Article 20: if the qualified trust service providers are responsible for the validity of the Third Party's licence to operate, a specific attribute needs to be added to identify if and when a Third Party is legally registered by the competent authorities.

With reference to the requirements for the communication interface that the ASPSP has to provide, we note that:
• The provision and offer of at least one communication interface (Article 19(1)) completely fulfils the obligations to provide access to the PISP, AISP and PIISP. Therefore any Third Party must adapt its services based on the communication interfaces made available by the ASPSPs for that purpose. In this sense, the Draft RTS achieves what was already indicated in point 63f of the Discussion Paper: “the minimum reachability requirements for each ASPSP to provide at least one interoperable interface serving all requirements of the RTS and compliant with PSD2 regulation, while AIS and PIS would have to adapt their services to the respective standardised interfaces used”.
• We do not consider it realistic to provide, a priori, all Third Parties with all the data currently available to customers, as this data is highly diversified and is calibrated to meet specific requirements of the target market. In order to avoid fragmentation and inefficiencies, it should be left to the market to decide which data and services can be shared, but within a general common framework which EBA could usefully set out;
• It could be useful that EBA clarifies which initiation services an APSPS is obliged to expose to a Third Party and when this obligation enters into force. All the initiation functionalities which fall in the scope of the PSD2 should be made available, excluding any obligation to leave access to Third Party to the associated component which is not strictly payment-related. An approach that would oblige to open access also to services regulated in commercial bilateral agreements, as for example mobile phones recharge or tickets where the payment is only a part of a broader service offered to the customer would not appear consistent with the stated objectives.
• The ASPSP are requested to provide high service levels (testing, support, publicised technical specifications etc.), which entail considerable investments without, in return, PISP/AISP being dependent on the existence of a contractual relationship with ASPSPs.

Specific observations are given below:
• Article 19(2) and 19(2)b: “the communication interface shall: enable PISPs and AISPs to “start the authentication procedure”; and “…throughout the authentication procedure”. It is not clear to what the “authentication procedure” refers, given that the “authentication” is normally part of the process. In any case it must be clear that the ASPSP is free to develop its own procedures without any technical constraints.
• Article 19(4): For security and confidentiality reasons, there should be no requirement for the technical specifications of the communication interface to be made available in the form of a publicly downloadable document. Documentation could be made available in a reserved ASPSP’s area on request, after verification of the PSP's identity.
• Article 19(5): The requirement for public disclosure with three months' notice of the changes has the following disadvantages: a) it does not allow the rapid implementation of changes; b) the specifications of new functionalities are often subject to change during the final test phases. For these reasons we suggest that this provision either be eliminated or the period be reduced to one month.
• Article 19(6): Guaranteeing, at no charge, the same support availability of the online platform for the user also for the Third Parties increases the operating costs with no obligation for the supported PSPs to develop and properly manage their interfaces with the ASPSP. Free support should therefore be limited to basic queries.
• Article 19(7): Guaranteeing the free unlimited availability of test environments for the Third Parties community increases the operating costs without equivalent obligations for the supported PSPs to develop and properly manage their interfaces with the ASPSPs. This provision is also a burden in terms of liability. Providing a secure test environment such as the communication interface equates to creating a new channel for external entry, which creates exposure to risks of fraud and cyber attacks. We therefore request that this provision be eliminated.
• Article 22(1)a: It should be clarified that the information provided to the Third Parties should be limited to information about the payment services by making direct reference to Article 67(2)d of PSD2 (the AISP “only access information on the designated payment accounts and on the associated payment transactions“).
• Article 22(4): it is very important to avoid that when a Third Party accesses the ASPSPs' systems it can mask or substitute the characteristics of the customer's connection (such as the IP number, fingerprint), with all the data that is essential in the antifraud systems especially in cases of phishing). We therefore ask that the text of this article be amended as follows: “......with the same information requested collected from the payment service user…”.
We agree with the aim to harmonize the Third Party – ASPSP communication. However, taking into account the huge variety of possible or already used applications, we think it is necessary to modify the term “ISO20022” with a more generic reference to ISO standards, saving the valid principle of referring to EU or international standards. The Article 19(2) could be changed into: “(Omissis) uses ISO elements, components or approved message definitions, if available, as well as standards of communication which are developed by other international or European standardisation organisations.”
As already mentioned there are legal and operational issues in referring to the eIDAS regulations for identification between PSPs. This scenario should legally be based on interventions on the primary legislation which should specify the responsibilities in the event of fraud and/or errors or irregularities in the identification process.
In any case, it is not possible to predict whether designated qualified trust service providers under the eIDAS provisions will be operational by October 2018. Also, it would be desirable for a control and supervisory body to be set up.
It would be appropriate to include an adequate test period.
Finally, the communication between PSPs should not be able to be distributed on devices controlled by the user, but should remain server-to-server.
In general, whichever the maximum number of accesses permitted by EBA, it is not clear why it is necessary to allow AISPs to access to the payment account information when it is not the customer himself who is actively requesting them. If the customer does not want to record his status through the AIS service, the AISP should not request access. Also, it must be remembered that in addition to the number of daily requests, there are other factors that may impact the availability of the service, such as the volume of data requested and the number of requests from different AISPs in the same timeframe.
[Other "]"
Voluntary non-profit organization; represents the Italian credit and financial industry in all international fora (EBF, EMF, EBIC, IBFed, etc. )
[Other"]"
promotes the knowledge and awareness of social values and actions inspired by the principles of sound and proper entrepreneurship, as well as the creation of a free and competitive market
Rita Camporeale