...
| Table of Contents | ||
|---|---|---|
|
...
Open Banking Standards Development Roadmap
The intention development of both the v2.2 & v2.3………..
PREVIOUS FOR V2.0 (TO BE DELETED)
The intention of Version 2.0 of the Account Information and Payments Initiation API standards is to unlock a range of additional functionality that has been requested by both API Providers and Third Parties.
The scope of the proposed v2.0 standard directly addresses feedback raised by the market with respect to the current v1.0 standards set. This feedback was received via:
One-on-one feedback from the Pilot Development Partners,
Findings of the Pilot Close Report,
Discussions held with the API Working Group and Technical Sub-Group,
Wider market engagement, including from two focus group sessions and ad-hoc engagement.
It is worth noting that the development of the proposed v2.0 commenced in April 2019 and has progressed with feedback and input from all registered Standards Users of the API Centre. This release candidate should be considered as being in draft format and it is open for industry feedback via the ‘feedback form' as below in the feedback section.
Functionality updates for v2.2 & v2.3
The below functionality has been highlighted as the key areas for development for v2.0.0 of the existing API standards. This functionality unlocks a wide range of use cases for API Providers and Third Parties, and is considered to bring the most value for the NZ ecosystem for the next iteration of the API standards.
v2.2
Mandatory Decoupled authentication flow
……
Explaining decoupled authorisation flow (We used this page last time, might help to explain what this is this time around)
Mandatory Account Information resources
……
v2.3
Mandatory Enduring Payment Content
…..
Explaining enduring payment consent (We used this page last time as well - might be useful in this situation3 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 |
|---|
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. |
| Info |
|---|
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
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.