Contents
Open Bankings 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 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.
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.
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.
Add Comment