Decision Proposal 213 - CX Standards | Energy Data Language

October 29 2021: Decision Made This decision was approved on 29 October 2021. The decision record is attached below: Decision 213 - Energy Data Language Standards.pdf

September 24: Decision Proposal 213 Published This decision proposal relates to consumer experience (CX) standards for energy data language.

This paper seeks to define candidate standards for the energy sector, which will only become binding in accordance with the making of the energy rules and any such standards by the Data Standards Chair. The proposals will be subject to change pending further changes and decisions.

Specifically, this decision proposal seeks to:

Determine appropriate changes to the data language standards to accommodate energy
Determine if additional descriptions should be required for energy data to facilitate comprehension
Determine the specific language to be used for each authorisation scope

The community is encouraged to review the existing banking language standards for reference.

The decision proposal for energy data language is attached below: Decision Proposal 213 - Energy data language.pdf

Feedback is now open for this proposal and will close on Friday 22nd October 2021.

Edit: Decision record published Edit: Placeholder updated; decision proposal published

Clarification sought - Presumably this DP will be updated to include the fields in DP 194-198 which have changed since this DP was published? Do respondents need to call out each of these changes in their submissions or can these be assumed?

@johnAEMO We will be incorporating them into the decision process when the consultation closes, but we still welcome the highlighting of those changes in submissions for completeness.

Please find below EnergyAustralia’s feedback. Note that our comments for your consideration largely reflect a view of consistency with the language/wording our customers are used to seeing on bills, our website and other communications such as emails.

Use of term “Consumer”: We always use the term “Customer” so would suggest using this term.
Use of term “Organisation” for business customers: We always use the term “Business” so would suggest using this term. e.g “Business profile”, “Business name” etc
“Organisation (Business) name”: Businesses can have a legal business name, a trading name and a billing name. So suggest making this clear to customers which one this is referring to
“Organisation numbers (ABN)": A business can also have an ACN, therefore suggest changing this to “Business numbers (ABN/ACN)” – noting our feedback above also re use of “Business”
Addresses o “Residential address” and “Organisation (Business) address”: We use the term “Service address” as the physical address relevant to their supply/service. o “Mail address” for organisation/business customers and Individual customers: Assuming this is a physical mail address, suggest making this “Postal address (which may include a PO Box)” to clearly distinguish from email addresses.
“Other account users”: We always use the term “Additional account holders” so suggest using this term. We assume there’s no connection of this term to secondary users
Stored Payment Information: Use of term “payment agreements” we suggest using the term “payment arrangements” as the term we always use, and also think “agreements” may sound too legalistic
Billing Payments and History: use of term “Account ID” and “Invoice ID”: suggest always using “Number” – i.e. “Account Number”, “Invoice Number” - rather than ID as numbers are always used with our customers
“Reading type”: Suggest using “Meter read type” as this is the term always used with our customers
Electricity connection: “Connection point details” understand that this is likely ‘not surfaced to consumer/customer’ but just confirming that our customers are not familiar with “connection points” whereas NMI is a familiar term i.e. visible on bills
“Consumption level”: we suggest using the term “Energy usage level” as usage in this context is the term we always use.
DER: “Energy generation and storage” and “Devices that can operate off-grid”: Just confirming that the specific common examples (as you’ve listed) are very important to prominently expose to customers
DER: “Device characteristics”: We suggest changing to “Device details” as a term we use with our customers

Thank you for the opportunity to respond to the above Decision Proposal.

Our response is covered in the attached document Decision Proposal 213 - AEMO Response v1.0.docx :

DP 213 - Energy Data Language Standards

As acknowledged by the DSB, retailers use different terminology depending on the size of the consumer and the products and services that they offer to their customer base. The terminology may have different meanings to each of the retailers from both a customer interface and system perspective. For examples, account may refer to a contract/plan for one retailer and for another retailer an account may refer to a customer number. A further complication is that customers are not always familiar with industry terminology that they see on their invoices (ie NMI).

From a customer experience point of view, it will be important that there is some sort of uniformity in the data cluster terms being used by both data holders and ADRs – this will be especially important for the consumer dashboards. We feel that it would be helpful to have descriptions for the permission language.

Based on the above comments , Origin’s preference is option 2 of the paper –

Option 2: Require additional descriptions The low comprehensibility of energy data may warrant additional descriptions to support energy data literacy. This option proposes that:

a separate entry to the common section of the standards be created for energy data; and

descriptions be required for energy data in addition to the use of data cluster and permission language

The precise wording of any additional descriptions would be at the discretion of the CDR participant; standardised descriptions could be adopted as optional. Examples of additional descriptions are provided in relation to each cluster and permission in the data language section in relation to each cluster and permission.

Some additional comments from the paper – 1) The energy specific data - clusters, the column ‘Payload (Simplified Fields and Descriptions)* ‘ are not complete. They only include a few and not all the fields from the specific payloads.
Will the final DP only include these fields or will the final paper include all the fields suggested and included in other payloads (once they have been finalised)? If requested, can we provide examples of the missing fields? 2) What is the difference between the two terms – ‘Merged language’ and ‘if referenced in isolation’? Is it possible to explain with an example. Do the data holders have to build/provide both ‘merged’ and ‘if referenced in isolation’ options on their dashboards ? 3) For C&I consumer, our assumption is the ‘Individual consumer’ section is not applicable. Can DSB confirm this is correct? 4) Individual consumer – ‘Phone’ - Is this mobile or landline? We have both in the system at the moment, but are trying to move towards the mobile phone as the primary contact. This should be made clear to the customer which phone is being referred here for sharing? 5) Mail address – We usually refer to this as ‘Postal address’. 6) “Residential address” – Is this the physical address which is usually referred as ‘supply address’? They could technically be different. 7) Meter address – this does make sense, but usually we call this the “supply address”. 8) General terminology – we usually refer to “Natural Gas” instead of just “Gas” because it can be confused with LPG. 9) Fees, features and discounts – This section also contains the current tariff details. This should be added to the permission language. Further, the common term for the “tariff” from a customer point of view is customer “rates”. We use this commonly across our channels to signify the c/KWh or supply charge. “Tariff” is only really used with regards to the “Solar feed in tariff” which should be included in this description. 10) Business consumer – Organisation name -->Agent name and role – Is this referring to only ‘Primary contact’ or ‘Authorised contact’? We have different contacts and roles related to them. For an organisation, what if there are multiple contacts? Do we need to specify which role will be shared for clarity to the consumer? This is to ensure the customer is clear on the details to which they are giving consent for the data sets to be shared. 11) Under the below permission language, ‘the ID and name of the account(s)’ – is this referring to the ‘accountID’ field of the payload? If yes, this is customer information that does not exist as it is a CDR generated ID. If not, then how is it different from the account number referred in next bullet point?

Account and plan information † Includes information such as: • the ID and name of the account(s) • the account number • when the account was opened • when the plan was active

12) From consumer’s perspective, the two data clusters ‘Accounts and Plans’ and ‘ Additional Account and Plan Details’ do not sound very different. Can all the related permission language sit under one data cluster header instead of two? This is to save confusion for the consumer.

Accounts and Plans † This includes information about the accounts and plans you have with your retailer.

Additional Account and Plan Details † This includes additional information about the energy accounts and plans you have with your retailer.

13) Other account users: We usually refer this as “Additional account holders”. Recommended that this terminology be amended to align with the industry.

14) Other account users – Is there a limit on number of contacts to be shared? Or considering its’ an array, there are no limits? This is especially an issue from a C&I perspective. We can have many contacts linked with an organisation or specific accounts in different role. As questioned in the description section - ‘who are authorised to act on this account’? Are there defined roles which are to be shared or ALL contacts in any possible role maintained on the account could have authority? It is also suggested that the word ‘current’ is added to ensure that only current authorisation details are shared . 15) Concession – As concession is not in scope for C&I customers, are we not expected to display that data cluster on dashboard for C&I consumer? 16) For the following description of concession type permission language , we need to be careful that the consumer does not assume life support details like equipment etc will also be shared. It still need to be their responsibility to call and inform new retailer of LS details. We are noting the risk with the use of including life support rebates in the below description.

Concession type † A general description of any concessions you may have. This may include seniors discounts or life support rebates.

17) Stored Payment Information – Assuming this excludes hardship (Referring to Rule 1.3 of Schedule 4 of the Rules which suggest hardship details are not CDR). If not, do we need to let the customer know this explicitly regarding hardship plans here? 18) Stored Payment Information – Could this be referred to as ‘Payment information’ to keep it simple as description covers ‘stored by your retailer’? Also, this section is valid only if the customer is on payment schedule/payment plan. If yes, can that be added to the description? 19) If the customer is not on payment plan, are we still required to display this data cluster for authorization or is it up to the data holders to make a decision on this? 20) Invoice and account IDs – In the technical payload column, it suggests ‘accountID’ be included which is a tokenisedID and not the actual account number. Based on this, do we need to update the permission language or description below? Invoice and account IDs † Indicates the invoice ID and the account for which the invoice was issued.

21) For the permission language – ‘Charges, discounts, credits’ , the technical fields column suggests only ‘payontime discount’ .There are other examples which should be included in this. 22) NMI standing data table (if referenced in isolation) covers the description for all technical fields. However, the NMI standing data table(merged) doesn’t cover the description. Better to have uniformity in representation and extend the description to this table too. 23) ‘Electricity meter ID’ under Usage data cluster – we suggest that it may be better to keep it similar to NMI standing data terminology and name it ‘ Meter Details’ for uniformity. The description should also define what it covers. 24) For the purpose of transparency with consumers, is it advisable that primary data holders(retailers) note on the authorization screen that the meter data, NMI standing data and DER data is provided from AEMO and not retailer systems.

Thanks to those who provided feedback. This consultation is now closed. Feedback will now be reviewed and considered as part of the candidate standards finalisation process.

This decision was approved on 29 October 2021. The decision record can be found in the original post.

This decision was incorporated into the v.1.14.0 release. The candidate standards can be found here: https://consumerdatastandardsaustralia.github.io/standards/#energy-language

Note: the energy data language standards are currently considered non-binding. This status will be changed by a decision of the Chair after the CDR rules relating to the energy sector are finalised.

In response to @PratibhaOrigin's queries:

The energy specific data - clusters, the column ‘Payload (Simplified Fields and Descriptions) ‘ are not complete. They only include a few and not all the fields from the specific payloads. Will the final DP only include these fields or will the final paper include all the fields suggested and included in other payloads (once they have been finalised)? The decision proposal included a column for payload fields to help participants cross reference, but the final data language tables only refer to the authorisation scope and not the fields (see the above link)

What is the difference between the two terms – ‘Merged language’ and ‘if referenced in isolation’? Is it possible to explain with an example.

This knowledge article provides an overview of this issue: https://cdr-support.zendesk.com/hc/en-us/articles/900004582823-Requirement-for-Basic-and-Detailed-Scopes In short, an ADR may in theory request a detailed scope 'in isolation', and the language standards supports this potential.

Do the data holders have to build/provide both ‘merged’ and ‘if referenced in isolation’ options on their dashboards? As noted in the above article, the expectation would be for the DH to use the merged language when the ADR requests the detailed scope, though the standards provide flexibility if the DH deems it necessary to refer to the data clusters independently. For example, an ADR may request a basic scope on Day 1, and on Day 90 the ADR requests an amendment to the consent that includes the detailed scope. A DH could, for example, show these as separate data clusters to the consumer to make clear that a new scope is being requested on Day 90.

For C&I consumer, our assumption is the ‘Individual consumer’ section is not applicable. Can DSB confirm this is correct? That is correct. The business consumer language would apply to, for example, non-individual consumers and partnerships as per the rules on eligible consumers. The individual consumer language would only be used for individual consumers.

Individual consumer – ‘Phone’ - Is this mobile or landline? This may be either and may differ by DH. The data language is generic for this reason.

Business consumer – Organisation name -->Agent name and role – Is this referring to only ‘Primary contact’ or ‘Authorised contact’? This only refers to the user who is initiating the consent/authorisation.

As concession is not in scope for C&I customers, are we not expected to display that data cluster on dashboard for C&I consumer? and Stored payment info: If the customer is not on payment plan, are we still required to display this data cluster for authorization or is it up to the data holders to make a decision on this? In response to both of these questions: yes. If an ADR requests it then it must be displayed by the DH in places such as the authorisation flow and dashboard. This is because the consumer has given consent to an ADR to access to that data, even if that data is not (yet) available. Using the payment plan as an example, if the consumer is not on a payment plan when they establish the authorisation but go on a payment plan 3 months later, the ADR can then start to receive that data once it is generated (because the consumer has already authorised its disclosure).

Where DHs do not hold or generate a certain data cluster at all - such as C&I customers and the concessions scope - DHs can rely on the CX standard provisions for 'additional descriptions' and note to the customer that this data is not held by the DH and will not be shared (e.g. in the authorisation flow, dashboard, etc.).

For the purpose of transparency with consumers, is it advisable that primary data holders (retailers) note on the authorization screen that the meter data, NMI standing data and DER data is provided from AEMO and not retailer systems. We would welcome this being raised in standards-maintenance as a change request, including the proposed level of obligation (i.e. a MUST, SHOULD, or MAY). This has been raised by the community elsewhere; raising it as a change request can allow us to consider it as a CX standards provision to either require or allow DHs and ADRs to note this detail to consumers.

Some queries were not responded to as they were either incorporated into the final decision or related to rules or technical standards rather than CX.

If there are queries that were missed in the above response, please raise them as tickets on our CDR support portal here: https://cdr-support.zendesk.com/hc/en-us (through the 'raise a question' link at the top right), or by sending an email to: support@cdr-support.zendesk.com (which will automatically create a ticket in the support portal).

ConsumerDataStandardsAustralia / standards

Decision Proposal 213 - CX Standards | Energy Data Language #213