Downtime

Downtime is defined in section Availability

Planned downtime, by its nature, is something that an ASPSP anticipates and therefore is able to give advance notice to TPPs. It is not generally possible to give advanced notice of unplanned downtime, but ASPSPs should give notice as soon as they are aware of the downtime. The impact of any downtime can be minimised by an ASPSP informing TPPs as soon as the downtime is anticipated, when it takes effect and as soon as the service is reinstated. ASPSPs should therefore provide notice of downtime notifications which should be published on their own website or developer portal. When providing notifications, ASPSPs should provide a specific time period, so TPPs are aware that the dedicated interface will be unavailable for that time, or upon a subsequent notification to confirm that the service has been reinstated sooner than anticipated.

The final EBA Guidelines do not distinguish between planned and unplanned downtime. As such, when an ASPSP engages in planned downtime activities, these must be considered within the context of their obligations to ensure that their dedicated interface targeted levels of availability are at least as stringent as those for the PSU interface, including maintenance, problem resolution, out of hours support, monitoring and contingency plans. Planned downtime should not therefore be implemented in a way that it could impact the required target service levels for the dedicated interface.

OBIE Support Services can assist ASPSPs with the dissemination of downtime information to the wider Open Banking ecosystem via its central noticeboard facility. ASPSPs can provide advance notice for future planned downtime and submit real time updates related to downtime (planned or unplanned) that currently impact

TPPs and the subsequent reinstatement of service. It is not expected that ASPSPs raise tickets for very short lived periods of unplanned downtime (e.g. when full service is likely to be restored before the ticket has been raised), although all downtime should be reported as per section 2 above.

Planned downtime should be given with at least five business days’ prior to the event. Apart from cancelling the planned downtime, no changes should be made to the planned downtime notification within the five business day period. Where practical, ASPSPs should give advance notice via their own website, developer portal or OBIE of any planned downtime one calendar month in advance.

In the event that the interface does not offer at least the same level of availability and performance as the PSU interface(s), if there is unplanned downtime, or if there is a system breakdown, ASPSPs are required to have ‘contingency measures’ in place which include a strategy and communication plan to inform the TPPs of measures being undertaken to restore the system and a description of immediately available alternate options that TPPs may have during this time.

ASPSPs should make this plan available to TPPs (e.g. on their website or developer portal) so that they know in advance what to do in the event of unplanned downtime.