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

---

1. Introductions
2. House Keeping
3. Updates
4. CDR Stream updates
5. Presentation
6. Q&A
7. Any other business

• 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	Topic	Update
Standards	Version 1.29.1	Published: 28th of February 2024 Change log
Maintenance	Maintenance Iteration 18 commenced on the 7th February 2024 Working Group met on the 3rd of April 2024	MI 18Agendas Please reach out to [email protected] for an invitation
Maintenance	Iteration 19 to commence	Invitations will be sent out shortly
DSB Newsletter	To subscribe to DSB Newsletter	Link here
DSB Newsletter ⭐	28th of March 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 330 - UNSW Reports	Link to consultation
Consultation	Decision Proposal 340 - Maintenance Iteration 18	Link to consultation
Consultation	Noting Paper 342 - Information Security Working Group	Link to consultation
Consultation	Noting Paper 345 - Data Standards Body Capability, Consultation Processes and Operating Mode	Link to consultation
Tooling	The Github Repository has been updated ( v1.5.0 ) to align with the artefact to the latest CDS version (1.29.1).	The relevant NPM package ( 1.5.0 ) has been published in the NPM Registry as well.
Video	Noting Paper 345 - narrated by Neale Morison (4/04/2024)	Link to video
ANZAC Day	The CDR Implementation Call for the 25th of April 2024 will be cancelled.	Updates to invitations will be sent out.

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

Organisation	Stream	Member
DSB	Consumer Experience	Bikram
DSB	Energy	Hemang
DSB	Information Security	Mark

None this week.

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.

Ticket #	Question	Answer
2280	Referring to the consent sequence diagram in the link https://cdr-support.zendesk.com/hc/en-us/articles/5300325565199-Consent-sequence-diagrams. Please clarify the below points: 1. In Step 2 under "Consent sequence diagram 2 - consent sequence", if the Data Holder redirects consumer to ADR with failed response then does Data Holder need to display this authorisation with status as 'failed' in the Data holder consent dashboard? 2. In Step 3 under "Consent sequence diagram 2 - consent sequence", if the ADR was unable to get access and refresh tokens or the authorisation code expires, then should Data Holder display this authorisation with status as 'failed' in the Data holder consent dashboard? 3. Considering above does DH need to notify consumer regarding this authorisation? As we have not seen any notification obligation around this case. OR 4. Does DH need to display the consent as active in the DH consent dashboard immediately after Step 2 under "Consent sequence diagram 2 - consent sequence", irrespective of whether ADR had a success or failure token exchange call?	Thanks for these questions. The ACCC and DSB have considered together to provide the following response. In relation to questions 1, 2 and 4, Data holders must display details about authorisations in accordance with the CDR rules. For example, rule 1.15(1)(b), (3) and (5)(a) require a number of details about authorisations to be contained in the consumer dashboard, including details of the CDR data that has been authorised to be disclosed, and the period of the authorisation. The CDR standards additionally require authorisations to be displayed as 'active' if the duration is current, and 'expired' if the duration is not (and/or the authorisation was withdrawn by the consumer). The technical validity of the authorisation could be displayed, but would not determine whether it's an 'active' authorisation. This means that if the consumer has given the authorisation then the authorisation needs to be displayed on the DH dashboard, regardless of the ADR's ability to get the data. In relation to question 3, there are no specific notification requirements under the rules for the scenarios raised in questions 1 and 2. However, data holders should take care to comply with the ordinary notification requirements that apply to authorisations, for example if the authorisation was given by a joint account holder, the notification requirements under r 4A.14 would apply.
2304	For the Banking Sector, the CDR rules have a sub-clause for eligible members: "the account is setup in such a way that it can be accessed online" (Part 2, section 2.1) We would like clarification on this for scenario where a Consumer has had their access to accounts online removed/restricted. If a consumer's account has been setup for online access, but the consumer is currently unable to access the online channels for some other reason (potentially just a temporary reason, but sometimes for more extended periods), should that consumer be deemed "ineligible"? Example: - the Data Holder has temporarily locked the consumer's access to online channels due to fraud investigations or periods of login inactivity - the user has been locked out due to failed login attempts In such cases the consumer's ACCOUNT remains set up for online access, but the consumer is unable to log into the online channels to access that account. And in these situations the consumer's access to online channels can usually be resolved by contacting the Data Holder.	As you have flagged, one of the criteria for a consumer to be considered an eligible CDR consumer in the banking sector is that the account is set up in such a way that it can be accessed online (see clause 2.1 of Schedule 3 to the CDR Rules). We consider that a consumer who is temporarily unable to log into their account online (for example, due to a number of failed login attempts or a forgotten password) remains an eligible CDR consumer because their account is still technically able to be accessed online. This means that authorisations do not expire merely because a CDR consumer’s account has been temporarily locked and data should continue to be shared in relation to a valid consent even if the consumer is temporarily unable to log into their account online.
2310 part 1	Could clarity please be provided if the CDR Software Product Name is intended to be the specific software product that the Consumer sees? I ask because we are noticing a number of software products of representatives registered under the representative company name which begs the question, what happens when a representative has multiple CDR software products?	The Accreditation Registrar requests that CDR Principals include the legal entity name in software product entries. If the Principal considers it useful to do so, it may include additional information in brackets after the legal entity name - e.g Wealth Management Partners Pty Ltd (MoneyManager). If a representative has multiple software products, the information in brackets can be used to differentiate between them.
2310 part 2	I presume this is as a result of the flaws identified in 2022 of the Register design: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/427 The issue we now see is that Consumers are unable to find software products in the Holder Dashboard matching what they believe the product to be called especially since it is presented side-by-side with the Unrestricted ADRs legal entity. How does the ACCC expect Holders to manage these Consumer expectations?	Software products are named by CDR Representative Principals within the guidelines set by the Registrar. The requirements on Data Holders to display this information within the Dashboard are laid out in relevant CX Standards and associated guidance. If the name of a particular software product(s) is not assisting consumers to manage authorisations via the Data Holder Dashboard, it would be useful for the consumer to contact either the Representative, or the ACCC (via [email protected]) so that we can better understand their experience. Any more details you or your clients are able to provide, including anonymised content of the relevant consumer contact, would also be gratefully received. This may enable us to work with the relevant Principal to make the name of the software product more useful to consumers. If this experience is not specific to a given software product or products, it may be useful to provide a screenshot to illustrate the issue and enable us to consider whether there is further guidance we can provide.

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.