Open Banking Standards Development Roadmap

The development of the v2.2 & v2.3 release candidates need to be considered in the context of a wider standards development roadmap. The main objective of the v2.2 & v2.3 API standards is to shift existing ‘optional’ functionality contained in earlier versions to being ‘mandatory’ for API Providers to implement.

This is shift to ‘mandatory’ will clearly define and set an implementation pathway for API Providers to provide support for key functions already defined and published in the Standards.

Looking beyond the v2.x standards, the API Centre is now beginning its development of the v3.0 major version release, which will introduce significant new functionality. The intent of v3.0 is to extend the customer reach of the standards, and to improve their operational utility. The v3.0 standards will develop:

multi-authorisation capability, which will enable the open banking standardised APIs to be used by some business accounts or joint accounts, which commonly require more than one account holder to authorise an action;
two-way notifications (commonly referred to as ‘event notifications’), which will enable API Providers to push notifications to Third Parties. The standard will create an event-subscription resource with an API Provider so that the API Provider knows the Third Party would like to subscribe to updates. The API Provider can then send a signed event notification to the Third Party. This functionality makes the open banking standardised APIs more usable by Third Parties, and also puts in place capability building blocks that we can use when we want to introduce new functionality in the future; and
we are also carrying out initial assessments on expanding the scope of v3.0 to include standardised APIs that enable a payment refund capability.

Version 2.2 and 2.3 summary

As described above, the intention of the v2.2 & v2.3 API standards for open banking shift existing optional functionality contained in v2.1 to become mandatory for API Providers to support. The functionality that is being targeted is described below.

NOTE: It is important to understand what ‘mandatory’ means in this context. A mandatory feature of a standard means that if an API Provider implements a particular standard, they must implement all of the mandatory features of that standard.

Example: In v2.1 of the Account Information API, the ‘Balances’ endpoint is ‘Mandatory’ and as such in order for an API Provider to confirm they are supporting the Account Information API, they must provide a ‘Balances’ resource. However, in v2.1, the ‘Party’ endpoint is ‘Optional’ and as a result it is up each API Provider to decide whether they want to provide this resource.

The approach being taken to shift optional features to mandatory has been designed to set out the stages of an iterative and progressive implementation pathway and provide greater certainty to all Third Party Standards Users of API Provider implementations and to increase standardisation across the industry.

Separate to the standards development process, the API Centre is working with the API Providers and Third Parties on what the details and timings of the implementation pathway look like. This is being managed separately to the publication of these API Standards in conjunction with all Standards Users through our working groups' project activities.

As v2.2 and v2.3 shift existing optional functionality towards being mandatory, the changes to the specifications are reasonably limited. For this reason, we were able to develop and manage the publication of both versions concurrently and are publishing for consultation jointly.

Version 2.2.0 scope

Mandatory decoupled authentication flow

Decoupled authorisation flow was one of the key features introduced in the v2.0 standard. The v2.2 standard shifts the implementation of decoupled flow to being mandatory for API Providers to make available to Third Parties. You can refer to this link for more information about decoupled flow.

Explaining decoupled authorisation flow

Mandatory account information resources

The current Account Information API contains a series of resources, or end points, detailing the account information, or data, that the customers can consent to share with a Third Party. Some of these resources are already mandatory, such as Account Balance and Transaction History. Version 2.2 makes two more resources, being Statements and Party, mandatory. These two were identified by the industry as as supporting high value use cases. You can refer to this link for more information about the Account Information resources

Overview of the v2.0 standard | Account Information

Bug fixes and errata

This version also includes bug fixes and corrections to errata that have been picked up and raised through the specification issues log. These issues were identified by both Standards Users, Community Contributors and interested stakeholders and assessed prior to inclusion in this version.

Version 2.3.0 scope

Mandatory Enduring Payment Content

v2.0 of the Payments Initiation API standard for open banking introduced enduring payment consent as a new payments capability. At the time of publication, this was one of only a handful of attempts at standardising a 'long lived' open-banking payment consent that enabled variable payments and as such, it was agreed that this would be optional for API Providers to implement so as to learn from experience and build common capabilities. However, in v2.3 this shifts the Enduring Payment Consent endpoints from optional to mandatory.

You can refer to this link for more information about enduring payment consent.

https://paymentsnz.atlassian.net/wiki/spaces/ACSC/pages/49283290

API Centre Standards Consultation

Overview and scope for v2.2.0 & v2.3.0

Contents