Australia's Consumer Data Right (CDR) has expanded beyond banking and energy, with non-bank lenders having commenced product data sharing in July 2026. For IT and technology leaders in newly designated sectors, the focus must now pivot to architecture upgrades required to support upcoming consumer data obligations. Meeting these strict Data Holder requirements demands Financial-grade API (FAPI) standards, automated consent management, and robust operational security controls.
CDR Expansion Timeline: Non-Bank Lender Data Holder Requirements for 2026
At its core, the Consumer Data Right (CDR) requires designated businesses to securely share consumer data with accredited third parties via standardised APIs — but only when explicit consumer consent is provided.
13 July 2026 (Product Data): Product reference data sharing (rates, fees, and eligibility criteria) is now active across designated non-bank lenders.
9 November 2026 (Consumer Data — Initial Phase): Consumer data sharing commences for designated initial providers, covering account balances and transaction histories.
10 May 2027 (Consumer Data — Large Providers): Consumer data sharing obligations extend to designated large non-bank lenders.
To meet these obligations, your security and data exchange architecture must strictly comply with the Consumer Data Standards (CDS). The CDS explicitly mandates the use of Financial-grade API (FAPI) and OpenID Connect (OIDC) protocols to protect data at the highest level.
Technical teams will need substantial lead time to build, test, and authorise infrastructure via the ACCC Conformance Test Suite before the regulatory deadlines arrive.
Why the CDR Regime is Expanding into Non-Bank Lending
The Australian Government designed the Consumer Data Right (CDR) to give consumers greater control over their financial data, enabling them to compare financial products, streamline loan applications, and access better-value services.
Expanding the regime into the non-bank lending sector targets a substantial portion of the credit market. Incorporating non-bank lenders ensures consumers gain a complete picture of their major household liabilities, including mortgages, car finance, and personal loans.
Ultimately, the CDR is not merely a regulatory compliance exercise. The objective is to build a secure, economy-wide open data ecosystem that prioritises consumer privacy and actively prevents unauthorised access.
Designing a CDR Compliance Architecture: Core Technical Specifications
To operate as a Data Holder, standard API gateways are not enough. Your business must expose secure APIs that strictly adhere to the Consumer Data Standards (CDS). Your technical architecture must meet the following baseline specifications:
Security Protocol: The Financial-grade API (FAPI) 1.0 Advanced Profile is the mandated standard, superseding basic OAuth 2.0.
Authentication & Authorisation: OpenID Connect (OIDC) paired with Strong Customer Authentication (SCA) must be supported to verify user identity prior to data exchange.
Consent Rules: The CDS dictates granular data sharing with a strict 12-month maximum consent duration, requiring a dedicated, compliant consumer dashboard.
Information Security: Comprehensive data encryption (at rest and in transit) and rigorous token lifecycle management are mandatory under Data Standards Body (DSB) guidelines.
4-Step Compliance Checklist: Practical Action Plan for IT Teams
Meeting these stringent standards requires structured technical planning. IT and technology teams should structure their preparation around four operational steps:
Step 1: Audit and Upgrade API Gateways
Evaluate your existing infrastructure against the FAPI 1.0 Advanced Profile. Decide whether to retrofit current systems to support mutual TLS (mTLS) and token binding, or procure a dedicated, CDR-ready API solution.Step 2: Engineer Consent Lifecycle Logic
Build the backend mechanisms and frontend user interface for the consent dashboard. Focus on implementing active consent capture, automated 12-month expiry triggers, instant revocation workflows, and an immutable audit trail.Step 3: Execute ACCC Registration and Conformance Testing
Allocate engineering resources early to register on the ACCC Participant Portal. You must run the official Conformance Test Suite (CTS) to validate that your endpoints, authentication flows, and data payloads function correctly before production release.Step 4: Configure Operational Monitoring for NFRs
Deploy real-time performance monitoring to meet the Non-Functional Requirements (NFRs) set by the DSB. Establish robust protocols for tracking API latency, maintaining uptime SLAs, and ensuring rapid failure recovery.
Becoming a compliant Data Holder is a complex technical undertaking that requires the standardisation of your API infrastructure and rigorous security implementations. For complete technical specifications and implementation timelines, review the official Consumer Data Standards and the ACCC Participant Portal. Consulting with cybersecurity and CDR compliance specialists early is strongly recommended to ensure your technical architecture is fully prepared for the 2026 regulatory deadlines.
Official sources:
SHARE
