Change and Communication Management

Downtime

This version is:

This is the latest version Published 1 week ago 18 Mar 2026

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 downtime notifications which should be published on their own website or developer portal and also via the OBL API Downtime Notification System. 

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.

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

To ensure that this notification system is effective, the following guidelines have been provided 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 five 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 unplanned 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 processes 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 unplanned downtime (e.g. when full service is likely to be restored 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 – Notification 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 information on downtime either by logging into the portal or receiving email updates. Whilst an interim update would not trigger a new email to the ecosystem, it would appear on the portal and for this reason remains 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.