ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 3rd 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.25.0	The latest version, 1.25.0 was Published on 8 July 2023.
Maintenance	Maintenance Iteration 16	Meeting #2 was held 26/07/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 June 2023	View in browser here
DSB Newsletter	28th of July 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	Decision Proposal 306 - Updates to Banking Product and Account Detail	Feedback extended now closes on: 11th of August 2023 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 314 - Last Consumer Change Date (Phase 1)	8 August 2023 Link to consultation
Consultation	Decision Proposal 316 - Non-Bank Lending sector alignment	25 August 2023 Link to consultation
Compliance Update ⭐	Following the publication of the Data Quality Findings Paper, the ACCC has been raising a number of PRD compliance issues with stakeholders identified through our conformance tool and manual reviews of data holder websites. The ACCC is aware that services are beginning to be used in the market to improve PRD compliance and the ACCC is currently exploring the procurement of a third-party testing tool to supplement its existing PRD compliance program. Any subsequent procurement by the ACCC is not an endorsement of a supplier’s product or service. The ACCC also monitors the compliance of all data holders’ PRD – regardless of whether or not they use a third party testing service. The ACCC encourages all data holders to regularly evaluate their PRD compliance and correct any issues they identify.

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
ACCC	Conformance Test Suite	Christian
ACCC	Compliance	Seamus
DSB	Consumer Experience	Bikram
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Register	James
AEMO	Industry Testing	Dylan

Presentation

Topic: Non-functional Requirement Workshops for August/ September 2023
Presenter: James Bligh

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
2034	preIdentification is missing in the finalised v1.25. It’s displaying abandonedConsentFlowCount (twice). Presumably an error.	Yes, this was an error. I believe it has been fixed now.
2035	Hi, in the v1.25 of CDS, it's stated in 2 places that v5 of Get Metrics is to be done by 13 June 2024. However, June 2024 is not one of the obligation milestones listed. Does that matter? it is right that it's listed for June 2024 or should it really be May 2024?	Yes, this is an error. It has not been fixed but it has been added to the known issues section and will be fixed in the next release.
2040	With reference to rule 5.34 where it states the Registrar may write to a DH to request that they stop responding to any consumer data request from a particular ADR. Today we call the Register API to get the latest status of the ADRs. If an ADR's status changes and is no longer active, then we will stop responding to the ADR's consumer data requests. In regards to rule 5.34, will the Registrar ask a DH to stop responding to an ADR's consumer data requests without changing the ADR's status on their register ? If so, does that mean DHs are expected to have another way to stop data sharing with an ADR without relying on the ADR's status on the register ?	Rule 5.34 allows the Registrar to temporarily direct a data holder not to respond to consumer data requests if it is necessary to ensure the security, integrity and stability of the Register or associated data base. It does not specify that the ADR status has to be changed for the Registrar to exercise rule 5.34. Hence, we consider it is possible for the Register to ask a DH to temporarily refrain from responding to an ADR’s consumer data requests without changing the ADR’s status on the Register. Other reasons the Registrar may provide a written notice are: - the Register status may be otherwise unavailable, - the notice may be specific to a DH, whereas the Register status is used by all DHs, - the Rules state that "a data holder must not disclose CDR data in response to a consumer data request contrary to a direction it has received under this rule.", and the Register status for a particular recipient may not be aligned to the given direction. The article Rules 5.33 and 5.34 – temporary restrictions or directions placed by the Accreditation Registrar states there is no expectation for DHs to build automated responses to requests under rule 5.34. This means that a manual setting or override of the usual processes may be an option. For reference, also note the article on Handling of refusals or errors when instructed to stop sharing states that depending on the instruction given by the Accreditation Registrar under rule 5.34, it may be expected for the data holder to act as if a constrained client, scope or customer is invalid. This means that in some limited circumstances, it may be possible for a data holder to rely on its usual processes for dealing with invalid requests when adhering to rule 5.34.
2040 Follow-up	Rule 5.34 states “The Accreditation Registrar may, by written notice. Since it’s a ‘may’ requirements, does it’s not a mandatory requirement for DH to implement an alternative way to stop data sharing with ADRs ?	We (DSB) can't provide specific Rules interpretation guidance; participants are urged to seek their own advice. I would think though, that the "may" in that sentence in the Rules could take its ordinary meaning as it doesn't say "MAY" in upper case, and it is not part of the Standards where an RFC2119 interpretation could apply to the use of that word. As to whether there is a requirement to implement anything because of that rule, that would be for the participant determine.
2041	Have following two queries regarding API endpoint pagination, can you please advise. 1. We would like to implement date range based(start and end date) cursor and make use of link to navigate between sets. In this case can we exclude the meta-information or return both totalRecords and totalPages as 0. 2. For some of the APIs eg Payee/ScheduledPayment for Account we are expecting small data on average 30-40 records. In this case can the API return all the records ignoring page size query param.	Question: We would like to implement date range based(start and end date) cursor and make use of link to navigate between sets. In this case can we exclude the meta-information or return both totalRecords and totalPages as 0. Answer: No. The standards require these fields to be provided. The ADR client systems are built to work consistently with all data holders so if you provide a non-standard behaviour the ADRS will likely break and they will raise an issue via the ACCC. The current position on pagination was consulted on multiple times and the current position is specific and required. Cursor support can still be support and the 'links' object can be include cursor based next, prev, first and last URLs but you still must implement the pagination query params and meta fields according to the standards. Question: For some of the APIs eg Payee/ScheduledPayment for Account we are expecting small data on average 30-40 records. In this case can the API return all the records ignoring page size query param. Answer: No. Same reason as above.
2045	Why does this curl request in command prompt not work? curl https://cdr.energymadeeasy.gov.au/red-energy/energy/plans -H "x-v:1" -H "Accept: application/json"	To use the GET Generic Plans endpoint you will need to ensure the request is aligned with the Consumer Data Standards for the request: https://consumerdatastandardsaustralia.github.io/standards/#get-generic-plans and the URI Structure: https://consumerdatastandardsaustralia.github.io/standards/#uri-structure You just need to add the '/cds-au/v1/' into your existing curl request. A working URI looks like: https://cdr.energymadeeasy.gov.au/red-energy/cds-au/v1/energy/plans
2046	As a Data Holder (DH), we wanted to confirm the registration process for Accredited Data Holders (ADR): As per CDR regulations, DH must expose a Dynamic Client Registration (DCR) endpoint for ADRs to obtain client credentials required to consume CDR APIs. Could you please confirm if ADRs would need credentials (API keys) to call DCR endpoint? Additionally, how will ADRs exchange certificates with DH required to establish a MTLS connection?	No, an ADR does not need to obtain an API key from each data holder. The requirements for how to use the DCR endpoints (including client authentication) is defined in the standards at: https://consumerdatastandardsaustralia.github.io/standards/#client-registration
2027	Query in relation to correction of data timeframes. As per Rulle 7.15 (b) correct the data within 10 business days after receipt of the request If retailers are not able to meet this 10 business days timeframe, what are they required to do?	Privacy Safeguard 13 and CDR Rule 7.15 require the recipient of the request to take certain steps to correct CDR data after a CDR consumer has requested that it be corrected, unless the entity does not consider a correction or statement to be appropriate. CDR entities have two options to correct it to the extent appropriate under Rule 7.15: - Correct the data, or - Include a qualifying statement with the data and where practicable, attach an electronic link to a digital record of the data in such a way that the statement will be apparent to users. The CDR entity can also refuse the request if they consider that it is unnecessary or inappropriate. A ‘qualifying statement’ is usually used because it is either not considered 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 correction request under Privacy Safeguard 13 when the request might otherwise be refused. Note, if a retailer receives a correction request relating to AEMO data, the retailer is not required to take action to correct, or qualify, the CDR data under Rule 7.15. Instead, the retailer must, as soon as practicable: - initiate the relevant correction procedures under the National Electricity Rules in relation to any NMI standing data or metering data for which correction is requested, and - if the request relates to DER register data, provide the consumer with information about how the consumer can contact the distributor to have the data corrected. For data that is not AEMO data, if the recipient does not meet the 10 business day requirements the recipient would be in breach of their obligations under the CDR Rules. The ACCC and OAIC take a risk-based approach to compliance matters with a proportionate response to the breach in line with the Compliance and Enforcement Policy.
2048	Follow-up of 1778 "Ceasing adr for secondary user sharing -- notification"	Please note, the ACCC has revised its guidance on the notification obligation for data holders under rule 4.28. Treasury previously consulted on proposed changes to rule 4.28 as part of its consultation on exposure draft operational amendments to the CDR Rules. Treasury intends to consult further before progressing any changes, including on whether there should be a requirement to notify account holders when a secondary user provides a new authorisation for the account. Data holders with concerns about compliance with rule 4.28 can contact the CDR Compliance team at [email protected]. Further feedback on the operation of rule 4.28 can be provided to Treasury at [email protected].
2049	Follow-up of 1749 "Alternate Notification Schedule for Individual Consumers"	Please note, the ACCC has revised its guidance on the notification obligation for data holders under rule 4.28. Treasury previously consulted on proposed changes to rule 4.28 as part of its consultation on exposure draft operational amendments to the CDR Rules. Treasury intends to consult further before progressing any changes, including on whether there should be a requirement to notify account holders when a secondary user provides a new authorisation for the account. Data holders with concerns about compliance with rule 4.28 can contact the CDR Compliance team at [email protected]. Further feedback on the operation of rule 4.28 can be provided to Treasury at [email protected].