ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 24th of August 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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

Agenda

Introductions
Updates
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

Acknowledgement of Country

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.

House Keeping

Recording

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.

Community Guidelines

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.

Updates

⭐ indicates change from last week.

Type	Topic	Update
Standards	Version 1.26.0	The latest version, 1.26.0 was Published today! 24th of August 2023.
Maintenance	Maintenance Iteration 16	Meeting #3 was held 09/08/2023, minutes will be available soon, check here. Email [email protected] to request an invitation
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	31st of July 2023	View in browser here
DSB Newsletter	24th of August 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	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 316 - Non-Bank Lending sector alignment	25 August 2023 Link to consultation
Consultation	Decision Proposal 320 - CX Standards - Non-Bank Lending	31 August 2023 Link to consultation
Consultation	Noting Paper 323 - NFR Workshops	Link to consultation
Workshop	Non-functional Requirements Management Check out Noting Paper 323 - NFR Workshops	Workshop Series

CDR Stream Updates

Provides a weekly update on the activities of each CDR stream and their work.

Organisation	Stream	Member
ACCC	Register and Accreditation Application Platform	Eva
DSB	Consumer Experience	Mike
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Register	James

Presentation

None this week.

Q&A

Questions on Notice

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.

Answer provided

Ticket #	Question	Answer
769	In the CDR Rules, Schedule 3, Part 7.2(3)(b) it is stated that if a person becomes a data holder rather than a data recipient or CDR data any authorisations to disclose CDR data in relation to the consumer data request will expire. Could you please clarify how the original data holder (DH) will be informed that the data recipient (DR) is now a DH for the data so that the related authorisations be expired. Also, should authorisations in relation to the data request be expired, even if other data for which the DR does not become DH is included in the authorisation?	Thank you for your enquiry and apologies for our delayed response. On 21 July 2023, the Competition and Consumer (Consumer Data Right) Amendment Rules (No. 1) 2023 (version 5 rules) were made and registered. Under the amended CDR rules, rule 4.14(5) states that when an ADR becomes a data holder of CDR data (i.e. as a result of meeting the conditions set out in clause 7.2 of Schedule 3), all the accredited person’s consents related to that data would expire. New rule 4.18AA requires an accredited person to notify a data holder if a collection consent expires for any reason, which (in accordance with 4.14(5)) would include when a consent expires because an accredited person becomes a data holder of CDR data. We note that new rule 4.26A also introduces a similar requirement for a data holder to notify an accredited person where an authorisation expires or is otherwise withdrawn. Furthermore, when an ADR becomes a data holder of CDR data, all consents and authorisations related to the CDR data must expire under rule 4.14(1C) and clause 7.2(3)(b) of Schedule 3. Our view is that this means an authorisation that relates to the relevant CDR data would expire even if the ADR does not become the data holder of all the data included in that authorisation.
1948	Hoping to clarify if get concession includes residential accounts only or business as well? There are instances where concession is provided to a business customer which is a bit complex - e.g. proprietors can fill out form 502 in QLD to get concession on behalf of residents. Usually, it will end up being a sum amount of all eligible concession based on info submitted by the proprietors. https://www.dsdsatsip.qld.gov.au/resources/qld/business/concessions/502-electricity-proprietor-application-form.pdf	Apologies for the delay. We have consulted with a the different CDR agencies who have confirmed concessions for business consumers is in scope. I've included key points they mentioned below: - The energy rules in Sch 4 provide that ‘account data’ includes: any concessions, rebates or grants applied to the account. - This suggests that if the concession is applied to the account to effect lower fees (i.e. rather than provided directly to the end user) it should be shared as account data. Basically concessions/rebates applied to business consumers account needs to be shared. In your example: - the eligible CDR consumer is a business customer who purchases electricity from a retailer for use by multiple other individuals (e.g. in a multi dwelling complex), and - the business consumer applies for concessions on behalf of those individuals (who are not eligible CDR consumers - i.e. they do not have any account with the energy retailer). In this case, the business consumer would be the account holder and any concessions applied to their account would be shared. - The following ACCC resources may also be helpful: Guidance on the eligibility criteria in the energy sector Compliance guide for data holders in the energy sector
2016	Can I please get clarification on below: Data correction can either be identified by the data holder or can be requested by a consumer. In terms of how the corrected data is reshared with the ADR, is it correct interpretation that the data holder needs to inform consumers that if the consumer wants the corrected data to be resent to an ADR, the consumer will need to ask the ADR to make a new request to collect the corrected data? Looking for clarification for all of the below scenarios please: 1. for one off data share consent. 2. For ongoing data sharing consent which is still active. To add to this question. Looking for clarification on what it means with regards to below two points in privacy safeguard 13: - include a statement with the CDR data to ensure that, having regard to the purpose for which the CDR data is held, it is accurate, up to date, complete and not misleading (qualifying statement), and - where practicable, attaching an electronic link to a digital record of the data in such a way that the statement will be apparent to any users of the data. Question 1: It says in first point to include qualifying statement with the CDR Data. Is there an ability to do so in current APIs? I could not find any info on this in the supporting documents. I want to know how we can do this. Only place I can see being able to include qualifying statement is the email. Question 2: Digital record mentioned in point 2. What does this mean? Is it going to suffice if we include the link to the Powershop My account page where relevant info in question is displayed? Or is there any other digital record that may be referred to here which I am missing?	Thank you for your enquiry and apologies for our delayed response. We have provided general comments below in response to your questions which we hope will assist. As general background, we note your question alludes to data holder obligations in Privacy Safeguards 11 and 13. While Privacy Safeguards 11 and 13 are related, they are separate: - Privacy Safeguard 11 and related consumer data rules set out obligations for data holders to: - ensure the quality of disclosed CDR data - inform consumers if they become aware they disclosed incorrect CDR data, and - disclose corrected CDR data to the original recipient if requested to do so by the affected consumer. Privacy Safeguard 13 and related consumer data rules set out data holder obligations in relation to correction requests made by consumers in respect of their CDR data. For more information about Privacy Safeguards 11 and 13, please refer to the OAIC’s Privacy Safeguard Guidelines. Can I please get clarification on below: Data correction can either be identified by the data holder or can be requested by a consumer. In terms of how the corrected data is reshared with the ADR, is it correct interpretation that the data holder needs to inform consumers that if the consumer wants the corrected data to be resent to an ADR, the consumer will need to ask the ADR to make a new request to collect the corrected data? Looking for clarification for all of the below scenarios please: 1. for one off data share consent. 2. For ongoing data sharing consent which is still active. It seems you are referring to Privacy Safeguard 11, which includes a requirement for data holders to disclose corrected CDR data to the original recipient if requested by the affected consumer (see subs 56EN(4) of the Competition and Consumer Act 2010 and rule 7.10 of the Competition and Consumer (Consumer Data Right) Rules 2020). Please refer to this knowledge article which provides guidance on how to comply in those two scenarios. Also to add to this question. Looking for clarification on what it means with regards to below two points in privacy safeguard 13: - include a statement with the CDR data to ensure that, having regard to the purpose for which the CDR data is held, it is accurate, up to date, complete and not misleading (qualifying statement), and - where practicable, attaching an electronic link to a digital record of the data in such a way that the statement will be apparent to any users of the data. Question 1: It says in first point to include qualifying statement with the CDR Data. Is there an ability to do so in current APIs? I could not find any info on this in the supporting documents. I want to know how we can do this. Only place I can see being able to include qualifying statement is the email. Question 2: Digital record mentioned in point 2. What does this mean? Is it going to suffice if we include the link to the Powershop My account page where relevant info in question is displayed? Or is there any other digital record that may be referred to here which I am missing? For both questions, it appears you are referring to rule 7.15 which concerns Privacy Safeguard 13. We believe this knowledge article, particularly the third and fourth last paragraphs in the green box address your questions (extracted below). A ‘qualifying statement’ is usually used because it is either not appropriate to correct a record in the way a consumer asks, or because it is not technically possible to update a particular document or record. A qualifying statement therefore provides a way of actioning a consumer’s correctio n request under Privacy Safeguard 13 when the request might otherwise be refused. This Privacy Safeguard 13 obligation to correct CDR data through including a qualifying statement with the CDR data relates generally to correction of an entity’s own data holdings. It does not relate to the transfer of CDR data to another CDR entity or to the consumer. In addition, for question 2, the requirement to (where practicable) attach an electronic link to a digital record of the data, helps to ensure that any qualifying statement included with the data is clear to those who access the data. An entity’s systems should be set up so that the data cannot be accessed without the qualifying statement or a link to that statement being prominently displayed.
2062	in DP288, this is one of the changes: Inclusion of aggregate metric for performance metrics. Each element of the array will represent a 1 hour period for the represented day with the 1st entry representing 12am-1am using the timezone used by the Data Holder. What do we do for Daylight savings changeover? Since the timezone for the calculation of the metrics is managed by the DH and not communicated, DSB/ACCC can't just assume what hour a DST change occurs at, or even how long it is going to be.	We don't assume anything and we also don't ask for specific times so timezones and DST changes don't matter as long as a consistent choice is maintained by the Data Holder. This is why the standards say explicitly Timezone for determining 12am must be consistent but is at the discretion of the Data Holder
2074	We have noticed that a new Authorisations object has been added to the Get Metrics API spec. We also see that the object is marked as optional, while all others in Get Metrics is mandatory. We wanted clarification on why this is; are there certain entities that would not be required to include the Authorisations object?	This looks like a defect. The object should be mandatory. We will fix it in the next version.