ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 29th of September 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: 1650705270@webex.com

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 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
CDR Implementation Call	Call for the 22nd of September 2022 was cancelled	Last week's Updates and Answered Questions here
Standards	Version 1.19.0 Published on 13th of September 2022	Link to change log here
Standards	Version 1.20.0 is being staged	View the branch here
Maintenance	Maintenance Iteration 12	Last meet on 14th of September 2022 Agenda for the Final meeting here
Maintenance	Decision Proposal 259 - Maintenance Iteration 12	Changes, meeting notes and updates for the iteration can be found here
Maintenance	Maintenance Iteration 13 Commences soon	Kicks-off next week on Wednesday the 5th of October 2022
Java Artefacts	Version 1.18.0 now published	View the Java Artefacts here
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	28th of September 2022	View in browser here
DSB Newsletter	23rd of September 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	Decision Proposal 264 - Telco Invoice Payloads Feedback closes: 17th of October 2022	Link to consultation
Consultation	Decision Proposal 265 - Telco Billing Transactions Payloads Feedback closes: 17th of October 2022	Link to consultation
Consultation	Decision Proposal 266 - Telco Balance and Usage Payloads Feedback closes: 17th of October 2022	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.	Link to consultation
Feedback	Thanks for all the feedback on the CDR Implementation Call!	Will plan to give an update in the next week or so on the themes and next steps
Feedback	We're looking for feedback and input on the next iteration of the Product Comparator! If you have ideas, feature requests or feedback on how we might take the platform to the next level: please reach out to: contact@consumerdatastandards.gov.au or support@cdr-support.zendesk.com	The DSB is keen on your usage as well and how this can enhance your experience
End of year	Starting to plan out end of year shut down period.	The DSB will issue a survey in October to get your feedback into when the CDR Implementation Call should pause in 2022 and recommence in 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	Emma Harvey
ACCC	CTS	Andrea Gibney
ACCC	CDR Sandbox	Andrew Grady
DSB	CX Standards	Michael Palmyre
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick

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
1605	View only dashboard for individuals linked to the non-individual who aren't nominated reps For Non-individuals, a dashboard will be provided to those who are nominated reps. The ACCC guidance confirms the ‘CDR consumer’ is the actual non-individual / partnership, not the NR. As a DH we have an obligation to provide the ‘CDR consumer’ with the consumer dashboard under rule 1.15. Therefore do we need to offer ‘View only’* consumer dashboard for the: i. non-NR partners of the partnership ii. other individuals linked to the non-individual entity (that aren’t NRs) (* view only given 1.15(2A) specifies that only a NR can manage authorisations). Our preference would be that the dashboard is only provided to nominated representatives. Consideration should be given to the powers/access given to nominated reps. Where the scope is more granular, it would be difficult to ascertain what non-NRs should see. Where DHs have chosen to take the more global approach this ensures that all IB Users listed on a non-individual are not able to view all consents/high level account details.	We have prepared a knowledge article Providing dashboards to nominated representatives acting on behalf of CDR consumers that may assist with your query.
1733	As a data holder for Power of Attorney, we expect to enable a Power of Attorney to share on behalf of a CDR Consumer (Donor) as required under the rules. We will authenticate the Power of Attorney as an individual. We will have no method in the request from the ADR to identify which CDR Consumer the individual wants to share for (e.g. personally as a CDR Consumer or for the CDR Consumer (Donor)), so we will provide them with a profile selection page where the Power of Attorney can select which CDR Consumer they wish to share for. They will then be able to select the CDR Consumer (Donor) and authorise data sharing on behalf of the CDR Consumer (Donor). The CDR Consumer’s (Donor’s) data will be shared with the ADR. When sharing the data with the ADR we do not see a way for the ADR to identify that the data is being shared by a Power of Attorney on behalf of the CDR Consumer (Donor), rather than directly by the CDR Consumer (Donor). Are there any concerns that a Power of Attorney can receive ADR products and services and there will be no way for the ADR to recognise this situation?	Our guidance on Powers of attorney and the CDR states that 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 data holder will be able to identify the attorney as the attorney should receive their own credentials to access CDR services such as a consumer dashboard or disclosure option management service. However, we note that an accredited person may not be aware that a consent belongs to a person acting under a power of attorney. It is the responsibility of the data holder to assess whether the attorney’s decisions on behalf of the CDR consumer are within the scope of the attorney’s authority. The data holder will need to refer to the power of attorney document and consider whether the attorney is allowed to act on behalf of a CDR consumer to authenticate and authorise the disclosure of CDR data. The ADR is responsible for ensuring that there is a valid authorisation which enables them to receive CDR data regardless of whether the CDR consumer or attorney authenticated the disclosure of data. Provided this has occurred, we do not have concerns with the fact that a Power of Attorney can receive ADR products and services and that an ADR may not be aware the consent belongs to a person acting under a power of attorney. According to the CX Standards, the ‘Profile selection’ step should only be considered if it is an existing customer experience and should be as minimal as possible to avoid introducing unwarranted friction as stated in rule 4.24. Implementation examples can be found in the ‘Profile selection’ section of the CX Guidelines.
1742	Clarification regarding Get Agreed Payment Schedule API response for a specific scenario Have a clarification query regarding Get Agreed Payment Schedule API response for a specific scenario below: Scenario Description: A consumer who is on Quarterly bill cycle and has setup a $50/ week payment plan which they pay manually. (‘manually’ as there is NO set payment method maintained on his account i.e., no Direct Debit (bank account), no CardDebit (credit card details) & no Digital wallet (PayPal) details set. Question: For the above scenario, please advise if the below response is inline with the data standards definition of this API endpoint: amount = blank (not passed) paymentScheduleUType = manualPayment Bill Frequency = Quarterly (will be in ISO format)	Given the consumer is paying the bills manually and the retailer has no payment method captured in their system I would say what you have proposed is correct.
1743	Clarification regarding passing Rebates detail within Get Concessions API endpoint Rebates / grants such as FER, EAPA, EEPS, URGS, Owner Onus, HEEAS, TWF etc. are provided by respective state govt. to help customers pay a mains electricity, gas or water bill that is overdue due to a temporary financial crisis. Unlike Concession for these rebates, we do not have a dedicated transaction time slice (valid from & valid to date) or an application / period as these rebates gets applied to a customer's account as onetime payment (which can be yearly once or twice etc.) depending on the customer’s eligibility to avail these rebates It will be an uncommon scenario that the rebate was posted the same date when an ADR request is received, i.e., there can be an instance where a rebate was applied few days / months /a year ago As per data standards the Get Concessions API structure is to share details of any concessions or arrangements applied to a specific energy accounts and to populate active & valid concessions/rebates details applicable for a customer at the time of CDR request rather than historical concessions information data. Therefore, when CDR request comes in its will be hard to identify or fetch a rebate. Due to the process of how a rebate is captured, not very clear as to how to take up rebates under Concessions API response. Scenarios like below also exists were: 1) For a rebate – partial posting is done on the same date or different date. e.g., $100 Owner Onus rebate is granted/ approved by Government for a customer for this year – and the $100 grant is provided as a split: $50 - Granted/applied in Feb’22 $25 - Granted/applied in Feb’22 $15 - Granted/applied in Sep’22 Remaining amount not known at present - Date of application not known at present ADR Get Concession Request comes on 15th Oct’22 – how will DH know what amount to post in such instances where how much rebate a customer is eligible to get is unknown/ when the remainder of grant amount will be received by government is not known until provided by Government. Therefore, seeking advice from DSB how to best populate the rebates information within the Get Concessions API as: Rebates have a set posting date (no specific start & end date time slice) and can be posted on customer’s account when grant is provided by government	The Get Concessions API is used to share information about concessions/rebates that are applicable to a customer’s account, not the actual concession applied at a given point in time. In the scenario mentioned, you would return information that the customer has owners onus rebate on their account for the year of 2022 of a total amount of $100. You could provide the start and end date of Jan 22 to Dec 22 which would cover the duration of the concession. You would also include the frequency of the concession (e.g. once a year, twice a year etc.) You would not return the actual concession amount applied at the time of request. When the actual concession is deducted (point in time at the time of request) would be captured in the [invoice] https://consumerdatastandardsaustralia.github.io/standards/#tocSenergyinvoice)/[billing ] https://consumerdatastandardsaustralia.github.io/standards/#tocSenergybillingtransaction)APIs as discounts or adjustments.