Known issues log

01

Specification issue

Aug 3, 2024

What should value of `exp` be in an introspection response with `"active": false`

Added explainer, will update the text in future specification versions. Also an errata candidate.

known issue

02

Specification issue

Aug 26, 2024

Contradictory statements regarding pagination 'Links'

Have published an explainer to communicate intent here: https://paymentsnz.atlassian.net/wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/1918533642 .

This is a candidate for errata and inclusion in future standards versions.

known issue

03

Specification issue

Sep 8, 2023

Time as Customer - GAP

https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/1680479034/v3.0.0+Security+Profile#Introspection-response states the exp is mandatory in the introspection response. What should the exp value contain if the response indicates "active": false?

Should exp be conditionally mandatory - that is, should we update the security profile to state exp MUST be returned if "active" : true otherwise expshould not be returned?

Added explainer here: https://paymentsnz.atlassian.net/wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/1921122308, will update the text in future specification versions.

This is a candidate for errata and inclusion in future standards versions.

known issue

04

Specification issue

Jun 26, 2023

here are a couple of potential errors/omissions in the sequence diagram in https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/800031520/Payments+Initiation+API+Specification+-+v2.1.0#Sequence-Diagram (and subsequent standards versions too, probably)

1. In step 4 the consent status depends on whether it is an enduring payment consent or a domestic payment consent. EPC’s don’t have a Consumed status.

2. Step 5 has two opts for [accounts] which don’t exist in these standards

3. Step 5 is missing the GET domestic-payment/debtor-account

Corrected the diagram in v3.0 onwards.

This is a candidate for errata and inclusion in any future patch changes for all other standards versions.

known issue

05

Specification issue

Jan 13, 2025

The PNZ v3.0 Security Profile lists the following statements:

While at the same time in the PNZ v3.0 Security Profile

This seems to be contradictory and should probably be clarified by:

1. updating the NZ Read and Write API Security Profile section to remove the assertion that FAPI-RW section 8.6 should be followed and instead explicitly list the algorithms (or reference Step 2: Form the JOSE header), since the standards are obviously not using the FAPI-RW JWS algorithms.

2. remove the other non-FAPI-RW algorithms.

 In the meantime, we has assumed option 1 above and will be using the list of allowed algorithms for signing:

• RS512

• PS512

• ES384

• ES512

If this is not the correct assumption, can you please let me know so we can fix this up on our end.

Thanks for raising, it does seem that this could create some confusion. To clarify, 8.6 partially applies, since we follow:

2. should not use algorithms that use RSASSA-PKCS1-v1_5 (e.g. RS256); and

3. shall not use none.

But your assumption of option 1 is correct, the algorithms specified

Probably the most practical approach would be to include this in a future update as a note to the Security Profile. In the meantime we will look to include in errata (when we publish this) in the near future.

This is a candidate for errata and inclusion in any future patch changes for all other standards versions.

known issue

06

Specification issue

Apr 2, 2025

The spec and examples all use http not https https://github.com/PaymentsNZ/API-Event-Notification/blob/master/schemas/event-notification-schema.json#L152 but the docs show that this should be https (and I would have expected https) https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/1909229073/Event+Notifications+v3.0.1#Event-Notification---Request

The API Centre will update and correct errata in the next standards version.

KNOWN ISSUE

07

Specification issue

Jul 16, 2025

The data model for the Statements resources (https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/1909098837/Statements+v2.3.3#Data-Model defines the StatementId field as optional, however this StatementId value would be necessary for a Third Party to call the following endpoints, which uses the StatementId in the path:

• GET /accounts/{AccountId}/statements/{StatementId}

• GET /accounts/{AccountId}/statements/{StatementId}/file

• GET /accounts/{AccountId}/statements/{StatementId}/transactions

This is the same definition in the v3.0.0 and v3.0.1 of the standards.

Accepted this is an oversight and this needs to be mandatory for the other endpoints to make sense.

Raised in ACSD-921

API Providers and Third Parties are to treat StatementId in the OBStatement1 object as mandatory.

The API Centre will update and correct errata in the next standards version.

KNOWN ISSUE

08

Security Profile

Aug 28, 2025

The Security Profile (all versions) currently include Entrust in the list of allowed certificate authorities. Since November 2024, Entrust has been officially distrusted by Google, Mozilla, Apple and others.

API Providers and Third Parties should treat Entrust as no longer trusted, and work to remove an Entrust issued certificates whenever possible.

The API Centre will include relevant certificate authority changes in the next Security Profile update.

KNOWN ISSUE

09

Clarification

Sep 15, 2025

API Providers could be unclear on the types of business accounts that are included in Open Banking  

The Account Information v2.3.3 scope states that business and personal accounts are in scope.

The definition of Customer in the NZ Banking Data API Specification v2.3.3 Actors section refers to customers as “Individuals who operate retail banking accounts who make use of an account information service or payment service. The banking accounts may be personal accounts or associated with businesses, trusts, etc.”

Therefore, while an individual must authorise a consent, that individual could be acting for themselves, or on behalf of a business (e.g. SME, Corporate, Institutional, societies and clubs, trust etc), or both.

The only other limitations applicable to personal or business accounts scope is whether the customer has access to that account via online banking and that it is BECS Identifiable or a Credit Card Account (account information only).

Note:

• The phrase retail banking accounts is intended to reflect that accounts are maintained by an NZ Retail bank (as opposed to a central bank or commercial bank)

• The term “business” is intended to reflect any non-personal account (so long as it is available to customers via digital channels).

Because of this language, API Providers could be unclear on whether the scope of business accounts required by API Centre Standards extends to corporate, institutional, trusts, clubs & societies (and possibly other sub-categories of non-personal customers and account).

For the purposes of improving clarity and readability, the following clarifications to the standards are recommended:

1. Customers (Actors) are

Individuals who operate accounts maintained by a Retail Bank (registered with the RBNZ) operating in Aotearoa NZ.

2. Account Information API Scope has this addition

Where “business” or “business account” refers to any non-personal customer or account.

The API Centre will enact this update in the next version of the standards

KNOWN ISSUE