Publication of Statistics

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

As per the EBA Guidelines, the ASPSP must publish statistics for each PSU interface. Therefore an ASPSP with a separate website and mobile app for consumer accounts and a separate website and mobile app for business accounts may need to report separately to cover each of the four PSU interfaces (which may still be within a single report) .

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.

• AISP Response Time: The average time taken in milliseconds from when a logged in (i.e. authenticated) PSU clicks on a button or link to access any PSD2 in-scope payment account information on their account (e.g. list of accounts, balance for an account, page/screen of transactions) to when the page/screen displaying this information has fully loaded. Where this information is displayed immediately and automatically after login, this time should be measured from when the ASPSP has accepted the last factor of the PSU’s authentication (i.e. the load time of the first page/screen after authentication is complete). This should be the average for all pages/screens loaded 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.
• Confirmation of Funds Response Time: There is no direct comparison for CBPII and PISP confirmation of funds in a PSU interface, hence this column should be left blank.
• Error Response Rate: As per row 23 in the EBA consultation feedback table, this column is not required for a PSU interface and should also be left blank.

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:

OBIE ASPSP Reporting Template v3.1.10

Whilst ASPSPs are only required to publish statistics on their website and submit to FCA every quarter, OBIE recommends that non-CMA9 ASPSPs submit these reports (all completed Report Tabs) and also the detailed workings (the Data Tab) using this template to OBIE on a monthly basis. This will enable OBIE to track overall health and growth of the Open Banking ecosystem.

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.

TPP Reporting

OBIE encourages TPPs to report statistics on availability and performance to OBIE. Whilst there is no EBA/FCA regulatory requirement, OBIE would find this information very useful in providing a balanced view of the overall health of the Open Banking ecosystem. The format and method of this is still to be confirmed and sits outside this document.