This page is a high level summary of the key points raised and discussion held in session.

1. Attendance

2. Overview

A briefing was given on the journey towards v2.0 release candidate, the API Centre and the standards development scope and process.

3. Specification run-through notes

A high level overview of the v2.0 standard was provided. Key points discussed and the API Centre response provided in meeting has been captured. The API Centre will ensure that all feedback provided below is incorporated into the ongoing consultation process.

The consultation process will inform the development of the final v2.0 standards as well as defining the development plan for future standards developed by the API Centre.

3.1 Optionality of API endpoints

Concerns were raised by attendees that leaving a large amount of functionality ‘Optional’ for API providers to support, and there may affect ultimate use of the standards in market and have a negative Third Party and customer impact. It also significantly reduces the value of the data to a Third Party consuming the APIs as this approach does not allow a uniform product across multiple providers.

The API Centre provided an overview of all endpoints that are optional and mandatory and advised that the standard(s) have been designed with flexibility for implementation as a priority in the short term. Consideration of expanding the list of 'Mandatory' endpoints could be considered as part of the pipeline plan for post v2.0 and will be incorporated into these discussions.

3.1.1 Account Information API endpoints

Further details on which endpoints are mandatory / optional can be found in the specification at the below location:

• Account Information API Specification v2.0.0-rc1 | Endpoints

3.2 Enduring Payment Consent clarifications

The API Centre team ran through the technical design of the Enduring Payment Consent functionality at a high level, this can be found in the specifications using the below link:

• Enduring Payment Consents - v2.0-rc1

Feedback received from the group was that the functionality enabled by EPC are broad and varied and removes friction in the payment experience for customers using the API. This could ultimately lead to a greater uptake by end consumers.

The value however is again restricted by leaving this as an optional endpoint in the specification and the expectation would be for this to be made mandatory in a future state as it would lead to consistency across the industry.

3.3 Security feedback

It was noted that a central registry for Standards User security information is a key component to the scaling of the centre and the uptake of the standards in the long term.

The provision of a centralised registry has been agreed as part of the scope of the Security Profile v2.0-rc1. This registry will be called the 'API Centre register' and further information can be found here:

• NZ Banking Data Security Profile v2.0-rc1 | API Centre Register

It was suggested that the API Centre should be open to incorporating a wider range of international certification authorities in the future (five certificate authorities are currently on the white list).

3.4 Provision of release candidate standards in the sandbox

The group advised that for future versions of the standard, it would be more valuable for developers to be able to use the release candidate specifications in the API Centre sandbox. This would enable developers to provide a more comprehensive set of feedback following testing.

4. Standards feedback

Below is a brief summary of the feedback received on what the members of the group would like to see next as part of the pipeline plan.

• Creation of term deposits for both existing and new customers. Viewing term deposit account in the Account Information API standard.

• Addition of credit card accounts into the API standards

  • The priority for members of the group was for credit card accounts to be incorporated into the Account Information standard

  • Subsequently the exploration of credit card Payments Initiation APIs could be considered.

  • Exploration of one-tie use virtual credit card numbers and their use in API generated payments initiation

• Reciprocity of information for APIs

  • API Centre acknowledged this is not a current priority at this stage. This is more of a macro ecosystem issue than API standards

• Threat detection and management

  • This could come in the form of a service / platform layer provided by the API Centre

• Inclusion of business accounts in the APIs to include:

  • Batch payments

  • International payments

  • International payment supporting information including (but not limited to):

    • SWIFT codes

    • IBAN #

    • Account Number

    • Account info etc

• Support for accounts (personal and business) with multiple signatories

• An assessment of how W3C payments initiation relates to V2.0 payments initiation, and if there is any future benefit/opportunity in aligning standards.

5. Any Other Business

The API Centre will be taking all feedback and thoughts on pipeline activities provided throughout the consultation process onboard and engaging with existing Standards Users through the working groups to define and agree the pipeline plan for the API Centre.

Feedback was noted that this pipeline plan / roadmap should be shared publically and be available for non standards users to view.