We are supportive of the EBA’s assessments on KPIs and the calculation of uptime and downtime, however, we have some comments in regard to some more technical level details.
The ASPSPs will designate their dedicated interface as a critical business process as they already do for the customer interface/proprietary channel. Therefore, the dedicated interface will be subject to the same high standards of uptime and availability as an online banking interface. Nevertheless, the Key Performance Indicators (KPIs) to monitor the performance of the dedicated interface will not necessarily match with the KPIs currently in use to monitor the availability and performance of Payment Service User (PSU) channels (eg online banking) as provided by an ASPSP.
Paragraph 21: with regards to the concept of ‘accuracy of information provided’ it should be clarified that the concept refers to the accuracy of KPIs.
Paragraph 24: comparison of availability and performance should be at channel level i.e. the channel chosen by the client. It is not appropriate to compare the API availability and performance with the best performing PSU interface, because by definition, a mobile banking interface will usually have a different access scope compared to the fully-fledged online banking interface. The first might allow only a limited access to the account and to limited types of transactions considered more appropriated for the user compared to the full online banking interface. Service levels and availabilities for interfaces differ by client profile based on customer’s targets and individual service level agreements – this is specifically the case for commercial clients. As a result, whilst the two should be separated and monitored separately, we propose that this is taken into account in the monitoring approach adopted by ASPSPs. This will allow ASPSPs to achieve comparable performances between the dedicated interface and PSU channels but only after a considerable usage period of the dedicated interface. Each ASPSP channel/segment has its own SLA/KPI, therefore the comparison of the API performance can be done only with the specific channel/segment which should be selected by the ASPSP based on the brand/channel.
Guideline 2.3: We agree with the proposed guidelines, which are in line with the Opinion on the RTS. Also, we understand that when confirmation of funds via yes/no message cannot be provided by the ASPSP, the additional information to be provided are limited only to what is needed for the execution of the payment. Allowing access to any other data would be against requirements on data minimisation or consent.
Guideline 2.4.:The service level should be measured over a longer time period, for example, averaged over a month, rather than each 24-hour period, to provide a more reliable metric. The reference time period is important to ensure that the dedicated interface is subject to high standard, and possible “underperformance” is not triggered inappropriately or unnecessarily, particularly taking into account the reality of unexpected downtime. Unexpected downtime could possibly affect the dedicated and user interfaces at different moments (i.e. in different 24-hour periods). In such case the dedicated interface could register “under-performing” metrics in a 24-hour period while it could even significantly exceed the user interface service levels over a longer time horizon. The use of a longer time average in Article 2.4(a) of the Guidelines instead of 24 hours, would implement a high threshold for the dedicated interface but reduce the number of “false positives”.
We would also like to draw attention to the fact that during very quiet periods or at low volume ASPSPs it might take several hours for downtime to be registered as it might take several hours for 5 consecutive requests to be received. When is the interface considered to be up again, after a period of downtime? How is this to be measured? More guidance needs to be available on how availability can be measured when the dedicated interface is not receiving requests.
The definition of “down” for the user interface is not clearly defined and there are likely to be substantial differences in interpretation among different ASPSPs, which could generate confusion and inappropriate comparisons. For example, some ASPSPs might consider their user interface to be “down” if one particular functionality is not working, while another may only define their interface as down if the entire system is offline. The guidelines do not take into consideration the possibility of partial availability. How should partial availability impact the KPIs? How should partial availability be measured?
Guideline 3:We would like to express our concerns regarding the publication of service level information on all of an ASPSP’s other user interfaces. This information is sensitive as reveals competitive information and should not be publicly available. The publication of absolute value statistics would allow a comparison of the performance of each ASPSP towards its customers, which is not only commercially sensitive, but would also favour cyberattacks. If a bank would be exposed to, for instance, a Distributed Denial of Service (DDoS) attack; the effects of such an attack would then be included in the publication, potentially putting at risk the cybersecurity infrastructure of the bank. The institutions behind the attack are then able to evaluate the success of their actions and adapt their processes thereafter. • Additionally, such requirement would also go beyond the scope and spirit of the RTS, whose aim is to allow NCAs to assess whether the performance of the dedicated interfaces towards TPs is equivalent to the user interface, and not to disclose the relationship between ASPS and their clients.
We would therefore suggest publishing percentage values comparing the availability of the user interface and the dedicated interface.
ASPSP’s should only be obliged to report service level information on their dedicated interface to their Competent Authority ex post, together with the reporting of the other relevant service levels, permitting Authorities to confirm their compliance with the RTS and Guidelines
Therefore, we suggest amending the Guidelines according to the following proposal:3.1 For the purpose of Article 32(4) of the RTS, the ASPSP should report to its competent authority:a. statistics percentage on a quarterly basis on availability and performance as set out in Guideline 2.2 and 2.3 for the dedicated interface and each payment service user interface together with information on where these percentage statistics will be published and the date of first publication. Access to further information shall be restricted to Comptetent Authorities
We agree with the proposal not to explicitly include testing such as security and penetration testing that is already part of an IT assessment
We do agree with the assessment that monitoring by CAs cannot be considered a criterion for granting an exemption to an ASPSP and it should be limited to compliance.
We agree in principle with the EBA assessment, however we suggest the authentication terminology in the Guidelines to be reviewed to improve clarity and ensure consistency with the EBA Opinion. In particular, we agree with the EBA that ‘redirection’ is not in itself an obstacle. We are of the strong view that a well implemented dedicated interface which makes use of redirection is best for the customer, the ASPSP and the best way to encourage new market entrants to create AIS and PIS services.
Guideline 5.1 a. refers to ‘method of access’ to address what the EBA opinion of 13 June refers instead to ‘authentication procedure’ as per the ‘methods of carrying out authentication procedure of the PSU trough a dedicated interface, and API in particular, namely redirection, embedded approach, and decoupled approach’. We suggest aligning the wording of the two texts to ensure legal certainty. Any further interpretation of such provisions should be left to Competent Authorities.
We would suggest using similar language in the Guidelines as in the Opinion, e.g. refer to: methods for carrying out the authentication procedure.
We agree with the EBA’s assessments for design and testing.
Paragraph 52/53: It should be explicitly mentioned also in the text of the guidelines that testing is performed on a dedicated test environment for which service levels differ from production or live environment.
It is worth mentioning that testing can only be done with registered/authorized TPPs or those that are in the process of getting a license/registration (Art. 30.5 RTS).Therefore ASPSPs should not be required to make available the testing facilities before an authorisation is granted, considering the resources that will be required for the testing on both sides. The requirements to publish and make available changes in the test environment before going to production applied to new products and innovations could severely impact the ability for an ASPSP to innovate, disrupting the level playing field if the intention that any innovation by the ASPSP must always be made available to all the TPP’s in the marketplace in advance of the actual introduction into the marketplace.
Even the availability of the technical specifications before authorisation should be reconsidered to avoid unnecessary diffusion of elements that could result in a fraudulent behaviour or attempts from non-authorised PSPs to access customers’ payments accounts.
Paragraph 55-59: We support the EBA’s assessment that the requirement ‘widely used’ is difficult to assess prior to 14 Sept 2019 and also should be specific to each Member State. We welcome the alternative proposal for this specific period for ASPSPs to prove/document the measures taken to publicise and encourage testing and usage of the API. Whilst it is the intention of ASPSPs to have the API up for testing well in advance of the minimum testing period, it is clearly beyond an ASPSPs direct influence upon TPP to make use of this testing environment as well as production interface prior 14 Sept 2019.
Guideline 7.1 : We would like to stress that to comply with guideline 7.1. certificates for the testing phase are needed.
Guideline 7.2: We would suggest that the evidence the ASPSP are mandatory requested to provide is limited to publications on the ASPSPs’ websites or channels. The other ways of publicising their interfaces should clearly be indicated as further options left to the policy of each individual ASPSP.
We support the EBA’s assessment that the condition of the sufficient resolution of problems is to be seen in the context of testing.
We support the EBA pragmatic approach and welcome the temporary provisions to ensure a timely processing of exemption requests prior to Sept 2019.
Nevertheless, from our point of view, the mechanism to oppose a negative decision should also be described and harmonized by the Guidelines. There should be clear timelines for acknowledgement and response of the exemptions, especially given the short deadlines which are imposed on both NCAs and the industry.
We would also welcome a clarification that ASPSPs who implement one API for TPP access across PSU interfaces in multiple countries or clients (e.g. retail vs corporate customers) will only have to apply for the exemptions for that API once with the NCA in the Member States where it has its registered head office.
We support the EBA definition of the envisaged timelines.
However, we are very concerned about the process and envisaged timelines for ASPSPs to develop an API and more specifically, the possibility for CAs to assess whether or not the ASPSP meet the requirements for an exemption according to article 33.6 in the RTS. Time is very short considering also that the PSD2 has not been transposed in all Member States yet and certificates are not in place (see ERPB statement), therefore that part of the dedicated interface cannot be finalised nor tested.
An ASPSP must be ready to publish the documentation on their websites already in the beginning of 2019 to meet the deadline in September 2019. Moreover, it has to be questioned, at least at this stage, if the CAs has the capacity to assess the upcoming applications. There is still an uncertainty on the administration time for local CAs which makes it difficult to understand and take into account the timelines for applications. This is especially important as any rejected exemption application leads to the need for develop a fall-back solution in two months’ time.
We agree with the overall level of detail.
Additionally, we would like to stress that:
the concept ‘accuracy of information provided’ should be further clarified
There is need for certificates for the test phase in order to comply with the guidelines. The timing issue is pressing and of high concern.
It should be clarified in the text that multi-country ASPSPs ask their home state NCA only for exemption