ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 7th of September 2023
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
- 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.26.0 | Published: 24th August 2023 Change log |
| Maintenance ⭐ | Maintenance Iteration 16 |
Meeting #5 was held 6/9/2023, minutes available here. Email [email protected] to request an invitation |
| Maintenance ⭐ | Iteration 17 Planned to commence 20th September 2023 | Invitations to be sent out. |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter ⭐ | 1st September 2023 | View in browser here |
| DSB Newsletter ⭐ | 1st September 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 317 - ‘Buy Now, Pay Later’ Product and Account Detail | 6 October 2023 Link to consultation |
| Consultation ⭐ | Decision Proposal 320 - CX Standards - Non-Bank Lending |
8th September 2023 Link to consultation |
| Consultation | Design Paper: Consumer Data Right Consent Review | 6 October 2023 Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Video | Product Comparator Demo - narrated by Neale Morison (31/08/2023) | Data Standards Body YouTube Channel |
| Video | CDS 1.26.0 Release Walkthrough and Changes - with Jarryd Judd (04/09/2023) | Data Standards Body YouTube Channel |
| Video | Decision Proposal 317 - narrated by Neale Morison (07/09/2023) | Data Standards Body YouTube Channel |
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 | Callina |
| ACCC | Compliance | Seamus |
| DSB | Consumer Experience | Michael |
| DSB | Technical Standards - Register | James |
None 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 |
|---|---|---|
| 1990 | We are seeking to confirm DSB’s guidance on whether a data holder may throttle requests before assessing whether they are valid or not, and in such circumstances whether a data holder should include a count of these requests in its refusal to disclose record keeping and reporting figures. As outlined per Section 8.1.4 of the Compliance Guide for Data Holders – Banking Sector (V2 June 2022) (page 34): - A data holder must share required data in response to a valid request that it receives, unless it is able to refuse to disclose CDR data in response to a request because CDR Rules 2.5(1), 3.5(1) and 4.7(1) apply in the circumstances. - Where a data holder refuses to disclose required data in response to a valid request that it receives, it must inform the requester by sending the HTTP error code as prescribed in the Data Standards (i.e. a 403, 404, 422 and 429 HTTP error code). - If a request is not received, or 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. While we note that requests not received, or not valid, do not constitute a refusal to disclose data and do not need to be reported under Rule 9.4(1)(d) – does a data holder need to distinguish whether a request is valid in circumstances where a data holder may throttle a request it receives before assessing whether the request is valid? For example, it may be an invalid request but this request was firstly throttled for exceeding traffic thresholds. Given this, is it acceptable that a data holder throttles these requests (before assessing validity) and subsequently includes them as part of its overall refusal to disclose record keeping and reporting figures? We appreciate the ACCC’s clarification of this matter. |
DSB Response When throttling for traffic reasons occurs, it was always expected that Data Holders will make this refusal before assessing the request itself (since the purpose of the throttling is to reduce system load). This ability to throttle is a practical concession to Data Holders to allow them to manage the integrity of their systems. The standards and rules provide many mechanisms to make a positive determination that a request is invalid but there is minimal support to make a positive determination that a request is valid. The regime is based on the assumption that a CDR request is valid until it is shown to be otherwise. In this context, if you have not processed a request and have yet determined it is invalid then the request should be assumed to be valid. You are, in effect, not simply refusing a CDR Request - you are refusing even to validate the request. The interpretation of the language of the rules and standards used to create the suggested interpretation is antithetical to the intent of this feature. If the interpretation you are proposing is accepted then the DSB would need to escalate this to the Treasury rules team to have the language changed to make the intent clear. In the meantime we would probably seek the Chair's acceptance to change the standards to address the issue in the mean time. For instance, this could involve raising the NFR thresholds so that throttling ceases to occur, or to require validation of a CDR Request before it is throttled. ACCC Response Thank you for your enquiry and apologies for our delayed response. We consider that requests should generally be assumed to be valid until they are identified as invalid. If another reason for a refusal occurs prior to the identification of an invalid request (for example, if a request has been throttled), then the request should be assumed to be valid, as it has met all the assessed validity requirements. Once the request has been refused, it is not necessary to make further judgements on its validity as the refusal is sufficient in justifying the data holder not responding to the request. Throttled requests should generally be reported as a ‘refusal to disclose CDR data’ in accordance with rule 4.7(1)(b)(ii) which states that a data holder may refuse to disclose CDR data if it believes that disclosure of the data would adversely impact the security, integrity or stability of the data holder’s online systems. As noted by the DSB, the ability to throttle requests allows data holders to manage the integrity of their systems. |
| 2066 | 2.1(1) Rule change in Amendment to Rules issued 11 July 2023 clarification The amendment to the rules have updated subclause 2.1(1) of Schedule 3 from: is that the person is able to access the account online. to: is that the account is set up in such a way that it can be accessed online. Can you please clarify what the update was attempting to address? |
Thanks for your query. We understand this update was made to improve consistency of language in the CDR rules – the language used in 2.1(1) now aligns with 2.1(2). We understand the policy intent for the eligibility requirements in the banking sector remain unchanged. That is, consistent with this CDR support portal guidance, the policy view is that CDR consumers in the banking sector must have an online account set up to be eligible. The Explanatory Statement for the Competition and Consumer (Consumer Data Right) Amendment Rules (No.1) 2023 includes further explanations of each rule amendment. Link here. |
| 2069 | Rules Amendment Item 11 - 9.3(1)(fa) added a requirement to keep records of Consumer Complaints data. Rule 9.3(1)(f) already included requirement to keep records for CDR complaint data. Could you please elaborate on what difference is between the two, and any specific data that is applicable to one and not the other? |
Rule 9.3(1)(fa) requires data holders to keep a record of the actual CDR consumer complaint (9.3(1)(fa)) in addition to CDR complaint data (9.3(1)(f)). 'CDR complaint data' is defined in rule 1.7(1) as including the following: (a) the number of CDR consumer complaints received by the CDR participant (b) the number of such complaints for each complaint type into which the CDR participant categorises complaints in accordance with its complaints handling process (c) the number of such complaints resolved (d) the average number of days taken to resolve CDR consumer complaints through internal dispute resolution (e) the number of CDR consumer complaints referred to a recognised external dispute resolution scheme (f) the number of CDR consumer complaints resolved by external dispute resolution (g) in relation to a CDR participant that is a data holder―the number of CDR product data complaints received. 'CDR consumer complaint' is also defined in rule 1.7(1) as meaning any expression of dissatisfaction made by a CDR consumer to or about a CDR participant, or a CDR representative of a CDR participant, with regards to: the provision to the CDR consumer of goods or services which the consumer has provided consent under Part 4 of the rules, and which a response or resolution could reasonably be expected a complaint relating to a participant’s obligations under, or compliance with, rules dealing with the handling of CDR consumer complaints a participant’s obligations under or compliance with Part IVD of the Act; the CDR rules; or binding data standards. |
| 2090 | Invalid Banking Account error response when there are more than one invalid account ID Issue : When there are more than one invalid account IDs in the POST request where accountId list is passed in the request body for the below APIs: Get Scheduled Payments For Specific Accounts Get Balances For Specific Accounts Get Direct Debits For Specific Accounts What is the expectation for the error response detail? As per our current implementation, if multiple accounts are provided in the request body, the solution would traverse through the list of accounts and stop checking for further IDs if it encounters an invalid Id. It will return the first invalid account ID encountered in the error response detail. Example: AccountId list in Request body ['validID1', 'validID2', 'InvalidID1', 'validID3', 'InvalidID2', 'InvalidID3'] detail field of API Response will have 'InvalidID1' I'd like to have the clarification from the support team if this response is correct and as per expectation of the standard. |
I had a look through the CDS Guide and this entry should help you out: https://cdr-support.zendesk.com/hc/en-us/articles/5729181240591#Accounts_that_cannot_be_shared:_404,_422 |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |