Decision Proposal 113 - Customer Data Payloads

[CDR-API-Stream]

The decision proposal for Customer data payloads is attached below:
Decision Proposal 113 - Customer Data Payloads.pdf

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

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.

[SelenaLiuEA]

Good Afternoon,

EnergyAustralia’s initial comments on the Decision Proposal are set out below.

Basic Customer Data – Response payload:

• lastUpdated – is described as “The date and time that any data in this record was last updated by the customer.” The relevant updates are those done “by the customer” – would this cover data updates done by a retailer to correct data errors – i.e. delayed data input or corrections after reconciliation work done by a retailer?

• agentLastName - should be Optional instead of Mandatory or alternatively the description should make clear that the “Array is mandatory but may be empty”.

• agentRole – should be a free text field, please confirm if this is the case.

• organisationType – is Mandatory. It is possible that not all retailers will have this data for each business customer. Please add an “unspecified” response; or state that the “Array is mandatory but may be empty”.

Detailed Customer Data – Response payload:

• emailAddresses – the email address that may be recorded against the account might be the customer’s/primary account holder’s email address, but it can also be a third parties’ email address (e.g. State trustee or authorised representative/additional account holder) – Please clarify if these would be valid responses, and if there are multiple emails, which email should be used. Also, some email addresses may not be a personal email address, but a shared inbox, will these be appropriate? We suggest the description should clarify these matters.

• physicalAddresses – please clarify what Registered and Mail are referring to.

• purpose (relating to physicalAdress) – Description should include Unspecified.

• addressUType – we agree with the flexible approach to allow Simple or PAF address formats.

• lastUpdated, agentLastName, agent role, organisationType – Same comments as above.

Regards,
Selena

[benjerm]

Hello

ERM’s initial comments on the Decision Proposal are set out below.

We support the approach of having a standard structure for all industries for customer data. However, given the level of optionality, it is questionable how useful this payload would be or how it would be used.

All Payloads:

• lastUpdated – it was not understood how this field would be used if the field is optional. However, there is no way ERM systems could currently differentiate a “customer driven” change versus a business driven change.
• organisationType – It is not clear in the documentation. Is “Other” an option in the Enum. Classifying all customer records before making them available via the CDR may not be viable, so a default or unspecified option is required.
• organisation - No organisation email or phone contact information is provided. In practice, this information is often available. Would there be value in adding these fields?

Note that on page 3 the Recommendation references “NMI Standing Data” while actually being in relation to “Customer Data”.

Kind Regards
Ben

[Mark-Lee-Momentum-Energy]

Hello,

Momentum Energy's feedback is provided below.

Detailed Customer Data payload:

• phoneNumbers: number & fullNumber fields - Why are both of these mandatory? Shouldn't it be one or the other?

• phoneNumbers: number - Does this accommodate for organisations that store phone number in a single free-text field (e.g.: "+61 (0)3 9400 0000")?

• phoneNumbers: fullNumber - If this field stays mandatory, organisations that don’t currently store phone numbers in the proposed format may be required to:
  - Change data structures in their IT systems, which may come at considerable cost; and:
  - Cleanse existing data, which may also come at considerable cost.
  Suggest that one of number or fullNumber must be provided (similar to how a 'simple' or 'paf' address must be provided).

Common Object Types: PAF Address Type:

• lotNumber - This field type is PositiveInteger. Some properties span multiple lots, and need to be recorded as such (e.g.: lot "10-12"). Suggest changing this field type to String.

Kind regards,
Mark

[mannharleen]

Origin Energy does not have any specific comments for DP113.

[CDR-API-Stream]

Feedback on this consultation is now being closed. Extra time was given due to the delayed workshop held last week so that any additional comments arising from the workshop could be captured.

Responses to the feedback given above will be provided shortly.

[CDR-API-Stream]

In response to EnergyAustrali's feedback posted by @SelenaLiuEA:

• lastUpdated – is described as “The date and time that any data in this record was last updated by the customer.” The relevant updates are those done “by the customer” – would this cover data updates done by a retailer to correct data errors – i.e. delayed data input or corrections after reconciliation work done by a retailer?

Any change or correction to the data payload initiated by a customer should result in this field being updated. The field is an indication of the last time the record was touched to correct or update data but it isn't designed to capture the the last time a customer manually edited the data specifically. If the correction is delayed due to batch but was in response to customer action or if a reconciliation is made with other data also provided by the customer in another context then the field should be updated.

The intent of this field is to indicating the level of currency of data as far as the customer is concerned to the recipient. This can then be used for a variety of use cases such as offering a choice to the customer to validate the data if it is considered to be aged.

• agentLastName - should be Optional instead of Mandatory or alternatively the description should make clear that the “Array is mandatory but may be empty”.

The name of the agent is required unless there is a valid scenario when this cannot be done (in which case a default name should be provided). For agents with only a single name the last name field is to be populated.

• agentRole – should be a free text field, please confirm if this is the case

Yes, this is a free text field as far as the standards are concerned (no specific enumeration or field format is specified).
.

• organisationType – is Mandatory. It is possible that not all retailers will have this data for each business customer. Please add an “unspecified” response; or state that the “Array is mandatory but may be empty”.

organisationType is not an array so the suggested description cannot be provided but the addition of an UNSPECIFIED or UNKNOWN enumeration field may be considered for addition.

• emailAddresses – the email address that may be recorded against the account might be the customer’s/primary account holder’s email address, but it can also be a third parties’ email address (e.g. State trustee or authorised representative/additional account holder) – Please clarify if these would be valid responses, and if there are multiple emails, which email should be used. Also, some email addresses may not be a personal email address, but a shared inbox, will these be appropriate? We suggest the description should clarify these matters.

The context here is that the customer, who has entered this data and has the right to share the data they have entered, has specifically requested that their data be shared. Email addresses, like other contact information, is on a specific consent scope. Note this context, the answer to the question is that the information should be shared without filtering.

• physicalAddresses – please clarify what Registered and Mail are referring to.

REGISTERED is a synonym for primary or legal in this context. It is the current primary address. It is the actual address of the customer as opposed to an optional address for a specific purpose (which is what the other options specify).

• purpose (relating to physicalAdress) – Description should include Unspecified.

If unspecified then REGISTERED or OTHER should be used depending on whether the address is the current primary address used by the Retailer or not.

[CDR-API-Stream]

In response to @benjerm:

We support the approach of having a standard structure for all industries for customer data. However, given the level of optionality, it is questionable how useful this payload would be or how it would be used.

Note that optional indicates that a field, in valid circumstances, may not be held by the data holder and therefore cannot be presented. It does not mean the field can be optionally implemented by the data holder. If they have the data then they must present it. If the data holder does not have a data field they cannot manufacture it.

• lastUpdated – it was not understood how this field would be used if the field is optional. However, there is no way ERM systems could currently differentiate a “customer driven” change versus a business driven change.

If ERM has no process by which customer data is modified without the customer's consent then all changes will be customer driven. The field is optional because some data holders do not, unfortunately, retain change history for customer records at all.

• organisationType – It is not clear in the documentation. Is “Other” an option in the Enum. Classifying all customer records before making them available via the CDR may not be viable, so a default or unspecified option is required.

Yes. The absence of a bullet point on the second occurrence is a typo in the proposal document. As stated in the previous response to EA an UNKNOWN value for the enum will be considered.

• organisation - No organisation email or phone contact information is provided. In practice, this information is often available. Would there be value in adding these fields?

This is a good idea and will be considered for addition as optional fields.

Note that on page 3 the Recommendation references “NMI Standing Data” while actually being in relation to “Customer Data”.

Apologies, another typo.

[CDR-API-Stream]

Response to feedback provided by @Mark-Lee-Momentum-Energy:

• phoneNumbers: number & fullNumber fields - Why are both of these mandatory? Shouldn't it be one or the other?

The number field is expected to be a localisation and the fullNumber is expected to be fully qualified for international dialling. Both are inherently useful and can be derived by the data holder but not always by the data recipient.

• phoneNumbers: number - Does this accommodate for organisations that store phone number in a single free-text field (e.g.: "+61 (0)3 9400 0000")?

Yes, but this was previously discussed in the banking sector. If a phone number can't be parsed by the data holder into a standard phone format (with assumptions for state and country made) that can be used for dialling then it is essentially invalid data and should not be included in the result set as it cannot be used in automation.

• phoneNumbers: fullNumber - If this field stays mandatory, organisations that don’t currently store phone numbers in the proposed format may be required to:
  • Change data structures in their IT systems, which may come at considerable cost; and:
  • Cleanse existing data, which may also come at considerable cost.

Not necessarily. As stated above phone numbers that can be used for dialling can be easily reformatted into the required format with some minimal assumptions for state and country. This can be done at the time of the API call trivially so cleansing is not required.

• lotNumber - This field type is PositiveInteger. Some properties span multiple lots, and need to be recorded as such (e.g.: lot "10-12"). Suggest changing this field type to String.

This field is part of Australia Post's format for mailing and is not under the control of the CDR so we cannot alter it. If an address cannot be stored in PAF format then the SimpleAddress format is provided as an alternative.