ACCC & DSB | CDR Implementation Call Agenda & Minutes | 17 September 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#
- 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.
| Organisation | Topic | Member | Minutes |
|---|---|---|---|
| DSB | Update on the outcomes of its consultation on proposed reforms to the development and delivery of regulatory data standards. Consultation Outcomes Paper Regulatory Data Standards Development Framework |
Clare | Clare advised that the DSB has published the consultation outcomes for its standards development reforms consultation. Stakeholder feedback was broadly supportive of the proposed reforms, particularly the move towards a more transparent, predictable and proportionate approach to standards development. The published outcomes paper includes an overview of the consultation process, key feedback themes, and the DSB's responses to issues and insights raised by stakeholders. Clare also advised that the DSB has published the Regulatory Data Standards Development Framework. The framework establishes the DSB's overarching approach to developing, maintaining, consulting on, publishing and implementing regulatory data standards. She thanked stakeholders who participated in the consultation process and noted that the DSB welcomes ongoing feedback as the reforms are implemented. |
| AEMO | AEMO production implementation dates for the API Uplift Project | Tommy | Tommy from AEMO provided an update on the API Uplift Project, advising that a number of internet-facing APIs are transitioning to new URLs. He noted that two CDR APIs are affected by the change and directed participants to supporting documentation (4 API Changes) outlining all impacted APIs. Participants were advised that the new production URLs will go live on 23 September 2026 and will operate concurrently with the existing URLs until their scheduled decommissioning in December 2026. Tommy encouraged participants who have not yet commenced pre-production testing to do so as soon as possible to support a smooth migration. He also recommended that organisations plan and undertake migration to the new production URLs as early as practicable following go-live to minimise risks associated with the eventual decommissioning of the existing URLs. Tommy advised that AEMO will continue to support participants during the transition, you can get in touch via email at [email protected] for any implementation or migration queries. |
⭐ 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). | |
| Guidance ⭐ |
Uplifted CDR guidance The ACCC is in the process of updating their CDR guidance to improve readability and accessibility. This includes restructuring content, including diagrams, using more concise language and revising titles to enhance searchability. The ACCC has now published the first tranche of recently revised guidance on:Over the coming months, the ACCC will continue to update our guidance to improve accessibility and the use of plain English. We encourage CDR participants to review the updated guides and welcome any feedback about the changes. |
|
| Tools ⭐ |
Postman Workspace Update The Postman domain has been renamed from winter-shadow-54100 to data-standards-body, and the workspace previously known as DSB-SCHEMA-TESTS is now cdr-tests. Stakeholders should update any saved bookmarks or links to use the new workspace URL. |
|
| DSB Newsletter ⭐ | Subscribe to the DSB newsletter for the latest news on consultations, workshops and key updates. |
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 |
|---|---|---|---|
| 2756 (Question taken on notice from 20 August Implementation Call) | General (DH) |
Clarification on the Get TransactionID API response 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. |
The Get Transactions response schema defines transactionId as a conditional field and specifies that it is mandatory when isDetailAvailable is true. Where isDetailAvailable is false, the field is not mandatory.In addition, the CDR Standards Payload Conventions state that: "If the field is optional a null value or omission of the field in the response is accepted."Based on the current Standards, the DSB's view is that where isDetailAvailable is false, a Data Holder may either:
null value for transactionId when isDetailAvailable is false is consistent with the Standards and Payload Conventions.For reference, the transaction schema is available under the Banking Transactions API definitions in the Consumer Data Standards: Get Transaction Detail – CDR Data Standards. As the current implementation is consistent with the Standards, the DSB is not recommending a change in behavior. Consequently, the transition concerns raised regarding ADR handling of newly populated transaction identifiers do not arise from the current Standards interpretation. The CDR Rules and Standards are revised from time to time. Parties should ensure that they consult the current version of the CDR Rules and Standards to understand their obligations, and consider the need for independent professional advice to assess whether a particular implementation is compliant with the CDR legislative framework. We trust this clarifies the intent of the Standards. |
| 2751 | Data Holder |
Clarification on Transaction ID Handling When isDetailAvailable is False In the Get Transaction API, the transactionId field is currently returned conditionally based on the value of isDetailAvailable. Our understanding is that the field is optional when isDetailAvailable is false. Where isDetailAvailable is false, can it be omitted (or returned as null), or is the expectation that transactionId must always be returned whenever it exists, regardless of the value of isDetailAvailable? If the identifier must now be returned in all cases, are there any transition considerations for ADRs that may have historically received transactions without a transactionId and implemented their own identifier logic? Specifically, could the introduction of a provider-supplied transactionId for existing transactions create a risk of duplicate records or identifier conflicts, and if so, how should these scenarios be managed? |
Where isDetailAvailable is false, transactionId is optional under the Data Standards. A Data Holder is therefore not required to return transactionId in this scenario. The data holder storing an internal transaction reference is evidence that the transaction is uniquely distinguishable, but this is NOT the data called for by transactionId. Due to how ID permanence works, different ADRs of the same consumer are entitled to expect different transactionId values. Therefore, the data holder should generally not disclose their internal references when transactionId is mandatory. Please also refer to the following guidance: Guidance on ID permanence for further information. |
| 2767 | Data Holder |
Redirect to App and webview implementation Clarification is sought on the implementation of Redirect to App for a Data Holder. Two implementation approaches have been identified, One is app native for the whole consent creation journey and one is partially native/partially webview embedded within the app. Guidance would be appreciated on whether presenting account selection and consent confirmation within an embedded webview, after native authentication, meets the requirements and intent of the Consumer Experience Standards. |
When implementing Redirect to App, it is at the data holder's discretion how the authorisation experience is delivered, provided it complies with the relevant consumer experience authentication and security profile standards. In particular, Security Profile, Authentication Flows, Redirect to App, Data Holder states that: Data holders MUST support Redirect to App in accordance with the Authentication Schedule, and: After authentication, the data holder MUST continue the authorisation flow within the data holder app. The standards do not prescribe how the authorisation experience must be implemented within the data holder app. For example, they do not specify whether the experience must be delivered through native app screens, embedded web content, or a combination of both. However, the authorisation flow must continue within the data holder app and comply with all applicable consumer experience and security requirements. |
| 2763 | ADR |
Cache Update using Get Data Recipients only Can we implement the Cache relaying only on GetDataRecipients API with an interval of refresh period 2-5minutes. i.e., instead of calling GetDataRecipientsStatus & GetSoftwareProductsStatus APIs with an interval of refresh period 2-5minutes and calling GetDataRecipients API with an interval of refresh period 6 hours, is it feasible approach to poll only GetDataRecipients of 2-5minutes. |
The approach is technically feasible as GetDataRecipients includes Data Recipient and Software Product status information. However, this is not the recommended approach. The Standards/design do not appear to treat it as a replacement for the dedicated status APIs. GetDataRecipientsStatus and GetSoftwareProductsStatus are the dedicated status APIs and should continue to be polled at the recommended 2–5-minute interval. This supports the requirement for Data Holders to react to Data Recipient and associated Software Product status changes within 5 minutes. GetDataRecipients contains broader Data Recipient, brand and Software Product information which changes less frequently, and the recommended cache refresh period of 6 hours. Therefore, we recommend continuing to use GetDataRecipientsStatus and GetSoftwareProductsStatus for frequent status updates, and GetDataRecipients for the broader participant information, rather than replacing the dedicated status APIs with polling GetDataRecipients every 2–5 minutes. Existing DSB guidance is available here: Data Holder cache update periods – Consumer Data Standards Australia |
| 2761 | NBL (Data Holder) |
Clarification on returning BNPL product category in an earlier x-v version Clarification is sought on how Buy Now Pay Later (BNPL) product features should be represented when they do not align with any existing value in the BankingProductFeatureType enum under the Product Reference schema (GetProducts / GetProductDetail). Some product types may include features that are not accurately captured by any of the currently defined featureType enum values. Two possible approaches have been identified: Suppress the feature by omitting it from the features array where no suitable enum value exists. Use OTHER to represent the feature where it falls outside the defined taxonomy. Could you please clarify the intended approach in this scenario? Specifically, should data holders omit features that cannot be mapped to an existing enum value, or is the OTHER enum intended to be used for product-specific features that are not represented in the current taxonomy? |
Currently, BNPL products are supported as a recognised product category within the Product Reference APIs. The BankingProductCategoryV2 enumeration includes the BUY_NOW_PAY_LATER value, and BNPL products should be disclosed using the product category definitions applicable under the Consumer Data Standards. Your question appears to relate specifically to the representation of product features within the features array of the Product Reference response. In this regard, the standards define a fixed set of values in the BankingProductFeatureV4.featureType enumeration, including the value OTHER. Where a product feature does not align with one of the specifically defined feature types, the standards provide an OTHER enumeration value together with associated descriptive fields. In particular, the standards indicate that additionalInfo is mandatory when featureType is set to OTHER. However, the DSB is not in a position to provide implementation or compliance advice regarding which specific featureType value should be selected for an individual participant's product offering. It remains the responsibility of each participant to determine how best to disclose their product features in accordance with the Consumer Data Standards and their own compliance obligations. |
| 2752 | Data Holder |
Logo URIs Could you please provide size, file type, definition and other requirements for logo URIs? |
The Consumer Data Standards specify a logoUri field for Data Holder Brands, Data Recipient Brands and Software Products within the CDR Register schemas. The standards define logoUri as a mandatory URIString and describe it as the relevant brand or software product logo URI. You can find the relevant schema definitions in the CDR Data Standards here:Based on our review of the standards, we have not identified any normative requirements that prescribe image dimensions, resolution, file size, aspect ratio or a specific file format (for example PNG, SVG or JPEG) for logoUri. The standards define the field as a URI reference to a logo but do not specify image design requirements. Accordingly, from a standards perspective, the key requirement is that the registered logoUri remains a valid and accessible URI that references the relevant logo. Please note that the Data Standards Body can provide general guidance on the Consumer Data Standards but cannot provide compliance or implementation advice. Participants remain responsible for determining how they will comply with the Consumer Data Standards. |
| 2741 | NBL (Data Holder) |
Guidance on Banking API – Get Payee Details (BankingProductFeeV2 FeeMaximum Field) We are seeking guidance regarding the Get Payee Details Banking API, specifically the BankingProductFeeV2 schema Within this schema, the variable property requires a BankingFeeRange object to be provided whenever feeMethodUType is set to variable, indicating that the amount or rate may not be known until the fee is incurred. The BankingFeeRange object includes the feeMinimum and feeMaximum properties. We are seeking clarification on the expected population of the feeMaximum field as an AmountString type. We would appreciate your guidance on the following questions:
|
Where a data holder does not hold data in relation to an optional field (such as feeMaximum), omitting the field is the best approach. Disclosing with a null value is also valid. Disclosing with an empty string is not a valid pattern for optional fields. A variable fee with no defined maximum value would be a situation where a data holder does not hold the relevant data. Similarly, omitting the field would be the best approach in the case where the maximum value is defined by a rule. This is because the maximum value can’t be expressed as an AmountString as required by the Standards.* In either of the above cases, it is best practice to populate the additionalInfo field in BankingProductFeeV2 with details explaining missing fields. When determining whether a data holder holds particular data, it should be noted that the core obligation is to disclose required product data and required consumer data that is held in digital form. This obligation is independent of where the data is held. The guidance on the Clarification of specific Data Quality obligations highlights required consumer and product data is not limited to information that is held by a data holder in specific business systems. Obligations to disclose data apply to all relevant information that appears on a data holder’s website, or in a product disclosure document. *If the maximum value is defined by a rule, then the value may in fact be fixed in relation to an account. This is relevant if BankingProductFeeV2 appears in BankingAccountDetailV5. Data holders should assess whether they hold the data on a case-by-case basis. For example, if a data holder presently displays the calculated fee amount to the consumer via their online channel(s), this means it is highly likely that they hold the actual fee amount and are required to disclose it, even where the calculation is performed dynamically upon the consumer logging in to the online channel. If the data holder merely has the ability to calculate certain information, the data holder is less likely to be considered to hold the data in digital form. |
| Verbal Question 1 | 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. |
The DSB acknowledged that instalment plans are an area currently being explored, including whether the standards and related requirements could be clarified. As an immediate answer was not available, the question was taken on notice for further consideration and follow-up. |
| Verbal Question 2 | General |
Future Dated Obligations after May 2027 After the obligations planned for May 2027, do we have any further obligations scheduled, or do we have any visibility on what is planned after that? |
At this stage, there are no additional obligation dates scheduled beyond May 2027. The DSB is currently undertaking pre-consultation work on potential future standards changes, including security uplifts, authentication requirements aimed at establishing a minimum baseline, and alignment with the FAPI 2.0 international standards. As this work has not yet entered formal public consultation, any future obligations and implementation timeframes remain to be determined. The DSB expects public consultation on this work to commence around late October 2026 and will provide further information as the consultation progresses. The absence of scheduled obligations beyond May 2027 reflects a deliberate approach to reduce the frequency of standards changes and provide participants with a longer period of stability compared with recent years. Future obligation dates, if required, will be informed by the outcomes of consultation and stakeholder feedback. |
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 (20 August 2026): https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Minutes-%7C-20-August-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 |