Building a CDR-compliant fintech app in Australia: a developer’s playbook

Australia’s Consumer Data Right (CDR) started as a banking data-sharing scheme. In 2026 it is a build-and-compliance decision that reaches far beyond the big four banks. The rules now extend to non-bank lenders and Buy Now Pay Later providers, and a set of reset reforms has reshaped what an accredited data recipient has to hold, store, and secure. If you are planning a fintech product that reads consumer financial data in Australia, CDR is no longer background reading. It is part of your architecture.

This guide is for the people who have to build it (founders, product leads, and engineers), and it draws on the data-handling discipline we applied on a live Australian payments engagement.

What the Consumer Data Right is, in one paragraph

CDR is a legislated framework that lets consumers securely share their data with accredited third parties, such as comparison services, budgeting apps, or lenders. It launched on 1 July 2020 in banking, with the four major banks the first data holders required to share consumer data on request. Unlike UK-style Open Banking, which is limited to financial products, CDR is designed to expand across sectors, starting with banking, then energy, and progressively into non-bank lending and beyond. For a builder, the practical meaning is simple: with a consumer’s consent, you can pull accurate, real-time financial data directly from the source instead of scraping it or asking users to upload statements.

CDR frameworks already reach data types that traditional Open Banking does not, including:

• Energy data: customer electricity and gas consumption, billing, and usage patterns.
• Non-bank lending data: Buy Now Pay Later, personal loans, and other credit products offered by non-bank lenders.
• Broader open finance products: financial products such as insurance, superannuation, and investments, planned or in progress.

What changed for CDR in 2025 and 2026

The regime is mid-reset, so several assumptions from a year or two ago no longer hold.

The non-bank lending expansion

The CDR Rules were registered on 3 March 2025 and commenced on 4 March 2025, extending CDR to non-bank lenders and bringing Buy Now Pay Later products into data-sharing obligations (MinterEllison, 2025). The rollout for non-bank lenders is phased:

• 13 July 2026: product data obligations for initial providers and lenders that became large providers on or before 13 July 2025.
• 9 November 2026: consumer data obligations for initial providers.
• 10 May 2027: consumer data obligations for lenders that became large providers on or before 13 July 2025.

Coverage depends on initial or large provider status, covered products, and the applicable start date. Provider qualification includes APRA-reported loan and lease values, customer counts, and accreditation status. Lenders that become large providers after 13 July 2025 have later deadlines: 12 months after qualification for product data and 15 months for consumer data. BNPL has separate timing rules. Lending outside the major banks alone does not make sharing mandatory; check your classification and products against the official CDR rollout guidance.

The reset reforms

Alongside the expansion, the government has moved to make CDR cheaper to participate in. One change that is often misread: the reset cut the period of historical data that data holders must keep and make available for sharing from seven years to two (Raidiam, 2025). That is a data-holder obligation, not a cap on what you store as a recipient, where Privacy Safeguard 12 already requires you to destroy or de-identify CDR data once you no longer need it. Niche products such as consumer leases, reverse mortgages, and non-standard asset finance have been carved out of mandatory sharing (they can still be shared voluntarily), and the consent process is being streamlined through action initiation.

Action initiation and the screen-scraping question

Action initiation is the shift from reading data to acting on it: an accredited person can be authorised to make a payment, switch a provider, or update details on the consumer’s behalf. In parallel, Treasury has been tasked with advising on a formal ban on screen scraping, though no ban date is set (InnovationAus, 2024). The direction of travel is clear: CDR is meant to replace screen scraping, not sit beside it. If your current product relies on stored banking logins, plan the migration now.

How to access CDR data: the five models

The first architectural decision is not which framework to code in. It is how you will legally access the data. There are five models, and they differ in how much you have to build and prove yourself versus lean on a partner. Both accreditation levels apply across all sectors and give access to all data sets in the CDR Rules, subject to the consumer’s request (cdr.gov.au, 2025).

For most new fintech products, the CDR representative model is the fastest path to market: you build the product and user experience, and a principal holding unrestricted accreditation handles the data collection. There is a trade-off worth knowing up front. The principal stays responsible for how you handle CDR data, so they will run due diligence on your security and privacy controls before entering the representative arrangement, and they often require you to build on their infrastructure. Many teams move to their own accreditation once volume or product scope justifies it.

Storing raw data does not itself require accreditation: a representative can receive and handle data from its principal under the written arrangement, but cannot collect directly from data holders (OAIC: CDR representative obligations). Trusted-adviser access is a separate disclosure pathway restricted to prescribed professional classes, with consumer consent and checks that the adviser qualifies (OAIC: trusted advisers).

The data-handling architecture CDR demands

Whichever access model you choose, an accredited data recipient is bound by the regime’s 13 privacy safeguards, which replace the general Australian Privacy Principles for CDR data, and must meet the information security controls set out in Schedule 2 of the CDR Rules. In practice, that translates into a handful of architectural commitments that should shape your system from day one, not be bolted on before an audit.

Consent as a first-class object

Consent is not a checkbox. It is state your system has to model, honour, and expire. Users must be able to grant, review, and revoke access at any time, and see exactly what they shared and with whom. The rules set different duration limits by consent type. Collection consents and the corresponding data-holder authorisations remain limited to 12 months. Eligible use and disclosure consents given to an accredited person by a CDR business consumer with a business consumer statement can last up to seven years; if you offer more than 12 months, you must also offer a duration of 12 months or less (Data Standards Body: consent requirements). Model collection, use, and disclosure expiry separately: a longer business consent does not extend permission to collect new data (Data Standards Body: business consent durations).

Longer consent does not remove the ongoing notification or withdrawal requirements. Track when the consumer last gave or amended consent, used their dashboard, or received a current-consent notification so you can send the reminder required after 90 days under CDR Rule 4.20 (or 4.20U for representatives). Keep withdrawal available through the dashboard and alternative channels, and stop the affected access when withdrawal takes effect. We model expiry, notifications, and revocation in the consent service and check the relevant active consent on every dependent data call.

Minimise what you store, and where

Privacy Safeguard 12 requires you to destroy or de-identify CDR data once you no longer need it, which makes over-collection a liability rather than an asset. The safest architecture collects only the data a feature needs, keeps the most sensitive fields with regulated providers instead of on your own servers, and uses pseudonyms wherever an identity is not strictly required. This is the same discipline we apply on payments work: keep raw card data with the payment provider so it never touches your infrastructure and your compliance scope stays small.

Encryption, monitoring, and an audit trail

Schedule 2 expects encryption in transit and at rest, access controls, ongoing security monitoring, and a tested incident-response process. On the connection itself, the CDR security profile is built on the FAPI 1.0 Advanced standard, with mutual TLS using CDR-issued certificates between your system and each data holder (Consumer Data Standards, 2025), so plan for that rather than a plain REST integration. Every access to CDR data should be logged so the business has a trustworthy audit trail, both for the regulator and for its own investigations. On our builds this log is queryable, not just written, so the team can answer "who touched this data and when" in seconds.

See how we built a marketplace app compliant with Australia’s Privacy Act.

What CDR unlocks once the plumbing is right

With consent, access, and security handled, several products become practical that were not before:

Personalised advice from live data

Before CDR, budgeting and advice tools ran on estimates, stale statements, or user-uploaded files. An accredited app can now pull real-time account and transaction data, with consent, from multiple banks or even energy providers, and turn it into relevant, timely guidance. This is the foundation of the next generation of banking and savings apps.

Fairer, faster credit decisions

Traditional credit checks miss people with non-standard income or thin files. With CDR, a lender can review a detailed, up-to-date picture of income, expenses, and even utility-payment patterns, producing fairer and faster decisions. The non-bank lending expansion means far more of the credit market can now build on this.

Account aggregation and one-click switching

CDR supports unified dashboards that bring a consumer’s accounts, cards, loans, and bills into one view, and it dramatically simplifies switching providers by standardising the underlying data. Combined with action initiation, this is where CDR moves from "show me my data" to "do this for me."

How Ronas IT builds CDR-ready fintech products

We are a fintech-focused software team, and Australian compliance is not a theoretical exercise for us. On a recent engagement with an Australian travel marketplace, we built a payment and anti-fraud layer under the same data-handling discipline CDR demands. To be clear, this was a Privacy Act and PCI project rather than a CDR-accredited build, but the architecture decisions are the same ones CDR forces on you. The project was under NDA, so we cannot name the client.

We aligned with the Privacy Act, collected only the minimum data needed, and used pseudonyms where possible. We never stored full card numbers ourselves; all sensitive card data stayed with the payment provider to keep the client’s PCI scope small, exactly the pattern CDR rewards. We added device fingerprinting and behavioural signals to produce a risk score, connected local Australian payment rails (PayTo and PayID) as fallbacks, and recorded every action in the admin panel so the client always has a defensible audit trail. The stack was Next.js and Node.js with PostgreSQL and Redis, and we shipped through a gradual rollout so we could watch live transactions before switching everyone over.

“Founders usually ask me how fast they can launch, not how they will handle compliance. On CDR those are the same question. The teams that reach the market first are the ones that treated consent and data handling as part of the product from week one, so when a sponsor or the regulator runs due diligence, there is nothing left to scramble to fix.”

Roman Surikov, CEO at Ronas IT

From discovery and product design through development and maintenance, we scope the compliance track in the first week so it runs alongside the build instead of blocking it. If you are also weighing regulation in other markets, our guide to US fintech regulations and compliance covers the equivalent decisions for the American market.

Planning a CDR-enabled fintech product? Get a scoped estimate for the build and the compliance track.

Get a project estimate

Common build challenges to plan for

Three areas consume the most engineering time on CDR projects.

Integration and standards drift

A CDR product connects to many data holders (banks, energy companies, and now non-bank lenders), each with its own API specifics and evolving standards. Reliable integrations demand real expertise and a commitment to keep adapting as the Data Standards Body revises the data standards, which happens several times a year. Plan the team around ongoing maintenance, not a one-off release.

Consent user experience

Consent flows must be intuitive and fully transparent, letting users grant, review, and revoke access without confusion. Get this wrong and you lose users at the exact moment they were ready to share; get it right and it becomes a trust signal that improves conversion.

Scale and performance

CDR applications handle large volumes of data requests, often in real time. Design for that load from the start rather than retrofitting it under a launch deadline.

Your next step

If you are building on CDR in 2026, start with three decisions: pick your access model (representative for speed, unrestricted for control), design consent and audit logging as core services rather than afterthoughts, and decide which data holders you need to integrate first. A proof of concept on a single data flow is the cheapest way to de-risk the rest.

Building on CDR in 2026? We’ll scope your access model, consent architecture, and integration roadmap, with the compliance work running alongside the build.

Get a project estimate