ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 6th of June 2024
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
- 5 min will be al lowed 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 | Updated | Links |
|---|---|---|
| Standards | Version 1.30.0 | Published: 24th of April 2024 Change log |
| Maintenance | Iteration 19 underway | You can sign up here. Look for the Maintenance Iteration 19 Series. |
| Maintenance | Iteration 19 Schedule 1/05/2024 Consultation 15/05/2024 Consultation and new issue checkpoint 29/05/2024 Proposal Checkpoint 12/06/2024 Approvals and Documentation |
Agendas and Meeting Minutes |
| Maintenance | Iteration 20 Planned to commence 10th of July 2024 |
Invites will be issued at the close of Iteration 19 |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 31st of May 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Noting Paper 346 - Standards Assessment Framework |
Feedback closes: 12th June 2024 Link to consultation |
| Engineering | Survey on updates to the GitHub Readmes | Complete the survey |
| Guidance | The ACCC has published a knowledge article that provides guidance on the meaning of ‘CDR consumer complaint’ and how records of complaints should be kept and maintained, and reported under rules 9.3 and 9.4 of the Competition and Consumer (Consumer Data Right) Rules 2020. | The article is available on the CDR Support Portal. |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform, Conformance Test Suite & Participant Tooling | Callina |
| DSB | Standards Assessment Framework | Elizabeth |
| DSB | Energy | Hemang |
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 |
|---|---|---|
| 2362 Part 1 | Would ACCC consider it as non-compliance if Data Holders do not get the below accessibility standards tested for the new Consumer Dashboard screens (Consent history summary and Consent history details) before making them go live https://consumerdatastandardsaustralia.github.io/standards/index.html#accessibility-standards | We note the relevant standard states: These standards SHOULD be assessed, tested, and refined further by accessibility consultants directly involved in implementation. As set out in our data holder compliance guides, if a Standard states that a data holder ‘SHOULD’ do something, the data holder should use RFC 2119 to interpret this as follows: - RFC 2119 states that ‘SHOULD’ and ‘RECOMMENDED’ mean that there may be valid reasons for not conforming with that item in some circumstances, but the full implications must be understood and carefully weighed before doing so. - As a matter of compliance and enforcement policy, where binding Standards state that a data holder ‘SHOULD’ do something, the ACCC expects that CDR participants operate in accordance with the Standard unless the circumstances and implications indicate that conformance would not give effect to the intention of the Standard. While there is no specific testing mandated by the ACCC, we recommend data holders take this step to ensure compliance with the relevant standards. |
| 2362 Part 2 | I can see that the below accessibility standards are laid out in the Consumer Data Standards specifically with respect to the Consent Model. There is no mention about assessing, testing and refining them for Open Banking Consumer Dashboard screens hosted on Data Holder's Internet Banking and/or Mobile Banking channels. Is this something you could clarify, or should I be checking with DSB?https://consumerdatastandardsaustralia.github.io/standards/index.html#accessibility-standards | You're correct that the accessibility standards you've referenced apply throughout the "Consent Model". This term is not defined in the standards or rules. However, the CX Guidelines website includes a description of the Consent Model as extending to consent, authenticate, authorise and consent management. Consent management is then further defined as including Data Recipient and Data Holder dashboards as well as other areas such as notifications, withdrawal, etc. (see here: https://cx.cds.gov.au/overview/about-consent/the-consent-model). On this basis, the ACCC's view is that the accessibility standards extend to dashboards. |
| 2366 | We have an inquiry regarding the Get Transactions for Account endpoint, and the requirement to enable 7 years worth of transactions data. Is it an option to limit a data recipient to only being able to request one year of data per request? A data recipient would still be able to retrieve 7 years worth of data, it would just have to be through 7 subsequent calls to our endpoint. The reason for this ask is that it will be impossible to retrieve large quantities of data within the required non-functional requirements, specifically the Performance requirement, of 1500 ms or 4000 ms. If we could instead return data just one year at a time, we could meet these NFRs, while providing a better customer experience. |
The Get Transactions For Account endpoint provides the following parameter: - page-size: Page size to request. Default is 25 (standard pagination) This means that if a request does not include a page-size parameter value, the default number of records to return for a single response is 25. This is not a limit on what must be returned to fulfil the request though. If the query requested transactions for seven years, and the result was 2,500 transaction records (for example), you would return the first 25 records in the first page and provide pagination links to all subsequent pages for the consumer to keep making requests for the remaining records (i.e., 100 pages of 25 records each). The Performance Requirements of 1500ms is per response (page in this case). As making 100 requests for 25 transactions at a time may be onerous for the recipient, they can also specify up to 1,000 records at a time as the page-size. This would then result in 3 requests (pages) of records needing to be returned (1000 + 1000 + 500) to fulfil a 7 year request comprising 2,500 records (as an example). The 'per response' performance requirement still applies to requests for up to 1,000 records though. |
| 2368 | I'm looking at the public APIs - specifically Get Products and Get Product Details for Banking sector. Now I know it has an enum to limit the products that come back in the response for Get Products, ie "TRANS_AND_SAVINGS_ACCOUNTS" however I'm wondering if there's a way to further filter this? Namely I'd like to fetch ONLY savings type accounts and if possible only retail ones as well. TLDR - how can I further filter Savings accounts only from TRANS_AND_SAVINGS_ACCOUNTS - how can I filter only retail accounts If there's not an explicit clear cut way do you have a suggestion on how I can perform this filtering manually on my side? |
The definition of transaction and savings accounts may differ across Banks, so filtering further than that category may depend on subjective factors. You could consider filtering by features that you consider only available to one or the other, the types of fees, or the presence or level of deposit rates, but the results may vary depending on the product proposition. Some transaction accounts offer interest on the deposited balance, for example. In terms of filtering to 'retail' accounts, I'm assuming you mean accounts available to personal consumers only, and not businesses. If so, you could consider excluding products that have the BUSINESS eligibility type, which states 'Only business may apply for the account'. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |