ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 8th of June 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
teams@vc.treasury.gov.au
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
Actions
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 contact@consumerdatastandards.gov.au 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

Type	Topic	Update
Standards	Version 1.24.0 published 7th of May 2023	Version 1.24.0 Change Log
Maintenance	Iteration 15 met on 31st of May 2023	See the agenda and meeting minutes
Maintenance	Iteration Candidates for Maintenance Iteration 15	List of candidates on the MI5 Project Board
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	26th of May 2023	View in browser here
DSB Newsletter	2nd of June 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

CDR Stream Updates

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

Organisation	Stream	Member
ACCC	Register	Eva
ACCC	CTS	Seamus
DSB	Consumer Experience	Holly
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Information Security & Banking	Mark
DSB	Technical Standards - Register	James
DSB	Technical Standards - Maintenance Iteration 15	Brian

Presentation

None planned for 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
1826 Part 1	Large customers (e.g. C&I) , 'plan' set up is bit different to mass-market i.e. the plan/s have multi year contracts with stepped prices each year; please refer to the below example of a C&I plan and tariff set up for clarity: Date of CDR request = 16.12.2022 Plan A 1/7/21 – 30/6/22 - Year1 Price 1/7/22 – 30/6/23 - Year 2 Price 1/7/23 – 30/6/24 - Year 3 Price WE note, DSB advice that "the intent is not to include historical plan information (within EnergyAccountDetailV2 API – PLANS array), therefore we believe the most appropriate data to provide in this instance, is providing plan and pricing detail that is "relevant for the year the request date is within and no past or future year prices" i.e. for the example above pass the response with "Year 2022" plan and pricing information. Seeking confirmation from the DSB, that the provision of plan and pricing details that is relevant for the year the request date is within and no past or future year prices is inline with the obligations for such customer data set ups.	The assumption I am making is that in the example above, the Year 3 price would be known as part of the plan during the request made on 16.12.2022. If the assumption is correct, it would make sense to share the known future price/rates. This would be beneficial in plan comparison use cases. Note that the rates objects in the energy schemas have start and end dates which can be used to specify when they are applicable from/to. For e.g. https://consumerdatastandardsaustralia.github.io/standards/#tocSenergyplantariffperiod
1826 Part 2	Yes your assumption is correct & the Year 3 price would be known as part of the plan during the request made on 16.12.2022. Regarding your point - "the rates objects in the energy schemas have start and end dates which can be used to specify when they are applicable from/to": we couldn't find the mentioned rate object that may fit this startDate & endDate however have included the dates in the "planOverview" object. As per our understanding have prepared the attached mock up - where every detail sitting underneath the "plans" array object will repeat w.r.t to the known current & future price/rates for that customer's plan.	As per your comment and the mockup, you can indeed use the start and end dates in the planOverview object as long as it is schema compliant. Apologies for not being clear in my previous response. By rates objects I meant the individual objects to capture different rates/charges, i.e. controlledLoad and EnergyPlanTariffPeriod respectively. Each have startDate and endDate fields (see attached screenshots). You could use them as well to provide rates that change for different time period. Which option to use is at the discretion of the DH based on a given scenario.
1962 Part 1	Considering post 10th July for DH it is Must to support Authorisation code flow and May to support/retire Hybrid flow. For ADR it is Must to use auth code flow post 10th July. As a DH our expectation is that all ADRs would transition from Hybrid flow to Authorisation code flow using DH's 'Update Client Registration' end point on or before 10th July. Question: Is there any expectation/obligation for DH to reject any client registration request from ADR that uses Hybrid flow post 10th July? or considering it is may requirement to retire Hybrid flow post 10th July, are we required to accept client registration request?	From July 10th 2023 "Data Holders MAY retire Hybrid Flow". This means that you MAY refuse a DCR request that includes Hybrid and you MAY reject attempts to authorise that use Hybrid. The MAY implies that you don't have to do this immediately and can start rejecting at a later time if you so desire. For existing registrations that include both Hybrid and Authorization Code Flow it would be logical to continue to support those registrations (even if they aren't updated) but only if Authorization Code Flow is used.
1962 Part 2	Sorry I didn't get your last sentence (but only if Authorization Code Flow is used.), could you please elaborate a bit. My inference please correct: at present if a client has registered both (Hybrid & ACF), then post 10th July DH must reject authorisation request if they use hybrid flow?	Yes, that is what I meant. For that last sentence what I was trying to emphasise is that the deprecation of Hybrid Flow should not mean that registrations that include Hybrid are invalid if the include ACF.
1991	Rule 9.4(1)(c) requires data holders to report on the number of ‘product data requests’ and ‘consumer data requests’ received during the reporting period. The rule does not specify whether the requests received and reported on be either valid and/or invalid requests. We are therefore seeking confirmation that for the purposes of Rule 9.4(1)(c) the number of product and consumer data requests received should include both valid and invalid requests that the data holder receives during the reporting period.	This question relates to data holders' reporting obligations for product data and consumer data requests, as well as for refusals to disclose data. The ACCC's banking compliance guide for data holders sets out a table which highlights the difference between requests that are received and valid, and those that are either not valid or not received, and how each should be treated in 9.4 reports. A summary of how requests should be reported is provided in the below table: See Appendices Therefore, only requests that are both valid and received need to be included in 9.4 reports, and only successful requests should be included in the number of product data requests and consumer data requests received under rule 9.4(1)(c). Any unsuccessful requests (which are requests that are received and valid but rejected for one of the reasons identified in guidance - such as a valid refusal to share data) must be reported as refusals. We hope this information assists you. If you have any further queries, please let us know.
1993	Are we only allowed to return the error codes listed in the Reponses section of each Banking and Common API ? Q1 : For example, the Get Account Detail Responses section has 4 error codes. They are 200, 400, 406 and 422. Does this mean we can only return any 1 of these 4 codes ? Q2 : If lets say an ADR calls the 'Get Accounts' API however none of the customer's accounts are eligible so we will return error code 422 however under the description section of this code, it states '422 - Invalid Page'. Are we expected to return that description ? This doesn't sound correct.	Q: Are we only allowed to return the error codes listed in the Reponses section of each Banking and Common API? For example, the Get Account Detail Responses section has 4 error codes. They are 200, 400, 406 and 422. Does this mean we can only return any 1 of these 4 codes ? A: The answer to your No, you should return many more errors than just the ones listed in the API specific documentation. The errors documented in the API specific sections of the standards are provided to indicate the context specific errors and does not contain many errors that could be returned (like standard HTTP errors for instance). This documentation supports, and does not undermine, the Error Codes section of the standards under the High Level Standards section. Q: If lets say an ADR calls the 'Get Accounts' API however none of the customer's accounts are eligible so we will return error code 422 however under the description section of this code, it states '422 - Invalid Page'. Are we expected to return that description ? This doesn't sound correct. A: This may not be the best example as this scenario should actually result in a 200 with an empty account array. If you think there are codes we have missed and we should add to the API specific documentation please raise a CR and we will do so in the next release of the standards.

Appendices

Request attribute	HTTP code provided to requester	Successful/Unsuccessful/Valid/Invalid
Valid	Received
Yes	Yes	200 OK403 Forbidden404 Not Found422 Unprocessable Entity429 Too Many Requests
No	Yes	400 Bad Request401 Unauthorized405 Method Not Allowed406 Not Acceptable415 Unsupported Media Type
Yes	No	500 Internal Server Error503 Service Unavailable504 Gateway Timeout