Operational Guidelines

Change and Communication Management

This version is:

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

This chapter outlines various change scenarios that may impact TPPs and provides guidance for an ASPSP to consider when implementing a change and communicating to TPPs.

Other pages in this section

This chapter outlines various change scenarios that may impact TPPs and provides guidance for an ASPSP to consider when implementing a change and communicating to TPPs.

Any change that may impact a TPP’s ability to deliver its services has the potential to cause a loss of business, reputational risk or to add additional resource cost to the TPP and result in a negative outcome for their customers.

As such, the ability to identify the potential impact that proposed changes may have and to communicate those changes to TPPs, is key to a successful Open Banking ecosystem.

The information that an ASPSP should include in its communication to a TPP is listed at section Notification of a change.

In this chapter

Downtime

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.

Implementation of a new Open Banking Standard

The Open Banking Standard will continue to evolve to cater for regulatory changes, Open Banking roadmap requirements and approved changes (which may include adding new functionality, fixing defects, and errata). Where possible, Open Banking Ltd (OBL) will schedule new versions of the Standard so that all participants can plan ahead and build new APIs, this will reduce development and support costs for all participants, and increase adoption.

Changes to an ASPSP’s Infrastructure, Configuration or Software

At any time, an ASPSP may need to make changes to any element of their system, including implementation of a new version (as described above). This includes the adding/removing of functionality or fields within an existing version. This may or may not require downtime.

Notification of a Change

ASPSPs should provide notice to TPPs of a change (within the time frames outlined above) via the ASPSP's own website or developer portal.