...
| Table of Contents | ||
|---|---|---|
|
...
Open Bankings 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 for open banking shift existing optional functionality contained in v2.1 to being mandatory. This is to set down an iterative and clearly sequenced implementation pathway.
Looking beyond the v2.x standards, the API Centre is now beginning its development of the v3.0 major version release, which will introduce new functionality. The intent of the v3.x series of standards is to extend the customer reach of the standards, and to improve their operational utility. The v3.x 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 he 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 considering introducing standardised APIs that enable 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 functionality. The functionality that is being targeted is described below.
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. A common example of where the standards use optional / mandatory settings is with respect to each respective API endpoint. The approach being taken to shift optional features to mandatory features is to set out the stages of an iterative and progressive implementation pathway. By shifting optional functionality towards mandatory, it also ensures that in the future there that Third Parties have more certainty as to what core features all of the API Providers offer.
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.
v2.2.0 Mandatory decoupled authentication flow & new mandatory account information resources
Version 2.2.0 focuses on making decoupled flow mandatory, and increasing the Account Information resources that are mandatory.
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
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
v2.3 Mandatory Enduring Payment Content
v2.0 of the Payments Initiation API standard for open banking introduced enduring payment consent as a new payments capability. This was one of the first times in the world that open banking enabled standing payment consents. v2.3 shifts the three enduring payment consent endpoints from being optional to mandatory. You can refer to this link for more information about enduring payment consent.