Definition of PERCENT in BankingProductRateTierV3

[af-stayorgo]

Description

unitOfMeasure within BankingProductRateTierV3 can be PERCENT, however the standard is not clear as to how these percent values (i.e. minimumValue and maximumValue) should be formatted (i.e. should 90% be 0.9 or 90?). Based on the majority of data holders, we assume that 90 is the correct approach, however some data holders are using 0.9, which obviously creates risk that the data will be misrepresented. Can the CDS's documentation be updated to clarify the correct approach.

Area Affected

BankingProductRateTierV3

Change Proposed

Update the CDS documentation to make clear that 90% should be formatted as "90" rather than "0.9" within BankingProductRateTierV3 minimumValue and maximumValue.

[nils-work]

Hi @af-stayorgo

Thanks for raising this issue.

The expectation is that the PERCENT values would be provided consistently in the RateString style throughout the Standards.

For example, this would be consistent:

// 80-90% LVR
+ "unitOfMeasure": "PERCENT",
+ "minimumValue": 0.8,
+ "maximumValue": 0.9,

These would be inconsistent -

// 80-90% LVR
- "unitOfMeasure": "PERCENT",
- "minimumValue": 80,
- "maximumValue": 90,

// 0-90% LVR
- "unitOfMeasure": "PERCENT",
- "minimumValue": 0,
- "maximumValue": 90,

// >90% LVR (0 is not equivalent to null, and a maximum lower than the minimum would be invalid)
- "unitOfMeasure": "PERCENT",
- "minimumValue": 90,
- "maximumValue": 0,

// >90% LVR (0 is not equivalent to null, and a maximum lower than the minimum would be invalid)
- "unitOfMeasure": "PERCENT",
- "minimumValue": 0.9,
- "maximumValue": 0,

A statement could be added to the description of the minimumValue and maximumValue fields to clarify this, to the effect of:

Values associated with the PERCENT unitOfMeasure MUST be stated as a number in the RateString format.

It has also been noted that some Data Holders appear to provide a value of 0 to indicate that the maximumValue is not applicable, to imply no upper bound. This also appears to be inconsistent.

A further statement added to the maximumValue could clarify this:

Zero is not equivalent to null when indicating that maximumValue should be treated as absent.

Acknowledging that there may have been different interpretations of these field types, any clarification could be provided with future changes to the affected endpoints with an FDO.

A comment has also been added to the next Maintenance Iteration thread to review some incorrect labels in the descriptions of fields in this schema.

[af-stayorgo]

@nils-work - thanks for this clarification.

I can see the logic in align the approach with RateString, however this would mean that the vast majority of data holders are currently publishing LVR tiers in a non-compliant format (i.e. 90 rather than 0.9 to represent 90%).

Can you please confirm that this approach is final so we can advise our customers accordingly?

I'd recommend that a notice be issued to all data holders on this issue so they can correct their data, and the proposed statements above be added to the CDS as soon as possible.

[af-stayorgo]

@nils-work - can you please provide an update on this issue? Thanks

[anzbankau]

Hi @nils-work

Regarding:

A statement could be added to the description of the minimumValue and maximumValue fields to clarify this, to the effect of:

Values associated with the PERCENT unitOfMeasure MUST be stated as a number in the RateString format.

The BankingProductRateTierV3.unitOfMeasure is very literal, so the PERCENTAGE enum value means that pairings like minimumValue = 20 and maximumValue = 80 are read as 20% and 80%.

In contrast, the RateString data type is a general solution to ratios - that can also represent a percentage (by multiplying by 100) when viewed by a person (vs. in computer-to-computer interactions).

We don't believe any standardising on integer vs. decimal and the number of decimals is necessary when number conversion is so broadly supported by platforms, tools and languages. (While the Number data type has the Description "A standard floating point number. Can be positive, negative or zero", the examples include the integer 10, so perhaps the description needs to be expanded. Raised in holistic feedback: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/612#issuecomment-1749849269.)

[nils-work]

Hi @af-stayorgo, @anzbankau

A statement to clarify the position above has been provided in the Candidate Standards for Banking.

Consultation on making the Candidate Standards binding is now open through Decision Proposal 338.