Product Reference Data - Residential Mortgage package discounts

[aj-mozo]

Further to Issue #282 there are also inconsistencies in how home loan package discounts have been represented in PRD. Of the 4 major banks, 2 present the net discounted rate in a separate product record, 1 presents the undiscounted rate and also shows the discount in a discount field, and the 4th presents the undiscounted rate and also shows the net-of-discount rate in a discount field.

So as well as this being an area of inconsistencies of the type discussed in #282, there are also additional problems:

• in the case of the 3rd bank there is no robust method to match up the rates and the rate discounts, leading the risk of error;
• in the case of the 4th bank the data does not comply with the standard and will result in significant error.

inconsistencies_in_cdr_get_product_details_HL.pdf

[perlboy]

@aj-mozo Specifically on this I confronted one of the holders in question during the Data Quality workshop on the use of discounts, indicated that I felt this was deliberate based on previous behaviours/data of their API, and received a snippy answer requesting I withdraw my comment, that they had implemented to the Standard and they believed they were accurate.

There is a significant power imbalance between Holders and Consumers, particularly of product data and the ACCC has elected to wait and see. Until they are held culpable (as you've requested in #286) I don't expect the behaviour to change.

With that said, I don't know if Mozo attended the workshop but I know that Finder and Choice (two advisory committee members) did not. Until comparison sites, particularly those sitting on the advisory committee, participate, there is little likelihood of seeing the status quo change.

[nils-work]

Hi @aj-mozo

Thanks for raising these observations.
It seems like they touch on similar points raised in Product Reference Data - major inconsistencies in Residential Mortgages #282.

As part of ongoing analysis, and related to the ACCC's recently published findings (Data Quality in the Consumer Data Right: Findings from Stakeholder Consultation), the DSB has published Guidance on BankingProductLendingRateV2 fields, as well as proposing a change to the Standards documentation to provide more consistent interpretation of rate types in Product Reference Data: Clarify Base and Adjustment Rate Types #585.

Issue #585 is a candidate in Maintenance Iteration 15 which is expected to conclude on 14 June 2023.

[nils-work]

Hi @aj-mozo
The DSB is proposing this issue be addressed as part of Decision Proposal 306. Any feedback would be welcome.

[af-stayorgo]

A broader issue with home loan interest rate discounts relates to 'index' or 'reference' rates. All lenders use the following method to calculate and set home loan rates: 'customer rate' = 'index rate' - 'discount'.

One existing PRD compliance issue across the industry is the absence of index rates in the PRD. Some banks have included them, but many haven't. Index rates are almost always published on bank websites and are certainly available digitally, therefore there's a requirement for them to be included in PRD. For the banks that are publishing their index rates, there should be specific lendingRateType ENUM, e.g. "INDEX" to help them be clearly identified.

And once index rates are reliably included, all other home loan rate types (including package rates) should be defined as a delta from their corresponding index rate. It may still make sense to include the 'all up rate', however clearly defining the relevant index rate and the margin off this index would better align with how rates are actually implemented and defined in T&Cs and loan documents.

Additionally, once index rates are included in PRD, a consumer, who knows their rate discount (e.g. by looking at their loan's letter of offer), will be able to easily determine their current rate using PRD.

Furthermore, interest rate data including in Get Account Details should including both the index rate and the discount off the index (and the 'all up rate' too, ideally). This is particularly important around the time of RBA rate changes when a bank may or many not have change their index rate. In this situation, know the customer's discount off index is critical to understanding their current deal.

[nils-work]

Hi @af-stayorgo

Regarding 'index' rates in PRD, if are you referring to a standard base VARIABLE rate, Standards v1.25.0 included a documentation change to clarify the rate types that describe what is a 'base' and an 'adjustment'.
I think you could consider a VARIABLE rate to be equivalent to an 'index' rate and INTRODUCTORY or BUNDLE_DISCOUNT_VARIABLE rates (for example) as discounts to be applied to that 'base' rate. Together, these should allow an 'all up rate' to be calculated.

Regarding Get Account Detail, I think the values you've suggested are covered in Decision Proposal 306 on page 10.
A new field called standardRate is what I think you're referring to as the 'index rate'.
Just below that field is also effectiveRate, which I think you've called the 'customer rate' or 'all up rate'.
There may be multiple discounts or penalties between the standardRate and the effectiveRate, and these would be found in the adjustments array which is shown on page 11.

Have I misunderstood, or would these clarifications and fields provide the necessary details?

[af-stayorgo]

Hi @nils-work

Thanks for calling out the documentation change - this appears to be a step in the right direction. We did notice this change recently, however it was not easy to find. I'd recommend calling the "base" and "adjustment" lendingRateTypes out more overtly in the BankingProductLendingRateV2 documentation. Ideally these would be including in the "Enumerated Values" table as a 3rd column.

Our observation, is that very few, if any banks are following this approach. For example most don't publish their home loan 'index' rates and instead publish their headline rates (which include a discount off the index) under the VARIABLE lendingRateType. And the few that are publishing index rates, aren't using the "Lending Adjustment Rate Types" to describe their headline rates.

The few banks that are using the "Lending Adjustment Rate Types" aren't using them as outline in the documentation.

Also, the current schema design has some issues that prevent these adjustments being used, for example, BUNDLE_DISCOUNT_FIXED states that additionalValue should be used for "The name of the bundle", however it should probably be used for the fixed rate term (e.g. P3Y) as it is for FIXED.

Regarding Get Account Detail, what you have described above seems to address the need.

[af-stayorgo]

Hi @nils-work

Further to the above, I want to flag another issue we have observed with the 'adjustment' lendingRateTypes, specifically, these 'adjustment' rates can make it difficult for data holders to publish comparison rates. A key issue is that the comparison rate can not be determined by adjusting the 'base' comparison rate by the same amount as the customer rate - this is because the comparison rate takes into account other factors, such as fees.

So even if there's a single 'adjustment' that applies across all rates within a product (e.g. 0.20% p.a. discount of fixed rates if you have the home loan package), the data holder must publish multiple 'adjustments' to accomodate the different comparison rate for every scenario. I don't think there's an easy way around this, however the need to handle comparison rates within these adjustments may need to be called out more clearly in the documentation.

A key issues is ambiguity as to whether the comparison rate included with the 'adjustment' rate should be an 'adjustment' to the base rate's comparison rate, or the 'all up' comparison rate. I'd suggest it be the 'all up' comparison rate.

[nils-work]

Hi @af-stayorgo

Re: your comment here about BUNDLE_DISCOUNT_FIXED, I thought there may be some value in providing an example of how the term/duration of a bundle discount could be described for reference and discussion - see comments in the example below. It's partly based on this guidance.

The comments highlight key parts, and I've left most properties as per the example code.
Apologies in advance for any inadvertent mistakes or incongruous values, this is pseudo-code only.
You may need to scroll sideways to see all the comment detail.

"lendingRates": [{
        "lendingRateType": "FIXED",
        "rate": "0.05", // 5% base fixed rate
        "comparisonRate": "string",
        "calculationFrequency": "string",
        "applicationFrequency": "string",
        "interestPaymentDue": "IN_ADVANCE",
        "repaymentType": "INTEREST_ONLY",
        "loanPurpose": "INVESTMENT",
        "additionalValue": "P2Y", // fixed rate for 2 years
        "additionalInfo": "string",
        "additionalInfoUri": "string"
    }, {
        "lendingRateType": "BUNDLE_DISCOUNT_FIXED",
        "rate": "0.01", // 1% discount from the base rate if product originated as a bundle
        "comparisonRate": "string",
        "calculationFrequency": "string",
        "applicationFrequency": "string",
        "interestPaymentDue": "IN_ADVANCE",
        "repaymentType": "INTEREST_ONLY",
        "loanPurpose": "INVESTMENT",
        "tiers": [{
                "name": "Bundle discount - Duration options",
                "unitOfMeasure": "DAY",
                "minimumValue": 0,
                "maximumValue": 90, // If the adjustment is not applicable for the full fixed term, tiers may be used to specify this discount rate from a possible range of duration options
                "rateApplicationMethod": "WHOLE_BALANCE",
                "applicabilityConditions": {
                    "additionalInfo": "When a fixed rate loan is opened as a bundle.",
                    "additionalInfoUri": "string"
                },
                "additionalInfo": "A discounted rate for 90 days.", // as specified in the tier detail
                "additionalInfoUri": "string"
            }, {
                "name": "Bundle discount - LVR options",
                "unitOfMeasure": "PERCENT",
                "minimumValue": 61,
                "maximumValue": 80, // other criteria may also specify the same discount rate
                "rateApplicationMethod": "WHOLE_BALANCE",
                "applicabilityConditions": {
                    "additionalInfo": "Requires LVR of 61-80% and loan opened as a bundle.",
                    "additionalInfoUri": "string"
                },
                "additionalInfo": "Discount available when LVR is 61-80%", // as specified in tier detail
                "additionalInfoUri": "string"
            }
        ],
        "additionalValue": "Online fixed rate loan bundle", // name of the bundle
        "additionalInfo": "The base fixed rate of this 61-80% LVR loan will be discounted by 1% for 90 days if opened as a bundle.", // can also be used to describe the discount duration and other details
        "additionalInfoUri": "string"
    }
]

Re: your comment about comparison rates, sorry if I have misinterpreted, but I think the expectation would be that the comparisonRate is only provided for relevant base rate types, and the value is independent (not necessarily calculated from, or by) any other adjustment rate values that may be shared.
Adjustments types would not be expected to have a value in the comparisonRate property.

[af-stayorgo]

@nils-work - thanks for sharing the above.

It might be worth setting up a call to work through some examples to ensure we are aligned on the problem and options to address.

The problems I'm seeing are:

• Comparison Rates: NCCP regulations state that interest rates for fixed term lending products (i.e. Home Loans, Personal Loans, etc) cannot be advertised without a comparison rate. This means there's little value in including a rate discount in PRD for these products if the comparison rate for the resulting discounted rate cannot be determined. Given the current 'lending adjustment rate types' schema doesn't offer a clear way to support comparison rates, it appears they can't be used for Home Loans, Personal Loans, etc. The only option lenders appear to have is to include all rates, including those with discounts, as 'lending base rate types' (i.e. "FIXED" and "VARIABLE") so that the comparison rate can be published. Accordingly, 'lending adjustment rate types' are not being used.

• Fixed Term Periods: In 'lending base rate types', additionalValue is being used to store fixed rate terms (e.g. "P2Y"), however, for 'adjustment rate types', its suggested that "tiers" be used. This inconsistent approach creates confusion for data holders and data recipients and will likely lead to ongoing data errors. I'd recommend that a consistent approach be developed and implemented as part of the next version of the standard, particularly given the importance and volume of Home Loan interest rates.

Hope this is clearer. Let me know if you'd like to find a time to discuss.

[nils-work]

Hi @aj-mozo, @af-stayorgo

The following fields (among others) have been added to the Candidate Standards for Banking -

• referenceRate
• comparisonRate
• adjustmentToBase
• adjustmentBundle

The 'adjustment' fields allow the additionalValue fields for adjustment rates to support term periods, in a way which is more aligned to other rate types.

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