Update CDS documentation to clarify expected rate value 'sign' (+/-) for each RateType

[af-stayorgo]

Description

The CDS documentation should be updated to clarify the expected rate value 'sign' (+/-) for each lendingRateType and depositRateType.

NOTE: the issue of which sign to use (+/-) was previously raised and resolved as part of DP306.

Intention and Value of Change

We are seeing some confusion across the industry regarding the expected 'sign' (+/-) that should be used for rate values associated with certain lendingRateTypes and depositRateTypes. For example, some data holders are using a negative sign for rates associated with the DISCOUNT lendingRateType, rather than the expected positive sign.

The consequences of this confusion are serious, specifically, its leading to errors in interest rates. Errors in interest rates make the data unusable, and if used risk misleading consumers.

Area Affected

The CDS documentation should be updated to clarify the expected rate value sign.

Change Proposed

Update the CDS documentation as follows:

• Product & Account Components section should be updated to clarify the expected rate value sign for each lendingRateType and depositRateType, in particular, the DISCOUNT, PENALTY and BONUS adjustment types.
• BankingProductLendingRate section should refer to the documentation about rate value sign.
• BankingProductDepositRate section should refer to the documentation about rate value sign.

DSB Proposed Solution

The current DSB proposal for this issue is in this comment.

[nils-work]

A solution to this issue could be to add clarifying text to the Description in the Adjustment Rate Types tables.
The tables below are to demonstrate the formula only and would not be added to the Standards.

1. For the Deposit Adjustment Rate Types 'bonus' values:

• BONUS
• BUNDLE_BONUS
• INTRODUCTORY

Append the text:

A deposit 'bonus' rate value MUST be specified as zero or a positive number in the RateString format. The formula to calculate an Effective rate would be (Base+Bonus).

Expected outcome (also current expectation):
This would have the following effect to positive and negative Deposit Base rates:

Deposit Base rate	Bonus (In favour of Depositor)	Effective rate (Base+Bonus)
2.0%	1.0%	3.0%
-0.5%	1.0%	0.5%

2. For the Lending Adjustment Rate Types 'discount' values:

• BUNDLE_DISCOUNT_FIXED
• BUNDLE_DISCOUNT_VARIABLE
• DISCOUNT
• INTRODUCTORY

Append the text:

A lending 'discount' rate value MUST be specified as zero or a positive number in the RateString format. The formula to calculate an Effective rate would be (Base−Discount).

Expected outcome (also current expectation):
This would have the following effect to positive and negative Lending Base rates:

Lending Base rate	Discount (In favour of Borrower)	Effective rate (Base−Discount)
3.0%	1.0%	2.0%
-0.5%	1.0%	-1.5%

3. For the Lending Adjustment Rate Types 'penalty' value:

• PENALTY

Append the text:

A lending 'penalty' rate value MUST be specified as zero or a positive number in the RateString format. The formula to calculate an Effective rate would be (Base+Penalty).

Expected outcome (also current expectation):
This would have the following effect to positive and negative Lending Base rates:

Lending Base rate	Penalty (In favour of Lender)	Effective rate (Base+Penalty)
3.0%	1.0%	4.0%
-0.5%	1.0%	0.5%

Please comment if there are any concerns with the above details or examples.

[cuctran-greatsouthernbank]

@nils-work the proposed change will be a breaking change for Great Southern Bank's current implementation. Our core banking system was designed long before CDR that the system has always calculated the net rate by the formula Net rate = Base rate + Margin. The margin can be either negative (i.e. a discount) or positive (i.e. a penalty).
This change request needs to be discussed further in details to understand the impact and any unintended consequences.
I am also interested in knowing if any other ADR see this as a problem and if an alternative solution can be explored to resolve this issue without creating a huge impact on Great Southern Bank.

[nils-work]

Hi @cuctran-greatsouthernbank

I believe the reason for this issue and the aim of the current proposal is to ensure consistency across Data Holder responses.

For that to be achieved, a level of transformation from what may be held in core systems across the sector could be expected. I don't think that implies your core system must be changed, but that will obviously depend on your implementation.

Is the requirement for a disclosed DISCOUNT rate value to be positive the only concern with the proposed change?
Your comment seems to suggest that a PENALTY rate is already positive in your system, which would be aligned.

[cuctran-greatsouthernbank]

@nils-work hi Nils. Yes the proposed change to enforce DISCOUNT rate value to be positive is the only concern we have. I am not sure why the calculation cannot be done at the ADR end with the use of absolute value as an example. That way, regardless of whether the DISCOUNT value is negative or positive, they will get the correct result. Unless this is the problem faced by all other ADRs and this change will deliver value for the whole ecosystem, we do not support it.

[nils-work]

Hi @cuctran-greatsouthernbank
Are you able to provide an example of what you would share and describe how an ADR would be expected to use it?

[cuctran-greatsouthernbank]

@nils-work the below is an example of our response for Get Product Details API for one of our products.

In the example below, the ADR is expected to calculate the net rate based on the base rate and the discount provided for the LVR under 70%. In general, the expectation is Net rate = Base rate + Discount/Penalty.

If the DISCOUNT value is negative and the ADR uses the calculation Net rate = Base rate - Discount, then maybe a formula of Net rate = Base rate - |Discount| can be explored?

"lendingRates": [
{
"lendingRateType": "VARIABLE",
"rate": "0.0843",
"comparisonRate": "0.0640",
"calculationFrequency": "P1D",
"applicationFrequency": "P1M",
"interestPaymentDue": "IN_ARREARS",
"repaymentType": "PRINCIPAL_AND_INTEREST",
"loanPurpose": "INVESTMENT",
"tiers": [
{
"name": "Basic Variable LVR <=70%",
"unitOfMeasure": "PERCENT",
"minimumValue": 0.00,
"maximumValue": 70.00,
"rateApplicationMethod": "WHOLE_BALANCE"
}
"lendingRateType": "DISCOUNT",
"rate": "-0.0209",
"calculationFrequency": "P1D",
"applicationFrequency": "P1M",
"interestPaymentDue": "IN_ARREARS",
"repaymentType": "PRINCIPAL_AND_INTEREST",
"loanPurpose": "INVESTMENT",
"tiers": [
{
"name": "Basic Variable LVR <=70%",
"unitOfMeasure": "PERCENT",
"minimumValue": 0.00,
"maximumValue": 70.00,
"rateApplicationMethod": "WHOLE_BALANCE"
}
],
"additionalValue": "A margin discount is a rate increment off the reference rate. The products reference rate less a margin discount determines a customer’s net interest rate.",
"additionalInfo": "Principal and Interest Repayment:70% maximum Loan to Value (LVR) ratio"

[nils-work]

Discussion on this issue on the Maintenance Call on 7th August noted:

• Apart from the comment above, no other Data Holders have raised a concern regarding the proposal.
• Data Recipients are in favour of consistency.
• A clearer description of the intended format would save current and future Data Recipients from applying custom code to handle different interpretations.

This change will be treated as non-breaking and no FDO will be specified, as:

• The intent of the change is only to provide clarity for an existing field,
• It seems most participants already follow the intended format,
• Any disclosures with different interpretations have already been live and recipients may currently be ignoring or handling these limited cases.

If there are concerns about compliance as a result of these or other matters, please refer to the ACCC and OAIC Compliance and Enforcement policy which sets out the general approach to CDR compliance and enforcement, and their strategic and risk based approach. Alternatively contact [email protected].

[nils-work]

This change has been staged for review.

[nils-work]

Incorporated into Standards v1.32.0.