Decision Proposal 260 - Energy Closed Accounts

[CDR-API-Stream]

This decision proposal outlines recommended changes to the technical energy standards to ensure closed account information can be shared in a schema compliant manner and in alignment with the rules.

The decision proposal is embedded below: Decision Proposal 260 - Closed Energy Accounts.pdf

This consultation will be open for feedback until the 18th August 2022.

---

The consultation is now extended until 30th August 2022. Please see this comment for latest proposal

Decision Record

The Data Standards Chair approved this decision on 9th September 2022. The decision record is attached: Decision 260-Energy Closed Accounts

[agl-cdrprogram]

This is with reference to the following point noted in “Additional Notes” of the Decision Proposal 260.

• The balance returned for closed accounts should be $0.

Unlike banking sector where an account can only be closed after 0 balance, in energy sector, there are scenarios where the customers either have credits or overdue on closed accounts for multiple reasons. AGL’s recommends that we send the actual balance for closed accounts instead of passing $0 for closed accounts by default even if the closed account has credit or an overdue amount.

In addition to the above, we believe that this change may be too close to Go Live (depending upon when it is approved finally), and we may not be able to accommodate it for Tranche 1 Go Live (15th Nov). Request to fast track decision taking and approval process for this change.

[JohnMillsEnergyAustralia]

In relation to closed accounts, as detailed on page 3, under heading of "Additional Notes".

EA supports the account balance to be the account balance held, and not a manufactured value of "zero".

[jsaxon-red]

Red is in agreement on the proposed changes.

As noted the balanced for closed accounts should be $0 and in most cases it will be, but given this is not a must we believe there is no issue, presuming that ADR's are aware that in some cases a non-zero balance may occur.

[JohnMillsEnergyAustralia]

EA opposes the below non-urgent change being made to be delivered prior to Nov 15 :

1. Introduce Account Status Flag
2. Add Query Parameter to filter based on Account Status
3. API Field change.

We have reached a date where any changes proposed cannot be accommodated within a phase 1 date of Nov 15 unless they are URGENT in nature.

There are several fields that EA would need to consider to be able to create a ‘closed account’ flag that meet the needs of ADRs. While we have been preparing to provide the appropriate data for open and closed accounts to ADRs, we were not preparing to expose this information and a default status for use in CDR payloads. We have reached a date where any changes proposed cannot be accommodated within a phase 1 date of Nov 15 unless they are URGENT in nature. Given the late notice, this can’t be done prior to 15 Nov.

[biza-io]

Biza.io believes the proposed solution is the most suitable way to achieve the Rules definition, without forcing Retailers to disclose voluntary data, while achieving schema compliance. On this basis our HaaS solution will be capable of delivering on the proposed outcomes, by November, of this Decision Proposal. In fact the Cosmos release of the HaaS environment already incorporates the required data within our integration layer, notably the addition of a status indicator.

With this stated, Biza.io does rely upon the source systems of its customers and consequently the availability of this field will depend on whether our customers are able to integrate it into their release cycles. While we can't make commitments in this respect, Biza.io is happy to be a champion for this change in our interactions with the relevant customers.

[PratibhaOrigin]

Origin welcomes this consultation and supports the recommended changes. The addition of the openstatus flag/field helps data holder with the differentiation of mandatory vs voluntary data and complying with CDR schema standards while sharing requested data.

[CDR-API-Stream]

Thank you to everyone who has put forward feedback. Consultation has been closed and feedback will now be reviewed and considered.

[CDR-API-Stream]

The DSB have reviewed the feedback and acknowledge that whilst the solution proposed has community agreement, having the implementation done for November 15th energy go-live date is not feasible.

As a result, the DSB recommends the changes in the decision proposal be adopted with future dated obligated as below:

• 07/04/2023: The changes in the DP should be implemented as V2 of the impacted APIs (Get Energy Accounts and Get Energy Account Details)
• 08/05/2023: The deprecation date for V1 of the impacted APIs (Get Energy Accounts and Get Energy Account Details) (Note: The dates are derived from the obligation date schedule)
• From the tranche 1 date (15/11/2022) until the V1 deprecation date Closed Accounts information must be presented via the V1 APIs in a schema compliant fashion. The guidance to implementers will be to provide values for all mandatory fields and to select reasonable default values and structures if the data is not available for closed accounts

The consultation will be re-opened and extended till Tuesday the 30th August 2022 for any comment on the above proposed dates. If no feedback is received the decision will be recommended to the chair for approval.

[biza-io]

Biza.io understands the DSB position being as follows:

1. Introduce a V2 of the API endpoint prior to initial Go Live with an FDO in mid 2023
2. Retain V1 of the API endpoint until mid 2023
3. Expect V1 payloads to include Closed Account data by either voluntarily providing non Mandated data or by stubbing in such a way that the outcome is schema compliant

While we are not adverse to the introduction of a V2 our position would be that a Holder must support at least one of the proposed versions from Go Live rather than being required to support, and therefore build, both V1 and V2 endpoints simultaneously.

Put another way, we would prefer to go live supporting only V2 and note that this was a similar approach taken for Get Metrics V1. We do not believe Data Recipients would be significantly impacted as there is currently none consuming this data and, in all likelihood, they will build for the future V2 state first.

[CDR-API-Stream]

@biza-io, this is reasonable feedback, thank you for providing it.

Given the unique circumstances of energy sector not being live yet, the DSB will consider making an exception and recommend the following:

• Two versions of the Get Energy Accounts and Get Energy Account Details APIs will be included in the standards for energy go live on 15th November 2022:
  • v1 will be the version that Data Holders may have already implemented without any changes approved as part of this DP260
  • v2 will contain the changes to approved as part of this DP260 to specifically support closed accounts
• Data Holders can choose which version to implement for November 15th
• Payloads for Closed Accounts information for v1 APIs must be presented in a schema compliant fashion. The guidance to implementers will be to provide values for all mandatory fields and to select reasonable default values and structures if the data is not available for closed accounts
• 07/04/2023 will be set as the future dated obligation (FDO) when v2 will become mandatory version all DH must implement and support
• Data Holders who have implemented v1 for November 15th can implement v2 anytime prior to the FDO stated above

As mentioned previously, If no further feedback is received the above recommendation along with changes in DP260 will be recommended to the chair for approval.

[agl-cdrprogram]

After reading the below references provided,

1. Schedule 4, Part -1, Section 1.3 - Meaning of terms for types of data
2. Schedule 4, Part 3, Section 3.2 Meaning of required consumer data and voluntary consumer data—energy sector
3. Energy Language & Authorisation Scope on Github
4. Decision Proposal - 260

we believe following will be the behaviour of Energy APIs for closed accounts where a data holder does not provide voluntary consumer data.

API End Point	DH Response	Rules	Authorisation Scope	Remarks
Get Consumer Get Customer Detail	Yes	Customer Data	common:customer.basic:read	Data Holder will respond as the consumer will have at least one active account with Data Holder
Get Energy Account	Yes	Account Data	energy:accounts.basic:read	As per DP-260, supply a schema valid response.
Get Energy Account Detail	Yes	Account Data	energy:accounts.detail:read	As per DP-260, supply a schema valid response.
Get Billing for Account	Yes	Billing Data	energy:billing:read
Get Invoices for Account	Yes	Billing Data	energy:billing:read
Get Concessions	No	Account Data	energy:accounts.concessions:read	We will not share concessions data for closed account as it is Refer Account Data (b)(v) “any concessions”
Get Balance for Energy Accounts	Yes	Billing Data	energy:billing:read	As advised earlier. we will send actual balance for closed accounts.
Get Agreed Payment Schedule	No	Account Data	energy:accounts.paymentschedule:read	Just clarifying the possible point of contention. This endpoint is account data under (b)(iv) “any payment schedule” and not billing data under (b)(iv) “the payment method”. The “payment method’ under billing data refers to how the actual bill was paid for that particular transaction.
Get Service Points	No	NMI Standing Data	energy:electricity.servicepoints.basic:read	Will align with AEMO response – Will AEMO omit the unavailable service points (ie. not under the control of the retailer)?
Get Service Point Details	No	NMI Standing Data	energy:electricity.servicepoints.detail:read	Respond back with 404
Get Usage for Service Point	Yes	Meter Data	energy:electricity.usage:read
Get DER for Service Point	No	DER Register Data	energy:electricity.der:read	Will align with AEMO response – Will AEMO omit the unavailable service points (ie. not under the control of the retailer)?

Based on the discussions we had in the CDR Implementation Weekly Call on 25th Aug, we felt there there were gaps and would like to clarify the expected behaviour for each API (in case of closed accounts and where we do not provide voluntary data)

[CDR-API-Stream]

@agl-cdrprogram thank you for your comment. The DSB is currently drafting guidance in collaboration with Treasury and ACCC covering the points you have raised and will publish it soon.

Feedback on this decision proposal is now closed. Thank you to everyone who has provided feedback. The agreed proposal will be incorporated into a decision document for the Chair to review and approve. The DSB will update the comment with the outcome.

[CDR-API-Stream]

The Data Standards Chair has now approved this decision. The decision record can be found in the original post.