ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 16th of March 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

Acknowledgement of Country

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.

House Keeping

Recording

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.

Community Guidelines

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.

Updates

Type	Topic	Update
Standards	Version 1.22.0 published 23rd of December 2022	Version 1.22.0 Change Log Release video 1.22.0
Standards	Version 1.22.1 is due soon.	Changes to include Draft Telecommunications Standards updates and removal of the festive hat.
Maintenance	Iteration 14 Working Group agenda and minutes for 8th of March 2023 published	Check out the agenda here
Maintenance	Iteration Candidates are in consultation	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	10th of March 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
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Decision Proposal 288 - Non-Functional Requirements Revision	Feedback 31st of March 2023 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
Consultation	Noting Paper 280: The CX of Authentication Uplift	UPDATE: New questions and context provided.
Guidance	Managing implementation change – Data holder obligations	The article highlights the need for data holders to give careful consideration to the impact of any changes on consents and authorisations. It sets out the ACCC’s expectation that data holders will take steps to ensure continuity of ongoing consents and authorisations when there is a change to a CDR technology solution.
Survey	Results are in	63.2% of the vote went to cancelling the 6th of April 2023

CDR Stream Updates

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

Organisation	Stream	Member
ACCC	CDR Register	Eva
ACCC	CTS	Andrea
DSB	CX Standards	Michael
DSB	Technical Standards - Banking & Infosec	Mark
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Telco	Brian
DSB	Technical Standards - Register	James

Presentation

None this week.

Q&A

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.

Answer provided

Ticket #	Question	Answer
1889	The new accountOwnership object being returned under CDR will now return various values. These are: - UNKNOWN - The exact party relationship cannot be determined. - ONE_PARTY - One party is the owner of the account. - TWO_PARTY - Two parties are the owners of the account. - MANY_PARTY - Three or more parties are the owners of the account. - OTHER - The account ownership relationship is a complex arrangement that cannot be expressed by the number of owning parties. In what situation would OTHER be returned? Can you please provide a real world example. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/513	We're not able to provide a specific real-world example, and it could be uncommon, but the OTHER value may be necessary in the case of an account belonging to a partnership of a combination of multiple individuals and/or non-individuals, certain trusts, or a combination of these, where the number of 'account owners' has not been, or cannot be determined in a consistent way by a data holder. Apart from the numeric values, the other values were intended to provide slightly different meaning. In summary: UNKNOWN - the number of account owners is not known, possibly temporarily. ONE_PARTY, TWO_PARTY and MANY_PARTY - the number of account owners is known and aligns to one of these values. OTHER - implies that an ownership relationship may be known to be complex, and a definitive number of 'account owners' cannot be provided, possibly temporarily.
1890	The ‘Get Energy Account Detail’ API endpoint requires account data and associated plan data for the account. EnergyPlanContract is marked as mandatory if the fuelType is ELECTRICITY. In the energy sector, the AER and the Victorian agency are designated data holders for all the relevant product data under the designation instrument. As such, we are seeking to confirm whether Dataholder A Energy Retail is required to provide the EnergyPlanContract data for the ‘Get Energy Account Detail’ API for plan data (EnergyPlanContract) in circumstances where the plan data relates to standing offer prices and is identical to the plan data provided to the AER for the purpose of maintaining the Energy Made Easy website?	Dataholder A energy is required to provide a response to any valid request to the Get Energy Account Detail API, which include the EnergyPlanContract structure. The below points should help clarify: EnergyPlanContract is a common structure used across Get Energy Plan Details and ‘Get Energy Account Detail’ API. The ‘Get Energy Account Detail’ is consumer data a API. The retailer is the designated data holder/provider for it. It is intended to provide information about a customers account with their consent (i.e. details about the account/plan the given customer has with the retailer) The ‘Get Energy Plan Detail’ is a product reference data API. As you rightly pointed out, the designated data holder for it is AER and it would be the same information that the retailers provide them to maintain Energy Made Easy and Vic Energy Compare sites
1831	We seek clarification on an aspect of the Nominated representative of non-individuals and partnerships in CDR - Fact Sheet published by the DSB on 22 December 2022: Section 4.3. Transfer of authorisations between nominated representatives states that “When a specific individual is made a nominated representative, an authorisation given by that individual cannot be transferred to (or amended or withdrawn by) a second nominated representative”. However, that appears to contradict the preceding section 4.2.1. Status of existing authorisations on revocation of nominated representative status, which caters for the scenario in which a nominated representative previously created an authorisation but is no longer with the organisation: “Non-individuals and partnerships may have authorisations in place that last beyond the time for which an authorising individual is a nominated representative. This is because the CDR consumer that has granted authorisation is the business, not the individual representative. A data holder cannot decide to end an authorisation because the authorising nominated representative has their status revoked. Data holders should work with their customers to ensure continuity of any ongoing authorisations. For example, a data holder may choose to have a default arrangement where any nominated representative or a select group of nominated representatives can view and manage all existing authorisations through the data holder consumer dashboard, and removal of a nominated representative does not affect authorisations they have previously given. A data holder is neither required nor authorised to disclose the consumer data of a nonindividual or partnership that has no nominated representatives. This means a data holder should cease sharing data from an account when the last nominated representative is removed. However, we recognise that there may be circumstances where an ongoing authorisation remains in place after the last (or sole) nominated representative has been removed from an account. In these circumstances, our view is that a data holder would not be in breach for continuing to disclose data in accordance with a valid authorisation.“ As the guidance notes “This is because the business is the CDR consumer (rather than the nominated representative), and the ongoing authorisation was put in place on its behalf.” We agree that as per 4.2.1., organisations should be able to revoke active authorisations that were created by former nominated representative and that this capability should extend to any of the organisation’s active nominate representatives. We believe that this position is consistent with rule 1.13(1)(c)(i)).	As stated in our guidance, in the case of a non-individual, the CDR consumer that granted an authorisation is the business, not the nominated representative. This means the authorisation belongs to the business rather than the nominated representative. Consequently, if a nominated representative has had their status revoked, remaining representatives are able to withdraw the authorisations made by the previous representative via the consumer dashboard. The data standards facilitate authenticated users through the Pairwise Pseudonymous Identifier (PPID) which is an unique identifier for an authenticated user. Where the authenticated user is a nominated representative, the PPID represents that nominated representative, not the entity they are representing. This means that the identifier is specific to the nominated representative that established the authorisation. While authorisations made by a former nominated representative can be revoked by other nominated representatives, it is not possible to transfer the authorisation to an existing nominated representative that already has a PPID. This is because an authenticated user cannot have more than one PPID. However, the PPID of a former nominated representative may be able to be transferred to a new authenticated user who will be a nominated representative for the same business and does not have an existing PPID. This would also transfer the authorisations given by the previous nominated representative. We will consider the need to clarify our guidance on the interaction between PPIDs and existing authorisations.
1860	An accredited data recipient (ADR) is required to submit reports in accordance with Rule 9.4(2) and, if it is a CDR Principal, in accordance with Rule 9.4(2A). For the purposes of completing the report under Rule 9.4(2), should the ADR include or exclude information that will also be included in a report it submits for the purposes of Rule 9.2(2A) for each of its CDR Representatives? For example, question 12 on the template report submitted for the purposes of Rule 9.4(2) requires the ADR to set out “the number of consumer data requests the accredited data recipient made during the reporting period. For the avoidance of doubt, this includes all consumer data requests made regardless of whether or not the request was successful.” Question 5.1 on the template report submitted for the purposes of Rule 9.4(2A) similarly asks the ADR to set out “the number of consumer data requests made by the CDR principal on behalf of the CDR representative during the reporting period.” When responding to question 12, should the ADR include the aggregate number of all consumer data requests it has made on behalf of a CDR Representative (and which would be separately reported for each CDR Representative in the response to question 5.1), or should the ADR exclude consumer data requests made on behalf of a CDR Representative?	As you have noted, Question 12 in the ADR report requires an ADR to submit the number of consumer data requests it made during the reporting period. In accordance with rule 1.10AA(2) of the CDR rules, an ADR that is a CDR principal is the one who makes an appropriate consumer data request on behalf of the CDR representative. Hence, Question 12 in the ADR report should include the total number of consumer data requests made by the ADR including the requests it has made on behalf of any CDR representatives. An ADR that is a CDR principal must also submit the number of consumer data requests it has made on behalf of each CDR representative in its CDR Principal report. We hope this information assists. We are currently in the process of preparing relevant guidance which we hope to publish soon.