Decision Proposal 361 - Energy LCCD Phase 2

[CDR-API-Stream]

This decision proposal outlines and seeks feedback on the proposed standard changes for incorporating the Last Consumer Change Date (LCCD) into the CDR standards for the energy sector.

The proposal covers changes to the standards for:

• Sharing of historical electricity usage data based on LCCD
• Include sharing of the LCCD via CDR
• CX considerations
• Future Dated Obligations

The proposal for consultation is attached below:
Decision-Proposal-361-Energy LCCD-Phase-2.pdf

Community views are being sought on the draft standards and positions outlined in this paper. Feedback received will be considered before standards are proposed to the Chair to be made binding.

This consultation period will close on Friday Tuesday 4th February 2025.

[mattyp]

Good work, guys. 👍

QQ - if there a particular reason the lastConsumerChangeDate field is proposed as optional rather than conditional upon the LCCD field existing for the Service Point in question?

[HemangCDR]

@mattyp the optional fields in the standards must to be shared if the DH holds the value. See "Mandatory/Optional Fields" in Payload Conventions. In other words, they are conditional to the data being held.

In other words, if the lastConsumerChangeDate is available for a given NMI/Service Point, it must be shared.

Hope this clarifies.

[mattyp]

Ah, yes, thanks for the reminder 😝. So, does that mean that some retailers may not have access to the LCCD to populate lastConsumerChangeDate? If so, then ADRs cannot rely on that property existing and so cannot create capability around it. If all retailers have access to it, then it should be conditional on there being a date. conditional or mandatory properties provide significantly more value to ADRs than optional ones. In any case, I think the real value is in the more accurate historical usage data rather than the date.

[HemangCDR]

@mattyp, below are few points which further clarifiy the proposal of making the lastConsumerChangeDate field optional:

• The lastConsumerChangeDate is populated by AEMO (not by retailers) as its a field in their MSATS database. AEMO, as the data holder for standing data in CDR, will provide the value. The retailer would only be passing it along like any other data AEMO provides.
• The field is being populated gradually by the industry (outside of CDR) and, I believe, the intent is that eventually it should be fully populated for all connection points.
• Defining the lastConsumerChangeDate as optional in CDR makes it conditional - i.e. if AEMO holds the value, they must provide it. This will allow the value to be provided where available while the gradual population of it continues.

[mattyp]

Thanks, @HemangCDR. It's good to have these points available for all to find 👍. So, by virtue of the DH architecture coupled with the definition of optional the property is implicitly conditional (on the LCC date having been populated in MSATS for the servicepoint in question). We may as well just explicitly make it conditional 😉. I won't labour on it longer (as there are bigger issues to resolve in CDR's energy sector atm, and there must be good reason for a preference of 'optional' over 'conditional'), but my preference would be to have this conditional rather than optional so as to provide explicit confidence to ADRs and their reps that this property will be set if the date exists, regardless of any future DH changes that might otherwise impact on an implicitly conditional property.

[Sbendat]

LCCD is an exciting step forward! Thanks Hemang and team.

I would second mattyp's point about optional fields being a bit of a thorn for ADRs. Constantly having to check if certain fields exist adds to the complexity of understanding if no data in a response was intended or is a legitimate issue that needs to be flagged. On many occasions we at SolvingZero have had to follow up through the various channels to figure out if the missing field is a legitimate issue or the case of an optional field not present. Primarly because, we feel, DHs will use optional fields very liberally.

As one example, DHs will populate optional fields with data that is effectively the same as it not existing, eg end_date can be in the year 9999 or not exist, both imply the date is basically infinite. In these cases the optional fields are providing too much wiggle room and the data quality suffers as a result.

Getting back to LCCD. Adjacent to LCCD, being able to track the energy tariffs a customer had during their historical usage across multiple DHs would be a significant benefit to ADRs and the end consumer. This will allow for the usage to be translated into dollar values (costs), which by and far is the preferred unit of measure for consumers, rather than kWh or some other energy-based measure of units. Perhaps this is out of the scope of LCCD, but this would be a huge next step to build upon the work of LCCD for the benefit of the consumer.

[mattyp]

Adjacent to LCCD, being able to track the energy tariffs a customer had during their historical usage across multiple DHs would be a significant benefit to ADRs and the end consumer. This will allow for the usage to be translated into dollar values (costs), which by and far is the preferred unit of measure for consumers, rather than kWh or some other energy-based measure of units.

Sounds like a good suggestion, worthy of its own maintenance issue, @Sbendat 👍. Another use-case for that data would be to know if a consumer is eligible for a tariff change (under the standard one tariff change per year DNSP rule). I can outline that against the dedicated maintenance issue.

[TaylorWoods1]

Hi Team, to what extent does the data request predate the LCCD? Are there guidelines for a fixed duration? % of historic data available? other?

[HemangCDR]

@TaylorWoods1 the rules limit the sharing of historical energy usage/metering data to a maximum of 2 years from the date of request.

[TaylorWoods1]

Thanks Hemang,

To confirm, is the intent of the 2-year data-sharing rule to provide all available usage data from the smart meter for the past 2 years, regardless of the customer’s tenure with their current retailer?

For example, if a customer has had a smart meter for 2 years but has only been with the current retailer for one week, would they still receive the full 2 years of data upon providing consent?

Regards,

Taylor

[AGL-ENERGY-CDR]

Hi @HemangCDR ,

AGL is currently in the process of reviewing the Decision Proposal 361 in detail. To determine whether we may need to provide further feedback to this consultation, we are seeking the DSB's clarification as to:

1. How the Participant ID will be used as a part of the Get Usage functionality for Service Point API payload when the LCCD and consent timeframe includes time FRMP with multiple retailers? We note that the Participant ID is mandatory in the header as a part of AEMO API guide but is not included in the DSB specs.

2. Accredited Data Holders cannot open AEMO payloads. Does the DSB expect that that ADRs would be responsible for opening and updating the payload "oldest_date" with the LCCD from AEMO?

3. If this Decision Proposal 361 takes effect as currently drafted, Data Holders will no longer be able to share closed account data because of an updated LCCD.

However, Part 3.2 Clause (7) of the Competition and Consumer (Consumer Data Right Rules) 2020 specifies that:
Despite subclause (2), for an account that is closed at a particular time, each of the following is not required consumer data:

(a) CDR data held by AEMO, other than metering data;
(b) CDR data held by a retailer, other than billing data; and
(c) CDR data that is not excluded by paragraph (a) or (b), but relates to a transaction or event that occurred more than 2 years before that time.

AGL is seeking clarification as to whether the DSB believes that the Decision Proposal 361 is compatible with the provisions above, or whether it anticipates that Treasury will seek changes to the legislation to facilitate these new changes.

[HemangCDR]

To confirm, is the intent of the 2-year data-sharing rule to provide all available usage data from the smart meter for the past 2 years, regardless of the customer’s tenure with their current retailer?

For example, if a customer has had a smart meter for 2 years but has only been with the current retailer for one week, would they still receive the full 2 years of data upon providing consent?

@TaylorWoods1 yes this is the intent.

@AGL-ENERGY-CDR, I've tried to respond to your questions below:

1. How the Participant ID will be used as a part of the Get Usage functionality for Service Point API payload when the LCCD and consent timeframe includes time FRMP with multiple retailers? We note that the Participant ID is mandatory in the header as a part of AEMO API guide but is not included in the DSB specs.

I don't fully understand the question. We don’t anticipate any changes to how participant ID will be used. Our understanding is it is used by AEMO for authenticating retailers and will continue to be so. Does this address your query?

2. Accredited Data Holders cannot open AEMO payloads. Does the DSB expect that that ADRs would be responsible for opening and updating the payload "oldest_date" with the LCCD from AEMO?

It is not clear if the question is for data holders or data recipients accessing AEMO payload? The ADR's would set the oldest-date to the value they want the usage data to go back to. The DH (Retailer) would (assuming its for an existing open account), would send it to AEMO as is. AEMO would use that date and apply various checks to determine how much historical data to share. One of the checks would be LCCD as being proposed by this paper.

3. If this Decision Proposal 361 takes effect as currently drafted, Data Holders will no longer be able to share closed account data because of an updated LCCD.

As noted in the DP, we do not anticipate any impacts on how data is shared for closed accounts. The data sharing for closed accounts would continue as it presently occurs – being limited to the duration the retailer was the FRMP for the NMI. This would require the retailer to ensure the request range for closed accounts is limited to how long the customer was their account holder for the NMI.

AGL is seeking clarification as to whether the DSB believes that the Decision Proposal 361 is compatible with the provisions above, or whether it anticipates that Treasury will seek changes to the legislation to facilitate these new changes.

We do not believe the proposed changes have any conflict with data sharing requirements for closed accounts. As noted above, sharing of usage data for closed accounts will continue as it presently occurs, limited to the duration the retailer was the FRMP for the account.

Hope the above clarifies.