In July 2026, MBIE opened a consultation period with participants in New Zealand's regulated open banking system regarding payment liability and risk allocation. Akahu's response to the consultation is below.

Introduction and summary

Thank you for the opportunity to respond to the consultation paper.

• Participant name: Akahu Technologies Limited.
• Participant type: Intermediary accredited requestor.
• CDR payment role: Akahu supports open banking payments pursuant to both one-off and enduring payment consents.

In summary, our views are:

• Enforcement: Compliance should be enforced so that banks meet existing disclosure obligations and reduce the risk of fraud or mistaken payments. 
• Standards: Standards should be developed to require the intended performance and reliability of open banking payments. 
• CoP: Banks should be encouraged to provide confirmation of payee results to customers on their authorisation screens.
• No new liability framework: A liability framework for open banking payments is not necessary.

In our full response below, we provide some general comments regarding payment liability, as well as specific responses to each scenario in the consultation paper. 

General comments

No new standalone liability framework

There are specific obligations and liability provisions in the regulation, and these add to existing payment liability rules. But we agree that the regulated system does not create a new standalone liability framework. 

We also agree that the regulation does not (and should not) create card-scheme-style chargeback or liability rules. Any such liability framework could emerge as a proprietary “scheme” built on top of the underlying open banking infrastructure, but does not belong at the infrastructure level itself.

One-off payments

One-off payments are a way to submit details of a payment to the bank. 

The customer authenticates with their bank, and authorises the payment, directly in the bank’s app or online banking. 

Accredited requestors are responsible for accurately transmitting those payment details to the bank. But otherwise we think there is no material difference between an open banking payment, and the customer choosing to manually create the same payment in the bank’s app or online banking.

Enduring payment consents

Enduring payment consents are similar to one-off payments described above. The accredited requestor is responsible for accurately transmitting the payment details to the bank. And it is also responsible for ensuring that the customer has authorised any payments that are initiated pursuant to that consent. 

But otherwise we think there is no material difference between the open banking payment, and the customer choosing to manually create the same payment in the bank’s app or online banking.

Payments NZ standards have outdated terminology

Payments NZ started work on open banking standards in 2016. Much of the original focus was on payments, and specifically the ability to make payments to merchants. 

Traces of this original focus show up in terminology in the Payments NZ standards, such as providing a “MerchantCategoryCode” and “MerchantCustomerIdentification” in a payment consent. 

However the standards became functionally broader over time, acknowledging that open banking payments are relevant to other use cases such as:

• Payroll: Enabling businesses to automate payroll payments.
• Personal finance: Enabling individuals to automate savings (pay-to-self) or money transfers (peer-to-peer).
• Other: A broad range of other payment scenarios such as paying rent, loan repayments, and tax payments.

We note that some terminology in the Payments NZ standards is outdated, and does not align with the objectives and requirements of the regulated open banking system. We believe that in order to enable innovation and competition, open banking payments must be unopinionated about the specific roles of each party involved in a payment. Open banking payments should be considered as a general utility to facilitate the transfer of money on behalf of the customer. This capability goes beyond the simple purchase of goods and services from a merchant.

Bank obligations for payment authorisation screens

The regulation sets out obligations that banks must comply with regarding the information that is displayed to a customer with a payment consent request.

• Section 7(6)(b) of the standards says that data holders must "comply with clauses 2.12 to 2.14 of the customer standard when carrying out the authorisation flow process."
• Section 2.14 of the customer standard requires "(a) the details of the payment being authorised; and (b) the identity of the beneficiary to whom the funds will be credited".

To comply with these obligations, we think that banks should be displaying the following details on their authorisation screen:

• The payee's name.
• The payee's account number.
• The name of the entity that the consent is being granted to (which may be different from the payee).
• Other details of the payment, like the amount, particulars, code, and reference values.

All bank implementations currently fall short of these obligations (some of these issues were shared with MBIE in relation to ANZ, ASB, BNZ, and Westpac in our compliance issues spreadsheet on 31 March 2026):

• ANZ: 
  
  • The fourth party’s name is incorrectly displayed as the payee instead of displaying the “CreditorName”. 
  • The payee account number is not shown.
• ASB: 
  
  • “CreditorName” is used in messaging that should refer to the fourth party. 
  • The payee account number is not shown.
• BNZ: 
  
  • The fourth party’s name is incorrectly displayed as the payee instead of displaying the “CreditorName”. 
  • The payee account number is not shown.
• Kiwibank: 
  
  • The fourth party is not mentioned. 
  • The payee account number is not shown.
• Westpac: 
  
  • The fourth party’s name is incorrectly displayed as the payee instead of displaying the “CreditorName”. 
  • The payee account number is not shown.

We have raised these issues with each bank when they were first observed, but the issues have not been resolved.

We mention this because, if banks genuinely want to control liability regarding open banking payments, the starting point is to ensure that they are meeting their regulatory obligations and providing their customers with full and accurate details of the consent request.

We think there is increased risk of customer loss, fraud, and scam activity due to the non-compliant bank implementations, because customers are not shown accurate payment details. For example, if an attacker obtains the necessary credentials to create an open banking payment consent, the attacker would often be able to conceal the payee details when attempting to convince victims into making fraudulent or mistaken payments. For completeness, we are not aware of this happening, we are solely acknowledging the heightened risk.

To respond to the questions in clause 7.8 of the consultation paper: yes we consider that bank views on liability uncertainty are being used as a reason to limit and delay their compliance with the required payment functionality, and the issues they’ve raised are better understood as non-compliance with existing obligations rather than uncertainty in the framework. 

Confirmation of payee

There is no requirement in the open banking regulation for a bank to use the confirmation of payee (CoP) system to ensure that the payment details being displayed to the customer are accurate.

However, in our view, if a bank wants to protect itself from liability in relation to fraudulent or mistaken payments, we think it should use the CoP system to ensure that accurate information is being presented to the customer on the bank’s authorisation screen. This would align with prerequisites in the Code of Banking Practice (CoBP) that enable the bank to disclaim liability in relation to a relevant payment.

When we’ve raised this point with banks, some have pointed to wording in the CoBP that says that the customer is eligible for compensation if they "weren’t using a third-party payment service to make the payment".

Our view is that banks should not be able to apply that exclusion to open banking payments:

• The customer authorises the payment consent in the bank app, and the bank decides whether to accept or reject each payment request. So an open banking payment is very similar to the customer choosing to manually set up the same payment in the bank’s app or online banking.
• Third parties do not have reasonable access to CoP. So banks are best placed to give the customer that protection.

We mention this because, if banks genuinely want to control liability regarding open banking payments, we think they would ensure that a CoP check is used to ensure that their payment authorisation screens accurately reflect the details of the payment being authorised.

In the meantime, we have developed a payee verification system to manage our own liability and to provide protection to customers. 

Specific responses to scenarios

Category A – Customer error or misunderstanding

We agree with the strawman view.

We think that liability is clear, and there is no need for new rules.

Category B – Scams or fraud scenarios

We agree with the strawman view.

We think that liability is clear, and there is no need for new rules.

However we think it’s important that banks comply with their obligations regarding the information that is displayed to a customer with a payment consent request (described in our general comments above).

We also think it’s important that banks use CoP to ensure accuracy of payment details being displayed on their payment authorisation screens. According to bank-owned GetVerified which operates the existing CoP service in New Zealand:

• “Since the rollout of the Confirmation of Payee account verification service across New Zealand banks, nearly 20% of users report the service has helped them avoid a misdirected payment or a potential scam”; and 
• “80% of respondents said the service made them feel more confident when making an account-to-account payment”.

If banks genuinely want to manage liability regarding open banking payments, and provide appropriate customer protections, we think they should ensure that a CoP result is presented to customers on their payment authorisation screens.

The smallest useful fix is to enforce compliance with existing consent disclosure obligations, and to encourage banks to display CoP results on their authorisation screens. 

Category C – Accredited requestor error or system failure

We agree with the strawman view.

We think that liability is clear, and there is no need for new rules.

Category D – Data holder error or processing failure

We agree with the strawman view.

However, in order to deliver the competition and innovation potential of open banking payments, we think that additional standards should be developed in order to improve the performance and reliability of open banking payments.

An important design element of open banking payments is the ability for an accredited requestor to immediately know whether the payment request has been processed successfully by the customer’s bank. Accredited requestors should receive a terminal status on a payment request within seconds, and should be able to rely on this status with certainty in order to release goods or services to the customer.

But the current bank implementations do not deliver on this design intent:

• There are no performance requirements for processing payment requests. In some cases, the processing can take days or weeks before a payment status changes to a terminal state (we have experienced this issue with three separate banks). In these cases, we need to manually ask the bank to confirm whether the payment was processed or not, and to ask the bank to change the payment status to a terminal state.
• We do not receive notification if a bank provides a successful terminal status for a payment, and then subsequently decides to cancel the payment before inter-bank settlement.

Given these issues, accredited requestors cannot use payment statuses to conclusively determine whether a payment will be settled successfully. To avoid credit risk, an accredited requestor needs to wait until the funds have settled and been reconciled before releasing the goods or services, which undermines a key attribute of open banking payments. 

We recommend that additional standards are developed to ensure that:

• Each payment request resolves to a terminal status quickly.
• Banks have an obligation to ensure that payment statuses are accurate, and that all relevant checks are completed prior to assigning a terminal status. If a bank fails to take reasonable steps to ensure the correct status is reported (such as cancelling a payment after it reaches the terminal status of AcceptedSettlementCompleted), that bank should be liable for any loss caused by its incorrect reporting.

Category E – Merchant or service provider error or failure

We agree with the strawman view.

We think that liability is clear, and there is no need for new rules.

Category F – Fourth or fifth party error or failure

We agree with the strawman view.

We think that liability is clear, and there is no need for new rules.

The risks that banks have raised would be addressed by complying with their existing obligations to disclose full and accurate details on payment authorisation screens.

Category G – Shared responsibility or multiple contributing factors

We agree with the strawman view.

We think that liability is clear, and there is no need for new rules.

Final words

Thank you again for consulting on these topics. We welcome further discussion on our submissions or other matters that arise through this consultation.