| Page Properties | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Contents
| Table of Contents | ||||
|---|---|---|---|---|
|
...
On this page you will find all supporting documentation and relevant forms to be used to provide your feedback on the published release candidate for version 2.1 of the Payments NZ API Standards for the below specifications:
NZ banking data
Account information
Payments initiation
Account information
The consultation period is open until 04 and until this date, the . The API Centre team and API Standards Users welcome all feedback from the industry as defined in the consultation and feedback section below.
...
As a part of the release candidate consultation process for v2.0.0, we asked for the industry’s opinion on whether there was any additional functionality that would enable use cases not currently supported by the APIs. The lack of Account Information API not including Credit Card information and the narrow scope of accounts, accounts and related credit card information was a recurring theme in the of feedback received, and was identified by respondents to be a major barrier to uptake of potential products by as a significant barrier to what Third Party propositions c an cover, and ultimately impacting the potential products offered to their Customers.
Assessment of all feedback received was carried out by the Business and Technical working groups and it was agreed that there was sufficient value in releasing a fast follower to the standards in a minor version update that broadened the scope of the Account Information API to include;
...
The NZ Banking Data and Payments Initiation APIs have no changes to functionality included in this update, the although some minor changes have been made to these specifications relate to clarifications and updates highlighted through the issues log by Third Party’s and Community Contributorsadd clarifications.
Version scope
The scope for the Account Information API v2.1.0 has been agreed and published in the release candidate as per the below:
...
The standard does not mandate the provision of any account type that a customer cannot currently access via their online banking environment beyond credit card accounts and as a result the account types available may vary between API Providers. In order to mitigate some of the friction that this creates for Third Party’s . Each API Providers has variations in their product that will fall into scope of this Standard. To assist Third Parties, it has been agreed that all API Providers must define what account types are available via the API in their developer portals.
It is the intention of the API Centre working groups that as part of future development activities, the scope of account types that are made available through the Account Information API are reviewed and expanded where there is an opportunity to do so as the market matures. This may include adding other account types that are currently not in scope of v2.1 such as foreign currency accounts. This may also include adding products that have joint accounts or have more than one signatory (v2.1 does not currently support multi-authorisation processes).
Any provider API Provider that is unable to support this functionality for reasonable business reasons will have to apply to the API Centre for an exemption, and this will managed on an individual organisation basis. This exemption framework is yet to be defined and developed by the API Centre and will become a key area of focus following publication of the standard and this will be shared with the broader industry in support of the standards when available for review. The rationale for making provision of the broader account types and credit cards mandatory and developing an exemption framework was to;
demonstrate steps are being taken to reduce the level of optionality in the standards;
acknowledge that from a Third Party perspective it is crucial that API Providers make credit card account available via API.; and
ensure ongoing directional alignment with the UK and Australia ‘CDR’ regimes.
There has been no change to the scope of the Payments Initiation API v2.1.0-rc1 as the changes to this specification have only been clarifications to the standard & specification.
...
The main functions that are being considered for inclusion in v3.0 are listed below. It should be noted however that these remain an indicative list only at this stage and further clarity will be provided once the high level scoping activities have been completed. Detailed v3.0 scoping work is currently underway on:
Development of a ‘Request to Pay’ API function - This would enable a Third Party to initiate an API payment journey with a customer, further clarity on exactly what functions should be supported within this are currently being assessed.
Future dated payments - Update to the Payments Initiation API to enable a customer to authorise API payments to be made at a later date.
Two way notification - Update the Payments Initiation API to introduce the ability for an API Provider to push notifications to a Third Party as well as keeping the ability for a Third Party to poll an API Provider.
Reduced optionality - Update to the Account Information API to increase the number of mandatory functions / resources in the API to ensure greater standardisation across API Providers.
Unique transaction identifiers - Update the Payments Initiation API to change the currently optional transaction ID field to mandatory and specify a format for this information to be provided in.
...
Feedback summary
We will be publishing the feedback received from all parties at the below location and the API Centre team will be responding to the feedback directly, using this page.
...