Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 7th of April 2022

CDR API Stream edited this page Apr 7, 2022 · 8 revisions

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT
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


Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

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

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.

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.

Updates

Type Topic Update
Standards Version 1.16.1 Published Link to change log here
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes on 6th of April 2022 Link to the agenda and minutes
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 6th of April 2022 View in browser here
DSB Newsletter 1st of April 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
Consultation Decision Proposal 240 - ADR Metrics Feedback closes 15th of April 2022
Link to consultation
Consultation Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation Link to consultation
CX Guidelines CX artefacts - Insights disclosure consents and minor revisions related to PS12
    CX artefacts and guidelines to support insights disclosure consents (detached flow).
    • Insight disclosure consent artefacts provide an implementation example to reflect the new rules on insight disclosure consents and the CX standards introduced in v1.16.0, related to Disclosure Consent: Insight Descriptions, and Disclosure Consent: Non-Accredited Person Disclosure Notification.
    • CX Checklist (on website) includes key requirements and guidelines related to insights disclosure consents, see checklist references starting with 1CO4.

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
DSB CX Standards Eunice Ching
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Ivan Hosgood
DSB Technical Standards - Engineering 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.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #747194

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1326 Can you please confirm my understanding below ?
When a CDR Consumer loses temporary access to his/her Internet Banking (e.g. lost login token), it will meet the following 2 rules below :
Rule Sch 3 (2.1)(1) -> “For subrule 1.10B(1), the additional criterion for CDR consumer to be eligible, in relation to a particular data holder in the banking sector at a particular time, is that the person is able to access the account online.” Rule 4.7 (1)(c ) -> “in relation to an account that is blocked or suspended”
In our implementation today, we consider the above scenario as meeting rule Sch 3 (2.1)(1) only.
As previously advised, our view is that temporary loss of access to online banking will not cause a CDR consumer to be ineligible in relation to a data holder (i.e. the consumer would not cease to be eligible for the purposes of rule 4.26(1)(c)).
We encourage you to seek independent advice if you require further information about the application of the rules to your specific scenario. It is the responsibility of CDR participants to determine how they will comply with the CDR Rules.
1391 For the requirement of providing copies of records to customers upon request, if the customer ends up leaving the bank, do we as a Data Holder still store the records for the 6 years and ultimately treat those records the same as we would if the customer never left?
Also, were there any use cases in mind for why a customer would request copies of records?
A data holder is responsible for storing relevant records for 6 years and responding to consumers’ requests for copies of their records regardless of whether the records relate to a former customer or an eligible CDR consumer. Please refer to our knowledge article on Record keeping obligations and customer eligibility for more information.
Unfortunately we aren’t able to provide advice about the reasons consumers may request access to these records.
1393 can you please confirm in the situation where a customer requests a Data Holder to provide copies of records relating to their sharing arrangements, how far back do provide the records?
Is it a certain period only or could it be for anytime during the 6 years that we hold the records?
Rule 9.3(5) states that records must be kept for 6 years. This means data holders are not required to provide records that are older than this. Please refer to our knowledge article on How far back can CDR consumers request copies of records? for more information.
1422 For CDR requests received on behalf of customers that have not yet been billed (i.e. new customers), can the Data Holder respond with a blank array as there is no information that can be provided in this scenario? And what, if any error code should be returned to outline why a blank array has been provided?
Additionally, for CDR requests received on behalf of customers that have only been billed a portion of the period being requested, is the Data Holder required to return with only the portion that is available, or rather than only providing a portion of the data that is being requested a blank array? And what, if any error code should be returned to outline why a blank array has been provided?
Question: For CDR requests received on behalf of customers that have not yet been billed (i.e. new customers), can the Data Holder respond with a blank array as there is no information that can be provided in this scenario? And what, if any error code should be returned to outline why a blank array has been provided?
Answer: Yes, as long as it’s a valid request with the appropriate consent, the response can be a blank array if there is no data to return. It would be a 200 OK HTTP status as the query was completed successfully.
Question: Additionally, for CDR requests received on behalf of customers that have only been billed a portion of the period being requested, is the Data Holder required to return with only the portion that is available, or rather than only providing a portion of the data that is being requested a blank array? And what, if any error code should be returned to outline why a blank array has been provided?
Answer: If you are referring to the “Get Billing For Account” endpoint, you would return the transactions available within the requested date range. It would be similar if you are referring to the “Get Invoices For Account”, return the invoices available within the requested date range.
Hope this clarifies. Do let me know if I misunderstood any of the above questions.
1430 Follow up to Ticket 1260 - the answer provided is not answering the asked question. The question was not about the authorization but about data sharing, assuming the account that is blocked is included in an authorization already. So the question is for a call to get accounts. The DR calls the get accounts API in relation to a consent that includes 2 active and shareable accounts and 1 blocked account. The DH responds with account info about the 2 active accounts but omits the blocked account. Is this reportable as a refusal or not? No guidance talks about these partial responded requests. We have looked through our existing guidance on the CDR Support Portal and believe that this article may answer your question: https://cdr-support.zendesk.com/hc/en-us/articles/900002708226-Valid-consent-over-multiple-accounts
1456 For the fields dailyDiscount , monthlyDiscount ,yearlyDiscount & percentageDiscount , within concessions api is the expectation is to pass the respective concession’s rate applicable to the Consumer i.e. for instance:
example a. If a QLD customer, holds a valid Pensioner Concession & is eligible and availing this concession, and as for Queensland, a pensioners and seniors are eligible for the Electricity Rebate—$340.85 per year (GST inclusive), then ‘yearlyDiscount = $340.85’ is passed in response
example b. If a VIC customer, holds a valid Pensioner Concession & is eligible and availing this concession, and as for VICTORIA, a pensioners and seniors are eligible for the 17.5% of electricity usage and service costs, then ‘percentageDiscount = 17.5’ is passed in response
The intent is correct. However, there is a change request being consulted on within the current maintenance iteration. It is proposing options to improve the structure to cater for variable concessions.
Link to CR - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/476
It was discussed in the maintenance iteration call on 30th March, the minutes can be found here - https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-10:-Agenda-&-Meeting-Notes-(30-March-2022). In summary, participants agreed with DSBs recommendation of option 2.
You would be really helpful if you could provide any feedback you have directly on the above CR github link.
1459 In this API data set, field - 'greenPowerCharges' states- 'Optional list of charges applicable to green power':
Qs. is this charges refers to - list of all optional 'greenPowerCharges' that are offered by data holders, for e.g. Green% (10%, 20% or 100% etc.) which customers can opt for.
or Is 'greenPowerCharges' refers charge/s that is currently applied to customer's account.
That would depend on which endpoint the data is being returned for.
If its for the Get Generic Plan Detail API, it would be list of charges that are offered by data holders as part of publicly available plan (i.e. exact same data they provide to AER/DELWP). Note that whilst AER/DELWP are the designated data holders for the Generic Plan endpoints, as per the rules a retailer may choose to host them instead voluntarily. In either case, the data would refer to publicly available plan data.
If its for the Get Energy Account Detail API, the expectation is that it would be the charges that are applied to the customers account.
1462 In Concessions API, the fields "dailyDiscount", "monthlyDiscount", "yearlyDiscount" are inclusive of GST or exclusive of GST?
Assumption is they are GST inclusive, pls advise.
The current view is that all charges should be inclusive of GST unless specified otherwise. However, based on community feedback a change request has been raised (link below) to consult on how GST is treated within energy sector and more broadly across the CDR standards. This is most likely to be picked up in the next maintenance iteration (assuming it is prioritized by the community) and the outcome of this may result in some changes on how GST is represented.
Link to GST CR - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/474
Do provide any comments/feedback you may have directly on the above github link, it would be of great value.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.

Clone this wiki locally