ANZSIC Code multiple version support

[commbankoss]

Description

Currently the standards only support 1 version of ANZSIC codes.

Area Affected

The customer API

Change Proposed

Commonwealth Bank recommends adding support for multiple versions of the ANZSIC code. Data holders will be using a variety of code version and potentially not supporting the 2006 revisions.

[perlboy]

Is there instances where the ANZSIC code specified overlaps in newer versions with completely different definitions?

[anzbankau]

ANZ supports this proposal. It should be noted that the ANZSIC that may be returned (including the ANZSIC version from which it is selected) is that provided by the customer at that time, not what ANZ uses for risk management. The ANZ-internal ANZSIC is based upon ANZ's consideration of the dominant industry for which risk will be assessed based upon the full suite of information available to ANZ as part of lending facility assessments and on-going market reviews. The internal ANZSIC(s) (the customer may be in multiple industries with weighting) will be periodically reviewed and updated with the customer or as part of broader market reviews. In contrast, the customer's perceived/proposed industry is unlikely to change as there is no ANZ imperative to solicit this information from the customer.

[commbankoss]

Commonwealth Bank would also like to include the following change request, alongside the one above.

Description
The current standard only supports 1 version of occupation codes - the ANZSCO v1.2 codes.

Area Affected
The customer API

Change Proposed
Commonwealth Bank recommends adding support for multiple versions of Australian industry codes. Data holders will be using a variety of code versions and potentially may not support ANZSCO v1.2.

[perlboy]

Is there a proposed method of communicating to what version is being provided? As stated in #124 when we asked about presentation in February and didn't get a response Babelfish does not currently enforce any validity check on this field. If this is now being formalised we request the DSB also takes steps to ensure that the Register LegalEntity definition aligns.

[CDR-API-Stream]

Thanks all for the input. This issue is being considered within Maintenance Iteration 4.

@commbankoss is your proposal suggesting:

1. Updating the standards to accommodate the latest ANZSIC/ANZSCO standards,
2. A method to version ANZSIC/ANZSCO responses so it is understood which version is being applied for the ANZSIC/ANZSCO code, and
3. Allow DHs to support multiple simultaneous versions because DHs may be using different versions of the ANZSIC/ANZSCO codes based on the review cycle of their customer base
4. In effect, enable ADRs to know which version of the ANZSIC/ANZSCO standards are being used for the customer record

[CDR-API-Stream]

Hi @commbankoss and @anzbankau,

ANZSIC Codes

1. Can you please comment on what other versions of the ANZSIC standards you consider applicable here?
   • Noting that the intention of the ACDS is to cover all revisions of ANZSIC 1292.0
   • Noting that Proposal 026 referenced the use of the 2006 version due to ATO reporting obligations and the allowance for the value is optional

ANZSCO Codes
2. Regarding ANZSCO codes, it is proposed that the standards, at least, be updated to refer to ANZSCO 1220.0 document, not v1.2 which is a revision of the ANZSCO 2013 codes.

[anzbankau]

Hi @CDR-API-Stream ,

ANZSIC Codes

Just to restate from our earlier post, ANZ uses ANZSIC for internal risk management purposes based upon ANZ's assessment of a customer's industries and of their proportions - using (but not limited to) a customer's financial accounts. We do not consider a single ANZSIC (or combination of them) to be customer data. The version of ANZSIC used within ANZ can therefore change without impacting data sharing and can be extended to include additional industries and lower levels, and can even be restructured (not to say that we have).

To provide a customer's ANZSIC for data sharing would require new data to be collected and maintained, requiring new processes and system features. Periodic reviews reassess customers' industries for credit and market risk purposes, but there is no business imperative to capture or maintain a customer's stated industry(s). As such, ANZ is not intending to populate this optional property. The lack of an array for multiple industries and their proportions in the standards indicates that this is simply the customer's view of their dominant industry.

We support @commbankoss 's proposal on the basis that if we were to populate CommonOrganisation.industryCode in the future, an accompanying version property would provide the context necessary to interpret the ANZSIC code as it defines the domain of valid values.

ANZSCO
ANZ will not be providing CommonPerson.occupationCode as our data does not conform to the ANZSCO v1.2 standard occupation classification.

Ideally, all data holders (including many more in the future) would have their business processes and systems on the same version of ANZSCO (and ANZSIC), but this would be difficult to achieve. And using an old version would force DHs on later versions to translate codes to earlier versions, which is non-trivial when destructive changes are made. As for ANZSIC, an accompanying version property would provide the context necessary to interpret the ANZSCO as it defines the domain of valid values.

[commbankoss]

Thanks for the response @CDR-API-Stream. We currently have date with the following versions: industry codes version ANZSIC 1993, and occupation codes version ASCO 1986. Mapping these to the currently supported versions is non-trivial, and will introduce errors.
We propose the following options to address the issue:

1. Add support in the standards for multiple versions, including:
   1. Industry codes: ANZSIC 1993
   2. Occupation codes: ASCO 1986
2. No change; currently the fields are optional, and while we prefer to have the ability to provide the data, it's not mandatory to provide these fields

[CDR-API-Stream]

Hi @commbankoss and @anzbankau thanks for the feedback.

To summarise the options identified so far:

1. Update ANZSCO / ANZSIC references to refer to the standards catalogue number. This baselines industry codes at ANZSIC 1292.0 (2006) and ANZSCO 1220.0 (2013) and implies support of minor versions to each. This is in effect "no change" but clarifies the existing data standards. (CBA Option 2)
2. Support historical versions of both standards with the addition of an additional version field denoting which version of each standard is applied. This could default to baselined versions. (CBA Option 1)

[perlboy]

1. Update ANZSCO / ANZSIC references to refer to the standards catalogue number. This baselines industry codes at ANZSIC 1292.0 (2006) and ANZSCO 1220.0 (2013) and implies support of minor versions to each. This is in effect "no change" but clarifies the existing data standards. (CBA Option 2)

Isn't the challenge with this option that if it is present an ADR cannot determine from what respective catalogue version it comes from and Data Holders are aligned (if at all) with different versions meaning alignment is impossible?

[CDR-API-Stream]

Thanks @perlboy this is a good point. This change request was discussed in the maintenance iteration call: https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-4:-Iteration-checkpoint:-Agenda-&-Meeting-Notes-(5th-August-2020)

The intention is not to support legacy versions for these codes. In this case, a baseline version for ANZSCO and ANZSIC should be established with an optional version field i.e. industryCodeVersion and occupationCodeVersion.

The expected baseline:

• ANZSCO(1220.0) 2013 v1.2
• ANZSIC (1292.0) 2006 v2.0

If no version is provided for the industry or occupation codes, then the baseline version would apply. Noting that @commbankoss has older versions, the DSB is interested in input from ADRs on the utility of those older versions. It would not be expected that ASCO codes would be supported.

ANZSCO Versions:

{
  ANZSCO_1220.0_2013_V1.3,
  ANZSCO_1220.0_2013_V1.2
}

ANZSIC Versions:

{
  ANZSIC_1292.0_2006_V2.0,
  ANZSIC_1292.0_2006_V1.0
}

[perlboy]

Noting that @commbankoss has older versions, the DSB is interested in input from ADRs on the utility of those older versions.

It seems likely that Tier 2/3's will have a variety of versions as well, like the Standards themselves it seems unlikely that all Holders will ever be aligned and this is particularly the case for CommonPerson which will presumably impact energy industry as well.

As such we would prefer if the proposed industryCodeVersion and occupationCodeVersion were made mandatory when field present (similar to additionalValue based on type) with an explicit set of enumerations (ie. all available versions of SCO and SIC) such that we can cross reference these versions during validation. There seems little reason why Holders cannot specify the source version in use at the same time as they are populating the value. This provides explicit guidance (rather than softly inferred) as to what version the data is intended to be alleviating the relatively high probability of overlapping codes with assumed version.

With regards to the utility of these for ADR's, feedback we have received is that the ANZSCO field is helpful for credit risk calculations when considered in the context of high risk industries and likelihood of a life changing event impacting repayment capabilities. In the long run it is also useful for insurance purposes although, as some of the holders have already noted, this value is often self nominated so the value of it in this sector may not be worth it.

For ANZSIC the most notable feedback we have received regarding this field is that it is useful for filtering a client list based on feedback of focus industries from the ATO. For instance, if the ATO makes it known they are focusing on IT Contracting arrangements business advisory and accounting firms have, using manual record keeping, targeted their client base based on the industries being targeted upstream.

[CDR-API-Stream]

Making industryCodeVersion and occupationCodeVersion mandatory when the associated field is present is a reasonable suggestion which will be accepted.

[CDR-API-Stream]

A change to the data standards was approved by the Data Standards Chair for inclusion in v1.5.0.

This issue will be closed accordingly.