Availability and performance

Availability

This version is:

This is the latest version Published 5 months ago 28 Jun 2024

EBA Guideline 2.2 sets out a minimum of two KPIs for availability that an ASPSP should have in place for each of its dedicated interfaces. EBA Guideline 2.4 provides information on how to calculate these KPIs. The following table explains these KPIs in greater detail and provides further guidance on how they should be calculated.

Other pages in this section

EBA Guideline 2.2 sets out a minimum of two KPIs for availability that an ASPSP should have in place for each of its dedicated interfaces. EBA Guideline 2.4 provides information on how to calculate these KPIs. The following table explains these KPIs in greater detail and provides further guidance on how they should be calculated.

TPPs may consider that a dedicated interface is only available if it is responding to all valid TPP requests a) without error messages and b) that have received a successful response from the ASPSP, for example returning the data required to be provided to an AISPs under PSD2. Open Banking Limited (OBL) has catered for error messages under section ASPSP reporting template, and data quality under section Stress Testing below.

Reference
Title
EBA requirement
OBL calculation guidelines
OBL recommended benchmark

EBA Guideline 2.2 a

The uptime per day of all interfaces

…the ASPSP should:

a) calculate the percentage uptime as 100% minus the percentage downtime;

For each 24 hour period, 100% minus the total percentage downtime in that period.

A quarterly uptime of 99.5%.

EBA Guideline 2.2 b

The downtime per day of all interfaces

b) calculate the percentage downtime using the total number of seconds the dedicated interface was down in a 24 hour period, starting and ending at midnight;

c) count the interface as ‘down’ when five consecutive requests for access to information for the provision of payment initiation services, account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs, AISPs or CBPIIs. In such a case, the ASPSP should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds, provided that there is no successful request in between those five requests to which a reply has been provided.

Downtime should be calculated as follows:

  • The total number of concurrent seconds per API call, per 24 hour period, starting and ending at midnight, that any element of the dedicated interface is not available divided by 86,400 (the number of seconds in 24 hours) and expressed as a percentage.
  • The clock for unavailability should start immediately after the first ‘failed’ request has been received within the 30 second timeframe.

At a minimum, downtime should be measured if:

  • Any ASPSP authorisation and/or resource server is not fully accessible and accepting all valid TPP requests as defined by EBA Guidelines 2.4c.
  • Any ASPSP downstream system required to support these API endpoints is also not responding in a way which effects the availability of the ASPSP authorisation and/or resource servers.
  • Any of the ASPSP screens and/or functionality of the PSU authentication flow is not available to enable PSUs to grant TPPs access to their account(s).
  • This should include all 5xx errors.
  • This should include both planned and unplanned downtime during each day.
  • Even if this only effects some TPPs and/or PSUs, downtime should still be reported, i.e. partial downtime should still be measured as downtime.
  • This should include any vendor/supplier failures in the case where the ASPSP has contracted the vendor/supplier to deliver a related service, e.g.
    • the ASPSP’s own hosting provider,
    • any QTSP the ASPSP has selected for their own certificates,
    • a third party directory service (e.g. the Open Banking Directory).

However, this should exclude errors resulting from issues outside of the ASPSP’s direct control, such as any of the following:

  • Issues with TPP software, infrastructure or connectivity.
  • Lack of response/availability from an individual QTSP resulting in the inability of the ASPSP to check validity of a TPP’s eIDAS certificate, since it is the TPP who has selected the QTSP.

The above guidelines relate only to how ASPSPs should calculate downtime. ASPSPs must be mindful of their own regulatory obligations under the PSD2 regulatory framework and eIDAS Regulation.

A quarterly downtime of 0.5%.

Circa 11 hours per quarter, or just under four hours per month, to allow for planned releases, updates, and also any unplanned downtime.