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
DSB	Update on the Informal Consultations on Proposed Security Changes focussed on minimum baseline authentication uplift and FAPI 2.0 alignment.	Clare	Following the call for expressions of interest in consultation on upcoming security changes, the DSB has engaged with stakeholders through more than a dozen consultation sessions on proposed authentication changes, with further discussions planned on alignment with FAPI 2.0. We greatly appreciate the time and expertise stakeholders have contributed to this process. Consultation activities are expected to conclude in the coming weeks, with feedback informing revised consultation drafts that are anticipated to be released for public consultation later this year. Stakeholders who have not yet expressed an interest in participating are encouraged to email [email protected] if they would like to be involved in the consultation process.
AEMO	AEMO API endpoint URL updates	Troy	AEMO provided an update on a project to enhance API security. AEMO confirmed that CDR participants will be using the new URLs as outlined in the Tech Specs. Different user groups within the National Electricity Market (NEM), Wholesale Electricity Market (WEM) and Gas sectors will also experience changes to API URLs. The security upgrade has already been implemented successfully in the pre-production environment and has been operating without issue. AEMO is targeting production implementation in September. AEMO noted that, following discussions with internal business owners, it sought to inform the forum of the upcoming changes.

⭐ indicates change from the last call.

Type	Updated	Links
Standards	Current version of the CDR Data Standards is v1.36.0 (published 4 December 2025).	Change log Future Dated Obligations
Tools ⭐	Product Comparator Demo The Product Comparator Demo has been updated, incorporating bug fixes and incrementing the API versions for brands/summary v2 and banking/products v7.	Product Comparator Demo Change log
DSB Newsletter ⭐	Subscribe to the DSB newsletter for the latest news on consultations, workshops and key updates. To ensure information is shared in a more timely and relevant way, the newsletter will now be published as needed rather than on a fixed monthly schedule.	17 July 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
2705	Banking (DH)	Redirect 2 Mobile Application (R2A) Based on the guidance provided - The Consumer Data Standards state that “If a data holder provides an app, the data holder MUST implement Redirect to App” (i.e., support App-to-App redirection for CDR authentication/authorisation). Is R2A a must only for brands supporting consumer app for CDR auth and not all the brands? Do we need to support the ‘Redirect to Web with OTP’ flow and build for Redirect to App?	The requirement to implement R2A applies to any data holder providing an app. For this purpose, an app is one that the data holder provides to consumers in the ordinary course of business (e.g., an app used for everyday banking). The app doesn’t need to serve a CDR-specific or data sharing purpose to trigger the requirement. The requirement to implement R2A applies on a per-brand basis. The requirement to support Redirect to Web with OTP applies whenever R2A or decoupled authentication cannot be used for authentication. It applies no matter the reason that R2A or decoupled authentication cannot be used, including reasons that are specific to the consumer (e.g., unwillingness to download the app). The CDR Data Standards currently permit decoupled authentication and will continue to do so past 10 May 2027.
2722	Banking (DH)	Deposit and Lending adjustment rates - PENALTY On reviewing the guidance related to lending adjustment rates, we have a query regarding penalty rates. Our understanding is that penalty rates represent additional rate components applied on top of the published base rates (variable or fixed), in accordance with the CDR specification. However, we have observed that the current CDR ecosystem does not appear to include any penalty rates for Residential Mortgage products. Could you please confirm whether our understanding is correct, and provide clarification on how penalty rates should be represented?	Some organisations may offer products that include penalty rates and others may not. For regulatory reasons unrelated to the CDR, you may observe that penalty rates are less prevalent in residential home loan products compared to other kinds of credit. Where the CDR Data Standards say "A penalty rate increases the interest payable", this should be understood as the effect of specifying a penalty rate. It's not a statement requiring there to be only one base rate or the use of penalty rates whenever there's more than one applicable rate. The Standards don't define the circumstances in which a penalty rate applies. The expectation is that a penalty rate is specified whenever it makes sense in the context of a product's terms and conditions. One relevant situation might be a default on some kind of obligation, such as a payment being late or missed.
2712	Banking (DH)	Transaction detail end point relevance to credit cards Is the transaction detail endpoint required for credit card accounts? The additional fields shared by the transaction detail endpoint (BankingTransactionDetailV3) are not relevant to credit card transactions. This is with the exception of BankingTransactionV2 schema, which can be separately accessed as part of Get Transactions For Account.	The Transaction Detail endpoint is intended for Osko payments. As outlined in the DSB guidance article, Get Transaction Detail X2P1.01 mandatory fields, the Transaction Detail payload is designed around transaction detail information that is only applicable in certain circumstances. Where a data holder does not hold transaction detail information for a transaction, the BankingTransaction response allows the data holder to indicate this by setting the isDetailAvailable field to false. In those circumstances, any request to retrieve transaction detail information for that transaction via the Transaction Detail endpoint should return a 404 Not Found response. For further information, please refer to: Get Transaction Detail X2P1.01 mandatory fields – Consumer Data Standards Australia
2735	Banking (DH)	Clarification on the use of the MAX_LVR constraint In relation to the guidance on Multiple LVR constraints not differentiated by rate Where the available rates for a product are differentiated by LVR: - Can a MAX_LVR constraint be used in the absence of maximumValue for a subset of PERCENT tiers, in which case the MAX_LVR would be assumed to apply wherever maximumValue is null? - Or are the tiers expected to fully define the LVR bands, i.e. every tier must have a minimumValue and maximumValue, and the MAX_LVR (if present) should be equivalent to the absolute maximum accross all tiers?	I can confirm that the second approach you outlined applies in this situation. If a product has multiple rates that are differentiated by LVR bands, then the minimumValue and maximumValue fields for each tiers object are expected to be present and populated. In this case, it’s not necessary to include a MAX_LVR constraint, but there’s generally no issue with doing so. If it’s included, it’s taken to specify a maximum LVR that applies to the product as a whole.
Verbal Question 1	General (DH)	In the Get Transaction API response, the transactionId field is currently returned conditionally based on the value of isDetailAvailable. As per the standards, the field is optional when isDetailAvailable is false. As a Data Holder, we do maintain the Transaction ID for the relevant account and transaction. However, in scenarios where isDetailAvailable is false, we currently return a null value for the transactionId field in the API response. Could you please confirm whether we can continue operating in this manner, or whether it is mandatory to return the transactionId whenever it is available, irrespective of the value of isDetailAvailable? There appears to be some ambiguity in our interpretation of the standard, and we would appreciate clarification. If the expectation is that the transactionId must be returned regardless of the value of isDetailAvailable, we have an additional concern. Historically, for transactions where isDetailAvailable was false, ADRs would not have received a Transaction ID from our side. As a result, some ADRs may have implemented logic to generate and maintain their own identifiers for such transactions. In that scenario, if we begin sending the Transaction ID now for those transactions, is there a risk of duplicate transaction records or identifier conflicts being created on the ADR side? We would appreciate guidance on how such cases should be handled and whether any transition considerations need to be taken into account. Please let us know your recommendation on how we should proceed.	Taken on notice
Verbal Question 2	General (ADR)	I noted that when we registered as an ADR, we provided an enterprise-level email address and understood it would primarily be used as a contact point for communications from the ACCC. However, we have since observed that the email address is displayed to consumers, resulting in customer enquiries being directed to an address that we would not normally use for direct customer contact. I asked whether the ACCC has a position on this practice. If the registered email address is intended to be publicly visible and used by consumers, it would be helpful for this to be made more explicit during the registration process, as we may have chosen to provide a different email address for that purpose.	The ACCC noted that it would need to consult with the registrar team regarding the purpose of registered contact email addresses, whether those details are intended to be publicly disclosed, and how they are managed within the relevant systems and made available to ADRs. The ACCC acknowledged the concern that an email address provided for one purpose may be used for another and agreed that this may not be the intended outcome. The participant was invited to send the details to the [email protected] inbox, and the ACCC would refer the matter to the appropriate team for consideration and provide further advice on available options.

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 (16 July 2026): https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Minutes-%7C-16-July-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	Email
Advisory Committee	CX Guidelines		Calendar
	Support Portal		LinkedIn
			YouTube
			GitHub
			Newsletter