Sign up: Sign Up
When: Fortnightly on Thursday's at 3pm-4:30pm (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: 426 030 545 881 4
Passcode: 5d7Kp73X
Download Teams | Join on the web

Dial in by phone
+61 2 9161 1229,,538826932# Australia, Sydney
Find a local number
Phone conference ID: 538 826 932#

Join on a video conferencing device
Tenant key: [email protected]
Video ID: 135 792 992 7

---

1. Introductions
2. House Keeping
3. CDR Stream updates
4. General Updates
5. Presentation
6. Q&A
7. Any other business

• 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 a weekly update on the activities of each CDR stream and their work.

Organisation	Stream	Member
DSB & ACCC	Participant Journey Map Yesterday's Data Holder Workshop Summary Next Wednesday's Data Recipient Workshop	Bikram

⭐ indicates change from last week.

Type	Updated	Links
Standards	Version 1.35.0	Published: 29 July 2025 Change log
Maintenance ⭐	Maintenance Iteration 24 The next call will be held on 20 August 2025. You can stay up to date on the discussion by checking out the meeting notes in Consultation Draft 373.	Sign up Consultation Draft 373
DSB Newsletter ⭐	The DSB Newsletter is published fortnightly, the next edition will be published on August 22 2025	8 August 2025 Newsletter Subscribe
Guidance ⭐	CX Guidelines update - Expanding amending business consumer disclosure consents Updated Amending business consumer disclosure consent artefacts and requirements to reflect Change Request 691: CX Guidelines - Expanding Amending BCDC CX Guidelines. This includes new artefacts for amending bundled collection, use and disclosure consents for business consumers, as well as updated standards and guidelines. For more information, see the change log These guidelines provide examples for how to implement amending consent scenarios.	Amending business consumer disclosure consent
Guidance ⭐	The July edition of the ACCC's Compliance and Regulatory Bulletin (The CURB) can be found here: The CURB - July 2025. Read our latest compliance review report and/or subscribe to the CURB.	The CURB - July 2025

None this week.

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.

Ticket #	Question	Answer
2337	Discovery of public DH endpoints for Energy The authoritative way to discover public DH endpoints seems to be by manually accessing a PDF file from the AER web site. The URL for this resource has changed multiple times requiring manual work to regularly find and check the file. Is there a way to have an authoritative source of this resource that is programmatically accessible?	The DSB is exploring options to address this, and there is a maintenence issue related to it - Update Register API to return separate PRD and status/outage endpoint.
2384	jwt-based response when cancel authentication When implement PAR request, and we only support code in response types, when the ADR sends invalid response_type, and we should return an error. Should it be JSON format error like describe here: https://www.rfc-editor.org/rfc/rfc9126.html#name-error-response? Or it should be a jwt-based?	The error should be a JWT as stated in the normative standard - 2.3. Error Response The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in Section 5.2 of [RFC6749] Where the response type is code and mode is jwt, FAPI also requires JWT responses as specified by JARM.
2460	Additional Service Point Data in Service Points APIs Could the below be considered for inclusion in future versions of the API? Transmission/Marginal Loss Factor (TLF/MLF) Transmission Node Identifier (TNI) (related to the MLF) Metering Data Provider (MDP)	The loss factor information (first two points) is likely to be included in the EnergyServicePointDetailV2.distributionLossFactor object. MDP was originally proposed to be included but was removed based on feedback from AEMO noting that most participants would only be interested in Financially Responsible Market Participant (FRMP), Local Network Service Provider (LNSP) or Distribution Network Service Provider (DNSP). If there is a need to have MDP included we would need to raise a change request via the maintenance iteration process.
2551	SMSF Product Can you confirm if Non-Banks are required to supply SMSF-related products, e.g., SMSF Mortgage product? The existing Banking CDR Products seem to exclude any SMSF Mortgage products.	Our understanding is that a SMSF is a type of trust that may have either individual trustees or a corporate trustee. Whether an initial or large non-bank lender would have CDR data sharing obligations for SMSF accounts depends on two factors: who is the relevant CDR consumer for the SMSF product (i.e. whether an eligible CDR consumer is an individual or non-individual); and whether the SMSF product is a CDR ‘covered product’ and therefore CDR data sharing is required. Individual or non-individual consumer and their related consumer data sharing obligations Where the eligible CDR consumer for the relevant account is an individual, consumer data sharing obligations may apply to initial and large providers in regards to covered products according to the timeframe provided in the CDR Rules (see section 3.2.1 of the Compliance guide for data holders in the banking and non-bank lenders sectors). Where the eligible CDR consumer for the SMSF trust account is a non-individual or partner in a partnership, the CDR consumer must appoint a nominated representative before consumer data sharing related to that account can commence (see Trusts and nominated representatives in the CDR). However, data sharing obligations do not currently apply to complex requests for data holders in the non-bank lenders sector. This includes consumer data requests that are made on behalf of a CDR consumer that has a nominated representative (see section 3.1.1 of the compliance guide for guidance on complex requests). This means data holders in the non-bank lenders sector do not currently have consumer data sharing obligations in relation to products held by consumers who are not individuals or a partner in a partnership. The explanatory statement notes that the policy intent of carving out complex requests is to avoid unnecessary or duplicative compliance burden for how non-bank lenders may be required to comply with this obligation in the future. Covered product In relation to whether a SMSF product is a covered product, we refer to the article on assessing whether a banking or non-bank lending product is in scope for CDR. Under the CDR Rules, a banking or non-bank lenders product will be a ‘covered product’ if it satisfies the below three factors: the product is generally known as being a type of product listed in clause 1.4 of Schedule 3 of the CDR Rules, the product is publicly offered by or on behalf of a data holder, and the product is offered to consumers through a standard form contract. Initial and large providers in the non-bank lenders sector are required to disclose product and consumer data for covered products in accordance with the timelines set out in clauses 6.4 and 6.5 of Schedule 3 of the CDR Rules (except for products listed in cl s 3.1(2) and 3.2(3) of Schedule 3 of the CDR Rules). If a product is not a covered product, no CDR product or consumer data sharing obligations apply for that product. We note that data holders are responsible for compliance with their CDR obligations. The information contained in this response is guidance only and does not constitute legal advice. We suggest you obtain independent legal advice where necessary.
2563	nppPayload - Service In relation to New Enums for Voluntary disclosure of additional service overlays #664: Can Service be null if nppPayload has data within it? There are old transactions where this field currently doesn't have information, and would like to know what is expected - a 5xx error or can we add in the null value?	You cannot provide a null for a mandatory field. Some related guidance - Handling transaction detail extended data when NPP is not supported: 404 Get Transaction Details Error Returned
2566	Guidance on Rule 4.26(1)(h) part 4, Division 4.4 The rule states: (1) An authorisation to disclose particular CDR data to an accredited person expires at the earliest of the following: (h) if the authorisation expires as a result of the operation of a provision of these rules that references this paragraph. Note: Clause 7.2 of Schedule 3 is an example of a provision satisfying paragraph (h). This relates to when an accredited data recipient of CDR data becomes instead a data holder of that CDR data. Is the “authorisation to disclose” in respect to this rule referring to disclosure consents? So if we had collected disclosure consent, it would expire once we act as a DH instead of ADR for that data sharing arrangement?	The intent of rules 4.14(5), 4.26(1)(h) and clause 7.2 of schedule 3 is that accredited bank or non-bank lenders who become data holders of CDR data because they satisfy the conditions in clause 7.2 of schedule 3 should still be able to: continue collecting CDR data where a collection consent and authorisation is in place, and use or disclose the data as a data holder. On that basis: relevant collection consents and authorisations remain current for the period consented to / authorised by the CDR consumer use and disclosure consents expire, however the relevant person can continue to use / disclose the data as they ordinarily would as a data holder. This allows accredited persons to continue to collect CDR data and hold it as a data holder where the conditions specified in clause 7.2 of Schedule 3 of the CDR rules are met, and then use / disclose the data as they ordinarily would as a data holder. Treasury is currently considering how this can be clarified in a future version of the CDR rules.
2571	CDR Specifications not matching deployed API The current CDR standards reference that the latest Endpoint version is 2. Calling https://api.cdr.gov.au/cdr-register/v1/banking/data-holders/brands/summary using x-v: 2 returns an error. However x-v: 1 returns the expected result. How do you determine what version is deployed?	The standards always show the latest specification available, but as these are generally defined as Future Dated Obligations (FDOs) the latest version specified will not necessarily be the version made available by a participant at that time. The FDO table explains the obligation dates for particular versions. The versions and dates of ACCC obligations (in particular Register endpoints) are not defined in the FDO list, but the endpoint version schedule provides detail of all versions and their associated dates. As the page notes, the ACCC will provide details of availability in due course, as noted here. Where an unsupported version is requested, the standards state that participants MAY provide detail of the versions supported through the error response, but it appears the Register does not currently do this.
2573	Register APIs implementation dates CD367 has mentioned updates to “Register” APIs. When will the new version be implemented and the old ones demised? Would we receive any separate communication on the same, or if it’ll be published on github?	The Standards will sometimes show future versions of endpoints that participants are required to make available by a Future Date (an 'FDO'). This is the same for future versions of Register APIs. The date details for all endpoints are shown in the following sections: Register Implementation Schedule Endpoint Version Schedule The Standards do not specify obligation compliance dates for the Regulator, so these are provided separately by the ACCC.

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)

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	Email
Advisory Committee	CX Guidelines		Calendar
	Support Portal		LinkedIn
			YouTube
			GitHub
			Newsletter