Change and Communication Management

Downtime

This version is:

Published 2 months ago 10 Nov 2025

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.

Other pages in this section

Downtime is defined in section Availability

Note: We can see significant benefits in firms adopting this guidance, but it is not mandatory provided that firms meet their regulatory obligations.

There are regulatory requirements on ASPSPs to communicate with TPPs which are set out in the FCA’s SCA-RTS as follows:

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 and also via the OBL API Downtime Notification System. 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.

Open Banking Ltd (OBL) Support Services can assist ASPSPs with the dissemination of downtime information to the wider Open Banking ecosystem via its central noticeboard facility notification system i.e., the OBL API Downtime Notification System.

To ensure that this notification system is effective, the following guidelines have been provided in the table below:

AreaASPSP GuidanceTPP Guidance
Planned Downtime – Notice PeriodASPSPs should provide notification of planned downtime, in the following timescales:
• Minimum: 5 working days’ notice
• Best practice: 1 calendar month notice

ASPSPs should avoid making any changes to the planned maintenance activities within the 5-day period.

However, if the duration or scope of downtime changes, that should be updated to improve accuracy. The OBL API Downtime Notification System enables edits of downtime, however note that edit will not trigger an updated email notification to the ecosystem. Material changes (such as a significant change in the duration or scope of downtime) should be implemented by cancelling the original ticket and creating a new one. 		TPPs should have processes to review planned outage notifications regularly
Planned Downtime – AccuracyASPSPs should seek to avoid worst-case or inflated durations, only notifying accurate expected downtime.TPPs should raise concerns with OBL if they identify a material discrepancy between planned and actual downtime by ASPSPs
Planned Downtime – ChannelsASPSPs should use both the following channels to notify TPPs of planned downtime:
• The OBL API Downtime Notification System
• Their developer portal and/or status page (if any)		TPPs should have processes to review planned outage notifications regularly, monitoring both ASPSP portals and updates from the OBL API Downtime Notification System
Planned Downtime – ContentNotifications should include (as a minimum):
• Expected exact start/end times
• Affected APIs/services

The description field should give TPPs any useful additional information, with the following suggested content:
• Expected impact on TPPs during time window
• Type of issue (full outage, intermittent, slower responses, etc)
• A support contact.		TPPs should use this information to coordinate fallback plans and log for tracking purposes
Unplanned Downtime – Detection & NotificationASPSPs should:
• Notify TPPs via their developer portal / status page of any un-planned downtime and follow their regulatory requirements (e.g. in the FCA’s SCA-RTS and EBA Guideline 2 in the EBA Guidelines on the conditions to benefit from an exemption from the contingency mechanism 4 December 2018).
• Establish automated process-es to streamline notification process where possible.
• Longer downtime should be notified via the OBL Service Desk, but it is not expected that ASPSPs raise tickets for very short-lived periods of un-planned downtime (e.g. when full service is likely to be re-stored before the ticket has been raised)
• ASPSPs should consider working directly with impacted TPPs during incidents, which could enhance collaboration and resolution speed.		TPPs should monitor API call failures (e.g. 5 consecutive fails) or implement automated unplanned downtime identification,

TPPs should escalate to ASPSP if no notification received
Unplanned Downtime – ContentNotifications should include (as a minimum):
• Issue start time
• Affected APIs / services

The description field should give TPPs any useful additional information, with the following suggested content:
• Interim resolution updates for longer unplanned downtime periods
• Recovery estimate (where available)
• Expected impact on TPPs during time window
• Potential workarounds TPPs could employ to avoid the issue.
• A support contact.

Note that TPPs are able to access in-formation on downtime either by logging into the portal or receiving email updates. Whilst an interim up-date would not trigger a new email to the ecosystem, it would appear on the portal and for this reason re-mains extremely valuable. We encourage regular updates. 		TPPs should use ASPSP notifications to manage downstream impact and update clients as needed
Unplanned Downtime – Post-IncidentIf ASPSPs to share post-event analysis, including details on the cause, fix, and measures to prevent reoccurrence, with OBL if they consider it to be valuable to ensure ecosystem resilience.

ASPSPs must still adhere to any FCA reporting requirements e.g. NOT005 reporting requirements under the Payment Services Regulations 2017 		TPPs should log incident details and provide feedback to ASPSP / OBL governance if gaps observed.

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 Open Banking Ltd (OBL) 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.