ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 25th of August 2022

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: [email protected]

Phones - AUDIO ONLY

Primary Australia: +61-2-9338-2221
Quick Dial: +61-2-9338-2221,,1650705270##
Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
Meeting Number/Access Code: 165 070 5270

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.18.0 Published	Link to change log here
Maintenance	Maintenance Iteration 12	First meet on the 20th of July 2022
Maintenance	Maintenance Iteration 12	Next week on the 31st of August 2022 is next meet up of the MI Working Group
Maintenance	Decision Proposal 259 - Maintenance Iteration 12	Changes, meeting notes and updates for the iteration can be found here
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	26th of July 2022	View in browser here
DSB Newsletter	19th of August 2022	View in browser here
Consultation	Normative Standards Review (2021)	No Close Date Link to consultation
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Noting Paper	Noting Paper 255 - Approach to Telco Sector Standards	Link to consultation
Noting Paper	Noting Paper 258 - Independent Information Security Review	Link to consultation
Consultation	Reopened Decision Proposal 260 - Energy Closed Accounts Feedback closes: 30th of August 2022	Link to consultation
Consultation	Decision Proposal 262 - Telco Product Reference Payloads Feedback closes: 5th of September 2022	Link to consultation
Consultation	Decision Proposal 263 - Telco Accounts Payloads Feedback closes: 16th of September 2022	Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language Feedback closes: 15th of September 2022	Link to consultation
Request for Feedback	The Data Standards Body request the Energy retailers to review and comment on Maintenance Issue 529 - CX - Energy Data Language Standards - NMI and Scheduled Payments. If there is consensus for the change to take effect from November, we will propose that the change be treated as urgent and dealt with separate to Maintenance Iteration 12.	Link to Issue 529
Guidance	Providing dashboards to nominated representatives acting on behalf of CDR consumers	Link to CDR Support Portal
Guidance	Joint article from ACCC And DSB on 31st of August 2022 FDO: Guidance for ADRs connecting to Data Holders using unsupported scopes	Link to CDR Support Portal
Action	Review CDR Support Portal article: "Sharing account data for businesses"	Complete - article has been archived and readers linked to Guidance published. Link to CDR Support Portal

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	Damien Messina
ACCC	CTS	Andrea Gibney
ACCC	Compliance	Cristina Blumberg
DSB	CX Standards	Eunice Ching
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Engineering & Register	James Bligh

Presentation

None.

Q&A

Questions will be received by the community via WebEx 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
969	Please could you clarify what us meant by a correction request? If a customer contacts a data holder after they have moved house and needs to update their address, is that consider a correction request? Is a correction request only where the customer complains about the data being wrong, not accurate or not up to date? What meets the definition of a correction request which requires an electronic notice to be issued within 10 working days? For a data holder, if a customer comes into a branch or contact via a phone to request their information is updated, then currently the information is updated and it is confirmed face to face or over the phone. Must we an electronic notice be sent to customer in circumstances where we are responding using a channel the customer has contacted with or requested?	‘Correction request’ is not explicitly defined in the Competition and Consumer Act 2010 or the CDR Rules, however under ss 56EP(1) and (2) of the Act (Privacy Safeguard 13) data holders and accredited data recipients must respond to requests from consumers ‘to correct’ CDR data in accordance with the CDR Rules. Under Rule 7.15, where such a request is received the entity has three options: (1) correct the data; (2) attach a qualifying statement to the data; or (3) provide a written notice stating why it thinks a correction was unnecessary or inappropriate. Under R 7.15(b)(ii)(A) (and consistent with s 56EP(3)(a)(ii) and s 56EN(3)), the purpose of actioning a correction request is to ensure that the CDR data is ‘accurate, up to date, complete and not misleading’ having regarding to the purpose for which the data is held. As set out in the CDR Privacy Safeguard Guidelines, CDR data may not be ‘up to date’ even if it is consistent with a consumer’s instructions, or if the inaccuracy is attributable to the consumer (see [13.45]). This means that requests to update address or other personal details are correction requests for the purposes of Privacy Safeguard 13 and R 7.15, and a correction request would not need to be lodged as a ‘complaint’ to trigger these obligations. In circumstances where a customer requests that a data holder update their information (including in person or over the phone), we note that Privacy Safeguard 13/R 7.15 would not apply unless the relevant updated data had previously been disclosed via the CDR system (56EP(1)(c)). Where the relevant data had previously been disclosed via the CDR system, the data holder would be required to respond to such a request in accordance with R 7.15. Under R 7.15(b), the entity must either correct or add a qualifying statement to the data within 10 business days. Under 7.15(c) the entity must also provide the consumer with a written notice by electronic means that: indicates the correction has been made (or explains why a correction was not made); and sets out the complaint mechanisms available to the requester. R 7.15(c) does not specify the form that the written, electronic notification must take, so this requirement could be satisfied in a range of ways (i.e. via email, notification in internet banking platform, via consumer dashboard, text message etc). We note that R 7.15(a) also requires entities to acknowledge receipt of correction requests as soon as practicable. However, where a request is made in person or over the phone the acknowledgment can be made as part of this interaction, i.e. no additional acknowledgement in writing is required. We also note that where a correction request is made triggering obligations under Privacy Safeguard 13/R 7.15, it may be that a data holder’s obligations under Privacy Safeguard 11 (see s 56EN(3)) are also triggered.
1115	We would like to clarify rules 1.15(5)(b)(i) and 4.6A(a)(ii). Rule 1.15(5)(b)(i) requires the Data Holder to provide functionality to the account holder to allow them to indicate that they no longer approve CDR data relating to a particular account being disclosed to a particular accredited person when the request is made by a Secondary User. Further the note to this clause states: “If the account holder makes an indication in accordance with subparagraph (5)(b)(i), the data holder will no longer be able to disclose CDR data relating to that account to that accredited person: see subrules 4.6(2) and (4) and subrule 4.6A(1).” This rule implies that once the account holder has made an indication, the Data Holder is not to disclose any CDR data relating to that account to the accredited person altogether. This potentially impacts other active consents to that accredited person which include the relevant account. Example for clarification (please see the attachment for Table): The Account Holder has two Secondary Users. The Account Holder along with both Secondary Users have granted consents to the accredited person Money Manager. A total of three separate consents exist. The Account Holder indicates they no longer approve CDR Data relating to consent 2, granted by Secondary User 1 to Money Manager. Westpac believes that data sharing should continue for consent 1 and 3. Can we please clarify that this rule is requiring the Data Holder to stop sharing CDR data for consent 2 granted by the Secondary User 1 alone? And that CDR data sharing to the accredited person under different consents, for example by the Account Holder or a different Secondary User can continue.	In relation to secondary users, rule 1.15(5)(b)(i) states that data holders must provide the account holder with a service that allows account holders to give the indication referred to in subparagraph 4.6A(a)(ii) in relation to a particular accredited person. Rule 4.6A(a)(ii) states that this indication is that the account holder no longer approves CDR data relating to that account being disclosed to “that accredited person” in response to consumer data requests made by “that” secondary user. This indicates that the scope of the indication in 4.6A(a)(ii) only applies to requests made to an accredited person made by that secondary user. As such, we agree with the outcome in the example you have provided.
1367	For joint accounts there is a Rule requiring that the relevant account holder be notified via existing channels if the authorisation is amended. Is this rule met if we notify the relevant account holders that the original consent was revoked and the new (amending) consent was created. This would remove some privacy concerns in certain scenarios. For example if AH1 & AH2 have JA1 together and AH1 includes an individual account and JA1 in a consent. When AH1 amends the consent & removes JA1 from the consent, from the perspective of AH2, the consent is revoked. If we were to tell AH2 that the consent was amended, we would leak private information that JA1 is continuing to share data with the data recipient, which would breach privacy. We have similar concerns in the case AH1 had a consent with only individual accounts and now includes a joint account on the consent. If we tell AH2 that the consent was amended we leak private information about AH1 already having a consent with the DR.	Please review our knowledge article https://cdr-support.zendesk.com/hc/en-us/articles/4807458486671-Information-to-be-provided-about-joint-account-authorisations
1661	Are you able to clarify the differences in the rules below, in particular the references to 'authorisation' and 'accredited person'? I am aware of what an authorisation is, and what an accredited person is, and I am aware that removing an approval is not the same as withdrawing a consent (which can only be done by the authorising consumer.) My question is about which level a 'disapproval' applies to - a specific authorisation only, or any authorisation with a 'particular accredited person'? Is the apparent distinction in these rules intended? 4A.13(1)(d)(i), regarding joint account dashboards, states – ...can be used by the relevant account holder to manage approvals in relation to each authorisation 4.6A(a)(ii), explains disclosure is not permitted by a secondary user, if the account holder – ...no longer approve CDR data relating to that account being disclosed to that accredited person 1.15(5)(b)(i), regarding secondary users, requires a service to – ...give the indication referred to in subparagraph 4.6A(a)(ii) in relation to a particular accredited person i.e. Are secondary user sharing approvals withdrawn at the ADR level, which would be different to having to remove approval for each authorisation?	In relation to data sharing that has been requested by a secondary user, rule 4.6A(a)(ii) explains that a data holder must not disclose requested CDR data that relates to a particular account to the person who made the request if the request was made on behalf of a secondary user of the account and the account holder has indicated that they no longer approve CDR data relating to that account being disclosed to “that accredited person” in response to consumer data requests made by that secondary user. We consider that where an indication is made under rule 4.6A(a)(ii) the data holder must stop sharing requested data (on behalf of the secondary user) to the particular accredited person entirely. This is supported by rule 1.15(5)(b)(i) which clarifies that data holders must allow account holders to withdraw approval in relation to a particular accredited person for the purposes of subpara 4.6A(a)(ii) (rather than in relation to a particular authorisation). As you have noted, this is different from the approach taken for joint accounts where rule 4A.13(1)(d)(i) provides that a data holder must provide a consumer dashboard with functionality that can be used by the relevant account holder to manage approvals in relation to each authorisation.
1689	The “Saved Payee” cluster is defined as being account related data as noted in the Rules Schedule 3, 1.3 - 2 account data. Some banks store the Payee against the consumer and when a payment is created using the Payee the customer chooses which account the funds are to be debited from. Only the customer can see & use their Payees. Payees are not linked to a specific account, but simply store the destination account number, name and reference information. And the consumer can debit different accounts each time they use the Payee if they wish. For Payees stored in this manner is it appropriate to return all Saved Payees regardless of the account selected? - e.g. Commbank currently return all Saved Payees for the individual consumer even if the selected account has never and cannot be used to make such a payment (discovered this via testing my own Commbank accounts with the Regional Australia MyCDRData tool) In these core banking systems, for accounts owned by non-individual, the Saved Payees would be those stored against the individuals authorised to withdraw from the account (which would include nominated representatives). As the non-individual account owner would not have Saved Payees stored is it appropriate to return nothing?	Saved payee data is considered required consumer data under the CDR Rules. A CDR consumer can only give an authorisation to share payee data that is accessible to the consumer in their account. In the circumstances you have described, we would consider it appropriate to return all saved payees that the customer can access across their accounts. However, we note that a CDR consumer cannot give an authorisation to share the payee data of another account holder or secondary user. An individual that is a nominated representative for a non-individual or partner in a partnership can only give an authorisation on behalf of the non-individual or partner in a partnership to share the payee data of the non-individual or partner in a partnership. Therefore, if there are no saved payees stored to a non-individual account, it is appropriate to return nothing. We recommend CDR participants obtain independent advice about how best to achieve compliance with the CDR rules in their specific circumstances.