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

• 3 min will be allowed for participants to join the call.
• This call is jointly facilitated by the ACCC and the DSB.

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.

Minutes

Standards Updates: from Clare, Director at the Data Standards Body Public Consultation on Planned Security Changes The proposed changes to security standards which focused on updates to the minimum baseline for authentication and alignment to FAPI 2.0 are in the final stages of development, and are expected to open for public consultation at the end of this month. The DSB will utilise their usual communication channels to notify participants when these changes are open for comment. A few key points: The consultation will formally be housed on the Treasury Consultations Hub, with the GitHub issue pages being updated with the link to the Treasury platform. Submissions can be made via the consultation platform. All public submissions will be published on that same page at the conclusion of the consultation period. The changes are being progressed as two separate changes, as each address different issues. As they propose changes to similar sections of the standards, they have been staged in tandem, and as such participants will be able to view the changes to the standards in the DSB staging environment together but provide comments to each set of changes separately. The minimum baseline changes also have corresponding impacts on the CX wireframes, and a link to view these will also be provided as part of the consultation. You are able to contact the DSB using our usual email address [email protected] if you have any questions or require any assistance. Additionally, as the next CDR Implementation Call on the 19th November will take place during the consultation period, we will be joined by the Data Standards Chair, Scott Farrell. NPP – Proposed Additional change targeted for April 2027 The DSB is currently preparing public consultation drafts for an additional change that is being targeted for inclusion in the April 2027 standards release. This change is to harmonise the NPP Payment Service enumeration fields to align with upcoming changes to the New Payments Platform. This change will ensure the standards align to the evolving NPP service model, harmonising Osko Service with Single Credit Transfer. This change has a very limited scope, focusing on the BankingTransactionDetail schema. The DSB is currently preparing materials to conduct public consultation on this proposal in November. Please don’t hesitate to contact the DSB for any further information on this proposed standards change, otherwise look out for further information in our channels around the public consultation timing. Type 8 and Type 9 Metering Arrangements An update on how the new Type 8 and Type 9 metering arrangements will interact with the CDR while the DSB considers whether any changes to the Energy Data Standards are needed. These metering types have been introduced through the Flexible Trading Arrangement reforms in the National Electricity Market. For Type 9 metering: this commenced on 31 May 2026 and supports approved alternative metering arrangements, including certain street furniture and public infrastructure connections. AEMO systems can support Type 9 metering through existing CDR service calls. Where a valid CDR request is made for a Type 9 NMI, the relevant data may be returned using the COMMS9 or COMMS9CM installation type codes. As an interim arrangement, we encourage participants to facilitate these values in relevant payloads. The DSB is considering how Type 9 metering data should be supported under the Standards and will provide further information once that work is complete. For Type 8 metering: Type 8 metering, which supports Secondary Settlement Points, this will commence on 1 November 2026. Secondary Settlement Points will not be included in CDR responses. If a CDR request is made for a Secondary Settlement Point, an InvalidServicePoint error will be returned in line with the current Standards. The introduction of Type 8 NMIs does not change the data currently available through the CDR and does not require changes to existing CDR services. These interim arrangements are intended to give participants clarity while implementation of the Flexible Trading Arrangements reforms progresses. We will keep participants informed of any further guidance or proposed standards changes. Questions For the planned security changes, will there be any indication of timeline in the consultation? The proposed changes will be consulted on for the 28 day period that could take place as soon as they open, likely the end of October through to the end of November or early December. They're also being proposed for the April 2027 release. As a preview, the intended future dated obligation for those standards changes, which is subject to consultation, is currently proposed for 12 months, which would come into force in April 2028. When you mention minimum baseline for authentication - is this referring to the TLS version? TLS version is not mentioned in the minimum baseline change, but is mentioned in the FAPI 2.0 draft change

⭐ indicates change from the last call.

Type	Update	Links
Standards	Current version of the CDR Data Standards is v1.36.0 (published 4 December 2025).	Change log Future Dated Obligations
Survey ⭐	Implementation Call Survey A short survey is now open seeking participant feedback on the future direction of the CDR Implementation Call in 2027. Insights gathered will help shape the future format, frequency, content and purpose of the series. Complete the survey here by 17 January 2027.	Implementation Call Survey
Information ⭐	DSB Domain and certificate changes The consumerdatastandards.gov.au and cds.gov.au domains and their associated certificates are being retired on 1 January 2027. Organisations should review any references to these domains and update bookmarks, systems, integrations and documentation before this date to avoid potential disruption. The domains currently redirect to dsb.gov.au and will continue to do so until their retirement. All references should be updated to dsb.gov.au prior to 1 January 2027.	dsb.gov.au
DSB Newsletter	Subscribe to the DSB newsletter for the latest news on consultations, workshops and key updates.	11 September 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
Question on Notice 1 (17/09/26)	Non-Bank Lenders	Instalment plans How should the standards be interpreted for instalment plan products offered by non-bank lenders where the product is not a Buy Now, Pay Later (BNPL) account? Existing standards references discuss instalment plans in the BNPL context, but the language does not explicitly limit the requirements to BNPL products, creating uncertainty about how other instalment-based lending products should be treated.	Since the previous call, the DSB has met with the requester to discuss the issue in more detail. The DSB is working with the ACCC on guidance to clarify the treatment of instalment plan products, which is intended to be published as a Support Portal article. Further updates will be provided once the guidance is available.
2777	General	Clarification on Deep-Link Registration, DCR Implications, and ADR/Data Holder Responsibilities for A2A Authentication ADR Deep-Link Registration and DCR Expectations Where an ADR intends to support an A2A journey and expose its own mobile deep-link destination as part of the authorisation experience: Given the expectation is such that ADR deep-link information be registered with Data Holders. If so, should this information be maintained through the existing DCR registration artefacts and processes? Would the introduction or modification of an ADR deep-link require the creation of a new DCR registration record, or is it expected to be accommodated within the existing registration framework without any DCR process changes? More generally, how should participants manage ADR deep-link information while maintaining alignment with the existing DCR model defined in the standards? Data Holder Deep-Link Behavior and ADR Interaction Expectations From an ADR perspective, we would also appreciate clarification on the intended role of the Data Holder's deep-link mechanism. Specifically: Within the authorisation journey, should an ADR expected be aware of, store, register, validate, or otherwise interact with the Data Holder's deep-link mechanism? Or should the invocation and management of the Data Holder's deep-linking behavior remain entirely within the Data Holder's implementation, with no additional ADR responsibilities beyond the existing authorisation flow interactions? Additionally, is there an expectation for the Data Holder to register their deep-link information with ACCC (directly or indirectly through existing participant registration mechanism)?	1. ADR Deep-Link Registration and DCR Expectations 1.1 Should ADR deep-link information be registered with Data Holders through the existing DCR process? For Redirect to App, the ADR app destination is managed as a registered redirect_uri, rather than as a separate deep-link registration artefact. Where an ADR supports both native app and web-based redirection, separate redirect URIs are required. The redirect URI used for the native app must support the claimed HTTPS URI mechanism. This continues to use the existing registration and DCR framework. 1.2 Does introducing or changing an ADR app Redirect URI require a new DCR registration record? Redirect to App does not introduce a separate DCR process. Changes to registered redirect URIs should be managed through the existing registration processes. A separate R2A-specific registration is not required solely because an app Redirect URI is introduced or changed. 1.3 How should ADR app redirect information be managed within the existing DCR model? ADR app redirect information should continue to be managed through the existing Redirect URI registration model. For a native app R2A journey, the applicable redirect_uri uses the claimed HTTPS URI mechanism to return the consumer to the ADR app. 2. Data Holder Deep-Link Behaviour and ADR Interaction 2.1 Does the ADR need to know, store, register or validate the Data Holder's deep link? The ADR does not need to separately register or maintain a Data Holder app deep link. The ADR continues to use the Data Holder's authorisation endpoint. The claimed HTTPS URI mechanism enables the Data Holder's native app to handle the authorisation request where the app is installed. Where the Data Holder app is not installed, the journey can continue through the applicable web authentication flow. 2.2 Does the Data Holder need to register its app deep-link URI with the ACCC Register? There is no additional requirement identified for a Data Holder to register a separate app deep-link URI with the ACCC Register for Redirect to App. The ADR continues to use the Data Holder's authorisation endpoint, while the association between the claimed HTTPS URI and the Data Holder's native app is managed as part of the Data Holder's implementation.
2775	Banking (DH)	Once-Off Authorisation Metrics – sharing_duration Threshold For consents that are exactly for 24 hours - Are they considered Once off or Ongoing?	The CDR Data Standards specify that where the sharing_duration value is less than or equal to 24 hours, one-time collection is assumed. Accordingly, a sharing_duration value of exactly 24 hours (86,400 seconds) should be treated as one-time collection.
2772	Banking (Data Holder)	Comparison Rates for DISCOUNT rate entries Could clarification be provided on whether we need to supply a comparison rate on lending rate entries of type DISCOUNT? DISCOUNT rates are documented in the standard as being applied to base rates. They are not standalone rates by themselves. Also, if multiple discounts are available it is possible to have multiple DISCOUNT rates reducing the base rate for the final effective rate. In this scenario it is not actually possible to calculate a comparison rate for these discounts because different combinations will produce different comparison rate. It is our understanding that the DISCOUNT rate entry (like PENALTY and INTRODUCTORY) was intended to advertise available variations to base rates under certain conditions and were not intended to be specific rates in their own right and, as such, were not intended to have comparison a rate. This interpretation is based on the statement that accompanies the definition of lendingType = DISCOUNT in the standards.	The DISCOUNT rate is a lending adjustment rate type. Lending adjustment rates are intended to communicate a value that’s added to or subtracted from a base rate. Therefore, a DISCOUNT rate is intended to communicate the size of the discount, not the rate that results from applying the discount. For similar reasons, it’d usually be meaningless to include a comparison rate in a BankingProductLendingRateV3 object whose lendingRateType value is one of the lending adjustment rate types. If a comparison rate has been calculated by applying a discount, then the comparison rate should be disclosed in the same object containing the base rate to which the discount applies. It's the data holder’s responsibility to determine whether and how any discount affects a comparison rate. As you suggested, it’s sensible to represent a discounted rate without necessarily using a DISCOUNT rate.
2745	Non-Bank Lender	How to represent a risk fee Can you provide some guidance on the best way to show risk fees, where the risk fee is x% of the loan amount and where x is determined by the LVR on the application?	In this situation, the recommended approach is to return an array of rate-based fees, each with appropriate LVR information in the additionalInfo field. This approach helps to communicate the relationship between the rates and LVR bands.

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 (17 September 2026): https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Minutes-%7C-17-September-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