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#

---

1. Introductions
2. House Keeping
3. CDR Stream updates
4. General Updates
5. Q&A
6. 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 an update on the activities of CDR streams.

Organisation	Topic	Member	Minutes

⭐ 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). There are 2 Future Dated Obligations approaching on 13 July 2026: Get Products v5 Get Product Detail v7	Change log Future Dated Obligations
Guidance ⭐	New guidance has been published on Understanding Product Base URI and URI Structure for Product Reference Data. The guide explains what a product base URI is, how to correctly construct URIs for API endpoints defined by the standards, and how a data holder is expected to enter product base URI information for each of its brands in the Participant Portal.	Guide
DSB Newsletter ⭐	The DSB Newsletter publishes monthly on the Friday following the implementation call and will include a summary of discussions from the call.	22 May 2026 Newsletter Subscribe

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
21/05/26 Verbal Question 1	Banking (DH)	We think there is a small inconsistency in the Consumer Data Standards (since the CDR Rules were amended on 04 March 2025). Prior to these amendments, a customer may have been able to share their customer data (and address book) without needing to select an account. With the change in Rules such that a customer MUST select an account we think the line in bold below should be removed from the Standard. Section: Authorisation Standards Authorisation: Account selection Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees). The provision in the rules is Clause 3.2 of Schedule 3.	Updated response: The DSB has reviewed the provisions you mentioned and formed the view that there is no inconsistency. As such, we are not considering a CDR Standards change to remove references to data that is not specific to an account. We acknowledge that the Amending Rules may have caused some confusion. Those rules introduced the concept of a “relevant account” to clause 3.2 of Schedule 3 to the CDR Rules, the provision that determines the meaning of “required consumer data” in the banking and non-bank lending sectors. However, the Explanatory Statement to the Amending Rules confirms that this change “is not intended to affect the practical operation of how consumer data will continue to be shared” in those sectors (paragraph 34). Therefore, in line with the situation before 4 March 2025, the DSB does not interpret the current clause 3.2 to require a CDR consumer to select an account in every case.
21/05/26 Verbal Question 4	Non-Bank Lenders	Question raised regarding whether non‑bank lenders planning to go live ahead of the 13 July milestone could seek an exemption from the pre-July 13th reporting requirement, noting concerns that early reporting would be of limited value and may discourage earlier participation.	Updated response: The outcome of the ACCC's consideration is that a non-bank lender data holder that commences product data sharing prior to 30 June 2026 will be required to complete its biannual report in the participant portal for the 1 January to 30 June 2026 period. The ACCC will provide targeted support to any data holder who commences product data sharing prior to 30 June 2026 to support the completion of the report. The ACCC has broad discretionary powers under section 56GD to exempt a person in relation to particular CDR data, or from one or more classes of data, or from all or specified provisions of the CDR. Participants considering whether an exemption may be relevant to their circumstances should carefully review the Guidance for applicants seeking exemption under section 56GD that sets out the approach the ACCC will take in relation to applications for exemption from provisions of the CDR.
2706	General (DH)	Products need to be listed by last_updated_time, if a Data Holders system updates all products at the same time, is there a secondary field that could be listed by if last_updated_time is the same?	The lastUpdated field represents the timestamp of the most recent update applied to a product and is typically expressed in ISO 8601 format, for example: "lastUpdated": "2026-05-20T14:25:30Z" As outlined in the Data Standards, product records include a lastUpdated timestamp (e.g. "lastUpdated": "2026-05-20T14:25:30Z"), which is used both for ordering and for incremental retrieval via the updated-since query parameter. The specification indicates that responses from the Get Products endpoint are expected to be ordered in descending order of lastUpdated, with the most recently updated products appearing first. It also allows clients to request only those products updated after a given point in time using updated-since. In practice, because the timestamp includes date and time (and may be implemented with sufficient precision), the likelihood of multiple products sharing the exact same lastUpdated value is generally low. In cases where multiple products are updated at the same time (for example, batch updates), the standards do not prescribe a secondary sorting field. In these situations, products can be returned to the order determined by the data holder’s implementation. Where the API already provides results in a consistent descending order by lastUpdated, this ordering can be relied upon. There is no requirement in the standards to introduce an additional field solely to differentiate between records with identical timestamps. Accordingly, a consistent ordering approach (supported by the existing lastUpdated field and updated-since filtering) is considered sufficient for predictable and reliable retrieval of product data.
2707	General (DH)	Pushed Authorisation Request 90-second expiry Under the CDR rules, is it permissible to validate the 90-second Pushed Authorisation Request (PAR) request expiration strictly at the initial point of user interaction (e.g., when the user first authenticates and hits the account selector), or is it a compliance requirement to enforce that 90-second window through to the final step of the authorisation journey? Alternatively, would introducing a backend grace period or omitting the expiry check at the final step be considered compliant?	In the CDR Standards under the "Request Object Submission" section it specifies the expiry time of the request uri, i.e. "The Request URI MUST expire between 10 seconds and 90 seconds." This means that once the client (DR) makes a request to the AS (DH's) PAR endpoint, it will receive the request URI as well as the "expires_in" field, E.g. HTTP/1.1 201 Created Content-Type: application/json Cache-Control: no-cache, no-store { "request_uri": "urn:mtls.dh.example.com:bwc4JK-ESC0w8acc191e-Y1LTC2", "expires_in": 90 } The expires_in value must be within the range of 10–90 seconds as specified above. The client (DR) then formulates this request_uri into the redirect and sends the user to the authorization endpoint of the AS (DH). KEY POINT REGARDING "expires_in" FIELD The 90-second expiry defines the validity window of the request_uri from the time it is issued by the PAR endpoint until it is first used at the authorization endpoint. It does not include the duration of the user authentication and consent journey that follows after the authorization request has been successfully initiated. In practice, the DH validates the request_uri expiry when the authorization request is received at the authorization endpoint. If the request_uri is valid at that point, the PAR request is accepted and the authorization flow continues independently of the PAR expiry timer. So it is appropriate to enforce the expiry check only at the point the request_uri is first processed at the authorization endpoint, rather than re-validating it at later steps in the user journey. As per above, no grace period should be necessary if the redirect from the client (DR) to the AS (DH) is performed within the required timeframe (as specified by the expires_in field).
Verbal question 1	General (DH)	In the NFR standards it refers to how frequently ADRs can call data holders. There's a particular term in that standard, which we are finding is being interpreted differently by different data holders. The particular NFR I'm referring to is the limit of 20 sessions per day. So there's an unintended traffic NFR that says that you are allowed for unintended traffic 20 individual sessions per day Session refers to tokens which generally have a lifespan of 5-15 minutes depending on the data holder. Effectively what this is saying is you can have up to 20 of those per day per customer. But it's the per customer part that seems to be open to interpretation because customer isn't really a concept or an entity from an authentication perspective. We are seeing some data holders interpreted as 20 sessions per arrangement. We've seen others interpreted as 20 sessions per customer as far as the data holder is concerned. And quite often as an ADR, we don't get to see what that information is. A suggestion that will be raised in Github to amend the standards to refer to 20 sessions per arrangement per software product.	Background context: That line was written when the standard said that there could only be 1 consent per customer at a time, per data holder ADR. So at the time, the concept of arrangement didn't exist and customer was equivalent to arrangement. Since then, there was a decision proposal to change that and allow multiple arrangements for a customer and ADR data holder combination. So the original intent of that was per arrangement.
Verbal question 2	Energy (DH)	Do we have any updates on how retailers should manage the Solar Share Offer (SSO) and impact on CDR information API return? In reference to Issue 719	Question taken on notice
Verbal question 3	Non-Bank Lenders	When a non-bank lender updates product guides (when we update interest rates, we have to update documents in the website), what is the expectation from the ACCC on timeframes for updating the existing products on the CDR portal? Is there an expectation to retain the existing productIDs or can they be renewed?	Taken on notice by ACCC Comment from a consumer of product reference data: We rely on those product IDs. If you change the product ID, it's effectively a different product. There's no way of relating it to the previous iteration of their product. So if you change the product IDs and it isn't a different product, then the people that are using this data to help you potentially sell your products will get confused. So it's in the best interest of data holders to keep the product IDs consistent if it's the same product. If you change the rates, you need to update the CDR data.

Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.

Minute

There is currently 1 more call in the calendar for July. The DSB will be sending out further invites, if you have previously signed up for the call you will receive the new batch of invites. We welcome your feedback on how these calls can best meet your needs. In particular, we are interested in the topics you would like covered, as well as any suggestions regarding the agenda structure or meeting frequency. Please share your feedback and ideas by emailing [email protected].

Thursday, 3:00pm (Canberra Time)

Minutes from the previous Implementation Call (21 May 2026): https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Minutes-%7C-21-May-2026

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