ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 23rd of February 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
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 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.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.22.0 published 23rd of December 2022 |
Version 1.22.0 Change Log Release video 1.22.0 |
| Maintenance | Iteration 14 continues! The working group met on the 22nd of February 2023 |
Check out the agenda here |
| Maintenance | Iteration Candidates are nominated | Check out the Project Board See "Iteration Candidates" column for the list |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | 13th of February 2023 | View in browser here |
| DSB Newsletter | 17th of February 2023 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Decision Proposal 267- CX Standards Telco Data Language |
Feedback extended with an end date to be determined pending the making of the telco rules. Link to consultation |
| Consultation | Decision Proposal 275 - Holistic Feedback on Telco Standards | No Close Date Link to consultation |
| Consultation | Noting Paper 276 - Proposed v5 Rules & Standards Impacts | No Close Date Link to consultation |
| Design Paper | Design Paper: Consumer Data Right Rules and Standards for the Non-Bank Lending Sector |
Feedback closed Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 292 - Approach to developing Data Standards for the Non-Bank Lending Sector |
Feedback 24th of March 2023 Link to consultation |
| Workshop | 7th of March 2023 Action Initiation Workshop 01 |
Registration for Workshop |
| Engineering | Fixed 2 bugs in the DSB Schema tools repo: Github issues 22 & 23. Fixed a bug in the JS Holder SDK repo: Github Issue 3. (NPM package will be updated by end of week. |
Provides a weekly update on the activities of each of the CDR streams and their stream of work
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register | Emma Harvey |
| ACCC | CTS | Andrea Gibney |
| ACCC | CDR Sandbox | Andrew Grady |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking & Infosec | Mark Verstege |
| DSB | Technical Standards - Energy | Hemang Rathod |
Topic: Action Initiation Workshop activity
Presenter: Mark Verstege
Link: TBA
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 |
|---|---|---|
| 1856 | We're a DH who is still improving our API performance times and looking for some guidance at what point we'll be considered compliant. For the NFRs on API endpoint performance time, the schema says 95% of calls per hour responded to within a nominated threshold. Based on this "per hour" requirement, as soon as we have improved our performance to below the thresholds, will we be considered compliant? We won't need to wait for over average performance over a set time period to come down in order to be considered compliant? |
The general expectation would be that you have been, and then continue to maintain the response times defined in the Performance Requirements for all hours that your services are available, according to the Availability Requirements, but excluding any requests received above the defined Traffic Thresholds. The question of whether you are currently, or have been compliant at a specific point in time or over an extended period would be a matter for the ACCC Compliance Team to consider, and they may request further details to support a review. To answer your question more specifically, for each hour that you are compliant, you would be considered compliant for that hour. Any hours where you are not compliant would be considered as not-compliant hours. If you have not explored it already, you may find the details available in the ACCC Performance dashboard interesting to understand your performance as measured by the ACCC from your Get Metrics endpoint - https://www.cdr.gov.au/performance The default view shows details for the last 30 days, but you can select a specific date range at the top right to show more recent trends. |
| 1852 | Is it valid for a DH to revoke a consumer's consent if it hasn't been requested and there is no specific risk to the consumer? | An accredited person can only ask a CDR consumer for their consent to collect and use their CDR data if the CDR consumer requests the accredited person provide goods or services and the accredited person needs to collect and use the CDR consumer’s data to provide those goods or services (see 4.3(1() CDR Rules). If an accredited person seeks to collect CDR data without a valid request, it will contravene privacy safeguard 3 (see 4.3(3)). If an accredited person asks a CDR consumer for their consent to collect and use their CDR data, it must do so in accordance with the CDR Rules, and in particular, rules 4.10, 4.11 and 4.12. A consumer consent not obtained in accordance with the CDR Rules is therefore not a valid consent. If a request is not valid, data holders cannot provide data in response. Therefore, these instances do not constitute a refusal to disclose data, and do not need to be reported under rule 9.4 of the CDR Rules. More information on reporting implications can be found in this article. |
| 1862 | We are seeking clarification on the error codes that need to be factored while providing details on ‘refusal to disclose’ count in the bi-annual data holder report. In the past we have submitted the count of all 4xx errors as part of ‘refusal to disclose’ sections for product data request and consumer data request via ADR. The reasoning for that was the guidance provided in report template However, when we look at the clarification provided on Zendesk (link below), it primarily covers the scenarios mentioned in first four bullet points in the above screenshot. Zendesk article: What constitutes a refusal to disclose required data? – Consumer Data Standards Australia (zendesk.com) Hence, we wanted to confirm if we need to report on all 4xx errors in our reporting, or if we should cover only the scenarios mentioned in the Zendesk clarification. |
The ACCC’s Compliance guide for data holders – banking sector provides guidance on the reporting requirements for refusals to disclose data, and the associated error codes. Our guidance provides that a data holder must share required data in response to a valid request that it receives unless it is able may refuse to disclose CDR data in response to a request because CDR Rules 2.5(1), 3.5(1) or 4.7(1) apply, and our expectation is that these refusals will be reported on under rule 9.4 of the CDR Rules. However, if a request is not received or is not valid, data holders cannot provide a response and therefore these instances do not constitute a refusal to disclose data, and do not need to be reported under rule 9.4 of the CDR Rules. Therefore, when providing details on refusals in the data holder report, only the 4xx error codes in the top row of the above table need to be included (this is in line with the knowledge article you linked). We do note, as per the compliance guide, the return of a 403, 404, 422 and 429 HTTP error code in response to circumstances other than those set out in the above table does not constitute a refusal to disclose data under the CDR Rules. Also see Q&A Appendix below |
| Request attribute | Data holder obligation | HTTP code provided to requester |
|---|---|---|
| Valid | Received | |
| Yes | Yes | Must disclose required data, except in circumstances set out in the CDR Rules. |
| No | Yes | Unable to disclose required data in response to an invalid request. |
| Yes | No (due to outages) | The data holder is unable to disclose required data as the request is not received. |
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |