ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 3rd of February 2022 - ConsumerDataStandardsAustralia/standards GitHub Wiki

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 Standards Staging Release 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 Part 1 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. 3. 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. 4. 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. 7. Interpretation of this field should be according to the existing interpretation when Retailers are providing tariff data to EME. 8. 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. 10. Interpretation of this field should be according to the existing interpretation when Retailers are providing tariff data to EME. 11. 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
1238 Part 2 Regarding 9.2, Current structure handles time of use with control load but not time of use along with time of Use controlled load. In South Australia, you can have “General Peak, General off Peak, General Shoulder and Controlled load Peak, Controlled Off Peak and Controlled Shoulder”. Example: General Peak: Monday to Sunday 12.00am to 1.00am, 6.00am to 10.00am, 3.00pm to 12.00am CST/DST. Off Peak: Monday to Sunday 1.00am to 6.00am CST/DST. Shoulder: Monday to Sunday 10.00am to 3.00pm CST/DST. Dedicated Circuit/Controlled load: Peak: Monday to Sunday 6.30am to 9.30am, 3.30pm to 11.30pm CST. Off Peak: Monday to Sunday 12.00am to 6.30am, 11.30pm to 12.00am CST. Shoulder: Monday to Sunday 9.30am to 3.30pm CST. Hope this helped to explain. Regarding 11, Ok, In a “EnergyBillingDemandTransaction” section, if charges are populated with time of use type as “Peak” then I thought it’s peak demand. If time of use type “Off Peak” then off peak demand. If we have a dedicated code for “Off Peak Demand Charge”, should we also have as Peak demand? Regarding #3, Usually, the concession amount is calculated at the time of issuing a bill based on eligibility check and type of respective concession. If Concession card is applied recently but bill is yet to be issued after card is applied, should Data holder try to calculate the current concession el igible amount or % at the time of API request? Also, Concession type “Service to property charge concession” amount is calculated & concession is provided when the usage charges is lesser than the supply charges. The actual amount can be known only if the bill is issued (as dependent on usage amount too). How do you suggest this information to be passed in Get Concession API response? 2. The simplest answer is the information is required because the rules specify it. The dataset was agreed by DHs and ADRs during consultation on Energy API design and the data represented is directly related to the consultations and feedback. We tend not to predict the use cases participants may come up with. In banking, for example, there have been some unique and interesting solutions with CDR data. A good example of creative use of CDR data is https://www.adatree.com.au/adatreenews/launch-covid-hotspot-alert. 3. The concessions endpoint is meant to provide the concessions that are applied to a customer’s account, not the calculated amount resulting from applying the concession. In the above example, you would include the concession card details with the start date it would be applicable from along with how much concession will be applied to the account (e.g. 5%, or $5 per month). You would deal with “service to property charge concession” in a similar way. 5. After discussing internally, the view is that all charges should be inclusive of GST unless specified otherwise. If you think of an invoice, the invoice amount is inclusive of GST with the GST component specified separately, it’s a similar concept. This is an excellent question; we will update the descriptions to state as such and raise a CR to allow community feedback to capture any changes. 6. Authorised Contact refers specifically to any secondary person who can contact the call centre and ask/answer questions for the account but does not have full operational authority on the account (i.e. are not a full customer). Basically, if someone has an online account and/or can provide consent to share data in CDR, they should not appear in authorised contacts list. 9.2. The structure is derived from the existing EME/VEC structure which retailers currently provide their plans to, so it would be how you would provide a similar plan to them. I reached out to EME for an example, they have asked if you can provide an plan Ids for the plans that demonstrate this scenario? That way they an look up those plan Ids in EME and extract the data to show an example. 11. We included the ENUMs values based on feedback provided during the consultation. If you believe there are other ENUM values that should be included I suggest you raise a change request (https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues) with the details so the rest of the community can provide feedback as well.
1238 Part 3 9.2 : Please refer the controlled load section in plan ID: ENE95306MRE15 https://www.energymadeeasy.gov.au/plan?id=ENE95306MRE15&postcode=5000 3. “Service to property charge” concession amount may vary as it depends on the bill amount. It’s not a % or daily or monthly or yearly fixed amount. For a concession card holder in Victoria, if their supply charge on bill is higher than the consumption charges then we will provide the difference as concession amount. https://services.dffh.vic.gov.au/service-property-charge-concession Re: 9.2: Having discussed with EME, it seems that TOU information for controlled loads is provided by the retailers to EME and stored in database as a free text description, and displayed on the website as-is. For CDR, it would actually be a better approach to provide a structure to share the TOU controlled load information. We will raise a CR with a proposed solution for community feedback. Re 3: This is another candidate for a CR. Similar to 9.2, we will raise a CR for community feedback.
1251 Is there a requirement for the data holders to notify the primary account holder of the data sharing authorisations granted on his/her account either by the primary account holder itself or the secondary user for that account via an email notification or by post? We understand there's definitely a dashboard requirement to present the existing authorisation details to both primary and secondary users on the DH dashboard, but want to ask if there's a requirement to send notifications to the primary account holder as per above. CDR Rule 4.28: Notification requirements for consumer data requests on behalf of secondary users (1) This rule applies if: (a) an accredited person makes a consumer data request under this Part on behalf of a secondary user for a particular account; and (b) the secondary user amends or withdraws an authorisation, or an authorisation given by the secondary user expires. (2) The data holder must, as soon as practicable, notify the account holder of that fact through its ordinary means of contacting the account holder. Here's the link that I've found which talks about the dashboard requirement but none that talks about the notifications. https://cdr-support.zendesk.com/hc/en-us/articles/360003965656-Data-Holder-obligations-around-consent-notifications Data Holder obligations around consent notifications: Question Can you please detail the Data Holder obligations around send notifications to customers when consent is created, withdrawn or expired? Answer In terms of informing the CDR consumer about their authorisations, a data holder is required to keep the consumer dashboard updated (Rule 4.27). Information that must be contained on the consumer dashboard includes details of the CDR consumer's authorisations (Rule 1.15)(b). In addition to the rules, you may also want to consider what the CX Guidelines say about management of authorisations. See, e.g., page 108. But it is important to note that the CX Guidelines contain recommendations that SHOULD be followed, as well as mandatory requirements. Rule 4.28 applies where a secondary user amends or withdraws an authorisation, or an authorisation given by the secondary user expires. In such circumstances, the data holder must, as soon as practicable, notify the account holder through its ordinary means of contacting them. Rule 1.7 states that the ordinary means of contacting an account holder is the specific form of communication the data holder has previously agreed with the account holder to use to contact them about their account. If no form of communication has previously been agreed on, the ordinary means is the default means by which the data holder contacts the account holder in relation to their account.
1274 Considering there are three Joint Account Holders (JAH) and one Joint Account (JA). Joint Account Holder 2 (JAH2) has disabled data sharing for the Joint Account (JA) using DOMS. So during the authorisation flow: 1. Can JAH1 give a consent on JA, which is disabled for data sharing by JAH2? 2. If yes, then is DH required to send approval request (JA data sharing approval) to JAH2 only? 3. If now JAH2 doesn't approve the JA sharing request within the required date, can DH remove this JA from the consent ? Answer from the Data Standards Body: If JAH2 has disabled sharing for the joint account (i.e. changed to a non-disclosure option) then data cannot be shared from that account by any of the joint account holders. This account would potentially appear as an 'unavailable account' in the authorisation flow for all joint account holders, and would not be selectable for sharing at this point. As such, it would not trigger an 'approval request' flow via the authorisation flow as would occur in the DOMS. For any of the joint account holders to re-enable sharing for that account again, all the joint account holders would need to agree. This would trigger an approval request flow via the DOMS, as stated above.
1308 For credit cards, where the Direct Debit Authorisation is held with Merchants, and authorisation can be deduced based on regular payments / transactions, should the data holder list those authorisations as part of the Direct Debits API? The authorisation can be derived based on scheme flag from card schemes (Master / Visa) passed on to the data holder. This allows the data holder to populate last debit amount and last debit date / time, however the financial Institution details are not available in such cases. Please advise if such recurring payments derived based on card scheme information are in scope for the Direct Debit APIs. Banking Code of Practice does consider such transactions as direct debits, hence the query. CDR Support Portal Article
1310 Regarding the CDR Rule section 9.4, one of the items required for the bi-annual reports is: "Number of consumer data requests received from accredited persons on behalf of eligible CDR consumers" We believe this is referring to the number of individual API calls to request data. I.e. it's not just the number of sharing arrangements established. Please confirm our understanding is correct. Rule 9.4(1)(c)(iii) requires data holders to provide the number of consumer data requests made by accredited persons on behalf of eligible CDR consumers. This section of reporting requirements refers to the number of API calls to request data, not the number of sharing arrangements entered into.
1320 We don't seemed to be able to find information in the spec on when production Registry will support the updated APIs. In particular, https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/424 and https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/425 Please clarify when Registry will support the changes and so we can plan for our changes. Currently, the future-dated obligations section of the Consumer Data Standards indicates August 30th, 2022 as the implementation date. This date is still tentative and the expectation is that ACCC will provide a concrete date. This will be a topic for the Maintenance Iteration #10 so we will endeavour to provide certainty soon.
1323 I am looking for clarification on backoff patterns. I note that the last mention of backoff patterns in the standards was Register Standards 1.5.0, now superseded. It appears this section was not migrated to the Consumer Data Standards. Could you confirm that, for an ADR retrying to hit a DH endpoint, the short term and long term backoff patterns (fixed 10 minute every 1 minute, exponential 7 days, respectively) in Register Standards v1.5.0 are still relevant? If not, could you provide further guidance? There is a requirement that the data holder notifies the data recipient of the withdrawal of authorisation and to aid participants, the Register design specified backoff patterns as implementation guidance. Due to this categorisation, it was not transferred to the Consumer Data Standards. However, the short and long-term approaches specified at https://consumerdatastandardsaustralia.github.io/register/#backoff-patterns are still relevant.
1327 3. Cancelled/Reversed Bills Are Data Holders expected to provide cancelled bills to ADR? If yes, what field is used to use to denote the status of transactions? Relevant APIs referred here, Get Invoices Get Billing We received the following response from Treasury - "Treasury has advised that the intent is not to capture cancelled bills for data sharing because no amount was ultimately payable under the cancelled bill."

Useful Links

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