Overview of the v2.1 standards

Owned by Matthew Bell
Last updated: Jun 26, 2022 by Sheri-Lee.Paulse
4 min read

Purpose

This page provides a high level overview of the scope of changes that have been included in v2.1 of the Account Information and Payments Initiation API. It provides a non-technical explainer of the changes made and included in this version of the standard.

Note that included in each respective page of the the v2.1 specifications is a full change log that describes all technical changes made to the specification.

High level scope

This version of the standards is intended to include:

  • Credit card accounts in the Account Information API

  • Clearer definition of range BECS identifiable accounts in scope of Account Information API

  • Clarifications and errata fixes in Payments Initiation API

Description of standard

The v2.1 Standard originated just prior to the publication of the v2.0 Standard, when Standards Users, Community Contributors and industry stakeholders were consulted on what the market would like to see developed in the ‘pipeline’ of future standards.

A strong feedback theme was that the v2.0 Account Information API did not include Credit Card accounts and related credit card account information, which was identified as a significant limitation of what customer data Third Party propositions could cover. This was seen to ultimately impact the viability of the Third Party potential products they could offer to their Customers using v2.0 Account Information. Following this assessment, the Council approved the development of a fast follower minor version update that broadened the scope of the Account Information API standard to include credit card account types.

The v2.1 standard also takes a further step forward by explicitly listing the minimum account product types that are considered as being in scope (as opposed to leaving the types of accounts that the standard covers open to interpretation).  Feedback from Standards Users on the v2.0 standard was that the ambiguity and absence of information about what account types the Account Information API covered created challenges when scoping internal implementations.  The amended scope statement now adds the minimum account product type categories that the v2.1 Standard covers and is detailed below for reference.

There were no substantive or functional changes to either the NZ Banking Data API or the Payments Initiation API for this minor release.

Payments Initiation

No substantive or functional changes for this iteration of the standards, however there have been a number of updates to fix errata and provide clarifications to the specification.

Account Information

In scope accounts

The definition of in-scope accounts for v2.1 has been changed to provided greater clarity and surety for a Third Party looking to consume the Account Information API resources. Below is a table providing a comparison between v2.0 and the newly agreed scope of accounts to be included in v2.1. Importantly, this new scope allows for all existing Account Information API functions to accessed on a far broader range of accounts including Credit Card accounts.

Version 2.0.0

Version 2.1.0

In scope

In scope

The Account Information API provides the ability for Third Parties to access a Customer's account information for NZ Bank accounts. While this version of the API specification only allows access to NZ BECS identifiable accounts, the API specification is silent on what account types must be accessible.

The Account Information API provides the ability for Third Parties to access a Customer's account information for NZ bank accounts. This version of the API specification allows a Third Party to access NZ BECS identifiable accounts and credit card accounts:

  • If a Customer has access to these accounts in their online banking, then these accounts must be made available for access via the Account Information API.

  • An API Provider must define and publish what account types are available for access via the Account Information API in their developer portal.

The minimum API Provider NZ BECS identifiable and credit card account product types (covering both business and personal accounts) that are in scope of the Account Information API are:

  • Transactional accounts. This includes accounts that are sometimes are referred to as: current accounts; cheque accounts; debit card accounts; personal accounts; business accounts; call accounts; etc.

  • Credit card accounts

  • Savings accounts

  • Lending accounts. This includes accounts that are sometimes referred to as: personal loan accounts, fixed rate home loan accounts, floating home loan accounts; floating home loan accounts; business loan accounts; or mortgage offset transactional accounts; etc.

Out of scope – No change to the out of scope areas between v2.0 to v2.1 of the Account Information API

This specification does not cater for:

  • Write operations (the ability to create) standing orders, direct debits and beneficiaries.

  • Progressive or changing consent - if the consent between the Third Party and Customer changes, then the existing account-access-consent object is deleted and a new account-access-consent is created with the new consent.

  • The ability for a Third Party to pre-specify the list of accounts that are linked with the account-access-consent.

  • Access that requires multiple authorisers.

  • Non-functional requirements and specification of caching and throttling.

Credit card number masking

The working groups expended significant effort to consider how the Standard can remain PCI DSS compliant when it adds in credit card account types. The approach taken with the Standard is to require API Providers to ensure PCI DSS compliant practices, and to require API Providers to display card identifiers in the same way as they currently do in their own online channels (i.e. instead of prescribing a card identifier approach and format).

As a result of taking this approach, there will be implementation variations between different API Providers and as such a Third Party will need be aware of the format of the account / card identifier prior to carrying out a call to the Account Information API and so an API Provider must provide this implementation detail as part of their respective developer portals.