ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 12 June 2025 - ConsumerDataStandardsAustralia/standards GitHub Wiki
When: Weekly every Thursday at 3pm-4:30pm AEST
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions
Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney
Phone Conference ID: 715 805 177#
Find a local number | Reset PIN
Learn More | Meeting options
- 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.
⭐ indicates change from last week.
| Type | Updated | Links |
|---|---|---|
| Standards | Version 1.34.1 | Published: 11 April 2025 Change log |
| Standards | Future Dated Obligations From 14 July 2025, the following Future Dated Obligations will take effect: |
Future Dated Obligations |
| Consultation | Consultation Draft 364 The draft standards arising from Maintenance Iteration 22 have now been published for a further 28 Days of consultation, feedback welcome. The closing date is 3 July 2025 |
Consultation Draft 364 MI22 Meeting Notes |
| Maintenance ⭐ |
Maintenance Iteration 23 The final call of Maintenance Iteration 23 will be held on 25 June 2025 You can stay up to date on the discussion by checking out the meeting notes. The next meeting will focus on approving and documenting MI23 candidates. Next meeting: 25 June 2025. |
|
| DSB Newsletter ⭐ | 6 June 2025 | View the latest Newsletter and Subscribe |
| ACCC Regulatory Guidance |
|
Provides a weekly update on the activities of each CDR stream and their work.
None this week.
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 |
|---|---|---|
| 2531 | We're looking to rely on Product Reference Data to show users potential mortgage options. How reliable and accurate is the data? In the event that providers haven’t updated the information correctly, who is liable for the wrong information? |
CDR data quality is a compliance and enforcement priority under the ACCC/OAIC CDR Compliance and Enforcement Policy and the ACCC closely monitors data holder compliance with product reference data obligations to promote good quality data sharing. The ACCC:
If a data holder fails to comply with its CDR obligations, including in relation to product reference data sharing, the ACCC and, in some circumstances, a person impacted by the breach, may be able to take action against the data holder. Ultimately, data holders are responsible for ensuring they meet their CDR obligations, including those regarding product reference data sharing. Should you start using product reference data, the ACCC welcome feedback about any data quality issues you observe, which you can email to [email protected] or by making a report via the CDR website. The ACCC considers reports and potential non-compliance in line with the ACCC/OAIC CDR Compliance and Enforcement Policy. |
| 2523 |
Clarifications on Account level Features (DP338) Issue #316 brings about changes to the isActivated field on account level features as part of the deliverables for DP338. Having reviewed version 1.34 of the standards we have some queries around the display of features at the account level. Get Account Detail is required to display an array of account features and then present the isActivated field. Q1. There are 30 possible features. For each account sharing request is the expectation that all 30 features are displayed along with the isActivated field? Q2. isActivated now has an option of 'Unknown'. With 'Unknown' the description is as follows - "UNKNOWN or absent if the activation state is unknown". In this instance the isActivated may not be shown, but in that case what is the value in the Feature itself being displayed. This follows on from Q1. If 30 features are shown, but 20 are unknown - where is the value in presenting the information? Q3. In Issue #316 on Jul 20, 2023 ANZ Bank responded to Great Southern Bank regarding the Offset feature on their Home Loan Products. GSB - "Some of our home loan products have offset as a standard feature of the product. Currently, if a customer does not have any linked offset accounts to the home loan, it is deemed as "available for activation" and the isActivated = false. With the proposed change, it is challenging to determine if the status should be true (it is a product standard feature) or false (it is not yet "activated" by the customer)." ANZ - "The proposal deliberately doesn't add to the isActivated property the semantics of whether the feature is defined as part of the product or is selected/activated by the customer. For your home loan customer with a linked offset, isActivated would be true, and without an offset account it would be false. The presence of the feature indicates that the feature is available (i.e., a standard feature of the product) - irrespective of the value of isActivated." Here we have (at the account level) the Offset feature being set to 'Activated' or 'Not Activated' based on if the account has a linked Offset. Yet the standards state the following about the 'isActivated' field: "ACTIVATED if the feature has been activated by the customer or is a standard feature of the product" In the GSB example above, if Offset is a standard feature of the product why is the value of this field not 'ACTIVATED' on the account which does not have an offset account? Our feeling is that the standard features of the product should be shown along with whether they are activated or not on the account. But it is not clear as to whether this is the correct approach. |
Q1. The intent of the features array has always been to provide the set of features that are associated with a product or account. If by 'possible' you mean features that can be activated on an account, then yes, they should be included in the array with appropriate values in the respective isActivated fields. If your system includes some features that cannot be associated with a particular account, then they should not be included in the array with that account. Q2. The UNKNOWN option has been provided for cases where you may be unable to determine the status of an available feature for specific reasons (for example, customer acceptance of a third-party loyalty program offered with the product).It does not mean that it is unknown whether the feature is applicable to the account. UNKNOWN will mean to an ADR that the account has the specified features available, but it is unknown whether the consumer is actually making use of them. If you know the actual status, it should be specified as being either ACTIVATED or NOT_ACTIVATED.Q3. As stated in ANZs reply to the GSB query, the presence of the OFFSET feature in the array indicates that an offset is available on the account. The isActivated field then specifies whether the offset has been accepted and in use by the consumer. If the offset account was available but not taken up by the consumer, then NOT_ACTIVATED should be provided.Where the standards state 'or is a standard feature of the product', this may apply for a feature such as DIGITAL_BANKING on an e-savings account, where for example, it could be expected to be ACTIVATED as part of the base features of the account, where it would generally not be possible for it to be deactivated. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
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 |