1. Introduction

This section outlines various change scenarios that may impact TPPs and provides guidance for an LFI to consider when implementing a change and communicating this to TPPs and the OFP. Any change that may impact a TPP's ability to deliver its services can cause a loss of business or reputational risk or add additional resource cost to the TPP and result in a negative outcome for Users. Identifying the potential impact that proposed changes by LFIs may have and communicating those changes to TPPs is key to a successful Open Finance ecosystem.

2. Types of Change

2.1 Implementation of a new version of the Standard

The CBUAE Open Finance Standard will continue to evolve to cater to potential regulatory changes/clarifications, agreed Open Finance roadmap requirements, and approved changes (which may include adding new functionality, fixing defects, and errata).

The following table outlines the types of releases for the Standard.

For each new release of the Standard, CBUAE will communicate expectations and timelines via communication channels.

2.2 Changes to Infrastructure, Configuration or Software

LFIs must ensure continuity of TPP services such that TPPs do not need to re-onboard their applications, consents and Users.

3. Minimising Disruption

3.1 Dual Running and Deprecation

Dual running requires a pragmatic approach to ensure that LFIs expose and support two API versions and that TPPs use these via the OFP to migrate applications as intended without unnecessary conflict. The ability to support two API versions allows TPPs to maintain existing integrations with the older version and benefit from features and enhancements offered by the new version. Over time, TPPs will migrate all their applications to consume the latest API version. 

• LFIs MUST support a minimum of two API versions in a production context, provided that the LFI previously supported both versions. 

• LFIs MUST support dual running for a time period to be determined for a final version and a shorter time period to be determined for an errata version. This period may be reduced if all TPPs have successfully migrated all their applications and Users to the latest version.  

• CBUAE MAY recommend or even require that any specified version (Final, Errata, or Release note) SHOULD be deprecated at any time, and this SHOULD be implemented as soon as possible after such notification by CBUAE. This is to cater to critical defects, especially those relating to security. 

• Where a LFI implements an API for the first time, they will only need to support this single version to start.

• LFIs MUST not apply any measures to induce TPPs to adopt a new version of the APIs (e.g. rate limiting the older version while providing better performance on a newer version).

3.2 Backwards and Forwards Compatibility

It is expected that:

• A long-lived consent (e.g. for continuous access to Bank Data resources) created using an older version of the APIs can be used for read/write operations in newer versions of the API.

• A single-use consent (e.g for single access to Bank Data resources) can only be used within the same version of the API for creating resources.

• In the event of an update to the consent model, CBUAE will provide a mapping table.

4. Downtime

The impact of any downtime (whether planned or unplanned) can be minimized by a LFI informing TPPs as soon as possible: 

• That downtime is anticipated

• When downtime takes effect 

• When the service is reinstated. 

Planned downtime, by its nature, is something that a LFI anticipates and can give advance notice to TPPs.

It is not generally possible to give advance notice of unplanned downtime. However, LFIs MUST submit details of the reasons for the downtime to CBUAE.

5. Notification

5.1 Timing

Where possible, the publication and LFI implementation of any new version of the Standard will be scheduled so all participants can plan. This will reduce development and support costs for all participants and increase adoption. 

• LFIs MUST give at least one month's notice for any changes (to API versions, infrastructure, configuration, or software) which result in breaking changes for TPPs.

• LFIs SHOULD give one month's notice and MUST provide at least five business days' notice of any other planned downtime before the event. 

• Apart from cancelling the planned downtime, changes SHOULD NOT be made to the planned downtime notification within the five business day period. 

• LFIs MUST give notice of any unplanned downtime immediately after they are aware of the downtime.

• LFIs MUST give notice immediately that any change has been implemented or any downtime has been restored.

It is not expected that LFIs provide notifications for very short-lived periods of unplanned downtime (e.g. when full service is likely to be restored before the notice has been issued). However, all downtime SHOULD be reported in all cases.

5.2 Content

When providing any notification, an LFI MUST provide the following details:

• Date notice is given.

• Details of the change that will be made (e.g., implementation of the new version).

• Reason for the change (e.g., new version to be implemented, the old version to be deprecated, etc.).

• Details of LFI system(s) affected (e.g., test facility, production interface).

• Details of how any change will be made available in the test facility in advance of the production interface (where relevant).

• Indicate the likely impact for a TPP, including any action required by TPPs (e.g., requiring Users to re-authenticate).

• Rating of the impact on the TPPs' service:

  • Business critical issue – represents a complete loss of service or a significant feature that is completely unavailable, and no workaround exists.

  • Degraded service issue – includes intermittent issues and reduced quality of service. A workaround may be available.

  • General cosmetic issues include product questions, feature requests, and development issues in staging environments.​

• Start time/date the change is anticipated to take effect and the end date/time (if applicable).

5.3 Method

All communication will be submitted via the portal.