Remove requirement for at least one address in physicalAddresses array

[JamesMBligh]

Description

As per this Support Portal article some scenarios have been raised where a physical address is held but is invalid and cannot be provided in a schema compliant manner. The physicalAddresses field requires at least one address, however.

The original intent of requiring at least one address was based on feedback that all valid banking customers are required to have at least one address and therefore making this mandatory requirement was valid. This did not take into account the possibility that the address may be held but the data might be invalid and not held in a fashion that is schema compliant or can be transformed into a schema compliant form.

Area Affected

The Customer Detail API.

Change Proposed

Remove the statement that at least one physical address must be included in the physicalAddresses array. Note that, under the definition of optionality in the standards, any valid address must still be returned so this would not create data holder discretion.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration call.

It is proposed to change the current text:

Must contain at least one address. One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail

To be:

One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail

This would create a breaking change because Data Holders may no longer return any physical addresses, or may return an empty array. Feedback is welcomed regarding obligation dates and implementation considerations.

[CDR-API-Stream]

Further to this, the Iteration call discussed whether a free form address format would be useful where data holders can't sufficiently represent structured addresses. For this change to be consulted on, the DSB requests a change request is raised for consideration during the iteration.

[PaulaAF11]

Thank you for the above information - Just wanted to confirm if there was any progress on this decision.

[PaulaAF11]

Hi can you please confirm if with this decision being made to remove the requirement that states that having at least one physical address must be present, that participants that do have this array empty and where ADRs see this array empty that it will not trigger a non-compliance action from the ADR? The assumption being that if the physical address is empty this is due to DH data issue and therefore not required?
Confirmation to ensure compliance where this requirement is relaxed is critical to the DH.

[CDR-API-Stream]

Hi @PaulaAF11, the change request has been discussed during maintenance iterations. The final consideration for discussion are the obligation dates given the change will be a breaking change to Data Recipients.

Generally the approach with changes through standards maintenance is that changes agreed by the community are summarised in a decision document taken to the Data Standards Chair at the conclusion of the iteration. Maintenance Iteration 9 is due to conclude community consultation on the 1st of December and it normally takes a week or two to take these decisions to the Chair for approval.

In regards to your question on non-compliance, this can be answered in three parts:

1. If the decision to allow for an empty list of physical addresses is approved you are syntactically compliant with the standards
2. If you have the data and it can be correctly conveyed in the data standards then you must provide it (it is not optional to choose if you omit valid physical addresses). This change will allow DHs that hold invalid address data to respond to the Customer API calls whilst remaining syntactically correct.
3. If you hold physical address data that cannot correctly be conveyed through the data standards (for example you are missing the State or you hold an invalid Australian postcode or suburb) then you should identify and seek to correct the data you hold. This is outside the API response compliance and feeds into your obligations for data quality. Refer to this change request: Align data quality NFR with Privacy Safeguard 11 #407

[CDR-API-Stream]

These changes have been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.15.0...maintenance/391

[CDR-API-Stream]

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.