...
| Table of Contents | ||
|---|---|---|
|
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 for open banking is to shift existing optional ‘optional’ functionality contained in v2.1 earlier versions to being mandatory. ‘mandatory’ for API Providers to implement.
This is shift to ‘mandatory’ will clearly define and set down an iterative and clearly sequenced 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 the v3.x series of standards 0 is to extend the customer reach of the standards, and to improve their operational utility. The v3.x 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 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 carrying out initial assessments on expanding the scope of v3.0 to include standardised APIs that enable a payment refund capability.
...
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 functionalityfor 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 features is has been designed 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 offerand 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. This At the time of publication, 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 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.
...