Resources
Open banking API compliance in Australia for 2026
A practical 2026 guide to CDR participation, consent, API security, data management and reporting, with a checklist of evidence to review before launch.
Open banking API compliance in Australia in 2026 means joining the Consumer Data Right through the right participation arrangement, obtaining valid consent, protecting the data and keeping evidence that those controls work. The responsibilities continue after the first successful API request.
For product and engineering teams, the useful question is practical: who is responsible for each part of the service, and what can you show before launch? This guide focuses on applications receiving customer banking data, with the separate data-holder role identified below.
The 2026 update: non-bank lending enters consumer data sharing
From 9 November 2026, initial in-scope non-bank lenders are required to share consented customer data, subject to exemptions and exclusions. API teams should verify which lenders, products and customer requests are supported.
The ACCC's rollout guidance distinguishes three stages:
- 13 July 2026: product-data obligations began for initial providers and non-bank lenders that became large providers on or before 13 July 2025.
- 9 November 2026: consumer-data obligations began for initial providers, excluding complex requests.
- 10 May 2027: consumer-data obligations begin for that early large-provider cohort, excluding complex requests. Later qualifying providers have a rolling timetable.
Public product data describes a lending product. Customer data describes a customer's relationship with it and needs the applicable consent and access arrangement. The non-bank lending rules exclude complex requests, including requests involving joint or partnership accounts, secondary users and nominated representatives.
For an API team, this means checking the lender, covered product, customer permissions, commencement date and any exemption before promising a connection. The rollout does not establish a particular API provider's live coverage.
Start with your role in the CDR
Australia's framework combines Part IVD of the Competition and Consumer Act, the CDR Rules and the Consumer Data Standards. The ACCC and OAIC regulate different aspects of the system. Map your legal entity and activities to the applicable requirements before configuring production.
| Your role | What to establish before implementation |
|---|---|
| Accredited data recipient | Accreditation level, permitted activities, technical onboarding and the controls your organisation must operate |
| CDR representative | The unrestricted accredited principal, written representative arrangement, registration and responsibilities for the service |
| Data holder | The institution's obligations to disclose eligible data, obtain authorisation and operate the required APIs and customer controls |
The OAIC's representative guidance explains how an unaccredited representative receives data through its unrestricted accredited principal under a written arrangement. The representative still has obligations under that arrangement and may have other privacy obligations.
Sponsored accreditation is a separate pathway. Our CDR accreditation and access guide explains the distinctions. Record the actual arrangement in your launch plan rather than treating an API subscription as the participation decision.
Check the requirements that are already in effect
A 2026 implementation should review older consent templates against the current rules and standards. Two concrete checks are:
- Consent receipts: the DSB's receipt requirements effective from 14 July 2025 cover receipts after consent is given, amended or withdrawn. They include specified content and written delivery outside the consumer dashboard.
- Outsourced service provider information: the DSB's collection and use consent guidance identifies requirements applying from 12 November 2025. Reconcile the consent journey with the actual direct and indirect providers involved in handling data.
Keep a register of the rule, standard, affected component, effective date and implementation owner. Published standards can also contain future obligations, so distinguish a planned change from a requirement already due.
Make consent enforceable throughout the application
The recipient's consent to collect and use data and the data holder's authorisation to disclose it are different parts of the journey. The OAIC's consent and dashboard guidance explains those responsibilities and the customer's controls for managing sharing.
Define the service, required datasets, purposes and duration. Request only the data and collection period reasonably needed for that service. Use the applicable consent language and choices, and make the route to review or withdraw consent clear. Then connect those choices to backend behaviour.
For example, consider a hypothetical cash-flow app adding a customer's non-bank loan account. Before enabling the feature, check whether its approved purpose and requested data cover that use. A later feature that assesses borrowing eligibility needs its own review of purpose, permissions and downstream recipients.
A useful engineering test is to queue a data fetch, withdraw the relevant sharing permission and then process the queued job. Verify that collection relying on that permission stops. Repeat the test with delayed notifications and retries. Record what was tested and which cases still require live validation.
Treat API security and organisational security together
The CDR Security Profile defines technical requirements for the regulated data-sharing connection. When a platform manages that connection, establish which controls it operates and which remain in your application.
The OAIC's Privacy Safeguard 12 guidance also addresses the wider CDR data environment, information security controls, assessment and incident management.
Prepare a data-flow map covering production databases, background workers, logs, support tools and external processors. Assign owners for access controls, secrets, security testing and incident escalation. Review overseas processing and disclosure under the applicable safeguards and contracts. A provider's assurance report should be assessed against the service and systems it actually covers.
Define what happens when sharing ends
Stopping new collection and handling data already held need explicit processes. The CDR privacy safeguards require protection of CDR data and destruction or de-identification of redundant data, subject to the applicable requirements and exceptions.
Document the permitted purposes, customer deletion elections, retention exceptions and treatment of copies. Include derived information, exports and backups in the review. Give each retention decision an owner and a reason that can be checked later.
For a representative arrangement, agree how directions and completion evidence move between the principal and representative. Test the process with a small, labelled fixture before relying on it for customer data.
Keep complaints, incidents and reporting operational
The customer needs a clear route to raise a problem. Your team needs an agreed process for investigating it, correcting data where required and escalating to the responsible participant.
Incident procedures should identify who assesses a suspected breach and who handles any required notification. The OAIC's NDB guidance explains that accredited data recipients and designated gateways are covered for eligible breaches involving CDR consumer data. Confirm the requirements applying to each entity in your arrangement.
Keep a reporting calendar too. The ACCC's rule 9.4 guidance requires data holders and accredited data recipients to submit six-monthly reports by 30 January and 30 July. CDR principals have additional representative reporting requirements. Agree who gathers the underlying records even where another entity submits the report.
A practical compliance evidence checklist
Use this as a proposed internal review aid alongside the requirements for your arrangement. A completed checklist is evidence for a decision; it is not a regulatory certification.
| Area | Evidence to review |
|---|---|
| Participation | Legal entities, verified status, written arrangement and responsibility owners |
| Consent | Current journey, requested data and purposes, dashboard and receipt examples |
| Access lifecycle | Results for approval, withdrawal, expiry, queued work and repeated events |
| Security | Data-flow map, control ownership, assessment scope and incident exercise |
| Data management | Retention decisions, deletion elections, exceptions and completion records |
| Operations | Complaint route, reporting calendar, change register and unresolved issues |
Record passed, failed and untested items separately. A successful account-linking demonstration should not hide an unresolved mandatory requirement.
Applying the checklist to a Fiskil integration
Fiskil's consent documentation describes auth sessions, account selection, consent checks and notifications when sharing ends. Use those mechanisms to build and test the application's access lifecycle.
Review Fiskil's CDR policy and confirm the arrangement and responsibilities applicable to your service. Its Go Live Checklist sets out the Console onboarding questionnaire, security information and compliance and developer checks for production access.
Start with a proof of concept that tests the customer journey and backend controls. Then discuss your intended use case with Fiskil, including any non-bank lending requirements, and agree the remaining conditions before launch.
