ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 1st of August 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 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 | Updated | Links |
|---|---|---|
| Standards | Version 1.31.0 | Published: 3rd of July 2024 Change log |
| Maintenance | Iteration 20 Commenced 10th of July 2024 |
Sign-up and Register Data Standards Body Events |
| Maintenance | Iteration 20 Schedule: 7/08/2024 Consultation and new issue checkpoint 21/08/2024 Proposal Checkpoint 4/09/2024 Approvals and Documentation |
MI20 Agendas and Minutes |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 26th of July 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 351 - LCCD Risk workshop summary | No feedback sought Link to Noting Paper |
| Engineering | Type Definition Library: The Github Repository has been updated to align to the latest CDS version (1.31.0). | See latest npm package The Github Repo |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
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 |
|---|---|---|
| 2401 | There are fields defined in the BankingTransaction as being of the String or AsciiString data type. The definitions for these data types do not explicitly approve or deny that empty strings are permitted. We are seeing some data holders pass us a "description" attribute for transactions as an empty string. Can the DSB recall if this was left loose on purpose, or if there is an expectation that a field such as "description" which is listed as mandatory in the standards should infact NOT permit an empty string value. |
The Empty/Null Fields section states: An empty string (“”) is not considered to be equivalent to null. And the mandatory reference field in BankingTransaction (and a couple of others) states: Empty string if no data provided. This is to allow for Data Holders that do not have a value for that field to return a schema-compliant response. i.e. To provide the field with an empty value, which is different to a null value, being equivalent to an absent field. As the description field doesn't include that statement it could be argued that an empty string is not allowed, but the Data Holder may have valid reasons for it. i.e. the customer did not provide a description. In some cases, how the description is presented in other channels may be a consideration (e.g. if they show some default text). Are you finding that these Data Holders always provide an empty string, or only for certain products, or is it indeterminate? If there is a compliance concern, it could be something the ACCC could review in the first instance, otherwise a Standards Maintenance issue could be raised to clarify the standards expectation. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |