Decision Proposal 314 - Last Consumer Change Date (Phase 1)

[CDR-API-Stream]

Tuesday 11 June: Decision Proposal 314 Published
This decision proposal outlines and seeks feedback on the considerations and recommendations for incorporating the Last Consumer Change Date (LCCD) into the CDR standards. It focuses on scenarios where the LCCD value can be utilised by the standards, identify potential risks related to LCCD usage and the need for consumer experience (CX) data standards.

The proposal for consultation is attached below:
Decision.Proposal.314-Last.Consumer.Change.Date.(Phase.1).pdf

Feedback is now open for this proposal. Feedback is planned to be closed on Tuesday 8th August 2023.

[Parag-PowershopAU]

Discussed in AEC/DSB forum 20/07 - Recommendation to add data correction as a topic for this consultation as the scope of data correction increases by introducing LCCD related changes to CDR data being shared. If a data correction request comes through for CDR data which is from before the current FRMP start date, how will this be managed and by whom etc.

[AGL-CDR]

Please find AGL's response to the consultation paper attached.
AGL Response - Phase 1 LCCD Consultation Paper 7th August 2023.pdf

[OAIC-CDR]

Please find the OAIC's officer-level comments on DP 314 attached.
DP 314 - OAIC officer level comments.pdf

[TravisWorsteling]

Thank you for your consideration of EnergyAustralia's response.
EnergyAustralia submission - DSB Decision Proposal 314 - Last Customer Change Date .pdf

[CDR-API-Stream]

Thanks to those who provided feedback. The feedback period is now closed, and responses will be reviewed and considered as part of phase 2 consultations.

[CDR-CX-Stream]

Thanks again to those who provided feedback on this decision proposal. The DSB has developed responses to a number of the queries raised.

Thank you @OAIC-CDR for your submission. Please see responses to specific queries below:

There is concern that consumers should be informed of historical metering data sharing during the consent flow with an accredited person, in addition to the authorisation flow with a data holder. This includes sharing historical data generated while the consumer was with a previous retailer.

The DSB understands that ADRs are already required to inform consumers of historical data that may be accessed, which we expect would naturally extend to historical data relating to a previous retailer. This understanding stems from r4.11(3)(c)(i), OAIC guidance on consent (Chapter C: Consent, C.56), and is reflected in the CX guidelines on consent (Collection and use consents - default example, wireframe ref 34). The DSB will consider the need for further detail regarding previous retailers as part of this message.

[In relation to unnecessary friction (as referenced in Option 1a):] friction is not necessarily negative. Positive friction can result in a consumer paying attention at the right time to what is being asked of them in relation to the data being shared.

In the context of Option 1a, the meaning of unnecessary friction is not to be conflated with positive friction. Option 1a is considered to minimise unnecessary friction compared to Options 2a and 2b, which would require consumers to give permission separately and actively to share historical data. This is considered unnecessary friction as ADRs are already prohibited from collecting more CDR data than is reasonably needed, as per the data minimisation principle, and as such should only be requesting the data if it is necessary for the service.

Further, Option 2a may result in a redundant or conflicting control on the DH side where the consumer has already given the ADR permission to access historical data. On this basis, Option 1a is considered to minimise unnecessary friction, in the form of controls that may be redundant or contribute to consent fatigue, while still providing positive friction, in the form of a contextual notification.

[In relation to consumers being informed about historical metering data sharing:] the DSB’s starting point should be that consumer consent satisfies the objects in rule 4.9. Further CX research would assist to determine the best way to achieve this, and the optimum amount of friction in the consent process.

This decision proposal was informed by 2020 research on energy data sharing and AEMO’s role in CDR, along with more recent research conducted in 2022 on the consent review. Based on research to date, Option 1a is considered to strike the right balance between transparency, control, and cognitive load when facilitating informed consent.

In relation to option 1, it is unclear what is meant by ’Allow historical data from previous retailers to be shared by default’.

Option 1 refers to sharing historical metering data without the need for the consumer to actively make a selection. The options provided by option 1 are to (a) clearly indicate to the consumer as part of the consent when historical data from previous retailers may be shared; or (b) share historical data from previous retailers without indicating this fact.

In the preferred Option 1a, while historical data will be shared by default, the consumer will be alerted to this detail before the data is shared and as such will have the opportunity to exit the process if they do not wish for this to occur. With Option 1b, which is not recommended, the consumer will not be alerted that historical data will be shared by default.

Our understanding is there are no CX standards in relation to AEMO’s role. We consider the risks raised by the lack of consumer awareness of AEMO’s role are magnified in a HMDS context. We recommend the DSB revisit this issue with Treasury to ensure that consumers are appropriately notified of AEMO’s role in handling CDR data.

The findings from energy sector research conducted in 2020 showed that participants expected AEMO’s role to be made transparent. Noting this finding, the DSB will revisit this issue and consider the inclusion of further detail in the authorisation flow in relation to historical data and AEMO’s role in the process.

[CDR-CX-Stream]

In response to @AGL-CDR, please see the below from the @CDR-API-Stream:

Scenario 2 – LCCD is not populated
By default, consumers who churn retailers frequently but do not move to new supply addresses in that time, will have their window of sharable meter data restricted. While this is necessary to prevent privacy concerns stemming from usage data being shared from a previous occupant, this has further implications.

Should the consumer seek to access the full benefit of 24 months of historical data, the current FRMP would need to work with their customer to independently verify their time of occupation. AGL notes that there is no industry standard for such a process, which will likely lead to inconsistent application and outcomes. Importantly, this is likely to result in an unsatisfactory CDR experience because it puts the burden of proof back on the consumer.

To address this, AGL proposes that, wherever possible, LCCD is pre-populated immediately prior to the adoption of LCCD. This should be achieved by working with AEMO, using the Blind Upload Tool (BUT) in the lead up to deployment. AGL has engaged with AEMO and requested support in this action.

With the assumption that the LCCD will be populated with a pre-defined default value, its interpretation and use would be similar to leaving it blank. It is not clear how this will address the above noted issue. If the intention is to pre-populate with the appropriate value a consumer has been at a given premise, this would be beneficial to consumers allowing them to benefit from LCCD sooner. Further details of how this would be carried out would be of value to discuss and understand.

Risks
AGL supports the view that all energy Retailers must support the upkeep and overall validity of LCCD at all times, as required by the MSATS procedures. We note that while all retailers are obligated to maintain the LCCD, not all are required to participate in CDR, and we note that they may have less focus on this matter.

This is important because, once populated, Retailers who gain ownership of a supply address via insitu transfer will be blind to previous customer movements and the LCCD will be assumed to be correct in all circumstances. A partial implementation of LCCD will increase the risk of inaccuracy, leading to potential privacy concerns.

The DSB understands that this risk was discussed as part of AEMO's original consultation. As per our understanding the mitigation of this risk is that a retailer will be required to update the LCCD value based on AEMO defined rules as they are applicable to the energy sector outside of CDR. Note that the DSB is intending to undertake a risk assessment on the use of LCCD for data sharing resulting from feedback received during this consultation.

Thank you @AGL-CDR for your input on implementation considerations. We will consider this when proposing any new obligation dates.

[CDR-CX-Stream]

The @CDR-API-Stream has provided the below in response to @TravisWorsteling:

Thank you for your submission. Based on stakeholder feedback in relation to these issues, given in various forums, the DSB is planning to undertake a risk assessment consultation for community feedback on the use of LCCD in sharing consumer energy usage data via the CDR data standards. We currently anticipate initiating this assessment this year. We will update the community with further details soon.

[CDR-CX-Stream]

In response to @Parag-PowershopAU, please see the below from the @CDR-API-Stream:

Recommendation to add data correction as a topic for this consultation as the scope of data correction increases by introducing LCCD related changes to CDR data being shared. If a data correction request comes through for CDR data which is from before the current FRMP start date, how will this be managed and by whom etc.

Our current understanding is that the existing data correction processes for AEMO held data would work for LCCD as it is also AEMO held data. We are discussing the issue with Treasury and will provide clarification when available.

[AGL-CDR]

@CDR-CX-Stream thank you for your detailed comment and response. I look forward to discussing these issues further in more detail. AEMO have recently confirmed that they will not be upgrading the existing Blind Update Tool (BUT) to enable bulk update to LCCD. This precludes a coordinated response from industry to address the issue raised in our submission above. Alternative solutions are available but are dependent on individual retailer implementation, eg. it may be possible to bulk trigger updates via CATS CRs, however this needs to be approached carefully to prevent stop-files caused by exceeding MSATS thresholds.

[mattyp]

A little late to the party, sorry, but commenting nonetheless...

As a fledgling DR in the energy space, I am very supportive of the introduction and use of the LCCD field as a means of providing the full consented extent of the consumer's usage history at a site, regardless of the retailer's involved. In a time of increasing churn frequency, this would allow use-cases to be implemented that would otherwise not be viable.

The options recommended in the DP paper make sense, provided the "notification" obligation on the DH can be satisfied by a simple "Includes usage data from before ACME Energy" (or similar).

The only potential alteration would be to include the LCCD date in the CDR data standards. Having this date available could enable software products to better understand the integrity of the usage history data, as well as provide a more personalised contextual experience (cheesy example: "Happy 5-year anniversary at 1 Main Street!"), particularly when the LCCD date is prior to the oldest retrieved usage date and so the usage history can't be used as a proxy to determine move-in date.