ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 15th of December 2022

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
End of Year	15th of December 2022 Last Call for 2022!	Thank you to everyone for a great year!
CDR Implementation Call 2023	Commences 19th of January 2023	Invitations to be updated and sent out Due to the 'unstable' nature of Outlook looking
Standards	Version 1.20.0 Published on 3rd of November 2022	Link to change log here
Standards	Version 1.21.0 is being prepared	ETA is mid December 2022
Standards	Version 1.22.0 is being prepared	ETA is late December 2022
Maintenance	Maintenance Iteration 13 change window concluded	Met 23rd of November 2022 and the agenda for the meet is here
Maintenance	Decision Proposal 272 - Maintenance Iteration 13	Changes, meeting notes and updates for the iteration can be found here
Maintenance	Retrospective for MI13 delayed until next year	Invitations have been cancelled.
Maintenance	Iteration 14 to Commence on 8th of February 2022	Invitations to be sent
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	3rd of November 2022	View in browser here
DSB Newsletter	9th of December 2022	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 closed: 15th of September 2022 Thanks to those who provided feedback on DP267 by 15th September. With the v5 rules out for consultation, the DSB will leave this issue open for comments while considering existing feedback and developing version 2 of DP267, which is expected to be published for consultation in October. Reopened for feedback until the 9th of December 2022	Feedback extended with an end date to be determined pending the making of the telco rules. Link to consultation
Consultation	Noting Paper 273 - Consent Review	Feedback closes: 16th of December 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	Feedback closes: 27th of January 2023 Link to consultation
Design Paper	Design Paper: Consumer Data Right Rules and Standards for the Non-Bank Lending Sector	Feedback closes: 31st of January 2023 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	CDR Register	Emma Harvey
ACCC	CTS	Andrea Gibney
ACCC	Guidance	Catherine Manson
DSB	CX Standards	Michael Palmyre
DSB	Technical Standards - Banking and Info Security	Mark Verstege
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Register	James Bligh
DSB	Engineering	Sumaya Hasan

Presentation

No presentation planned 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.

Please note: as the last call for 2022. The team will not be taking questions on notice for this week. We ask that you submit these to the CDR Support Portal and the team will work to address them over the break and new year. Thank you

Answer provided

Ticket #	Question	Answer
1542	Two questions raised on the CDR Implementation Call 19th of May 2022: Question 01: Regarding passing ‘PayPal’ payment mode information within Get Agreed payment schedule CDR API: Where the customers pay his bill via ‘PayPal’ on a regular basis: Qs1. Does this information to be passed on in Get Agreed payment schedule CDR API Qs2. If above is yes, can ‘PayPal’ method of payment be categorised under paymentScheduleUType = ’directDebit’ Reference: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/511#issuecomment-1126687376 Question 02: Clarification required regarding Get Agreed payment schedule CDR API fields – ‘isTokenised’ ‘Bsb’ & ‘accountNumber’. CDR std. definition for following fields is as per below: • isTokenised : Flag indicating that the account details are tokenised and cannot be shared. False if absent. If false then bsb and accountNumber should not be expected to be included • bsb : The unmasked BSB for the account to be debited. Is expected to be formatted as digits only with leading zeros included and no punctuation or spaces. Is required if isTokenised is absent or false • accountNumber : The unmasked account number for the account to be debited. Is expected to be formatted as digits only with leading zeros included and no punctuation or spaces. Is required if isTokenised is absent or false Qs.1 ‘isTokenised’ definition mentions that - If false then bsb and accountNumber ‘SHOULD NOT’ be expected to be included, however, in ‘bsb’ & ‘accountNumber’ its mentioned that this field/ ‘IS REQUIRED’ Reference: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/511#issuecomment-1126687376 During the call Biza offered to add these to: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/511	Below are the responses per question Question 01: Regarding passing ‘PayPal’ payment mode information within Get Agreed payment schedule CDR API: Where the customers pay his bill via ‘PayPal’ on a regular basis: Qs1. Does this information to be passed on in Get Agreed payment schedule CDR API Qs2. If above is yes, can ‘PayPal’ method of payment be categorised under paymentScheduleUType = ’directDebit’ Qs1 - Yes, it should be passed. Qs2 - Paypal would be captured within a digitalWallet object of EnergyPaymentSchedule structure with the provider ENUM set to PAYPAL_AU Question 02: Clarification required regarding Get Agreed payment schedule CDR API fields – ‘isTokenised’ ‘Bsb’ & ‘accountNumber’. CDR std. definition for following fields is as per below: • isTokenised : Flag indicating that the account details are tokenised and cannot be shared. False if absent. If false then bsb and accountNumber should not be expected to be included • bsb : The unmasked BSB for the account to be debited. Is expected to be formatted as digits only with leading zeros included and no punctuation or spaces. Is required if isTokenised is absent or false • accountNumber : The unmasked account number for the account to be debited. Is expected to be formatted as digits only with leading zeros included and no punctuation or spaces. Is required if isTokenised is absent or false Qs.1 ‘isTokenised’ definition mentions that - If false then bsb and accountNumber ‘SHOULD NOT’ be expected to be included, however, in ‘bsb’ & ‘accountNumber’ its mentioned that this field/ ‘IS REQUIRED’ The above was a documentation error, it was corrected in release 1.18.0 of the standards (as part of maintenance iteration11)
1560	We are in the process of becoming an accredited data recipient for the CDR data which we hope to initially leverage with the Energy data that is becoming available later in the year. We can see that there is both Electricity AND GAS data points are available via the APIs. We are hoping to use the data to be able to extract the customers’ current tariff, usage, meter information for both Gas and Elec to assist them with their comparison. Will this be possible for Gas as well as Electricity (based on the data you are releasing)? Will both the Elec AND Gas details of the customer be accessible (where consents are given and appropriate accreditation etc) via the Billing/Service Point/Account Detail/Billing for a Specific Account APIs etc? Or is this only for the electricity account, not gas? If Gas is not planned to be released at the same time as Electricity, can you inform as to when the Gas account information is due to become available.	The CDR data sets for energy include consumer and product data relating to the sale or supply of electricity, including where electricity is bundled with gas. In other words, gas data will be shared if it is part of a bundled/duel fuel plan with energy. This is based on the designation instrument for the energy sector. There is more information in this guidance article - https://cdr-support.zendesk.com/hc/en-au/articles/5333637909903-Dual-fuel-for-Service-Points
1815	I am hoping to get a hold of the process flow that outlined the DH/Retailer to AEMO exception/complaint management process. I believe this was shared with tier 1's.	Given that it relates to the AEMO exception/complaint management process, we suggest logging a support ticket via the AEMO Information and Support Hub ([email protected]) to receive a relevant response.
1816	We would appreciate consult on an interpretation of the rules, that would allow the requirement of ADRs collecting once-off consents to provide consumers with a consumer dashboard met by sending the required information of the consent via email in consideration that it a) email is an online service b) the consent does not require management as it's once off. c) the data is deleted once used, and therefore customer does not need to manage data deletion or cancellation of consent. We'd be interested in your advice on whether this interpretation would meet the CDR rules on consumer dashboards.	Rule 1.14 of the CDR Rules governs the requirements for consumer dashboards that are provided by ADRs. Under this rule, an accredited person must provide each eligible CDR consumer with an online service that can be used to manage consumer data requests and associated consents, contain prescribed details of each consent, has functionality that allows the CDR consumer to withdraw current consents and elect that redundant data be deleted, is simple and straightforward to use and is prominently displayed. The consumer dashboard must meet these requirements regardless of whether a once-off or continuing consent has been given. This knowledge article provides guidance around the requirements of providing consumer dashboards, and highlights that the rules require consumer dashboards to be provided online but do not specify the channel. There are however requirements relating to ease of use and access, including that the dashboard be made no more complicated to use than the process of giving the authorisation to disclose CDR data. While CDR Rule 1.14 does not specify the channels through which a consumer dashboard can be provided, we consider it is unlikely that a dashboard provided via email would satisfy the requirements of Rule 1.14. The CX Guidelines outline how consumer dashboards may be provided, but do not specify this in the context of once-off consents. However, the Data Standards Body and Treasury are currently consulting on opportunities to simplify the CDR consent rules and standards to support a better consumer experience while maintaining key consumer protections. Outcomes from this consultation will inform proposals for a joint Treasury/DSB rules and standards design paper in early 2023. Whether consumer dashboards are required to be provided for once-off consents is being considered as part of this consultation. You can find the noting paper here, which welcomes feedback from CDR participants on the issues raised in the paper. Please note consultation closes on Friday 16 December 2022.
1817	Have a Rules query on how long a Data holder (possibly ADRs too) is expected to show expired and revoked consents in the consumer dashboard. Note; Using the term consent to refer to the authorization to disclose (at DH) and consent (at ADR) for ease of use. A DH is expected to keep records for 7 years? (unsure about this number ) Is the consumer dashboard expected to show the expired and revoked consents for these 7 or x years? Does it not make sense to show the active consents along with consents that had expired recently (say last 6 months)? Customers can have access to historical consents through other mechanism (DH's discretion to provide different methods). Is that allowed by the rules? For now, this is not a challenge but in the longer run when customers have lots of consents, does it make life easier for all the parties to reduce the clutter and show just key and relevant information in the Consumer dashboard. Note: In real life, i don't expect customers to create heaps of consent. They are likely to work with just 1 or 2 ADR software products and create consents for reasonable periods (e.g 6 months/12 months). So the total list of consents itself is likely to be small. However, edge cases where customers provide 1-time sharing numerous times and then DH's having to show that in the consumer dashboard makes life difficult. Wondering what the rules state as a DH obligation	Data holders must keep and maintain records of authorisations in accordance with CDR Rule 9.3(1), and accredited persons must also keep and maintain records of consents in accordance with CDR Rule 9.3(2). CDR Rule 9.3(5) specifies that each record must be kept for a period of 6 years beginning on the day the record was created. The Compliance Guide for Data Holders - Banking Sector provides that consumer dashboards must contain details of each authorisation to disclose CDR data, including when it was withdrawn or expired, within the past 6 years. For accredited persons, under CDR Rule 1.14, consumer dashboards must also contain details of each consent, including when it expired or was withdrawn. We consider that for accredited data recipients, the consumer dashboard should also contain details of consents, including the date that the consent expired, for six years from the date it expires. The six year period for displaying authorisations and consents that are expired or withdrawn is because this aligns with the record-keeping obligations specified under Rule 9.3 of the CDR Rules. We hope this information assists you. If you have any further questions, please feel free to get in touch again.