ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 26th of October 2023
When: Weekly every Thursday at 3pm-4:30pm AEDT
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.
We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.
The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may [email protected] should they have any further questions or wish to have any 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 | Topic | Update |
|---|---|---|
| Standards ⭐ | Version 1.27.0 | Published: 10th October 2023 Change log |
| Maintenance ⭐ | Maintenance Iteration 17 | Met on the 18th of October 2023 Next meet on the 1st of November 2023 |
| Maintenance | Maintenance Iteration 17 | All agendas and meeting minutes |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 20th of October 2023 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 280: The CX of Authentication Uplift | No Close Date Link to consultation |
| Consultation | Noting Paper 307 - LCCD Consultation Approach | No Close Date Link to consultation Video |
| Consultation | Noting Paper 308 - Categories of Standards | No Close Date Link to consultation |
| Consultation ⭐ | Decision Proposal 318 - Non-Bank Lending Standards |
Feedback Closes: 8th of December 2023 Link to consultation |
| Consultation | Noting Paper 326 - Authentication Uplift Context |
Feedback Closes: 15th of November 2023 Link to consultation |
| Consultation | Decision Proposal 327 - Authentication Uplift Phase 1 |
Feedback Closes: 15th of November 2023 Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation ⭐ | Decision Proposal 333 - Business Consumer Provisions | Feedback Closes: 21st November 2023 Link to consultation |
| Consultation ⭐ | Decision Proposal 334 - Data Holder Dashboards | Feedback Closes: 21st November 2023 Link to consultation |
| Video ⭐ | Maintenance Iteration 17 Candidate Issues - narrated by Neale Morison (20/10/2023) | Video |
| Video ⭐ | Future Dated Obligations for Q4 of 2023 - narrated by Peter Nowotnik (25/10/2023) | Video |
| Survey | End of the year! Question to everyone on the Call: When do we want to stop the call in 2023? And when to pick it back up again in 2024? Survey closes: Tomorrow! 27th October 2023 Review results: 2nd November 2023 |
2 question survey CDR Implementation Call 2023-2024 |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform | Eva |
| ACCC | Conformance Test Suite | Christian |
| DSB | Consumer Experience | Holly |
None planned 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 |
|---|---|---|
| 2133 | Referring to the response received for ErrormetricsV2 "The aggregate field is intending to be a carry forward of the previous v3 errors field so should only include server errors and not client errors (ie. just keep your previous implementation for this field)." does this response applies to the aggregate object definition containing in other metrics i.e. AvailabilityMetricsV2, AverageTPSMetricsV2, PeakTPSMetricsV2 for Get Metrics V4? | Yes. Each of the aggregate fields represents a field in the previous v3 version that has been modified. The aggregate field is intended to retain the v3 field for continuity |
| 2147 | Just double checking, that the intrinsic greenpower is only talking about the greenpower scheme? Therefore, any other scheme should not be passed in the get energy account details? Reason I ask is because we have 100% carbon neutral included within some of our plans, but could be misleading as its not greenpower. (Carbon neutral and greenpower are two different things). Based on our current understanding, we dont intend to pass any value in the intrinsic green power rate section as ours is not greenpower. But looking to clarify in case we have this wrong. |
This structure, including the field is based on the current plan information the retailer provides EME/VEC. My suggestion would be to base it on what you currently provide in such plans/scenarios to EME. |
| 2151 Part 1 | The field EnergyInvoice.servicePoints has the description "Array of service point IDs to which this invoice applies. May be empty if the invoice contains no electricity usage related charges" Is this meant to be an array of NMIs? |
It is meant to be an array of servicePointId's which is not the same as the NMI. servicePointId is a tokenised ID of the service point/NMI to be used for referring to the service point in the CDR API suite. The DH would need to create this in accordance to CDR ID permanence rules Note that the servicePointId would need to be populated with the equivalent NMI for interactions between energy DH and AEMO (i.e. for any API calls a DH makes to AEMO). |
| 2151 Part 2 | I did wonder that however what got me confused is that AEMO are responsible for that endpoint GET /energy/electricity/servicepoints so therefore I would assume they create the mapping between servicePointId and nationalMeteringId when they return the data in the schema EnergyServicePoint ? |
Using Get Service Points as an example of Shared Responsibility Data, there are two types of it in the standards: The one that energy DH implements and which ADRs call - https://consumerdatastandardsaustralia.github.io/standards/#get-service-points The one that AEMO implements and DHs call - https://consumerdatastandardsaustralia.github.io/standards/#get-service-points-sr The high level call sequence would be something like: ADR calls the Get Service Points API of the DH The DH calls AEMO's Get Service Points-SR API AEMO returns the data with a list of NMIs DH creates servicePointids corresponding to the NMIs in accordance with the ID permanence rules and send its back to ADR ADR can use the servicePointids for calling other DH APIs such as GET /energy/electricity/servicepoints/{servicePointId}/usage. The DH would replace servicePointId with value of NMI when calling the AEMO version of the API |
| 2151 Part 3 | So in #3 "AEMO returns the data with a list of NMIs", when AEMO returns the data in the schema EnergyServicePoint, both servicePointId and nationalMeteringId will be the NMI? and then we create our own servicePointids as per step #4 ? | Yes that is correct. |
| 2143 | My understanding of Secondary Data Holders is that they are only relevant to the Energy sector at this stage, i.e. AEMO is the Secondary Data Holder. Is it expected that Secondary Data Holder rules will apply in the Banking sector in future? E.g. if a bank uses another vendor to disclosed Product Reference Data? | According to Rule 1.7 of the CDR Rules, secondary data holders for a sector must be specified in the relevant sector schedule in the CDR Rules. At present the only specified secondary data holder in a sector schedule is AEMO in relation to energy sector data. As stated in the Explanatory Statement for version 4 of the CDR Rules, “[the secondary data holder] model will initially be used in the energy sector, but may be applied to other sectors as appropriate.” We note that there are no current plans to apply the secondary data holder model to the banking or non-bank lending sector. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |