Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



The API standards were developed primarily by two working groups: the API Technical Working Group and the API Business Working Group. All Standards Users can contribute and participate on these working groups. Each group generally meets fortnightly, on alternating weeks. You can see who the API provider Provider and third party Third Party Standards Users are on the API Centre public website.

The API Technical Working Group’s main focus from May 2019 to March 2020 was the development of the v2.0 standard. The API standard documentation on Confluence, and Swagger documentation on GitHub, were developed iteratively against an agreed scope of the API standard. Once final drafts of the standard were developed, the working group held longer working sessions to walk through the draft API standard. This helped ensure the final API standard aligned with the scope, accurately reflected the group’s previous discussions and agreements, and that the API standard held together as a whole.

The Business Working Group was instrumental in making scoping decisions on non-technical issues that arose from time to time. They also assessed the risks and scope of the standards, and generally supported the API Centre run the API standards development process.



The v2.0 security profile sets out how third parties Third Parties connect securely to an API providerProvider.

The NZ Banking Data Security Profile v2.0.0 is based on the OpenID Foundation's FAPI Read+Write specification document, and applies this standard to the New Zealand market context. This specification is used to help define requirements for how API providers Providers can safely make APIs available and connect with third partiesThird Parties. This specification applies to both the Payment Initiation and Account Information API specifications. The security profile:

  • Aligns with the UK’s upstream OBIE standards.

  • Aligns with Australian direction being taken under their open data programme.

  • Aligns with general best practice API security practices and global standards.

Key changes made to the v2.0 security profile (compared to v1.0) include:

  • Adding the decoupled authentication flow (FAPI-CIBA profile) to accompany the redirect authentication flow.

  • Reducing existing optional elements where applicable to simplify implementations and enhance security.

  • Additional guidance for clarity.

  • Simplifying and restructuring the content of the security profile document.



The v2.0 standard has delivered a range of other technical improvements and enhancements to make the API standards clearer and generally make them easier to adopt. The v2.0 standard contains a detailed version control log of all changes made to the standard compared to v1.0. A summary of key general API related improvements and enhancements include:

  • Structural improvements and clarifications to the API standard.

  • Release management guidance on what is available across different versions of the API standard.

  • More clarity on refresh tokens for long-lived consent.

  • Renaming consent resources (from payments to payment-consents; account-requests to account-access-consents; and from payment-submissions to payments) for clarity and alignment to OBIE.

  • Addition of minimum certificate security standards.

  • Detailed error codes so the API providers Providers can provide useful information back to the third party Third Party in failure scenarios.

  • Updated data model and usage examples added to help illustrate the API standard.



The way in which the API specifications have been structured allow the API Centre to mandate a core set of functions that API providers Providers must support when they implement the API standards, as a minimum to meet their obligations in their terms and conditions as a Standards User in the API Centre. There are however a range of additional optional endpoints that API providers Providers can choose to support and provide if they decide to do so.

These endpoints have been defined as ‘mandatory’ and 'optional' in the specification for both the Account Information API Specification v2.0.0 and Payments Initiation API Specification - v2.0.0 APIs.

The endpoints that are being made available will be published on the respective organisations' developer portals and made available upon request.



Customer authentication is a crucial part of the consent journey, where an API provider Provider validates that a customer has authorised a third party’s Third Party’s consent request, before providing access to a protected resource.

This can be carried out using one of two flows defined in the specification. The redirect flow has been defined as a mandatory function and API providers Providers must provide this method of authentication to customers. The decoupled flow has been defined as an optional function and may be implemented by API providersProviders. This information will be made available via their developer portals. More information about decoupled flow and redirect flow can be seen here.