CDR and Open Banking APIs: A Guide for Fintech Teams
CDR is Australian legislation giving consumers the right to share their data via standardised, regulated APIs. This guide explains what that means architecturally for fintech engineering teams, from accreditation models to the API standards you need to build against.
The Consumer Data Right (CDR) is Australian legislation that gives consumers the legal right to direct that their data — starting with banking, and now expanding to energy and other sectors — be shared securely with accredited third parties, instead of through screen-scraping. Open banking is the CDR's first sector rollout: a defined set of API standards, published and maintained by the Data Standards Body, that any fintech wanting to read a customer's transaction, account, or product data from a bank must build against. For engineering leaders, this is the short version. The longer version — and the part that actually determines your architecture, your compliance surface, and your build timeline — is what follows.
What is the Consumer Data Right and why does it matter for fintech engineering teams?
The CDR is administered by the Australian Competition and Consumer Commission (ACCC) in partnership with the Office of the Australian Information Commissioner (OAIC) and the Data Standards Body. Together they set the rules for how consumer data can be requested, shared, and used. For fintech teams, the practical consequence is straightforward: any product that wants to read a customer's transaction, account, or product data from a bank must do so through a standardised, regulated API — not a screen-scraping workaround, and not an informal data-sharing arrangement with a third party.
This matters because CDR is not simply a privacy regime layered over existing infrastructure. It's a technical standard with its own authentication model, data schemas, and consent lifecycle. Teams that treat it as "just another OAuth integration" tend to underestimate the engineering effort that sits around consent state management, data minimisation, and the ongoing compliance obligations that persist long after the integration ships — including consent expiry handling, withdrawal flows, and audit logging that regulators can request.
How does CDR accreditation affect your system architecture?
Accreditation is the gate that determines what your system is legally allowed to do with CDR data, and it directly shapes your build-versus-partner decision. Becoming an Accredited Data Recipient (ADR) means your organisation — not just your software — meets ACCC-set standards for information security, dispute resolution, and insurance. That typically requires a dedicated compliance and security uplift well before the first API call is made.
Most growing fintechs do not need to pursue full, unrestricted accreditation on day one. The regime includes tiered participation models — sponsored affiliates operating under an existing accredited entity's obligations, and outsourced service providers who process data on an ADR's behalf without holding accreditation themselves. The right model depends on your product roadmap, your risk appetite, and how much of the compliance surface you want to own directly.
| Participation model | Who holds accreditation | Typical fit |
|---|---|---|
| Full Accredited Data Recipient | Your organisation | Products where CDR data is core to the value proposition and long-term, ongoing data access is required |
| Sponsored affiliate | A sponsor ADR holds accreditation; you operate under their obligations | Earlier-stage fintechs wanting to test CDR-powered features without carrying full compliance overhead |
| Outsourced service provider | You process data under an ADR's instructions | Engineering teams building infrastructure or analytics on top of someone else's CDR data flow |
| CDR representative | A principal ADR authorises you as a representative | Products distributing CDR-enabled features through a partner's accreditation |
These are qualitative distinctions, not a ranking. The correct choice is a governance and commercial decision as much as a technical one, and it's worth making deliberately rather than defaulting to full accreditation because it sounds most complete.
For teams working from an older core banking or account-management platform, the accreditation decision is often tangled up with a separate question: can your existing system even support the consent, token, and data-minimisation requirements the standards demand? In many cases the honest answer is no, and the CDR mandate becomes the forcing function for a broader application modernisation effort — decoupling legacy data stores from customer-facing services so consent and access control can be enforced consistently at the API layer, rather than patched on afterwards.
For related reading, explore our ai product strategy and ai engineering services, or browse more insights.
What API standards do fintech teams need to build against?
CDR data sharing runs on API standards published and maintained by the Data Standards Body (consumerdatastandards.gov.au), which define both the data payloads (the shape of account, balance, transaction, and product reference data) and the security profile that governs how a request for that data is authenticated and authorised.
The security profile is built on OAuth 2.0 and OpenID Connect, layered with the Financial-grade API (FAPI) security profile, which adds stricter requirements around client authentication, token binding, and request signing than a typical consumer OAuth flow. This is the part most engineering teams underestimate: standard OAuth libraries and patterns are a starting point, not a finished implementation. FAPI compliance affects how you manage client certificates, how you validate redirect URIs, and how you structure token lifecycles — decisions that need to be made early, because retrofitting them into a live consent flow is expensive.
On the data side, the standards specify versioned, sector-specific schemas — banking today, with energy and other sectors following a similar pattern. Building against these schemas means your data layer needs to map cleanly from whatever internal representation you use for accounts and transactions to the standard's published structures, and needs to stay current as those schemas evolve. The Data Standards Body publishes changes on a public roadmap, so this is an ongoing maintenance commitment, not a one-off integration project.
For teams evaluating what to build in-house versus what to source through a sponsor or an outsourced service provider, the practical test is usually this: how much of your product's value depends on owning the full data pipeline versus consuming a compliant feed that someone else maintains? Getting that assessment right early avoids both the trap of under-investing in a core capability and the trap of building compliance infrastructure that a partner could have provided.
CDR and open banking are not going away, and the standards will keep expanding in scope. Teams that treat the architecture decisions — accreditation model, consent handling, FAPI compliance, schema mapping — as foundational rather than incidental tend to ship faster and spend less time re-architecting later.
If you're weighing up your CDR participation model, your API architecture, or where legacy infrastructure is holding back a compliant integration, get in touch — we're happy to talk through what fits your product and your timeline.
Chris Kerr
Partner at Horizon Labs, an AI product consultancy and venture studio. A commercially focused product and technology leader with 20+ years building and scaling digital platforms, teams, and businesses across SaaS, travel, eCommerce, logistics and transport, and digital marketing — operating at the intersection of product, engineering, and data. Writes about platform strategy, AI transformation, modern data ecosystems, and the operational discipline that separates AI demos from AI products.
