Decision Proposal 114 - Account Payloads

[CDR-API-Stream]

The decision proposal for Energy Account data payloads is attached below:
Decision Proposal 114 - Account Payloads.pdf

Feedback is welcome on this proposal. This thread will remain open for feedback until the 9th of October.

As previously discussed in various forums, the practice of the DSB is to respond to feedback incrementally before the consultation is complete to promote an interactive style of consultation.
Participants are therefore encouraged to provide feedback earlier in the consultation process so that the community can work together to a consensus outcome.

[perlboy]

This recommendation states that the proposal is targeted only at Electricity which is fine but the industry path is /energy.

Is there an intent to consider the inclusion of Gas at some point in the future? Would this be within the same industry path? If so, should the electricity payloads be wrapped in uType's. If not, should the industry path be /electricity?

[perlboy]

None of the multi value payloads include pagination which is divergent from Banking payloads. Is there a reason why, for consistency reasons, this shouldn't be supported? Is this divergence and reasons for doing so documented somewhere?

[perlboy]

A number of notes regarding properties:

• In these payloads name is used for a display name while in banking account payloads it is displayName
• openDate is specified as The date that the account was created or opened, is there a difference between created or opened? Is there a reason this is different to BankingAccount creationDate?
• servicePointIds, do NMI's have a specified format? Given their importance in the ecosystem should this specified as a new String type?
• planOverview includes something that seems to relate to product information. Without Product Payloads for Energy it is difficult to understand how these relate, could this be clarified? If it is indeed a reference to product information, this is an explicit tie in to a potentially unavailable plan detail? In addition is the plan vs. product naming difference deliberate? Do Products have one or more Plans? Is it possible to have multiple plans active for a single product?
• planOverview has an applicability end date but there is no support for multiple entries (ie. current and previous plans) in the payload? How does historical rollover information get displayed with relation to a specific account?
• There is no concept of isOwned in these payloads which is relevant for a Consumer accessing on behalf of a Business? Is this intentional?
• For authorisedContacts this structure looks like CommonPerson? If so, ideally this would include some indicator of whether the active consent relates to a specific authorised contact (which comes back to the isOwned comment above). Is there personal information disclosure limitations related to this?
• Regarding /payment-schedule is there a reason this isn't aligned to the Banking Scheduled Payments path of /payments/scheduled etc.
• Regarding the scope energy:accounts.paymentschedule:read, this is not aligned to the scope format within banking. A suggested format would be energy:regular_payments:read or at least pluralised underscores
• Regarding perDayDiscount and perMonthDiscount the alignment here would probably be dailyDiscount and monthlyDiscount

[CDR-API-Stream]

In response to the following feedback from @perlboy:

This recommendation states that the proposal is targeted only at Electricity which is fine but the industry path is /energy.

Is there an intent to consider the inclusion of Gas at some point in the future? Would this be within the same industry path? If so, should the electricity payloads be wrapped in uType's. If not, should the industry path be /electricity?

The potential addition of other energy related sectors in the future (like gas) is the cause of this choice. The current position is based on feedback to consultion #103 that specifically canvassed this question and feedback in open workshops where this was also discussed.

[CDR-API-Stream]

In response to the following feedback from @perlboy:

None of the multi value payloads include pagination which is divergent from Banking payloads. Is there a reason why, for consistency reasons, this shouldn't be supported? Is this divergence and reasons for doing so documented somewhere?

For the get account list this is an oversight and a good pickup. In early iterations it was unclear if account was multiple or singular. Now that we have a get account list end point it should be paginated for consistency even if there will only be one or two records in the majority of cases.

The other case of this is the concessions end point. This end point, while containing a base array, is intended to provide a single set of data (concessions) that is unlikely to have numerous entries and is more analogous to a list of features or eligibility criteria in the PRD for instance. It was separated only to support an expectation that customers would want to provide access separately. It is also unclear if an array is the correct structure or where a fixed object is better or if there should be a second 'hardship' array. For these reasons this end point has been treated as returning a single sub-attribute of an account rather than a record set.

[CDR-API-Stream]

In response to the following feedback from @perlboy:

• In these payloads name is used for a display name while in banking account payloads it is displayName
• openDate is specified as The date that the account was created or opened, is there a difference between created or opened? Is there a reason this is different to BankingAccount creationDate?

Good feedback. Alignment is on this is a good thing as they are fields with essentially the same meaning.

• servicePointIds, do NMI's have a specified format? Given their importance in the ecosystem should this specified as a new String type?

A service point ID is not a NMI. It is record ID for the CDR like accountId in banking so it has been typed the same way (see the discussions on this in previous consultations - #109, #103).

• planOverview includes something that seems to relate to product information. Without Product Payloads for Energy it is difficult to understand how these relate, could this be clarified? If it is indeed a reference to product information, this is an explicit tie in to a potentially unavailable plan detail? In addition is the plan vs. product naming difference deliberate? Do
  Products have one or more Plans? Is it possible to have multiple plans active for a single product?

Please refer to the separate consultation on public plans - #111.

• planOverview has an applicability end date but there is no support for multiple entries (ie. current and previous plans) in the payload? How does historical rollover information get displayed with relation to a specific account?

In alignment with the treatment in banking only the current plan is included. We are open to feedback that previous plans should be included but would seek retailer feedback on whether this data is digitally held. Obviously plans from a relationship with previous retailers would not be able to supplied.

• There is no concept of isOwned in these payloads which is relevant for a Consumer accessing on behalf of a Business? Is this intentional?

Based on feedback from retailers the concept if access to an account is managed differently in the energy sector to the banking sector. It is understood that access to an account that is not 'owned' is managed via authorised contacts (which are included in the payload).

• For authorisedContacts this structure looks like CommonPerson? If so, ideally this would include some indicator of whether the active consent relates to a specific authorised contact (which comes back to the isOwned comment above). Is there personal information disclosure limitations related to this?

See response above. As the authorised contact is a 3rd person the inclusion of data is more akin to an address book contact rather than a customer record and is therefore treated similarly to the organisation agent for a organisational customer in banking and is provided a dedicated data structure.

• Regarding /payment-schedule is there a reason this isn't aligned to the Banking Scheduled Payments path of /payments/scheduled etc.

Yes. The data held by retailers has been indicated as being significantly different.

• Regarding the scope energy:accounts.paymentschedule:read, this is not aligned to the scope format within banking. A suggested format would be energy:regular_payments:read or at least pluralised underscores

Thank you. The underscore will be added although the 'accounts.' will remain as this is a sub-scope for an account which was separated based on CX research findings. It is therefore treated similarly to 'bank:accounts.basic:read'.

• Regarding perDayDiscount and perMonthDiscount the alignment here would probably be dailyDiscount and monthlyDiscount

Thanks for this feedback, we will review the change.

[perlboy]

The potential addition of other energy related sectors in the future (like gas) is the cause of this choice. The current position is based on feedback to consultion #103 that specifically canvassed this question and feedback in open workshops where this was also discussed.

All of this is fine (and was the basis of my first set of questions) however it doesn't answer this:

If so, should the electricity payloads be wrapped in uType's[?]

It seems inevitable gas (and potentially "combo" situations I guess) would eventually be in-scope so defining a response object that implicitly starts at a root level with a uType and a sub-class of electricity would ensure that future changes that introduce additional sectors are not implicitly breaking to existing implementations.

I can't comment on undocumented, unrecorded workshops but this does not appear to have been explicitly covered in #103, rather what was discussed was the entirely justifiable reasons for having a single endpoint for potentially multiple industries.

The other case of this is the concessions end point. This end point, while containing a base array, is intended to provide a single set of data (concessions) that is unlikely to have numerous entries and is more analogous to a list of features or eligibility criteria in the PRD for instance.

Except feature and eligibility do not have explicit responses (ie. they are contained within a detailed response) and so it is not analogous.

It was separated only to support an expectation that customers would want to provide access separately.

This sounds like a reasonable justification for the additional endpoint.

It is also unclear if an array is the correct structure or where a fixed object is better or if there should be a second 'hardship' array. For these reasons this end point has been treated as returning a single sub-attribute of an account rather than a record set.

I can't comment on something that might be defined at some undefined period in the future that might change the payload presentation and so consequently can only respond in line with the current proposal which is a Mandatory Array of Objects. On this basis the reasons for adopting a paginated response are for the same reasons agreed upon in List Accounts "should be paginated for consistency even if there will only be one or two records in the majority of cases.".

The justifications for this are fundamentally about consistent developer experience across sectors. If this payload is an array it leads to the question of whether the meta object should include a totalRecords field (which would then have cascading questions regarding the impact on other endpoints). As a consequence the adoption of MetaPaginated for this payload seems the easiest since Holder implementations could reasonably assume it would only ever be a single paged response of 25 records or less while Recipient implementations could use the exact same method as other paginated responses for resultset construction.

A service point ID is not a NMI. It is record ID for the CDR like accountId in banking so it has been typed the same way (see the discussions on this in previous consultations - #109, #103).

Fair enough although the proposal appears to be confusing:

An array of servicePointIds, representing NMIs, that this account is linked to

Also, if service point id is "like accountId in banking" then it would be a pairwise identifier and unique for each recipient? This seems unlikely?

In alignment with the treatment in banking only the current plan is included. We are open to feedback that previous plans should be included but would seek retailer feedback on whether this data is digitally held. Obviously plans from a relationship with previous retailers would not be able to supplied.

Previous plan information is highly useful for same retailer contract re-signs at lower rates. This is a very common action taken by retailers to retain customers and would result in the ability to measure the savings of simply talking to your retailer rather than moving. For what it's worth here, my question was "there is no support for multiple entries" which wasn't a specific request for previous plans (that was simply the example) but rather a, potentially/initially single value, array which would also lend itself to complex/innovative plan constructions (for instance, multiple active plans such as on/off-peak/solar-feed-in/network managed etc).

Based on feedback from retailers the concept if access to an account is managed differently in the energy sector to the banking sector. It is understood that access to an account that is not 'owned' is managed via authorised contacts (which are included in the payload).

Definitional debates of whether something is "managed" or "owned" aside the major advantage of having a boolean of isOwned in Banking payloads is the ability for Recipients to provide feature flag enablement of things that only an account which a consumer explicitly owned (versus had access to) would be able to execute, for instance access to a credit card rewards shop is generally a primary card holder permission. While authorised contacts is useful it's also very fuzzy and doesn't provide a recipient a programmatic way of determining whether any of the authorised contacts relate to the consumer that gave consent.

See response above. As the authorised contact is a 3rd person the inclusion of data is more akin to an address book contact rather than a customer record and is therefore treated similarly to the organisation agent for a organisational customer in banking and is provided a dedicated data structure.

See response above. My specific response was with regards to the alignment and reuse of CommonPerson (which this looks like) which implicitly reduces implementation effort and will allow more effective data quality management across sectors.

Yes. The data held by retailers has been indicated as being significantly different.

Which is why it is under /energy. The request was with regards to the path chosen which uses hyphens rather than a nested path of /payments/scheduled like banking. Regardless of the mechanical information (ie. direct debit details etc) the payload includes frequency periods indicating it is quite aligned in this respect to the banking scheduled payments endpoint.

Thank you. The underscore will be added although the 'accounts.' will remain as this is a sub-scope for an account which was separated based on CX research findings. It is therefore treated similarly to 'bank:accounts.basic:read'.

What was raised was about formatting of scopes. The sub-scoping is fine provided it is known that scheduled payments will only ever relate to a single account and therefore it is possible that the same scheduled payments will be repeated across account lists. I should highlight this approach effectively precludes the ability to create a bulk payments schedule endpoint without poisoning the scope namespace or creating an entirely separate scope/data cluster.

It would be ideal if this payload included an identifier to allow for uniform correlation of payment detail information across accounts. Additionally, the calculationType includes a STATIC option but the actual value of that payment is never described?

[CDR-API-Stream]

All of this is fine (and was the basis of my first set of questions) however it doesn't answer this:

If so, should the electricity payloads be wrapped in uType's[?]

It seems inevitable gas (and potentially "combo" situations I guess) would eventually be in-scope so defining a response object that implicitly starts at a root level with a uType and a sub-class of electricity would ensure that future changes that introduce additional sectors are not implicitly breaking to existing implementations.

I can't comment on undocumented, unrecorded workshops but this does not appear to have been explicitly covered in #103, rather what was discussed was the entirely justifiable reasons for having a single endpoint for potentially multiple industries.

Apologies, I assumed the answer to this was implied. It is understood from feedback from retailers that a single account is able to cover both gas and electricity (and potentially other services) so a root level union of distinct structures would not be appropriate. If the structure for gas and electricity accounts were entirely distinct we would have used '/electricity' and added '/gas' in the future.

If a new energy type is designated then this would likely be added through changes at various points of the account structure and, without a known designation, it isn't clear where those changes are likely to occur. Additions would likely be handled through end point versioning.

[CDR-API-Stream]

A service point ID is not a NMI. It is record ID for the CDR like accountId in banking so it has been typed the same way (see the discussions on this in previous consultations - #109, #103).

Fair enough although the proposal appears to be confusing:

An array of servicePointIds, representing NMIs, that this account is linked to

Also, if service point id is "like accountId in banking" then it would be a pairwise identifier and unique for each recipient? This seems unlikely?

This is explicitly what was proposed in the NMI standing data decision proposal. servicePointId is an ID following the CDR ID permanence rules.

[CDR-API-Stream]

Definitional debates of whether something is "managed" or "owned" aside the major advantage of having a boolean of isOwned in Banking payloads is the ability for Recipients to provide feature flag enablement of things that only an account which a consumer explicitly owned (versus had access to) would be able to execute, for instance access to a credit card rewards shop is generally a primary card holder permission. While authorised contacts is useful it's also very fuzzy and doesn't provide a recipient a programmatic way of determining whether any of the authorised contacts relate to the consumer that gave consent.

This is agreed - which is why the isOwned flag was included for the banking sector. The context for the electricity sector is that authorised contacts are not yet envisaged as being able to share data in the same way as they are able in the banking sector. If an isOwned flag was introduced it would therefore never be false. If this assumption around eligible consumer changes then an isOwned flag would be something to consider as an addition.

[perlboy]

This is agreed - which is why the isOwned flag was included for the banking sector. The context for the electricity sector is that authorised contacts are not yet envisaged as being able to share data in the same way as they are able in the banking sector. If an isOwned flag was introduced it would therefore never be false. If this assumption around eligible consumer changes then an isOwned flag would be something to consider as an addition.

So what is the envisaged view of contacts with various access levels on accounts? Take this form from Energy Australia, the following access permissions can be assigned:

[mannharleen]

Feedback from Origin Energy on DP-114

Accounts

• Ambiguity regarding accountid: It is not very clear what an accountId is. We learnt that it is a unique identifier that follows the ID Permanence rules documented in the Standard and that it is a relationship between the DH, ADR and the customer for a given consent. However, a formal documented definition is required.

• Whether the release of additional contacts will form part of the framework is being reviewed by the ACCC. There should be a placeholder in the paper that notifies the same

Payment Schedule

• Information such as accountNumber are tokenized in our systems, so there is no means by which we can provide it. The field thus should not be mandatory

• Further, what is the expectations around passing bank details, e.g. do we pass any bank details that may be linked to the account? Is it only for accounts with active DD’s? What happens if the last payments have been dishonoured and the DD is about to be cancelled because of the missed instalments?

• It is not very clear around what is deemed manual to ensure Origins definition is aligned. Clarification required, best to be part of the paper

• Ref “cardScheme”: As above - No specific privacy concerns with providing this level of detail but unsure as to any customer benefits to be had by doing so (except for maybe a fee perspective but individual retainers should already have a estimated split between the two) Please note: Origin does not currently accept all types listed

• W.r.t paymentScheduleUType, why is credit card excluded?

• How would one categorize self-administered payment plans, i.e. those customers that are paying an amount that is in equal instalments of equal amount that either do or do not meet the customers usage patterns

Concession and hardship

• We feel that the two terms have been mixed up, and they indeed mean very different things. Concessions are supported by the government () while hardships are energy specific arrangements. It seems the payload should be limited to concessions only

• Regarding concessions: Centrelink own the customers concession details. There are regulatory obligations for retailers to validate customer concession details with the appropriate regulatory bodies (Centrelink) and if they are no longer eligible, then the concession will be end dated and removed. If this data is to be provided, it needs to be recognised that the data is relevant at a point in time. Even if a concession is noted on a historical bill or information returned, it does not mean the customer is eligible on a future basis. Or there maybe situations where the concession has been removed but may be eligible for the next bill.

• We do not share the concession information outside of our validation process with Centrelink unless Services Australia or a State Government has requested. Ques: Has Centrelink/ Services Australia been engaged as a part of this activity? We would not be able to share concession details without the engagement and approval from them

• What is the intend of the field “additionalInfo”. It is too wide to say “information regarding concessions”

• Does this relate only to a rebate based on a customer’s concession card eligibility or does this extend out to all available rebates and grants that do not require a card

• What is the view required for the applicable rebates? If a customer checked today would we only show rebates that are currently active or alternatively a 12-month retrospective view that would display all rebates and grants the customer has received in this timeframe?

[ghost]

Feedback from AGL Energy on behalf of AGL Energy CDR technical working group.

General

• Our assumption on the approach to implement the ID permanence for AccountID will be driven deterministically from (ADR identifier) + (Retailer Internal Account ID) while taking customer authorisation (consent) into consideration. Are you able to confirm this logic?

Section: Detailed Account Data (/energy/accounts/{accountId})

• Authorised Contacts are automatically delinked from Accounts that have Domestic Violence flag set. In this scenario the array may not include all authorisedContacts

Section: Concession & Hardship Data

• The name field is described “The ID of the plan applicable to this account”. Concession is typically a type (in most instances state based) and not a plan (i.e. there is no association with a product).

• Assuming the intention of the name field refers to a type of concession, it is not uncommon for concession type definitions to embed within it a medical classification. Subsequently, there is a risk of this field being used to derive a customer’s medical condition. We recommend caution and suggest that further consultation occur on this data cluster decision proposal.

• The optional inclusion of endDate should be considered.

[CDR-API-Stream]

At the request of a number of participants the consultation on this topic will be extended until October 9th

[Mark-Lee-Momentum-Energy]

Feedback from Momentum Energy:

Account List

• accountId & servicePointIds: Require further understanding of how these fields will be used. Will retailers be expected to generate & provide these fields in responses, OR will AEMO generate and populate them before sending to ADRs? Assumption is that retailers must generate and populate them, because "AEMO’s handling of data sets for which it is not a data holder will be transient" (source: CDR - Energy rules framework consultation paper - July 2020)

• planOverview: Please confirm that multiple planOverview records can be included.
  Also please confirm if the intention is to include only the current plans, or all historic plans (inclusion of 'endDate' infers that historic plans may be included)

• planId: Is this the same planID as in the Tariff payload?

Detailed Account Data

• authorisedContacts: Noting that this section is subject to final outcome of ACCC CDR rules

Agreed Payment Schedule Data

• cardDebit: paymentFrequency & directDebit: paymentFrequency: Suggest these fields are non-mandatory to accommodate where customers have agreed to pay amounts on specific agreed dates (non recurring)

• calculationType: Suggest adding an option for AGREED AMOUNT: Indicates a specific payable amount that has been agreed between retailer and customer

• accountNumber: We mask these values in our system as per our security framework. Would assume most other retailers do too.

• billFrequency: Unless my interpretation is incorrect, this field should belong in the planOverview section of Detailed Account Data payload. Bill Frequency is an attribute of their product plan, not of the payment plan. The frequency of payments for payment plan is already covered by the paymentFrequency field.

Concession & Hardship Data

• name: It looks like this is the planId as per Account List / Detailed Account Data. Why call this 'name' instead of 'planID'? Also, Concessions don't necessarily apply to a payment plan, they might just be applied directly to the account. Suggest this field be Optional.

[SelenaLiuEA]

Afternoon All,

EnergyAustralia's feedback (some relates to the same issues already discussed in other feedback):

Account list

planID –

• What is the purpose of the planID and name? Is this supposed to map back to EME and Vic energy compare plan IDs? This does not appear to be the intent given that not all plans, particularly legacy plans, are provided to EME and Vic Energy Compare.

• If planID is an internal reference used for retailers, we question the necessary level of granularity for this data. For example, EnergyAustralia has a very high level, generic plan code – which covers plans which may have different discount levels and other plan variations. This may be sufficient because the discount level for a particular plan can be required under plan details (via tailored tariff data payloads) instead of being included in planID. To make the planID reflect discount level and other variations within one type of plan, EnergyAustralia would have to change the data and combine two data points.

• We note that internal reference plan IDs used by retailers is an unregulated data item and so plan ID will not be standardised across the industry (Please note that the Plan IDs assigned by EME may not be linked to the plans in a retailer’s billing system, where other tools have been built to link the two)

• What is the difference between planID and name?

openDate – we take this to mean when the account is opened. Again different retailers may open accounts at different times. For EnergyAustralia, we open a new account when an electricity or gas plan is entered into and/or when a customer changes premises. A customer may open a number of accounts over its relationship with EnergyAustralia.

• Please confirm that an Account can link to multiple NMIs, while this is not the typical configuration it is possible (but usually the one to one relationship is the most typical arrangement).

startDate – We understand this to mean when the account is associated with a plan, please confirm.

endDate – again, we understand this to mean when the account is not associated with a plan, which is likely to be when the account is closed. Please confirm.

Detailed Account Data

• authorisedContacts – we understand that this will relate to Nominated persons, ACCC decision is pending. We would support the inclusion of this data should these persons be eligible to use the CDR, but it is unclear whether there is value in including this data where they are not eligible. We also refer to our comments on CX Consultation Draft 5: Joint Accounts CX Consultation Draft 5: Joint Accounts #106 (CX Consultation Draft 5: Joint Accounts #106) which sets out that additional account holders can have different levels of authority on an account. Other persons such as accountants and lawyers can be referenced on an account, but again, we don’t see a specific need to share this data unless these roles are made eligible/otherwise recognised in the CDR regime.

firstName, lastName and middleNames – We suggest that middle and last names should not be mandatory, as it is possible that some persons may not have these names.

Agreed Payment Schedule Data

For Payment Schedule Data:

• We can confirm that payments are applied to an account, and where there are multiple NMIs on an account, the payment is divided. Having multiple NMIs assigned to the one account is uncommon for SME and residential customers, but it is possible. We have not addressed multisite customers here.

• Please confirm that manualPayment will refer to all other types of payment other than cardDebit and directDebit. i.e. it will include Auspost and Centrepay and concession vouchers like EAPA (https://www.service.nsw.gov.au/transaction/energy-accounts-payment-assistance-eapa-scheme )

calculationType and paymentFrequency are two fields that together should reflect different payment arrangements that are common/regulated in the energy sector:

1. payment plans for customers in payment difficulty (with the agreement of customers)

2. payment plans for budgeting purposes (bill smoothing payment arrangements under the regulations and unregulated regular payment arrangements)

3. customers that choose to pay any amount (not necessarily the invoice balance) at any frequency on their account (as determined by the customer)

4. Subscription type plans which are different to the above, and require a fixed payment amount as a feature of the energy plan and “true up” payment - not a payment arrangement , but just noting for completeness.

Concession and hardship data

• Concession and hardship data is complex and a workshop may assist the DSB in developing this data payload, if other retailers agree.

• Concession and hardship data should be separated as they relate to different data. Hardship data should only indicate whether the customer is in the retailer’s hardship program – this is different again from customers who are on a payment plan for payment difficulty as this more broadly includes both hardship customers and customers which the retailer considers are in payment difficulty.

• Concessions “name” - is described as “The ID of the plan applicable to this account” which appears to be not correct.

• additionalInfo and additionalInfoUri – please clarify what these mean in their descriptions. E.g. does the additionalInfoURI refer to a website address, and if yes, which address?

perDayDiscount/ perMonthDiscount/ annualDiscount/ percentageDiscount –

• we understand that the intent is that these fields should cover all concession formats. Different individual concessions for each state/territory can be structured quite differently. The DSB might want to take a bottom up approach to confirm that each individual concession will fit into one of the formats.
• For example, there would need to be a category of non-ongoing or non-periodic concessions that are expected to be applied once or a few times only e.g. Qld asset ownership divided, or rebates like the utility relief grant scheme which occur every two years or more, or EAPA which is applied twice a year.
• We also note that concessions data may change where the concession amount changes during a period. The relevant period should probably be the billing period, but there can be changes within the billing period.
• Purpose – what is the overall purpose of including concession data in Account payloads? If the overall purpose is to indicate that a customer is paid concessions but not how much is paid – this data could be standardised and provided by AEMO (as it will not change from retailer to retailer). If the purpose is to allow a calculation of the concession paid on a bill, it may be better to specify this as an item in billing data (and if so, we'll need to consider this more).

[CDR-API-Stream]

Thanks for all of the feedback. This thread is now closed for further feedback.

We are processing the responses and will provide comment below. Further feedback on this payload (and the rest of the standard) will occur once consultation on the remaining data clusters is complete and we are able to publish a full draft.

[CDR-API-Stream]

In response to AGL:

Our assumption on the approach to implement the ID permanence for AccountID will be driven deterministically from (ADR identifier) + (Retailer Internal Account ID) while taking customer authorisation (consent) into consideration. Are you able to confirm this logic?

Yes, that sounds appropriate.

Authorised Contacts are automatically delinked from Accounts that have Domestic Violence flag set. In this scenario the array may not include all authorisedContacts

The management of this data set is expected to be according to the practice of the retailer so this approach would be appropriate.

The name field is described “The ID of the plan applicable to this account”. Concession is typically a type (in most instances state based) and not a plan (i.e. there is no association with a product).

Thanks. That appears to be a cut & paste issue. The description will need to be corrected

Assuming the intention of the name field refers to a type of concession, it is not uncommon for concession type definitions to embed within it a medical classification. Subsequently, there is a risk of this field being used to derive a customer’s medical condition. We recommend caution and suggest that further consultation occur on this data cluster decision proposal.

We are aware of this. This is primarily why the concession data is moved to a different scope so that the customer has complete control over the data they share.

The optional inclusion of endDate should be considered.

We will take that into consideration

[CDR-API-Stream]

In response to Origin Energy:

Ambiguity regarding accountid: It is not very clear what an accountId is. We learnt that it is a unique identifier that follows the ID Permanence rules documented in the Standard and that it is a relationship between the DH, ADR and the customer for a given consent. However, a formal documented definition is required.

The description in the feedback above is correct. This is as stated in the decision proposal. We will look at providing more detail.

Whether the release of additional contacts will form part of the framework is being reviewed by the ACCC. There should be a placeholder in the paper that notifies the same

The standards follow the rules. Once the ACCC positions are fully known the standards will be modified to align.

Information such as accountNumber are tokenized in our systems, so there is no means by which we can provide it. The field thus should not be mandatory

Thanks we will take this into account

Further, what is the expectations around passing bank details, e.g. do we pass any bank details that may be linked to the account? Is it only for accounts with active DD’s? What happens if the last payments have been dishonoured and the DD is about to be cancelled because of the missed instalments?

If the data is held it should be shared. If it is not held it can't be shared. If a dishonour has occurred but the data is still considered current by the Retailer (ie. it hasn't been replaced or deleted) then it should be returned.

It is not very clear around what is deemed manual to ensure Origins definition is aligned. Clarification required, best to be part of the paper

Manual simply means that the customer pays each bill according to their own preference. There is no automatic mechanism configured.

Ref “cardScheme”: As above - No specific privacy concerns with providing this level of detail but unsure as to any customer benefits to be had by doing so (except for maybe a fee perspective but individual retainers should already have a estimated split between the two) Please note: Origin does not currently accept all types listed

If a type is not held then it should not be returned. The schema has been structured to allow this variability.

W.r.t paymentScheduleUType, why is credit card excluded?

Credit cards are included under the cardDebit structure noting that a scheme card can be a debit or a credit card and that from the Retailer perspective it will be used to execute a debit.

How would one categorize self-administered payment plans, i.e. those customers that are paying an amount that is in equal instalments of equal amount that either do or do not meet the customers usage patterns

This is the purpose of the calculationType field to indicate the type of payment schedule. The actual amounts are not included in the energy:accounts.paymentschedule:read as this is available from the billing/statements data clusters.

If an amount would be valuable to add to these APIs this can be considered.

We feel that the two terms (concession & hardship) have been mixed up, and they indeed mean very different things. Concessions are supported by the government () while hardships are energy specific arrangements. It seems the payload should be limited to concessions only

What we have attempted to do is allow for both sets to be included without emphasising the source of the discount. This feedback is helpful. If the structure for a discount is different for a concession vs a hardship arrangement then this would be helpful to know.

Regarding concessions:

• Centrelink own the customers concession details. There are regulatory obligations for retailers to validate customer concession details with the appropriate regulatory bodies (Centrelink) and if they are no longer eligible, then the concession will be end dated and removed. If this data is to be provided, it needs to be recognised that the data is relevant at a point in time. Even if a concession is noted on a historical bill or information returned, it does not mean the customer is eligible on a future basis. Or there maybe situations where the concession has been removed but may be eligible for the next bill.
• We do not share the concession information outside of our validation process with Centrelink unless Services Australia or a State Government has requested. Ques: Has Centrelink/ Services Australia been engaged as a part of this activity? We would not be able to share concession details without the engagement and approval from them

Thank you for this helpful context. It is the understanding of the DSB that the requirement for the sharing of data via a designation instrument validly registered according to the CDR legislation would remove the need for further sharing authorisation. We will however confirm this.

What is the intend of the field “additionalInfo”. It is too wide to say “information regarding concessions”

It is a free form text field to provide additional context that could be displayed to a human.

Does this relate only to a rebate based on a customer’s concession card eligibility or does this extend out to all available rebates and grants that do not require a card

All rebates, concessions and grants are assumed to be in scope

What is the view required for the applicable rebates? If a customer checked today would we only show rebates that are currently active or alternatively a 12-month retrospective view that would display all rebates and grants the customer has received in this timeframe?

The concessions API is not time bound so only currently active data should be provided.

[CDR-API-Stream]

In response to EnergyAustralia:

planID –

• What is the purpose of the planID and name? Is this supposed to map back to EME and Vic energy compare plan IDs? This does not appear to be the intent given that not all plans, particularly legacy plans, are provided to EME and Vic Energy Compare.
• If planID is an internal reference used for retailers, we question the necessary level of granularity for this data. For example, EnergyAustralia has a very high level, generic plan code – which covers plans which may have different discount levels and other plan variations. This may be sufficient because the discount level for a particular plan can be required under plan details (via tailored tariff data payloads) instead of being included in planID. To make the planID reflect discount level and other variations within one type of plan, EnergyAustralia would have to change the data and combine two data points.
• We note that internal reference plan IDs used by retailers is an unregulated data item and so plan ID will not be standardised across the industry (Please note that the Plan IDs assigned by EME may not be linked to the plans in a retailer’s billing system, where other tools have been built to link the two)
• What is the difference between planID and name?

The planID is intended to be the EME or VEC plan identifier and the name is intended to be a human readable display label for the plan. Based on the feedback above it would appear to be the case that the planID is not able to be reliably attached to a tailored plan as on market plans change. This was encountered in the banking sector also. In this context it is likely we will remove the planID field.

openDate – we take this to mean when the account is opened. Again different retailers may open accounts at different times. For EnergyAustralia, we open a new account when an electricity or gas plan is entered into and/or when a customer changes premises. A customer may open a number of accounts over its relationship with EnergyAustralia.

That is correct.

Please confirm that an Account can link to multiple NMIs, while this is not the typical configuration it is possible (but usually the one to one relationship is the most typical arrangement).

Yes. That is the intent

startDate – We understand this to mean when the account is associated with a plan, please confirm.

Yes. It is possible that this account has had multiple plans over time (due to renegotiation, etc). The state date is intended to indicate when the current arrangement was established.

endDate – again, we understand this to mean when the account is not associated with a plan, which is likely to be when the account is closed. Please confirm.

No, the endDate in this context is when the plan conditions will end, possibly due to a time bound contract or an introductory period. It is optional as it is expected that not all plans will have an end date.

authorisedContacts – we understand that this will relate to Nominated persons, ACCC decision is pending. We would support the inclusion of this data should these persons be eligible to use the CDR, but it is unclear whether there is value in including this data where they are not eligible. We also refer to our comments on CX Consultation Draft 5: Joint Accounts #106 (#106) which sets out that additional account holders can have different levels of authority on an account. Other persons such as accountants and lawyers can be referenced on an account, but again, we don’t see a specific need to share this data unless these roles are made eligible/otherwise recognised in the CDR regime.

The inclusion of authorisedContacts is unrelated to the eligibility criteria. It is a designated data set associated with an account. The eligible consumer decision will impact who is able to establish a consent for the sharing of CDR data.

firstName, lastName and middleNames – We suggest that middle and last names should not be mandatory, as it is possible that some persons may not have these names.

Currently firstName is optional, middleName is mandatory but may be an empty array (ie. no names exist) and lastName is mandatory. Where an individual has a single name this should be put in the lastName field. This is outlined in the field descriptions.

For Payment Schedule Data:

• We can confirm that payments are applied to an account, and where there are multiple NMIs on an account, the payment is divided. Having multiple NMIs assigned to the one account is uncommon for SME and residential customers, but it is possible. We have not addressed multisite customers here.

Thank you for this context.

• Please confirm that manualPayment will refer to all other types of payment other than cardDebit and directDebit. i.e. it will include Auspost and Centrepay and concession vouchers like EAPA (https://www.service.nsw.gov.au/transaction/energy-accounts-payment-assistance-eapa-scheme )

manualPayment indicates that the customer will choose when and how a payment will be made. There is no automated schedule.

If there are alternative methods that can be automated then we would love to understand what these methods are and include them in the payload.

calculationType and paymentFrequency are two fields that together should reflect different payment arrangements that are common/regulated in the energy sector:

1. payment plans for customers in payment difficulty (with the agreement of customers)
2. payment plans for budgeting purposes (bill smoothing payment arrangements under the regulations and unregulated regular payment arrangements)
3. customers that choose to pay any amount (not necessarily the invoice balance) at any frequency on their account (as determined by the customer)
4. Subscription type plans which are different to the above, and require a fixed payment amount as a feature of the energy plan and “true up” payment - not a payment arrangement , but just noting for completeness.

That is the intent of the payload to cover these scenarios in a generic manner. if the payloads need to be extended to accommodate any of these scenarios it would be helpful to understand the details of this.

• Concession and hardship data is complex and a workshop may assist the DSB in developing this data payload, if other retailers agree.
• Concession and hardship data should be separated as they relate to different data. Hardship data should only indicate whether the customer is in the retailer’s hardship program – this is different again from customers who are on a payment plan for payment difficulty as this more broadly includes both hardship customers and customers which the retailer considers are in payment difficulty.

A workshop may be worthwhile. The intent here is not to communicate the underlying driver of hardship but to accommodate a discount or grant that is the result of such an

• Concessions “name” - is described as “The ID of the plan applicable to this account” which appears to be not correct.

Thanks. Yes, this is an error.

• additionalInfo and additionalInfoUri – please clarify what these mean in their descriptions. E.g. does the additionalInfoURI refer to a website address, and if yes, which address?

additionalInfo is a free form text for display purposes that can be shown to a user. It is intended to be short, unformatted and pertinent to the context.

additionalInfoUri is a like to a hosted web page with more information that is able to be formatted however the Retailer wishes.

perDayDiscount/ perMonthDiscount/ annualDiscount/ percentageDiscount –

• we understand that the intent is that these fields should cover all concession formats. Different individual concessions for each state/territory can be structured quite differently. The DSB might want to take a bottom up approach to confirm that each individual concession will fit into one of the formats.
• For example, there would need to be a category of non-ongoing or non-periodic concessions that are expected to be applied once or a few times only e.g. Qld asset ownership divided, or rebates like the utility relief grant scheme which occur every two years or more, or EAPA which is applied twice a year.

Actually, the intent was to create a generic structure that would allow for the billing impact to be specifically applied but for the detail on the concession itself to be descriptive only. A state by state analysis of discounts was done to generate the proposed structure in accordance with this intent. If there is a specific application of a concession that is not covered by the structure then the details of this would be very helpful feedback.

The specific feedback above (on non-ongoing concessions) will be incorporated.

• We also note that concessions data may change where the concession amount changes during a period. The relevant period should probably be the billing period, but there can be changes within the billing period.

Detail on the drivers of these changes would be helpful.

• Purpose – what is the overall purpose of including concession data in Account payloads? If the overall purpose is to indicate that a customer is paid concessions but not how much is paid – this data could be standardised and provided by AEMO (as it will not change from retailer to retailer). If the purpose is to allow a calculation of the concession paid on a bill, it may be better to specify this as an item in billing data (and if so, we'll need to consider this more).

The data is included as per the designation instrument which separates concession information from billing data and nominates the retailer as the data holder.