EBA Guideline 3.1 requires that ASPSPs “… provide its competent authority with a plan for publication of daily statistics on a quarterly basis on the availability and performance of the dedicated interface as set out in Guidelines 2.2 and 2.3, and of each of the interfaces made available to its own PSUs for directly accessing their payment accounts online, together with information on where these statistics will be published and the date of first publication…”

In addition, the FCA PSRs Approach Chapter 13 requires ASPSPs to report these statistics to the FCA on a quarterly basis.

These statistics should be completed for each dedicated interface. In the case where an ASPSP has one dedicated interface per brand, then the ASPSP should publish a separate report for each brand. However where several brands share the same interface, then the ASPSP should only need to publish one report. In the case where an ASPSP maintains different versions of their dedicated interface in parallel (e.g. to support different versions of the OBIE Standard), then these should be considered as separate dedicated interfaces and published separately, as they may have different levels of availability and performance.

Reporting for PSU Interfaces

In this regard, ASPSPs are only required to report on PSU interface for PSD2 in-scope accounts and regarding PSD2 in-scope functionality (i.e. initiation of a credit transfer payments and/or accessing account and transaction information). In order to enable a ‘like for like’ comparison, OBIE recommends the following guidance for calculating each element in regard to PSU interface availability and performance:

• Uptime: 100% minus the total percentage downtime for each day.
• Downtime: The total time in seconds for each day when any element of the PSU interface is not accessible by the PSU in the process of accessing their PSD2 in-scope account, and in order to access PSD2 functionality. This should be divided by 86,400 (the number of seconds in 24 hours) and expressed as a percentage. PSU accounts which have been blocked by the ASPSP should not be counted as downtime, as it is the downtime of the service, and not the individual PSU’s access, which is relevant here.
• PISP Response Time: The average time taken in milliseconds from when a PSU clicks on a button or link to initiate a payment (i.e. after they have supplied all details and clicked “confirm payment”) to when the PSU receives either a confirmation screen or error message to confirm the status of the payment initiation. This should be the average for all PSU payments initiated each day for each PSU interface. OBIE recommends that the time is reported based on the time taken for the page/screen which contains the confirmation/error message to fully load.

ASPSP Reporting Template

OBIE has included a template that ASPSPs using the OBIE Standard might find useful in preparing their information for publication and reporting to the FCA (or other CA) from September 2019:

Where ASPSPs support more than one major or minor API version in production, each version must be reported separately. For example, v3.0 and v3.1 must be reported separately. However patches, for example v3.1.1, should be reported as aggregate together with the relevant major or minor release (i.e. together with v3.1).

For the avoidance of doubt, the reports that the CMA9 ASPSPs are mandated to provide to OBIE are detailed in a separate MI template and not covered within this document.