ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 4th of May 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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
teams@vc.treasury.gov.au
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 contact@consumerdatastandards.gov.au 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.23.0 published 14th of April 2023	Version 1.23.0 Change Log
Standards	Next version of the Consumer Data Standards: 1.24.0	Version 1.24.0 will contain changes from Maintenance Iteration 14
Maintenance	Iteration 14 retrospective survey issued	Closes Friday 5th of May 2023
Maintenance	Iteration 15 commenced 3rd of May 2023 Invitations sent out	Agenda for 3rd of May 2023
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	24th of April 2023	View in browser here
DSB Newsletter	28th of April 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	Noting Paper 280: The CX of Authentication Uplift	UPDATE: See NP296 for continuation of consultation
Consultation	Decision Proposal 288 - Non-Functional Requirements Revision	Feedback closes 12th of May 2023 Link to consultation
Consultation	Noting Paper 289 - Register Standards Revision	Feedback closes 12th of May 2023 Link to consultation Video 56 of NP289
Consultation	Decision Proposal 302 - Telco Draft Feedback Cycle 2	No Close Date Link to consultation

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	Register	Eva
ACCC	CTS	Seamus
DSB	CX Standards	Amy
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Banking & Information Security	Mark
DSB	Technical Standards - Register	James
DSB	Technical Standards - Telecommunications	Brian
DSB	Technical Standards - Engineering	Sumaya

Presentation

Data Standards Body
James Bligh
Options on DP288 - Non-Functional Requirements Revision

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
1864	I was wondering if there are sample payloads available for reference across the various APIs? Our dev team have had a few queries come up and the question was asked so I thought I’d share it. In particular we’re looking at the ‘Get Accounts’ payloads for reference.	Apologies for the late reply. We do not have any sample payloads. However, our engineering team have been working on a test data generator tool which may be of help to you. It can be accessed here - https://github.com/ConsumerDataStandardsAustralia/testdata-cli If you discover any problems you can raise an issue on the repository, or send another message via zendesk.
1950	Plan DisplayName versus NickName - Energy I was hoping you could help clarify what is the use for nickname and display name? The reason I ask is because I am unclear on the definitions. We want to provide the customer friendly plan name but arent clear on which one will have that value. Our understanding is that it can fit into either of those. Also, nickname definition says "provided by customer" which adds to our confusion.	Confirmed on the call 270/04 AEC/DSB Both are optional fields and the nickname is actually a nickname given to the property by the customer if the data holder provides this service.
655	Guidance on eligible consumers where a data holder has multiple brands and/or white-label arrangements We would like to clarify the definition of eligible consumers for a data holder where the data holder has multiple brands and/or white-label arrangements for the following scenarios: Scenario 1: • A DH brand does not have any online consumers for an in-scope product. This scenario may occur (for example): - the data holder currently does not provide any online channel for that brand’s consumers, or - the data holder has no active accounts remaining for that brand. Scenario 2: • (Similar to the above but under white-label arrangements) A DH white-label arrangement does not have any online consumers due to (for example): - the brand owner or data holder not providing an online channel to that brand’s consumers, or - the data holder no longer having active accounts remaining for that white-label arrangement. Our interpretation of the eligibility requirements is that consumers for the above scenarios would not be eligible CDR consumers – is this correct?	We have updated our guidance on this topic. See link here: https://cdr-support.zendesk.com/hc/en-us/articles/4871126055567 If the approach outlined in the guidance raises implementation challenges we are encouraging those affected to provide feedback to Treasury at data@treasury.gov.au. Alternatively, if you are concerned about compliance, you can contact the ACCC on accc-cdr@accc.gov.au.
1793	We appreciate your guidance on this issue and have follow-ups regarding the suggested approach : In a scenario where we are transitioning between a deprecated, but active brand, and a new brand, should we: Limit the duration of a request establishing new consent, or amend consent request can be active for in the old system? or, can we simply inform the user on the old system, during the consent flow, that their consent will be cancelled at a pre-determine end date? or, both?	It is not permissible under the Rules to limit the duration of a consent to less than the period requested by the consumer (in either manner described in your enquiry), or to amend the consent without instruction from the relevant consumer. The ACCC understands that platform migrations create particular difficulties. The ACCC considers non-compliance in line with the factors in the ACCC/OAIC Joint Compliance and Enforcement Policy for the Consumer Data Right, particularly the actions of the business in relation to the conduct, including whether the conduct was self-reported, the timing of the self-report, and whether the business has taken action to mitigate the impact of the breach. We encourage any data holders who are experiencing issues of this kind to contact the ACCC Compliance Team via accc-cdr@accc.gov.au to discuss their circumstances. We advise doing this well in advance of any migration dates.
1879 Part 1	As a Data Holder do we need to display ADR's Legal entity ID along with ADR's Legal entity name in the consent authorisation journey? OR ADR's Legal entity name with accreditationNumber is fine to proceed? legalEntityId: Unique id of the Data Recipient Legal Entity issued by the CDR Register. legalEntityName: Legal name of the Data Recipient accreditationNumber: CDR Register issued human readable unique number given to Data Recipients upon accreditation If a DH is displaying ADR's Legal entity ID along with ADR's Legal entity name in the consent authorisation journey is there any compliance issue?	Regarding what information relating to an ADR that a DH must display during authorisation: Rule 4.23(1)(a) requires a data holder to provide the consumer with the name of the ADR (i.e. legal entity name) during the authorisation process. There are no requirements in the rules or standards requiring the disclosure of the legal entity ID or accreditation number in the authorisation process. Rather, the display of this information may be prohibited due to Rule 4.24(b), which prohibits Data Holders from adding additional information, interactions, or services to the authorisation process beyond what is outlined in the CDR rules and standards.
1879 Part 2	Could you please elaborate/ provide sample of information that DH needs to provide with regards to rule 4.23(2) "The data holder must also give the CDR consumer any information that the Register of Accredited Persons holds in relation to the accredited person that is specified as information for the purposes of this rule."	As of 02/05/2023, no information has been specified for purposes of Rule 4.23(2) and therefore no additional information is required to be reported.
1943	About a year ago I sought confirmation on managing nomination representatives / non-individual. (See attached image) We would like to seek confirmation that our manner of approach is still adhering the rules to offer sharing for the non-individual. So instead of a nominated rep having full access to share all the accounts belonging to a non-individual by default, we have offered a more granular approach to setup the sharing for non-individual, in that each nominated rep has to hold a relationship(for example - being a signatory) with the specific account in order to share it. This is in line with the manner that how DA system and our FIs operations are setup. Most FIs using our system are not setup to allow the non-individual itself access to Internet Banking(IB). Instead, IB access to the accounts are given to the natural person accessing the accounts. Therefore this forms the premise of how the non-individual 'line' of eligibility from this nominated representative is established. In practice, this would mean if there's no nominated rep having IB access to any of the non-individual's active accounts, the non-individual will be deemed as ineligible to share. Therefore in doing so, the non-individual would have a means of controlling only the accounts that can be shared (through the use of the nominated representative flag), and that these natural people are only able to represent sharing for these set of accounts because they already hold a relationship to these accounts. During our SIT testing we have encountered a likely edge case scenario. If the nominated rep has sharing rights to only closed accounts owned by a non-individual they are unable to share these accounts. While that nominated rep may have a "relationship" to other active accounts owned by that non-individual, they are not configured as a nominated rep on the active accounts. This is in spite of the non-individual still being an eligible CDR user in its own right if it has other accounts that are active and accessible by other nominated reps (i.e. it can still allow sharing of its other active/closed accounts through the other nominated reps). We would like to seek confirmation that our manner of approach do not contradict the CDR rules in non-individual sharing.	If a CDR consumer remains an eligible CDR consumer and holds at least one other account with the data holder that is open and accessible online, the consumer may share data from a closed account, subject to clauses 3.2(4) and (5) of schedule 3. In the scenario specified in your enquiry, the non-individual is the CDR consumer and it may be able to share data from a closed account if it remains an eligible CDR consumer. The CDR rules states that a nominated representative must be an individual who is 18 years or older but do not otherwise restrict who can be a nominated representative (see rule 1.13(1)(c)(i)). This means each nominated representative does not need to satisfy the CDR consumer eligibility criteria and may be able to share data from a closed account if the business has provided the relevant authority. However, we note that the CDR rules leave it open for data holders to agree with their non-individual customers on the scope of authorisations that different nominated representatives may have (see section 2.6 of our Nominated representatives guidance). This means that not all nominated representatives are required to have the same scope of authority to authorise or manage the sharing of CDR data on behalf of the non-individual. Therefore, a data holder is able to determine the scope of authority each nominated representative has with a non-individual CDR consumer and this will mean that nominated representatives may not have access to all of the non-individual accounts in different circumstances. The ACCC is unable to provide tailored compliance advice, and we recommend CDR participants seek independent advice on how best to achieve compliance in their specific circumstances. However, we hope that the above information assists you.
1944	Can I please ask what’s the expectation when sharing customer data if the person who authorised the consent was a Power of Attorney? Should we be sharing the POA’s information or the account owner’s information?	The CDR does not contain provisions that expressly deal with powers of attorney. We provide non-prescriptive guidance and information on power of attorney and its interaction with the CDR here. Key points in the guidance that are relevant to your question include: - In general, where the CDR Rules require something to be provided to a CDR consumer, we consider the same thing could be provided to the attorney acting on behalf of the CDR consumer (in addition to the CDR consumer), where this is within the attorney’s authority (for example, they could receive the consumer dashboard if they had appropriate authority). - A person acting under a power of attorney on behalf of a CDR consumer would not become the “CDR consumer” for that CDR data. Accordingly, where authentication is required, the attorney must authenticate using their own identity. This means the attorney should receive their own credentials to access CDR services such as a consumer dashboard or disclosure option management service. - Where, for the purposes of the CDR, a data holder, accredited person or CDR representative deals with an attorney acting under a power of attorney, they will need to assess whether the attorney’s decisions on behalf of the CDR consumer are within the scope of the attorney’s authority.
1946	In the following scenario in a consent flow: 1: Consumer consents for data collection and use 2. Collect data from DH 1 3. Collect data from DH 2 4. System outage So we have Collected 2 lots of data but not actually used them. I would assume there would have been notifications and dashboard items for the Collection consents. What about the use consent - even though it was provided, the data was never used for the consented purpose? I would think that it does not make any sense to put in the dashboard, and notify the consumer of a consent that did not actually happen, even though they consented to it. Can you please confirm? Thanks	Under the CDR Rules (clause 1.14), the consumer dashboard must contain details of each consent, including: - the CDR data that has been authorised to be disclosed; - when the consumer gave the authorisation and what period it was given for; - if CDR data has been disclosed – what data was disclosed, when it was disclosed and the ADR it was disclosed to; - for a use consent – details of the specific use or uses for which the CDR consumer has given their consent; - information relating to CDR data that was collected or disclosed pursuant to the consent. Therefore, if a consumer has given consent for their data to be collected, used, or disclosed, details of each consent (and what the CDR consumer has consented to) must be displayed on the dashboard – regardless of whether or not the consent was able to be fulfilled due to a system outage. We also note that once the system outage is resolved, ADRs are once again obligated to fulfil the request associated with a consumer’s authorisation they received prior to the outage. The only exception to this would be if the system outage occurred during the authorisation process and therefore the CDR consumer was not able to make a valid consumer data request before the outage. In this case, the consumer would need to re-start the authorisation process to give consent for their data to be collected, used or disclosed. We hope this information assists you. If you have any further questions, please do not hesitate to contact us again.
1957	Is the above FAQ just applicable to banking sector or all sectors. https://cdr-support.zendesk.com/hc/en-us/articles/4871126055567-Digital-channels-and-the-eligibility-of-CDR-consumers	The knowledge article (https://cdr-support.zendesk.com/hc/en-us/articles/4871126055567-Digital-channels-and-the-eligibility-of-CDR-consumers) provides guidance to data holders on assessing eligibility of CDR consumers in the banking sector, in accordance with the CDR Rules. However we note that in accordance with rule 1.10B of the CDR Rules, a CDR consumer’s eligibility is assessed at the data holder level across all sectors. If you are interested in understanding how to assess eligibility in the energy sector, guidance can be found in the following documents: Eligibility criteria for CDR consumers in the energy sector Compliance guide for data holders in the energy sector
1958	If I am not wrong ACCC uses a schema validation tool for PRD data. Could data holders have access to the schema validator tool too?	Unfortunately, the ACCC is unable to provide data holders with access to its automated schema validation tool at this stage. However, the ACCC is currently evaluating how it can best provide similar tooling to CDR participants and may consider publication of further information in this regard in the future. In the meantime, we recommend referring to the DSB's collection of Schema tests that DSB has provided links to above. We hope this information assists you. If you require any further information, please do not hesitate to contact us again. The Data Standards Body have a Postman collection and set of Schema tests. These are not the tools used by the ACCC nor give a participant a automatic pass for compliance. They can assist in vetting the work a data holder is completing on their endpoints. I'd encourage you to take a look at these as well. They are open source and developed by the DSB. Schema Tools: https://github.com/ConsumerDataStandardsAustralia/dsb-schema-tools Postman Collection: https://github.com/ConsumerDataStandardsAustralia/dsb-postman