CDR Open Finance: AI for Non-Bank Lenders
Open Banking Just Became Open Finance
For six years the Consumer Data Right was, for most people, a banking story. The big banks built the plumbing, a handful of fintechs consumed the data, and the rest of the lending market watched from the sidelines. That changed on 13 July 2026, when product data sharing obligations commenced for the non-bank lending sector under the Version 8 CDR Rules. The Consumer Data Right, which lives in Part IVD of the Competition and Consumer Act 2010 and is co-regulated by the Australian Competition and Consumer Commission and the Office of the Australian Information Commissioner, has stepped out of banking and into the broader world of open finance.
For a non-bank lender now in scope, this lands as a concrete set of technical and compliance obligations with dates already attached to them. Product reference data, advertised interest rates, fees, charges and eligibility criteria, has to be published in a standardised, machine-readable form. Consumer data sharing follows for the initial in-scope providers from 9 November 2026, and for large providers from 10 May 2027. A lender that has run comfortably outside the CDR regime now has to stand up data-sharing infrastructure, consent handling and compliance processes that were previously the preserve of the major banks, and it has to do so without the compliance headcount a major bank takes for granted.
This guide is for the operations lead, product manager or compliance officer at a non-bank lender, a mortgage aggregator or a broking group who now has to make sense of open finance. The reframing that makes it manageable is the same one that makes any regulatory shift manageable: underneath the acronyms, CDR is a data problem. It is about publishing data accurately, sharing data securely with consent, and consuming data lawfully. That is precisely the kind of structured, repeatable, high-volume work that disciplined automation handles well.
Which Side of the Data Are You On
The first thing any business in the finance chain has to work out is its role, because CDR imposes very different obligations depending on which side of the data you sit. A data holder holds consumer data and must share it on request. A data recipient wants to receive that data to build a service, and to receive consumer data it must generally be an Accredited Data Recipient, accredited by the ACCC against standards covering data handling, privacy and information security. A third, lighter pathway, the Trusted Adviser model, lets certain professionals such as mortgage brokers and accountants receive CDR data a consumer chooses to share with them without full accreditation.
What Is Your Role Under CDR
Getting this classification right is the whole starting point, because it determines whether the pressing task is to build data-sharing infrastructure, to seek accreditation, or simply to understand how the market is about to shift under you. A lender that is a data holder faces an engineering and compliance build. A recipient faces an accreditation and governance build. A broker weighing the Trusted Adviser pathway faces a lighter but still real set of obligations around handling the data responsibly. And a business that is none of these still has a strategic question to answer, because open finance changes what customers can expect and what competitors can offer.
What the Data Holder Obligation Actually Involves
For non-bank lenders, the immediate reality is the data holder obligation, and it arrives in two waves. The first, already live since 13 July 2026, is product reference data. Every in-scope lender must publish standardised information about its products, the advertised rates, the fees and charges, and the main eligibility settings, in a consistent machine-readable format so that comparison services and other participants can consume it. This sounds mundane, and in a sense it is, but the requirement for standardisation is exactly what makes it hard. Product data that lives in marketing pages, PDFs and spreadsheets has to be mapped to a common schema and kept accurate as products change.
The second wave is consumer data sharing, and it is heavier. From 9 November 2026 the initial in-scope providers, the group of non-bank lenders with more than 10 billion dollars of loans and leases that the ACCC has named, must share a consumer's own data, on that consumer's consent, with accredited recipients the consumer chooses. From 10 May 2027 the obligation extends to large providers with at least 1,000 customers and more than 1 billion dollars in loans and leases. That means building consent capture, identity and authorisation flows, secure data-sharing endpoints, and the operational discipline to honour, and to revoke, consumer consents reliably.
The Data Holder Sharing Flow
Wrapping the whole regime are the 13 Privacy Safeguards in Part IVD of the Act, which the OAIC enforces. They govern how CDR data is collected, used, disclosed, corrected and, importantly, destroyed or de-identified when it is no longer needed. One of the practical reliefs in the Version 8 Rules is that the historical data window a holder must maintain and share has been cut from seven years to two, which reduces the cost of storing and responding to requests for old data. It is a genuine easing, but it does not change the fundamental obligation: a lender has to know exactly what data it holds, share the right slice of it on consent, and prove it did so correctly.
Why This Breaks Manual Processes
The instinct at a busy non-bank lender will be to treat CDR the way most new compliance gets treated: assign it to a capable person, build a few scripts, and manage the whole thing by hand. That approach struggles here, and it struggles for a structural reason. CDR is not a one-off project that ends at go-live. It is a continuous obligation to keep product data accurate, to honour consumer consents in real time, to respond to data requests within required timeframes, and to maintain an audit trail that survives regulatory scrutiny. Every product change ripples into the published data. Every consumer consent has a lifecycle that has to be tracked and, when withdrawn, acted on promptly. A manual system copes with a trickle and quietly falls apart under sustained volume.
Where Manual CDR Compliance Falls Over
| Metric | Manual and Ad Hoc | Structured and Automated | Improvement |
|---|---|---|---|
| Product reference data | Retyped from marketing PDFs | Mapped once, synced from source of truth | Accurate |
| Consent lifecycle | Tracked in spreadsheets | Captured, monitored and expired automatically | Reliable |
| Data request response | Handled case by case | Serviced through a governed workflow | Timely |
| Privacy Safeguard evidence | Reconstructed after the fact | Logged continuously | Provable |
| Data deletion duties | Easily forgotten | Scheduled and enforced | Compliant |
There is a sharper edge than mere inefficiency. The CDR regime carries real enforcement backing, and the Privacy Safeguards sit alongside the broader obligations lenders already face. A non-bank lender that mishandles consumer data, shares the wrong data, or fails to delete data it no longer has a basis to hold is exposed under both the CDR framework and general privacy law. The governance discipline this demands is the same discipline that operational risk standards increasingly expect across financial services, a theme we explore in our look at APRA CPS 230 and operational risk for AI service providers. CDR compliance has to work as an operational capability, running continuously and holding up under examination, well beyond anything a box-ticking exercise bolted onto the business would deliver.
Where AI Earns Its Place
Artificial intelligence does not make a lender CDR-compliant by itself, and any vendor that suggests otherwise should be treated with suspicion. What AI does well is absorb the high-volume, structured, repetitive work that makes CDR heavy, so that the accountable people spend their time on judgement and governance rather than on data wrangling. There are four places where it earns its keep.
The first is data mapping and quality. Getting product reference data into the standardised CDR schema is a translation problem, taking rates, fees, charges and eligibility rules that live in disparate internal systems and expressing them consistently. AI-assisted mapping and validation can flag inconsistencies, detect when a published figure has drifted from its source of truth, and keep the published data aligned as products change, which is exactly where manual processes introduce errors.
The second is consent and authorisation workflow. A consumer consent under CDR has a lifecycle: it is granted for a purpose, it has a duration, it can be amended, and it can be withdrawn. Automating the capture, tracking and expiry of consents, and ensuring that a withdrawal actually stops the data flow, removes a whole category of compliance risk that manual tracking cannot reliably manage.
Where the Effort Goes, Manual vs Automated
The third is on the recipient side. A broker, aggregator or fintech that receives CDR data with consent suddenly has access to richer, more structured financial information than it has ever had. AI helps turn that raw data into faster, better-evidenced credit assessment and product matching, structuring the incoming data, surfacing what matters and supporting a human decision. The critical discipline here is that automation supports the assessment rather than making the credit decision unaccountably, which is why any automated processing has to be governed with a human in the loop and clear records. We examine that discipline in AI agent governance, data access and human override, and the broader question of how automated financial decisions are disclosed in our guide to automated decision-making and privacy in 2026.
The fourth is evidence and audit. Every CDR obligation carries an implicit requirement to prove compliance later. Automated, continuous logging of what data was shared, on what consent, with whom and when, produces the audit trail that manual reconstruction never quite manages, and it does so as a by-product of the workflow rather than as a separate chore.
A Realistic Timeline
Because the obligations arrive in waves, the sensible response is staged rather than a single scramble to a deadline. Consider a non-bank lender that has just crossed into scope. Its work falls into a natural sequence, anchored to the regulatory dates rather than to internal convenience.
Staging a CDR Capability
The strategic point for a lender is that open finance runs in both directions, and the cost side of it is only half the story. A lender must share its data, and the same regime lets it, or the brokers who distribute its products, consume a consumer's fuller financial picture with consent, which supports faster, better-evidenced lending decisions. The lenders that treat CDR purely as a compliance burden will do the minimum and gain nothing. The ones that treat the incoming data as an asset, and build the automation to use it responsibly, will make sharper decisions and serve customers faster. This is the same shift toward data-driven, automated financial operations we cover in AI for mortgage brokers and application automation and in our broader guide to financial services AI compliance under APRA and ASIC.
What to Do Now
Given where the dates sit, the immediate priority is certainty about role and readiness. A non-bank lender that has not confirmed which wave it falls into, and whether it is a data holder, a recipient or both, should do that first, because product data obligations are already live and the consumer data-sharing dates are close. From there, the work is to build the data-sharing infrastructure and the consent handling as genuine, governed capabilities rather than as brittle scripts.
The discipline that makes CDR sustainable is the same discipline that underpins good data governance generally, and it connects directly to a lender's obligations under privacy law. A lender that has not tightened its handling of personal and financial data more broadly will find CDR harder than it needs to be, which is why it pays to read CDR alongside general Privacy Act compliance for AI in Australia. The regimes reinforce each other, and the same investment in structured data handling, consent management and audit logging serves both.
The honest strategic read is that open finance has arrived for lending, and the direction of travel is only one way: more sectors, more data, more expectation that a lender can share and consume financial data securely and on consent. A non-bank lender cannot match a major bank's compliance department, and it does not need to. What it needs is to treat CDR as the data-and-workflow problem it fundamentally is, and to let disciplined automation carry the volume so that its people can carry the judgement. The lenders that build the capability properly now, rather than bolting on the minimum to survive an audit, will find that the same infrastructure that satisfies the regulator also makes them faster and sharper in the market open finance is creating.
Related Reading
- Financial services AI compliance under APRA and ASIC
- AI for mortgage brokers and application automation
- Privacy Act compliance for AI in Australia
- APRA CPS 230 and operational risk for AI service providers
- Automated decision-making and privacy in 2026
- AI agent governance, data access and human override
This article is general information, not legal or compliance advice. Your obligations under the Consumer Data Right depend on your role, your data and your accreditation status. Confirm your obligations against ACCC and OAIC guidance and qualified advice.