Associazione Bancaria Italiana (Italian Banking Association) - ABI
In general, there is agreement on Rationale 20 and Rationale 23 of the CP in regard to the fact that the availability of the interfaces is compared by means of a minimum set of key performance indicators (KPIs). It is believed, nevertheless, that certain specific aspects regarding the method used to calculate such KPIs require further clarification, in particular the fact that the planned downtimes, whether they concern the dedicated interfaces implemented for the initial launch of 14 September 2019, or subsequent developments of them after that date, are not to be calculated for the purpose of the statistics to be provided to the Competent Authority (CA), so as not to negatively impact the percentage uptimes of the interfaces. This is particularly important as it favours the continuous development and refinement of the dedicated interfaces during a new market phase and guarantees the correct technical-practical functioning of what has been put in place.
Furthermore, in order to simplify and facilitate comparing dedicated interfaces with those available to the user, it is proposed that performance of the dedicated interface, and specifically any gap between the dedicated interface’s performance and the average performance of the user interfaces made available by an individual account servicing payment service providers (ASPSP), be calculated in percentage terms as an annual average on a quarterly basis. Specifically, this calculation should be able to be done at banking group level in the case of those firms that, operating at EU level, could be providing a single dedicated interface for all the group entities within the European Economic Area (EEA). Otherwise, if, within a banking group, interfaces are created and services are provided by each Legal Entity in a separate, independent manner, then the performance calculations must be made and set out separately.
With specific regard to the requirements concerning the publication of the KPIs, it is important that the figures remain restricted to the assessment made by the national Competent Authority in question instead of being openly published and divulged. In fact, despite being aware of the requirements regarding the publication of quarterly figures by ASPSPs set out in Article 32.4 of the RTSs regarding Strong Customer Authentication and Common Secure Communication (RTSs), a closer analysis of the document in question and the consideration of such requirements, together with the addition of greater details introduced through the CP, led ASPSPs to appraise the costs and the complexity of such additions. More specifically, the confidentiality of the figures is supported by the fact that their publication is only required for the purposes of CA monitoring, and thus for the purpose of verifying that compliance requirements are met by each ASPSP hoping to benefit from exemption from the fallback option. If, conversely, the intent remains that of openly publishing figures to the market then it is very important that these are expressed, as previously mentioned, exclusively in percentage terms in virtue of the possible negative consequences, in competitive terms, of indicators that are not perfectly comparable between different ASPSPs throughout the EEA, and on the grounds that the dedicated interfaces may be subject to numerous processes of refinement in response both to legislative compliance and to market requirements.
There is general agreement with the key performance indicators (KPIs) envisaged by Guideline 2, in that they reflect the essential features to be guaranteed in the provision of services to the user (payment service user – PSU). However, the following critical aspects should be taken into due consideration:
1) The unit of measurement for the downtime calculation in seconds could prove overly burdensome in both financial and technical terms, and could have a considerable impact on the performance of the systems to be monitored. Furthermore, the KPI calculation must distinguish more clearly between planned and unplanned downtimes. More specifically, planned downtimes, whether regarding those dedicated interfaces created for 14 September 2019 or the relative updates of them thereafter, must not be included in the figures provided to the Competent Authority (CA), so that they do not negatively impact the percentage uptimes of the interfaces. On the other hand, these planned downtimes are generally limited to a maximum number of hours of unavailability. Insofar as it is deemed of essential importance, the planned downtimes may be notified separately to the CA.
2) It is not clear what the acceptable gap may be between the levels of performance achieved by the interface dedicated to TPs, and the benchmark standards of the interfaces available to the PSU, and which time range is to be taken into consideration. Specifically, we ask that confirmation be given of an acceptable downtime of 120 seconds more than that of the PSU’s interface calculated on an annual basis, and that it is possible to calculate it in percentage terms as an annual average on a quarterly basis.
3) In order to determine the response times of the dedicated interface, we request that the calculation does not include any possible factors external to the interface itself, such as, for example: network connectivity between the interface and the TPs, the performance of the TPs’ systems, the response times of the QTSPs (Qualified Trust Service Providers) or of the TP’s national Registers in regard to authentication using eIDAS certificates or verification of the TPs’ authorisation/registration, any downtime periods due to hacker attacks (e.g. DDOS) or to any other events not directly related to internal problems. Therefore, confirmation is requested of the fact that consideration should only be given to those response times that fall within the interval between the request received by the account servicing payment service provider (ASPSP) from an already authenticated TP whose authorisation/registration has been verified, and the response given by the ASPSP, regardless of the TP’s receiving times.
4) The performance levels of the dedicated interfaces may vary depending on the observation period (month, day, time) of the statistics and on the quantity of data to be transmitted per individual PSU or per individual transaction. Thus confirmation is requested of the fact that the values to be taken into account are those pertaining to the annual average of transactions, and not the absolute best figure recorded during the year.
In general terms, the KPIs used to monitor the interface’s performance may not correspond exactly to those currently used to monitor the availability and performance of direct PSU channels. Specifically, each of the ASPSP's channels, back-end systems, reference markets and customer segments possesses its own SLA/KPI, which may differ from one ASPSP to the next and between entities within the same banking group operating in different countries, resulting in a greater or lesser penalisation depending on the quality of measurement achieved. For these reasons, it is deemed inappropriate to compare the availability and performance of the dedicated interface with those of the best performing PSU interface, whereas it is hereby proposed that performance be calculated in percentage terms, and specifically any gap of the dedicated interface’s performance level from the average performance level of the user interfaces of the individual ASPSP, be calculated as an annual average on a quarterly basis. Specifically, this average should be calculated at banking group level in the case of those firms that, operating at EU level, could be providing a single dedicated interface for all group entities within the European Economic Area (EEA). Otherwise, if, within a banking group, interfaces are created and services are provided by each Legal Entity in a separate, independent manner, then the performance calculations must be made and set out separately, rather than at the group level.
Furthermore, the current performance of an ASPSP’s online and home banking channels is the result of the refinement achieved by means of a gradual process of improving the service on the basis of the actual use of the channels themselves by the PSU, and only a calculation expressed in percentage terms can facilitate the actual comparison between the comparable levels of performance of the dedicated interface and the direct PSU channels.
With specific regard to the publication requirements set out in Guideline 3, it is of the utmost importance that the figures remain confined exclusively to the appraisal by the national CA concerned, and must not be made public.
In fact, despite being aware of the requirements regarding the publication of quarterly figures by ASPSPs set out in Article 32.4 of the RTSs regarding Strong Customer Authentication and Common Secure Communication (RTSs), a closer analysis of the CP and the consideration of publication requirements in the light of the greater details introduced through the CP, led ASPSPs to appraise the costs and the complexity of such additions.
More specifically, the confidentiality of the figures is supported by the fact that their publication is only required for the purposes of CA monitoring, and thus for the purpose of verifying that compliance requirements are met by each ASPSP hoping to benefit from exemption from the fallback option. If, conversely, the intent remains that of openly publishing figures to the market then it is even more important that these are expressed, as previously mentioned, exclusively in percentage terms in virtue of the possible negative consequences, in competitive terms, of indicators that are not perfectly comparable between different ASPSPs throughout the EEA, and on the grounds that the dedicated interfaces may be subject to numerous processes of refinement in response both to legislative compliance and to market requirements.
Furthermore, in the case of major ASPSPs, disclosure requirements would entail the ASPSPs bearing increased costs, as they would have to manage a greater number of interfaces made available to the customer. In this regard, it would be advisable to establish a maximum number of interfaces to be compared, chosen on the basis of factors such as the number of customers using the interface, the date of its creation, and so on.
Finally, we agree with the suggestion that early disclosure could overlap with the phase of interface testing, and could thus render any comparison of performance unfeasible. Therefore, it is requested that the KPIs only be calculated from the date the RTSs come into effect on 14 September 2019, and that Q1 2019 be considered as the first period of observation in line with the proposed quarterly base of calculations.
We agree with the EBA’s overall proposal. However, the timing and manner of the stress tests should be specified in greater detail, and in particular it should be established whether such tests are to be carried out only in view of 14 September 2019, or whether they should be carried out also in the event of future important changes to the dedicated interface.
We agree with the fact that the CA is appointed to monitor the interfaces. Furthermore, we believe that if monitoring shows that the ASPSP has achieved the service levels indicated, this may represent a further possible factor in favour of the ASPSP for exemption from the fallback option.
Overall we agree with Guideline 5, and in particular, as far as concerns verification of the adequacy of the ASPSP’s choice of access method(s), the fact that the CA concerned has to consider the final user’s overall experience and the degree to which the chosen access method impacts the user’s experience or creates delays and hindrances in the customer’s payment process, is greatly appreciated. Thus we have a favourable view on the fact that in order to avoid the customer’s journey and users’ experiences being directly or indirectly affected, and to guarantee a level playing field, a free choice of access method has been granted.
Finally, we agree with the transmission to the CA of a detailed explanation of the workings of one or more access methods available at the ASPSP, and of the reasons why these access methods do not represent a hindrance to the PSU. Nevertheless, in virtue of the burdensome nature of this obligation, the EBA is requested to identify more streamlined modalities should an ASPSP only offer one available direct PSU channel.
Within the context of testing and designing the interfaces, and with specific regard to Rationale 45 and to the previously-mentioned Article 30.5 of the RTSs, it should be noted that the testing due to start on 14 March 2019 must be launched with regard to both enterprises that are already authorised/registered and those that have applied for the corresponding authorisation/registration. However, the CP once again refers to this requirement, by introducing in Rationale 46 the further point that the CA’s mere confirmation of receiving an application for authorisation from a Third Party (TP) is not in itself a guarantee that the TP will actually being granted authorisation. In view of this, it is considered risky to offer access to a party who, although having applied for authorisation/registration, may, in fact, not be authorised/registered and could therefore gain undue access to documents and testing facilities, to the detriment of the ASPSPs and the enterprises with proven authorisation/registration. Thus, verification of the necessary requirements for a TP to obtain authorisation/registration is requested to take place as soon as possible, in time for the preliminary testing procedures to be launched on 14 September 2019.
In addition to the foregoing, and in the event that the timescale for authorising/registering TPs is not compatible with the testing period, given the large number of activities required of the CAs in regard to various issues, it is worrying to note that the certificates to be used to identify the TPs during preliminary testing prior to the launch of the dedicated interface on 14 September 2019 may not be available, which might not only make it difficult to actually carry out the tests in an effective and timely manner, but might also entail greater risk associated with the inability to recognise and verify the TP calling the tested service. It is therefore requested that testing is done exclusively with enterprises possessing, at the very least, the certificates required for their identification.
We agree in general with the provisions of Guideline 6. However, as specifically regards the testing and design of the interfaces, we would point out the following:
• With specific regard to Rationale 45 and to the previously-mentioned Article 30.5 of the RTSs, it should be noted that the testing due to start on 14 March 2019 must be launched with regard both to enterprises that are already authorised/registered, and to those that have applied for the corresponding authorisation/registration. Nevertheless, in view of the fact that the CP explicitly mentions (Rationale 46) that the CA's mere confirmation of receiving an application from a TP is not in itself a guarantee that the authorisation/registration will actually be granted, it is in fact considered risky to offer access to a TP who, although having applied for authorisation/registration, may, in fact, not be authorised/registered and could therefore gain undue access to documents and test facilities, to the detriment of the ASPSPs and the enterprises with proven authorisation/registration. Thus it is hereby requested that preliminary testing be commenced in view of the launch of 14 September 2019, exclusively with enterprises possessing, at the very least, the certificates required for their identification, thus limiting the likelihood of accesses that are not actually authorised, and guaranteeing adequate levels of internal security on the ASPSP side.
• In addition to the foregoing, it is also worrying to find that the certificates to be used to identify the TPs may not be available for the start of the test phase prior to the market launch of the dedicated interface, in practice entailing greater difficulty in effectively carrying out the tests in time, and also the increased risk associated with the inability to identify and verify the TP calling the tested service. In this regard, particular attention should be paid to ensure that the TPs’ certification and authorisation requirements can be complied with in good time.
• Furthermore, despite agreeing on the fact that the tests ought to include the creation and maintenance of a connection, the exchange of certificates, the exchange of data and the flow of error messages, it may be opportune to specify the minimum set of error messages that a service should provide for, bearing in mind that the error messages sent by TP to the ASPSP can be managed by the latter in a standard manner in communications with the TP.
• Finally, we request that it be clearly specified that the tests are to be carried out in a dedicated test environment whose service levels differ from those of a production environment. More specifically, we request confirmation of the fact that for the purposes of testing, the “PSPs’ satisfaction” is evaluated in terms of functionality rather than performance.
In general, we agree with the assessment expressed and the requirements set out in Guideline 7.
Specifically, with regard to the communication activities promoted by the ASPSP, in order to show that the market has been informed of the availability of the test interfaces, we suggest that it be explained that mandatory publicising only refers to the ASPSP’s channels and website, whereas it is left to the discretion of each ASPSP whether or not to publicise projects on other channels (e.g. advertising, social media, etc.), which are only mentioned in the CP as an example of what an ASPSP may choose to do, depending on its usual policy.
We also believe that in order to further facilitate this publicising activity, it may be useful to have one single EBA website where TPs may easily identify all ASPSPs, at the European level, available to perform interface tests.
In general we agree with what the EBA has envisaged, with the exception of the provision whereby the CA is informed of the systems and procedures put in place to manage problems and anomalies. Specifically, we would ask for clarification of what exactly is meant by “any problem” both for the purposes of granting exemption and after the RTSs come into effect on 14 September 2019. Furthermore, it would be advisable to clarify the definition of “problem” also in order to create synergies and avoid any overlap with the incident reporting obligations of the PSPs (in the light of the PSD2 and of the relevant EBA guidelines), and also to circumscribe sending detailed reports to clearly defined occasions.
Finally, with a view to rendering problem detection and report management more efficient, we would ask for greater details regarding the time required to resolve more or less “serious” problems, seen as excessively lengthy, also in view of the fact that reporting the problem has to include everything reported by the TPs, which in turn are called upon to make monitoring reports available on the functioning of services.
In this regard, since reports will include data pertaining to TPs, we propose that such information be forwarded to the CA only.
In order to render the entire process of granting exemption more pragmatic and harmonised for all the stakeholders, it is important that an ASPSP wishing to create a single dedicated interface for all of the countries in which it operates, is required to submit one single application for exemption from the fallback option at banking group level in the parent company's home Member State, and that this application is thus valid for every other country. This would allow considerable benefits to be gained in terms of both the submission timescales and management of applications and the certainty of entities within the same banking group being treated equally across the various countries in the EEA, thus reducing the ASPSP's costs and complexity of gathering and transmitting documents.
In this same spirit of pragmatism and simplification, the suggestion is to make explicit reference to standardised, cooperative solutions or, in any case, to solutions adopted by several counterparties, in regard to the dedicated interfaces. In such cases, it is suggested that a simplified application process could be followed , insofar as is possible, whereby both the certification of the compliance of the dedicated interface, and the requirement of “widely used”, are assessed at the level of the standardised/cooperative solution, and the exemption application process for the individual ASPSP using that solution is suitably simplified.
In general we agree with the proposals set out in Guideline 9. More specifically, the following points should be noted:
• We appreciate the fact that in view of the considerable number of applications to be managed for exemption from the fallback option, the EBA has devised a very pragmatic process for both CAs and CA consultation with the EBA
• However, in order to ensure greater market harmonisation and the increased harmonisation of the specific activity of ASPSPs working Europe-wide, the CA would be advised to provide details of a window within which the ASPSPs are to submit their exemption applications, so as to also facilitate the timely preparation of the information to be transmitted (Guideline 9.1)
• For the very same reasons, we have a favourable view on the idea that the ASPSPs operating at the European level (and that implement, for example, a single dedicated interface for TP access in several countries) may request a one-off exemption from the CA in their home Member State which is valid for all entities within the same banking group operating in the European Economic Area.
• We also have a favourable view on the EBA’s proposal concerning the need to adopt a pragmatic approach to the process of verifying and granting an exemption to an ASPSP. In this regard, in order to streamline the procedures for verifying the requirements to grant a fallback option exemption, we suggest that specific reference be made to standardised, cooperative solutions or, in any case, to solutions adopted by a number of different counterparties. In such cases, provision could be made, insofar as is possible, whereby both the certification of the compliance of the dedicated interface, and the requirement of “widely used”, are assessed at the level of the standardised/cooperative solution, and the exemption application process for the individual ASPSP adopting that solution is suitably streamlined.
Furthermore, it is suggested that this simplified application process could all the more be followed by ASPSPs that adopt a cooperative solution after March 2019, thus allowing minimising the phase of diverse solutions coexisting during the test period.
• Finally, with a view to possible cases of revoking the fallback exemption, in the long term the CA’s willingness to open a dialogue on this matter would help the ASPSPs understand the reasons underlying revocations.
There is a strong concern regarding the timing of the final publication of the Guidelines and other relevant legislation and thus the actual time available to the ASPSPs to bring their systems, processes and procedures into line with the requirements for the purposes of exemption. In this regard, greater clarification regarding the deadlines that the ASPSPs have to meet to apply for exemption would be greatly appreciated and would help more effective and efficient planning in support of the shared objective of compliance with the foreseen deadlines and legislative requirements.
There is a strong concern regarding the timing of the final publication of the Guidelines (and other relevant legislation, e.g. at national level, as mentioned below) and thus regarding the time remaining available for ASPSPs to bring their dedicated interface into compliance with the requirements for the purposes of exemption.
In fact, on the basis of past experience of consultation within the PSD2 framework, the timescale could be further protracted owing to the considerable number and complexity of the responses to this consultation process, which could require more time for the EBA to consider them, and this could delay publication of the final Guidelines.
Furthermore, the timescale also depends on the process to implement the Guidelines, which requires each individual CA to express a position on compliance at the national level, which could entail the introduction of amendments requiring further/ diverse adjustments in order to reconcile local specifics.
Therefore, despite noting and welcoming the willingness to accommodate market divergences that has characterised the actions taken to date, the main concern expressed here regards the fact that implementing such provisions depends largely on factors beyond the direct control of the ASPSP, and this is aggravated by the need to reconcile constant legislative adaptations and to obtain exemption from the fallback option, in order to guarantee the proper functioning of the interfaces, by 14 September 2019.
Thus we ask for confirmation of the fact that all requirements and the corresponding interpretative guidelines, thus including the consolidation of requirements regarding TP identification certificates and the implementation of these Guidelines by the CAs, are made definitively available within an adequate period of time, and in any case no later than 31 December 2018, in order to allow the completion, in good time, of all that has to be provided for.
In general, the level of detail in these Guidelines is deemed adequate, and it is hoped that a correct balance be achieved following consideration of the observations made under the preceding points.