Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove requirement for at least one address in physicalAddresses array #391

Closed
JamesMBligh opened this issue Jun 16, 2021 · 7 comments
Closed

Comments

@JamesMBligh
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link

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

@PaulaAF11
Copy link

PaulaAF11 commented Nov 12, 2021

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
Copy link
Collaborator

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
Copy link
Collaborator

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

@CDR-API-Stream
Copy link
Collaborator

CDR-API-Stream commented Dec 23, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

3 participants