Operational Guidelines

Change and communication management

This version is:

Published 5 years ago 23 Sep 2019

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

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…

This version was published 5 Years & 2 Months ago 23 Sep 2019

Implementation of a new OBIE Standard

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

This version was published 5 Years & 2 Months ago 23 Sep 2019

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. In such cases, TPPs may need to update and re-onboard their…

This version was published 5 Years & 2 Months ago 23 Sep 2019

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. When informing TPPs of an anticipated change, an ASPSP should confirm: Date notice is given Details of the change that will be made (e.g. implementation of new version) Reason for the change…

This version was published 5 Years & 2 Months ago 23 Sep 2019