RateString Examples

[wickhams1]

Hi,

I'm looking to confirm that the examples provided for RateString in the standards do align with the definition that has been provided:

To me it seems that the maximum and minimum values should be 1.0 and -1.0 respectively, but “12.3456789”
“-99.123456789123”
don't seem to align with that.

Thanks :)

[perlboy]

@wickhams1 Refer to #65. The limit of -100% to 100% was, against at least my opinion, removed in 1.1.0. I haven't checked recently but this had resulted in holder products which were previously non-conformant because they were specifying interest rates like 19.99 (1999% but intended to be 19.99%) now being conformant.

The minutes of the last sprint log indicated there was "no support" in the DSB Maintenance Iteration for the reimplementation, most probably because there is an insignificant number of recipients actually attending.

[anzbankau]

I can understand the lack of support for reasonable bounds in #65 as, while the right intention, it would be using data standards for 'guidance' when the description should provide sufficient guidance. The description is very clear so it would be hard to justify using percentage values in a rate property. It highlights the issue of how data standards are 'enforced' when reasonableness is required. Besides industry feedback/complaints mechanisms, reasonableness warnings would have to be incorporated into the CDS conformance suite when its main purpose is binary conformance/non-conformance.

[perlboy]

@anzbankau As I said at the time, if RateString describes nothing more or less of an AmountString or even a native number there is not a lot of reason for it to even exist. "Reasonable" is incredibly difficult for a small cap FinTech to argue with a billion dollar institution and "warnings" are not legally enforceable. The lack of guidance on this front defeats the purpose of this data type being specified.

[anzbankau]

@perlboy, RateString provides a more-restrictive domain with a clear description for guidance. Removing it would appear to be moving in the opposite direction to your previous posts (or, to put it colloquially, 'throwing the baby out with the bathwater'). I can understand your frustration with others misinterpreting (or not reading) the data standards though.

[perlboy]

@anzbankau It seems more likely that others wish they could load a Swagger definition with sufficient format/min/max definitions that their tools could use and enforce natively. While I accept a specific sentence describing an interest rate is useful it is a very weak solution to a very common problem. Also worth nothing is that the UK OB standards do specify this format as an explicit regexp pattern so, if anything, Australia has regressed.

[wickhams1]

Thanks for your responses, it does seem that his has previously been a discussion point.

@CDR-API-Stream in that case will the following statement in the description for RateString 'A rate of 100% would be represented by the value 1.0 and a rate of -100% by -1.0' be removed if is not a requirement?
It doesn't seem valid to have that statement if it's not binding, with the examples provided not aligning to this statement, as well as having it essentially invalidated by also stating in the description that there can be 'At least 1 and up to a total of 16 significant digits before decimal point'

[CDR-API-Stream]

Hi @wickhams1, the sentence in the description provides guidance on how a percentage would be represented as a decimal number. A standards change is not required in this instance.

[CDR-API-Stream]

This issue has been closed as per the Data Standards Maintenance process. No further questions or comments have been received since an answer was provided.