Chapman Tripp | Open banking and fraud

The regulated open banking framework to come into force in December 2025 will stimulate increased competition and the innovative use of secure Application Programming Interfaces (APIs) but it will also create new opportunities for sophisticated global scamming operations, including an ability to act at scale.

New Zealand’s open banking system is being built with these risks in mind but will not be able to eliminate them entirely. So, who will pay when banking fraud does occur?

We examine the liability provisions in the Customer and Product Data Act 2025 (the Act) – commonly known as the consumer data right or the CDR – which indicate that banks or data holders that have carried out a payment action on behalf of a fraud victim customer may not have contravened the Act.

Scene-setting

The possibilities of open banking stretch far and wide, but for the purposes of this publication we will limit our discussion to two simplified payment initiation scenarios.

A customer has signed up with a payments service (the Provider) that is an accredited requestor under the CDR. The Provider puts a request through to the customer’s bank (Bank), to initiate payment from the customer’s bank account to a third party.

Scenario One: the customer authorised the payment but has fallen victim to an investment scam and is unknowingly transferring the money to a fraudster. This is authorised push payment, or APP, fraud.

Scenario Two: the customer’s account with the Provider has been hacked and a fraudster is making the payment request impersonating the customer. This is an unauthorised transaction.

While our Provider in these examples is itself an accredited requestor, in practice Providers will often use the services of a third party, which will require a different analysis again, depending on the relevant arrangements.

Legislative framework: the CDR provides a basic structure

The Act establishes a basic framework for a CDR that can be deployed across many sectors – not just open banking – so has relatively little content. Regulations will provide the detailed rules for each sector but these have yet to be published so our analysis focuses on the Act.

Under the Act, a data holder (such as a bank) must perform a designated action (such as making a payment) in response to a request from an accredited requestor acting on behalf of a customer within the scope of its accreditation.¹ The request must be technically valid and made using the correct APIs and electronic system.²

Each of the data holder and the accredited requestor must refuse to act where it has reasonable grounds to believe that the relevant request or instruction is made under the threat of physical or mental harm.

However, the data holder may (but is not required) to refuse to perform the action in a number of other circumstances, including where it reasonably believes:³

performing the action would create a significant likelihood of serious financial harm to any person
it is likely that the request was made (wholly or in part) as a consequence of deception, or
the accredited requestor has contravened any obligation under this Act in connection with the request.

This generally gives the data holder the ability to refuse to act where there is a reasonable belief of fraud. Accredited requesters are generally not compelled by the Act to accept instructions, so would generally be able to refuse to act in such cases (subject to any contractual provisions).

Liability for fraud under the Act

If there is a contravention of the Act and a customer has suffered, or is likely to suffer, loss or damage, the data holder or accredited requestor who contravened:⁴

will be required to take steps to avoid, mitigate, or remedy that loss or damage, and
may be required to pay reimbursement/compensation for a readily ascertainable cost or expense incurred as a result of the contravention. The specific required steps and liability for compensation will be set by regulation.

The Act also provides that contraventions can result in infringement offences or civil liability remedies such as pecuniary penalties, declarations, injunctions or compensatory orders, subject to various defences (including reasonable reliance and due diligence defences).

There is also a further defence for supplying customer data (rather than performing designated actions) in good faith compliance with the Act.

Accordingly, the Act contemplates two parallel (and non-exclusive) remedial paths for contraventions.⁵

A regulatory route with prescribed remedial steps and recovery for loss.
Civil liability following court proceedings brought by the Chief Executive of MBIE or any other person, which allows for statutory defences.

We anticipate that the regulations will create a simple process (potentially with strict liability) to recover small losses, reserving court proceedings, with the corresponding ability to raise defences, for more serious contraventions or larger losses.

However, in either case, liability under the Act will only apply where there has been a contravention.

Data holders have a fundamental obligation to perform a payment initiation as instructed by a customer and risk contravening the Act if they refuse. Apart from requests arising from threats of physical or mental harm, there is no scenario under which the data holder is obliged to refuse the payment initiation. However, a data holder may refuse a payment initiation where it reasonably believes that performing the action will create a significant likelihood of serious financial harm, or that the request was made as a consequence of deception.

The potential outcome of our illustrative scenarios under the Act is:

Scenario One: provided the Bank and Provider comply with any broader protections against frauds and scams in the regulations, it seems unlikely that the Bank would have contravened the Act where the customer has authorised the payment request but was operating under a deception.

Scenario Two: depending on how the customer’s account with the Provider was hacked (including how this fits with the Provider’s accreditation conditions), it is possible that either the Bank or Provider may have contravened the Act and/or regulations. If the unauthorised access was due to the customer’s negligence, it is also possible that neither have contravened the Act.

Although the regulations are still being drafted, it is not clear that the Bank or Provider will have contravened the Act in either Scenario One or Two. This means that open banking customers who have fallen victim to a scam – where the money cannot be recovered – will likely look to other legal avenues such as contract or dispute resolution schemes for a remedy.

Little guidance is available from Australia or the United Kingdom:

Australia’s open banking does not yet encompass payment initiation, and
reimbursement for APP fraud in the UK is governed by the Payment Systems Regulator’s reimbursement requirements, for which there is no direct equivalent in New Zealand. (By contrast, the voluntary reimbursement scheme applies to members of the New Zealand Banking Association and does not apply to third party payments).

While the introduction of the regulated open banking framework promises will stimulate increased competition and innovation, it also brings with it new risks of fraud. As the landscape evolves, it remains to be seen who will pay when a customer is scammed. All stakeholders need to remain informed as we wait to see how the law and dispute resolution schemes will respond.

1. Sections 18 and 19.
2. Sections 26 and 27.
3. Section 20.
4. Sections 58-59.
5. Section 60.