Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 3rd of February 2022

Jump to bottom
CDR API Stream edited this page Feb 3, 2022 · 6 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.15.0 Published Link to change log here
Standards Version 1.16.0
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 25th of January 2022 View in browser here
DSB Newsletter 28th of January 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 225 - Data Recipient Security Standards Feedback closes 18th of February 2022
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation
Telecommunications Consumer Data Right (Telecommunications Sector) Designation 2022 Find the Designation Instrument here

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 Hopeson Chiao
ACCC CTS Andrea Gibney
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking James Bligh
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: #169517

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1139 4A.13 Consumer dashboard for joint account holders specifies "the data holder must also provide a consumer dashboard for each relevant account holder and the dashboards must have additional functionality."
The rules do not specify what additional functionality is required.
Assuming the additional functionality refers to 4A.13(d), i.e.:
(d) has a functionality that:
(i) can be used by the relevant account holder to manage approvals in relation to each authorisation to disclose joint account data made by a requester; and
(ii) allows for withdrawal, at any time, of such an approval; and
(iii) is simple and straightforward to use; and
(iv) is prominently displayed; and
(v) as part of the withdrawal process, displays a message relating to the connsequences of the withdrawal in accordance with the data standards.
Can the ACCC team confirm there is no other additional functionality required in consumer dashboards for joint account holders?		 Where a data holder already provides the relevant account holder with a consumer dashboard under existing rule 1.15, the data holder must provide additional functionalities to enable the data holder to manage their approvals in that dashboard for joint accounts (r 4A.13(2)). Please note that the CDR Rules include requirements in relation to consumer dashboards in addition to those listed in rule 4A.13 (1)(d).
For more information, on joint accounts, please refer to the our recently revised Joint Accounts Implementation Guidance. We encourage you to seek independent advice if you require further information about your compliance obligations.
1140 We are a bit confused about the below 4A.14 rule from the published CDR rules version3:
· Rule 4A.14.(2) states that “data holder must make the appropriate approval notification to a joint account in relation to an event mentioned in subrule (1)”. That indicates that the data holder notification described in subrule (1) are event driven, not based on timeframe, i.e. frequency. However, 4A.14.(3) states that data holders must provide alternative notification schedules, including the frequency of notifications or not receiving notifications. That “frequency of notifications” seems to be conflict to the event driven notifications described in 4A.14.(1).
· Rule 4A.14.(2) also states that “data holder must make the appropriate approval notifications to a joint account holder as soon as practicable after the event occurs, unless the joint account holder has selected an alternative schedule of notifications.” Does this rule applies to only joint account holders? What about individual account holders’ consents on data sharing? And what about account holders’ consents on data sharing from accounts that includes both joint accounts and individual accounts?
4A.14 Notification requirements for consumer data requests on joint accounts
(1) For this rule, an approval notification is a notice given by the data holder:
(a) to a relevant account holder, to inform them that the requester has given, amended or withdrawn an authorisation, or that the authorisation has expired; or
(b) to the requester, to inform them that:
(i) one or more of the relevant account holders has not given their approval for disclosure within the time frame referred to in paragraph 4A.11(e); or
(ii) a relevant account holder has withdrawn an approval previously given; in accordance with the data standards.
(2) The data holder must make the appropriate approval notification to a joint account holder in relation to an event mentioned in subrule (1):
(a) as soon as practicable after the event occurs, unless the joint account holder has selected an alternative schedule of notifications; and
(b) through its ordinary means of contacting the joint account holders.
Note: This subrule is a civil penalty provision (see rule 9.8).
(3) The data holder must, in accordance with any relevant data standards:
(a) provide for alternative notification schedules (including reducing the frequency of notifications or not receiving notifications); and
(b) give each joint account holder a means of selecting such an alternative, and of changing a selection.
Note: This subrule is a civil penalty provision (see rule 9.8).
The section 4A.14 has be copied here, would be great if we could get some clarification on this.		 Data holders must make the notifications referred to in 4A.14(1) as soon as practicable, unless a joint account holder has selected an alternative schedule of notifications under 4A.14(3). If a joint account holder has selected an alternative notification schedule, then the data holder must make the notifications in accordance with that schedule. The Explanatory statement to the V3 amendments contains further information under the heading ‘Notification requirements’.
Rule 4A.14 only deals with approval notifications in relation to joint accounts. The rules contain many other notification requirements, including notification requirements for accounts held by a single account holder. We encourage you to seek independent advice if you require further information about the application of the rules to a specific scenario.
Please note that the ACCC has recently revised its Joint Accounts Implementation Guidance.
1183 In relation to Rule 4A.8 Obtaining agreement on change to a less restrictive disclosure option:
(3) At the end of the specified period, the data holder must, as soon as practicable
through its ordinary means of contacting the joint account holders, inform them
whether:
(a) all the joint account holders have approved the change, and as a result the
new disclosure option applies to the joint account; or
(b) not all the joint account holders have approved the change, and as a result
the disclosure option is unchanged.
The rule specifies the data holder must contact "the joint account holders". All other paragraphs on this subject refer to "relevant joint account holders" or "other joint account holders".
Can you please confirm whether Rule 4A.8(3) intends to give meaning to "all" account holders, or just the "other" account holders?		 All joint account holders must be notified about whether their disclosure option has changed. The DSB has developed Consumer Experience Guidelines providing examples of how to implement requirements related to changing disclosure options for joint accounts. This includes an example flow for changing to a less restrictive disclosure option.
Please note that the ACCC has recently revised its Joint Accounts Implementation Guidance.
1238 1. Confirm if Latest Contract/Plan Information of Account should be provided in Get Account & Get Account Details API.
Note: Customer’s Billing Account can have historical contract/plan. Last year Account # 1234 may be on plan “Y” or customer could have performed plan switch to plan “X” under same account #1234.
2. Regarding the need of getConcession API
Given that Energy Concession are regulated, concession from all retailers would ideally be same. In this case, why this information is required for best plan comparison? This would get netted anyways.
3. Regarding Concession Amounts in GetConcession API
Can you confirm if Data Holder should provide the concession value that was applied in last bill or eligible concession amount at the time of providing response to ADR?
4. Regarding Metering & Contract Charges in Get Account Details API
Can you please confirm if charges applied on last bill to be provided or Current charges at the time of providing response should be provided to ADR?
Assuming if there are any future prices (reprice) configured in system, is not required. API structure doesn’t support this.
5. Charges/Amount inclusive or Exclusive GST where not specified explicitly. Wherever the fields are not specified whether inclusive or exclusive GST, Can we assume respective field is exclusive GST? Examples:
MeteringCharges in GetAccountDetails API
Invoice Amount in GetEnergyInvoice API
DiscountAmount in GetEnergyInvoice API
EnergyBillingUsageTransaction fields in GetBilling APIs etc.,
6. Authorised Contacts in GetAccountDetails API
Can you please confirm what does this refer too? All additional persons or secondary person linked to the Account? Or just specific types? There are different relationship types available (example Fully Authorised, financially responsible, Customer Contact, Spouse etc.,) Or is it supposed to be Secondary User as defined in the Rules? or Joint Account holders?
7. IsFixed in GetAccountDetails API
What does fixed tariff mean? We take it to mean a tariff that is fixed for a period e.g. 2 years, but what happens if at the end of the period it can be changed? Can you please provide a definition.
8. PaymentOptions in GetAccountDetails API
Can you please confirm if this is the list of all allowed payment option for this account (Credit Card, Debit Card, BPAY, Cash etc.,)?
Payload examples shows PAPER_BILL? Not sure if you re intending to cover bill delivery method also here.
It’s not an enumerated list so assuming it’s up to DH to display the text/string.
9. EnergyPlanControlledLoad in ElectricityContract of GetAccountDetails API
EnergyPlanControlledLoad – Is also required if Pricing Model is FLEXIBLE_CONT_LOAD?
EnergyPlanControlledLoad – This section does not support controlled load with different time of use types such as Peak Controlled Load, Off-Peak Controlled Load and Shoulder Controlled load. How do you want us send controlled load tariff with different time of use types?
10. EnergyPlanControlledLoad - displayName (mandatory, A display name for the controlled load tier)
We think, this could be Controlled load bill line-item display name (what customer sees on their bill). Please confirm
11. EnergyBillingUsageTransaction or EnergyBillingDemandTransaction – timeOfUseType enumeration
Can you please clarify why timeOfUseType enumeration list has got OFF_PEAK_DEMAND_CHARGE separately?
Referred link: https://consumerdatastandardsaustralia.github.io/standards/#introduction 		1. The standards allow supplying of multiple plans associated with a customer account including current and historical plans. The plans array object in EnergyAccountDetail schema has start date and end date which can be used to represent the above example.

  1. The GetConcession payload includes an object of arrays (called concessions) with start and end date attributes which enables a DH to provide both current and historical concessions associated with an account.

  2. Get Account Details API is designed to represent information related to the tailored plan/contract customer account has with a retailer and is aligned with the generic tariff payload. With that context, interpretation of this field should be according to the existing interpretation when Retailers are providing tariff data to EME.

  3. Interpretation of this field should be according to the existing interpretation when Retailers are providing tariff data to EME.

  4. The paymentOption attribute is aligned with generic tariff and should have a list of ENUMs which seem to have been missed standards. Thank you for identifying this. Can I request you raise a CR about this for traceability and helping us action it. For reference, the ENUMs for paymentOption are below PAPER_BILL CREDIT_CARD DIRECT_DEBIT BPAY OTHER

9.1 "EnergyPlanControlledLoad – Is also required if Pricing Model is FLEXIBLE_CONT_LOAD? " - Yes this is correct. This is a known change we plan on making in version 1.15 of the standards

9.2 "EnergyPlanControlledLoad – This section does not support controlled load with different time of use types such as Peak Controlled Load, Off-Peak Controlled Load and Shoulder Controlled load. How do you want us send controlled load tariff with different time of use types?" - Can you give an example scenario to help understand this question? TOU type controlled loads can be specified by setting the pricingModel to TIME_OF_USE_CONT_LOAD and providing the rates in timeOfUseRates within the tarrifPeriod object.

  1. Interpretation of this field should be according to the existing interpretation when Retailers are providing tariff data to EME.

  2. OFF_PEAK_DEMAND_CHARGE was added based on feedback received from Origin during consultation for decision proposal 149. See link below for reference -https://github.com/ConsumerDataStandardsAustralia/standards/issues/149#issuecomment-777972557 | | | | | | | | | | | | | | | | |

Useful Links

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

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally