Overview of the v2.2 & v2.3 standards

Purpose

This page provides a high level overview of the scope of changes that have been included in both version 2.2 & version 2.3 of the Account Information and Payments Initiation API. This is a non-technical explainer of changes made and included in these versions of the API Standards. If you would like to see more detailed information about the changes, this information can be seen in the change logs at the top of each the API specification pages.

High level scope

v2.2 & v2.3 of the Account Information and Payments Initiation API standards scope and main purpose is to to reduce the level of ‘optionality’ that is present in the earlier versions of the standards. As such, they do not introduce any brand new functionality.

This approach will give greater certainty for Standards Users and the wider open banking ecosystem of what minimum functionality will be supported by all API Providers when they implement these API standards.

Origin and rationale of the v2.2 and v2.3 standards

In early versions of the API Standards, our industry stakeholders agreed that including a level of ‘optionality’ in the standards for API Providers to implement certain functions was an appropriate initial strategy. This allowed initial implementations to focus on a core base set of ‘mandatory’ functions in the standards, such as initiating single one-off payments, and the Account Information’s ‘balance’ and ‘transaction history' resources. These base functions were seen as deemed critical minimums for New Zealand’s open banking ecosystem. This also gave API Providers certainty as to what the minimum expectations are for what functionality is to be included in their initial implementations.

Our industry stakeholders recognised that a much wider range of use cases and open banking services could be provided to customers if the Standards also supported a wider set of functionality. Accordingly, the earlier versions of the Standards featured a wide range of ‘optional’ functions, such as enduring payment consent, and a number of other account information resources. The intention was that this ‘optionality’ would be phased out over time as industry expectations and experience of adoption changes. v2.2 & v2.3 of the Account Information and Payments Initiation API standards begin this phasing out of optional elements, as they focus on changing high priority functions in existing standards to become ‘Mandatory’ for API Providers to implement.

In the context of our standards, ‘optional’ and ‘mandatory’ functions mean:

  • Mandatory: For any API Provider and/or Third Party that implements and uses a given version of an API Standard, then a mandatory feature of that Standard must be implemented as set out in that Standard. 

  • Optional: If an API Provider and/or Third Party uses an API Standard, then an optional feature of the Standard might be implemented and used.  If an API Provider elects not to implement an optional feature of a Standard, Third Parties will not be able to access and use that feature of the Standard with that API Provider (regardless of Third Party preferences).

The use of different versioning of the standards groups functionality into chunks that can form the basis of an incremental pathway for API Provider implementation programs over time. Separate to these standards, the industry is working together on more coordinated implementation approaches, and using these different versions of the standards as future milestones.

Functions that have been switched to mandatory are outlined below under the relevant parts of the Standards.

NZ Banking Data API

Functions that have been switched to ‘Mandatory’ in the standards are:

Version 2.2.0

Version 2.3.0

Version 2.2.0

Version 2.3.0

Decoupled authentication flow

Using this flow, a Customer is able to authenticate a submitted consent request either using another device or at a later date.

See below for detailed explainer:

https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/298909741/Explaining+redirect+and+decoupled+flows#Decoupled-authentication-flow

No changes made for v2.3.0

Errata and bug fixes

These changes are detailed in the change log of the relevant specification page(s)

Payments Initiation

Functions that have been switched to ‘Mandatory’ in the standards are:

Version 2.2.0

Version 2.3.0

Version 2.2.0

Version 2.3.0

Errata and bug fixes

These changes are detailed in the change log of the relevant specification page(s)

Enduring payment consent

Establishing a long lived consent for payments would enable a Third Party to provide services wherein the Customer is not required to be present to authorise every payment request submitted.

This enables a wide range of Third Party use cases, equivalent to direct debit functionality but using APIs and providing greater control to the Customer.

See below for detailed explainer:

https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/298909733

Account Information

Functions that have been switched to ‘Mandatory’ in the standards are:

Version 2.2.0

Version 2.3.0

Version 2.2.0

Version 2.3.0

‘High priority’ Account Information resources

The working group carried out an API Provider implementation complexity vs Third Party value assessment and those that were deemed as ‘High priority’ by the group through this process were agreed to be made Mandatory in this version of the Standards as detailed below.

The intention for future versions of the standards, is that a similar assessment will be carried out and further resources will be switched to mandatory as Third Party demand for those functions increases.

The resources to be made mandatory are:

  • Party

  • Statements

Detailed explainer of all Account Info resources can be found below:

https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/298909721/Overview+of+the+v2.0+standard#Account-Information

No changes made for v2.3.0

Errata and bug fixes

These changes are detailed in the change log of the relevant specification page(s)