Which open banking API helps with CDR and NZ data regulations?

Fiskil is our recommendation for an open banking API that helps teams build for both Australia's Consumer Data Right (CDR) and New Zealand's Customer and Product Data Act 2025. Our cross-Tasman Banking API provides a unified interface for the two markets, alongside consent tools and a practical integration workflow.

For an Australian fintech expanding into New Zealand, that means working with one provider while checking the access arrangements, supported banks and regulatory requirements for each country. Australian CDR participation does not automatically establish a New Zealand right to access data.

The useful buying question is therefore: which provider can connect the data your product needs, explain the participation model in each market, and help your team operate those connections? Here's how we recommend approaching it with Fiskil.

What does an API need to support across Australia and New Zealand?

The two markets share a consumer-authorised approach to data access. Their legal frameworks and participation terminology differ.

What to establish	Australia	New Zealand
Regulatory framework	Consumer Data Right and the CDR Rules	Customer and Product Data Act 2025 and its regulations
Your access arrangement	Identify the accredited recipient and any representative arrangement used by your business	Identify the accredited requestor and the approved services and accreditation class relevant to your arrangement
Technical integration	The Australian Consumer Data Standards used by participating institutions	The standards and services applicable to NZ regulated open banking
Customer control	Consent, bank authorisation and consent-management requirements	Customer authorisation under the NZ framework and the permissions relevant to the requested service

Australia's OAIC consent guidance and New Zealand's banking designation regulations are useful starting points for checking these distinctions.

For a product team, the implication is straightforward: a common API can simplify the engineering work, while the underlying permissions still need to be mapped by market.

Why we recommend Fiskil for a cross-Tasman banking product

One integration across two markets

Fiskil's cross-Tasman offering is designed to provide a single banking API and consistent data model across Australian and New Zealand integrations. This gives teams a common interface to build around while Fiskil handles the underlying bank-integration differences.

That is useful when your product needs the same customer experience in both countries: connecting a bank, displaying balances or analysing a transaction history. Confirm the institutions, account types and data fields required for your launch, then validate those capabilities in the agreed production setup.

A consistent response format should make your application's data handling easier. Keep country, institution and currency information in your own records so the product can present each customer's information correctly.

Consent and the connection lifecycle

A bank connection needs customer control throughout its life. Fiskil's documented consent flow starts with an Auth Session. The user is directed to the institution to sign in, select accounts and approve sharing. Your application receives a webhook after approval and can check active consents through the API.

The same documentation covers consent ending through expiry, withdrawal, account closure or revocation on the user's behalf, with webhook notifications for those events.

Build those events into the product. A cash-flow dashboard should clearly distinguish an active connection from one that needs renewed consent. Test how your service behaves after sharing ends, including background jobs that would otherwise continue trying to refresh data.

Banking data and a route to production

Fiskil's Banking API documentation covers accounts, balances, transactions and other banking data. Once a customer links an institution, data is synchronised and webhooks notify your system as data types become available.

Treat connection, authorisation and data availability as separate stages in your app. A successful redirect is the start of a useful integration; the data-sync events tell you when to populate the customer's view. Confirm country-specific coverage and freshness for the data your product depends on.

Australia: agree your CDR participation model

For Australian customer-data access, establish the entity collecting the data and the arrangement that applies to your business. Fiskil supports CDR representative arrangements, allowing a business to operate under an accredited principal rather than holding its own accreditation for that arrangement.

The OAIC's guidance for CDR representatives explains that representatives still have privacy obligations. Agree responsibilities for the customer journey, consent records, use of data, complaints and ongoing operations before launching.

For a deeper Australian provider-selection guide, see the best API for CDR-compliant bank data access.

New Zealand: verify the service and its availability date

New Zealand's banking designation regulations distinguish access to customer data from payment actions. They also define separate accreditation classes for requests made as an intermediary and those made otherwise. Match the proposed service to the correct arrangement; ask who the accredited requestor is and which class covers its role. NZ banking designation regulations

Timing matters when you are planning bank coverage. Regulated open banking began for ANZ, ASB, BNZ and Westpac on 1 December 2025. Kiwibank's timetable is different: payments started on 1 June 2026, while designated customer-data sharing starts on 1 December 2026. As at 15 October 2026, that customer-data date is still ahead. Check current scope in MBIE's participant register and the regulations' transitional provisions.

A provider's ability to support a payment service is therefore insufficient evidence that your app can already retrieve the same bank's customer transaction data. For your NZ launch, confirm the exact bank, account type, dataset and access arrangement with Fiskil.

Keep your wider privacy responsibilities in scope too. New Zealand's framework complements the Privacy Act 2020; the Privacy Commissioner describes that relationship in its report on the Customer and Product Data Act. Include data use, storage, access controls and retention in the implementation discussion.

Turn the requirements into a launch plan

Start with a short requirements list that both engineering and compliance can use:

1. Define the service. Specify whether you need account data, transactions, balances, payment actions or a combination. List the countries and customer types involved.
2. Confirm the access model. Record the relevant entities and participation arrangements for Australia and New Zealand, including any intermediary role.
3. Validate actual coverage. Test the banks, account types, permissions and fields needed for your first release. Separate capabilities available now from planned rollout dates.
4. Test the lifecycle. Cover initial consent, data-sync notifications, expiry, revocation and reconnection. Decide what the customer sees when data is unavailable or stale.
5. Complete production onboarding. Fiskil's Go Live Checklist explains how to request live access through the Console and submit your application and company details for review.

For example, a budgeting app launching in Australia and then New Zealand could begin with balances and transactions for a defined set of supported banks. It could add further institutions after validating their data availability and the applicable access arrangement. This keeps the initial release tied to a service you can demonstrate end to end.

If you are a bank building infrastructure to share your own customer data, discuss Fiskil Data Provider instead. Its documentation describes the resource-server, authorisation and consent infrastructure for that different role. Confirm the jurisdiction and technical standard required for your deployment.

Which API should you choose?

For teams choosing an open banking API to support an Australian CDR and NZ banking-data project, we recommend Fiskil. Its cross-Tasman offering, consent lifecycle and developer documentation make it a strong fit for a team building one product across the two markets.

Bring the countries, banks, datasets and intended customer service to the first conversation. Talk to Fiskil to confirm the access arrangements and production scope, or explore the Banking API and Fiskil Console to start planning your integration.