ACCC & DSB | CDR Implementation Call Agenda & Minutes | 16 July 2026 - ConsumerDataStandardsAustralia/standards GitHub Wiki
Sign up: Sign Up
When: Third Thursday of the month at 3pm-3:45pm (Canberra time)
Location: Microsoft Teams (dial in details are below)
Join on your computer, mobile app or room device
Click here to join the meeting
Meeting ID: 487 742 173 354 95
Passcode: AN6KY2Lp
Dial in by phone
+61 2 9161 1229,,665346196# Australia, Sydney
Find a local number
Phone conference ID: 665 346 196#
- 5 min will be allowed for participants to join the call.
- This call is jointly facilitated by the ACCC and the DSB, and we welcome observers from APRA, OAIC and the Treasury.
We acknowledge the Traditional Custodians of the various lands on which we meet today and pay our respects to their Elders past and present.
The Consumer Data Right Implementation Calls are recorded for note taking purposes only. Recordings and transcripts are kept securely. No identifying material is provided without the participant's consent. Participants may email [email protected] with any questions or a request to have material redacted from the record.
By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.
Provides an update on the activities of CDR streams.
| Organisation | Topic | Member | Minutes |
|---|---|---|---|
| DSB | Expression of Interest for Informal Consultations in August on Proposed Security Changes focussed on minimum baseline authentication uplift and FAPI 2.0 alignment. Register your interest to participate via this EOI form. EOI will close on 31 July 2026. | Clare |
⭐ indicates change from the last call.
| Type | Updated | Links |
|---|---|---|
| Standards | CDR Data Standards v1.36.0 was published 4 December 2025. The release contains changes from Decision 376 (White label brand arrangements). | |
| Products ⭐ | A minor update to GetDataHolderBrandSummary V2, the API has now been updated to return all available Interim ID values. This ensures a complete and consistent response across all brand records and aligning the service with documented standards and expected behaviour. | |
| Media Release ⭐ | The ACCC has issued a media release regarding the commencement of new CDR obligations for non-bank lenders, requiring them to share product data including interest rates, fees, charges and eligibility criteria. | |
| Implementation Call ⭐ | New Implementation Call meeting series calendar invites will be sent on Friday, 16 July 2026. If you do not receive an invite by COB 16 July, please email [email protected] or register here. | |
| DSB Newsletter ⭐ | The DSB Newsletter publishes monthly on the Friday following the implementation call and will include a summary of discussions from the call. |
Questions will be received by the community via Microsoft Teams chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.
In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.
To view questions and answers from previous CDR Implementation Calls, click here.
| Ticket # | Sector | Question | Answer |
|---|---|---|---|
| Question on Notice 1 (18/06/26) | Energy (DH) |
Solar Sharer Offers (SSO) Do we have any updates on how retailers should manage the Solar Sharer Offers (SSO)? |
The EnergyPlanTariffPeriodV2.timeOfUseRates schema should be used to represent Solar Sharer Offers (SSO).Where an SSO includes a free electricity period, that period should be represented as a timeOfUseRates entry using the applicable time window and a unit price of zero.The DSB expects the free electricity period to use the OFF_PEAK value for timeOfUseRates[].type.Remaining charging periods should use the appropriate existing timeOfUseRates[].type values (PEAK, OFF_PEAK or SHOULDER) according to the applicable retail tariff.The timeOfUseRates[].type values describe the retail pricing periods represented in the Product Reference Data and do not need to correspond to the names used by the underlying network tariff.This guidance describes how Solar Sharer Offers should be represented using the existing schemas. It does not introduce any changes to the existing schema definitions or enumeration values. Guidance has been published under Guidance on Energy Plan Contract and related schemas |
| Question on Notice 2 (18/06/26) | Non-Bank Lenders |
Updating product guides When a non-bank lender updates product guides is there an expectation to retain the existing productIDs or can they be renewed? |
The Consumer Data Standards provide the following description for productID:‘A data holder-specific unique identifier for a Banking product. This identifier must be unique to a product but does not otherwise need to adhere to ID permanence guidelines.’If an existing product’s interest rate changes but the product is otherwise the same, data holders should retain the same productID instead of creating a new productid. However, the interest rate must be updated for the Get Product Detail endpoint, and the date/time of the update must be reflected in the lastUpdated field. The description for the lastUpdated field is: ‘The last date and time that the information for this product was changed (or the creation date for the product if it has never been altered).’For more information, see this Guidance on lastUpdated and lastUpdateTime fields. |
| 2714 | General (DH) |
Redirect to app - authorisation screens When redirect to app is implemented is it expected that customers should be able to navigate back and forth through the authorisation screens (Account selection --> confirmation)? |
The query relates to the Data Holder’s consent and authorisation flow, which occurs after the consumer has successfully authenticated. Redirect to App (R2A) versus Redirect to Web does not change the overall consent journey, including account selection and the authorisation steps. The design of the consent screens and how users move between them is implementation specific. This means Data Holders can determine whether users are able to navigate back and forward between steps such as account selection and the final consent confirmation screen. Implementations could allow users to go back and adjust selections prior to final confirmation, as long as the consent process has not been completed and the user has not been redirected back to the Data Recipient. The Consumer Experience (CX) Guidelines provides guidance for the Consent Model (Consent, Authenticate, Authorise, Consent Management and Notifications). A generalised example of the end-to-end flow can be viewed on The Consent Flow. This page also provides links to guidance regarding specific stages of the Consent Flow, this includes annotated authentication flows for Redirect to App and Redirect to Web with One Time Password. Also see: Authorise and Authorisation to disclose. |
| 2715 | General (DH) |
Redirect to app - customer not eligible for data sharing With redirect to app implemented it is not until the app has authenticated the customer that it is then possible to check eligibility. If the customer is not eligible for Data Sharing (e.g. due to age) what action is required? |
Where a Data Holder authenticates a consumer and subsequently determines that the consumer is not eligible to participate in CDR data sharing (for example, under CDR Rules r 4.5(1) and r 1.10B(1)), the authorisation process should not proceed. The Data Holder would be expected to terminate the authorisation flow and return an appropriate OAuth 2.0 / OpenID Connect error response in accordance with the applicable CDR standards and normative references, including:
|
| 2720 | General (ADR) |
Third party data sharing use cases Questions regarding the Third party data sharing use cases article: For scenario 1, it seems that the third party sharing authorisation is not a CDR consent, and that a request by an ADR for consent must not be combined with other requests except for a consent under the rules (CDR Rules, rule 4.10). Therefore the third party sharing authorisation must not be made at the same time as (bundled with) other CDR consents. In scenario 2, the guidance uses the language 'With consumer’s consent, ADR discloses data to a consumer’s account held with a third party', implying that this is a CDR consent. If the disclosure is to both the consumer and a third party, the guidance indicates that this is not a disclosure to the consumer only, so likely to be a mix of Scenario 2 and Scenario 1. In Scenario 2 and Scenario 1, does the use and collection consent need to be clearly attributed to the ADR and not a third party, or can the consent flow be 'whitelabeled' to the third party? Can the third party sharing consent for Scenario 2 be bundled with the collection and use consent? If separate to the collection and use consents, can consents for Scenario 2 and authorisations for Scenario 1 be bundled on the same screen? |
Scenario 1 in the guidance is premised on the consumer on-sharing their CDR data after this has already been disclosed to them by the accredited data recipient (ADR) - see under the heading ‘Scenario 1(a), (b) and (c) – Consumer decides to directly share their data with a third party’. We assume your reference to ‘third party data sharing authorisation’ refers to the consumer’s intervention e.g. by exporting the CDR data or configuring the ADR’s app/tool. If so, the intervention is not a CDR consent and a request to facilitate such an intervention cannot be combined with a request for CDR consents (see definition of ‘consent’ in rule 1.7(1), and rule 4.10 of the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules)). Scenario 2 in the guidance is premised on an ADR disclosing a consumer’s CDR data to the CDR consumer as part of a use consent as per rules 7.5(1)(a) and (d). That is, the disclosure is made to the consumer at an account they hold with a third party. If the third party needs the consumer’s permission to view the CDR data, it is more likely that this disclosure would be considered a disclosure to the consumer only (rather than a disclosure to both the consumer and a third party). While the guidance envisages a consumer providing a specific instruction to the ADR to disclose CDR data directly to the account they hold with the third party, it does not specify how this instruction can be made. It may be possible to incorporate this instruction as part of a request for a use consent, or it may be possible for an ADR to enable the consumer to provide that instruction elsewhere outside of the CDR consent flow. However, it is critical that consumers can make a clear and informed choice about the use of their data. ADRs should clearly explain to consumers that shared CDR data that leaves the ADR’s app/tool will be handled in accordance with any applicable privacy legislation outside of CDR such as the Privacy Act 1988, and that consumers should check the third party’s data handling policies such as their Privacy Policy. We encourage ADRs to carefully design consent flows and consider the impression they create in their interactions with consumers, to ensure they comply with the CDR framework, obtain informed consent and do not mislead consumers (noting the prohibitions against misleading or deceptive conduct under sections 18 and 29 of the Australian Consumer Law). For example, an ADR’s claims about a third party’s goods or services, or that third party’s data handling practices/policies must be true, accurate and based on reasonable grounds. While consent obligations sit with the ADR, there is some scope for an ADR’s CDR consent flow to include a third party’s branding, and we have published guidance on this – see Can ADRs ‘white label’ their products/services? |
| 2727 | General (DH) |
PAR maximum value for expires_in When sending PAR request, what's the maximum value for expires_in?We found CTS force it to be 10 to 90, but in the rfc doc, it has an example is 5 to 600. |
The Conformance Test Suite is applying a requirement that’s directly set by the CDR Standards. The Request Object Submission section, under Request Object, provides that the request URI must expire between 10 seconds and 90 seconds. This requirement supersedes any inconsistent statement in RFC 9126. |
| 2730 | General (DH) |
Expected Data Holder behaviour around CDR arrangement lifecycle Do Data Holders notify the Data Recipient when a CDR arrangement expires naturally (at expiry time), or only when the arrangement is explicitly revoked (e.g. stop sharing)? From the standards, it’s clear that revocation must be communicated, but it’s less clear how expiry is handled in practice. Could you please confirm whether: a notification is expected from the Data Holder on expiry, or the Data Recipient is responsible for handling expiry independently? |
I’ll use the terms “expire” and “expiry” to cover the cessation of a consent or authorisation for any reason. The CDR Rules set out various situations where a consent or authorisation expires as a matter of law. See rules 4.14 and 4.26 for further detail. Sometimes the expiry is caused by notifications between data holders and data recipients. For example, if an authorisation expires due to being withdrawn, then the data holder is obliged to notify the data recipient, which causes the corresponding consent to expire. In other cases, such as passage of time (or “natural expiry”), notification is not required to cause expiry or for any compliance reason. The CDR Standards have been developed with the above considerations in mind. As you mentioned, the Standards use the concept of a CDR arrangement to represent a valid consent and its corresponding authorisation. The Revoking Consents section, under Security Endpoints, deals with the matters of interest to you. Whenever a data recipient becomes aware that the consent has expired, they must notify the data holder by calling the data holder’s CDR Arrangement Revocation endpoint. Similarly, whenever a data holder becomes aware that the authorisation has expired, they must notify the data recipient by calling the data recipient’s CDR Arrangement Revocation endpoint. The Revoking Consents section outlines specific exceptions to this requirement. These exceptions generally cover the situations in the CDR Rules where notification is unnecessary. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
Thursday, 3:00pm (Canberra Time)
Minutes from the previous Implementation Call (18 June 2026): https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Minutes-%7C-18-June-2026
Implementation-related queries may be submitted at any time via the CDR Support Portal. These queries will be reviewed and responded to by an appropriate subject matter expert.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
| Data Standards Body | Consumer Data Right | Digital ID | Contact & Media |
| Chair | Standards | Accreditation Standards | Website |
| News | Maintenance Iteration | AGDIS Standards | |
| Advisory Committee | CX Guidelines | Calendar | |
| Support Portal | |||
| YouTube | |||
| GitHub | |||
| Newsletter |