BankingProductLendingRateV2 - Lending Rates – FIXED/INTEREST_ONLY period end date cannot be determined

[ZacHortaraSherlok]

Description

When processing the data inside lendingRates for ”lendingRateType”: “FIXED”, we’re finding that the end date and start date of a fixed rate period in most circumstances cannot be calculated even when the additionalValue field has a valid period in it.

This occurs predominantly with loans with a originalStartDate greater than the fixed period. We most commonly see this issue occur with loans that have been established for 3 or more years.

We also experience this issue with loans that have an INTEREST_ONLY repaymentType. Which (so far) we have only seen null in additionalValue, and are unable to determine when the interest only period should finish.

Below is example data of a fixed rate loan we have encountered in which we’re able to determine that the loan is fixed for 2 years, but are unable to determine when the start/end date of the fixed period actually is and where we are within the fixed period.

{
  "data": {
    "accounts": [
      {
        "creationDate": "2015-08-31",
        "loan": {
          "originalStartDate": "2015-08-31", 
          "loanEndDate": "2045-08-28"
        },
        "lendingRates": [
          {
            "lendingRateType": "FIXED",
            "rate": "0.0534",
            "comparisonRate": null,
            "calculationFrequency": "P1D",
            "applicationFrequency": "P1M",
            "interestPaymentDue": "IN_ARREARS",
            "repaymentType": "PRINCIPAL_AND_INTEREST",
            "loanPurpose": "OWNER_OCCUPIED",
            "tiers": [],
            "additionalValue": "P24M",
            "additionalInfo": null,
            "additionalInfoUri": null
          }
        ]
      }
    ]
  }
}

In other circumstances, we have the period completely omitted for a fixed loan with interest only payments:

{
  "data": {
    "accounts": [
      {
        "creationDate": "2011-04-28",
        "loan": {
          "originalStartDate": "2011-04-28",
          "loanEndDate": "2049-12-31"
        },
        "lendingRates": [
          {
            "lendingRateType": "FIXED",
            "rate": "0.0741",
            "comparisonRate": null,
            "calculationFrequency": "P1D",
            "applicationFrequency": "P1M",
            "interestPaymentDue": "IN_ARREARS",
            "repaymentType": "INTEREST_ONLY",
            "loanPurpose": null,
            "tiers": [],
            "additionalValue": null,
            "additionalInfo": null,
            "additionalInfoUri": null
          }
        ]
      }
    ]
  }
}

The inability to accurately determine when a loan is expected to revert to variable/principal and interest repayments drastically affects our use case and diminishes the value we’re able to present to our customers. We're currently working around this by frequently retrieving and checking the data to determine if the loan has exited the fixed period, or if the interest only period has expired, creating unnecessary overhead and preventing us from providing an acceptable service to our customers.

Area Affected

The BankingProductLendingRateV2 object definition.

Change Proposed

We would like to request that a change be made to BankingProductLendingRateV2 for supporting defining a start and end date.

• These keys must be required for when a lendingRateType is one of the types that would have a period (e.g. INTRODUCTORY, FIXED, etc.), or if the repaymentType is INTEREST_ONLY. I'm making the assumption that it's not possible to have a BankingProductLendingRateV2 object that contradicts itself (e.g. fixed rate period that differs to the interest only period), in which a different approach would be in order.
• For the lendingRateType/repaymentType that do not have a period less than the life of the loan, these values should be an empty string and/or null.
• Ideal key names would be effectiveFrom and effectiveTo, with the dates being considered inclusive and aligning with the DateString format outlined in common field types. Using dates for the range allows us to avoid the issue where providers may be using P3Y and P1095D interchangeably, allowing us to avoid differences in determining the end date when leap years are covered in the period.

[ShaneDoolanFZ]

Adatree supports this change request. In order for CDR to provide material benefits to consumers then the ability for an accurate comparison of a consumer's current loan product to others in market is critical. "A better deal on your home loan" is a use case that is often touted as justification for the need for CDR to exist. If that is not possible with the current dataset then that is a major information gap.

[AdamGrockeSherlok]

Urgent to address this please as the home loan fix rate sumani is coming mid 2023 and we need to know the fixed rate loan expire dates.

[nils-work]

To provide a point of reference for the changes proposed in issue #567 and #569, please refer to the below payload sample based on the BankingAccountDetailV3 structure.

Issue #567 (this issue) is requesting rate start and end (or 'revert') dates to support product comparison.
Issue #569 describes a gap in knowing a 'revert product', but proposes the addition of revert rate start and end dates and a 'revertdiscountrate'. It was also suggested that the 'revertdiscountrate' may be less important than the actual revert rate.

• Option 1 provides two new date fields at the top of the BankingProductLendingRateV2 schema as proposed in both issues with different names. These would be new optional fields of DateString type.
• Option 2 provides a new enum value for the unitOfMeasure property in the BankingProductRateTierV3 schema as proposed in the 2nd call of MI 14. The Description of the unitOfMeasure field could explain that when the DATE value is provided, the minimumValue and maximumValue fields provide 'from' and 'to' dates expressed as the number of days since 1 January 1970.

Additional options and feedback would be welcome.

 1  {
 2      "accountId": "string",
 3      "creationDate": "2010-11-12",                                  // Account creation date (existing field)
 4      "displayName": "string",
 5      "accountOwnership": "UNKNOWN",
 6      "maskedNumber": "string",
 7      "productCategory": "RESIDENTIAL_MORTGAGES",
 8      "productName": "string",
 9      "specificAccountUType": "loan",
10      "loan": {
11          "originalStartDate": "2010-11-12",                         // Loan start date (existing field)
12          "loanEndDate": "2034-05-06",
13          "repaymentType": "PRINCIPAL_AND_INTEREST",
14          "repaymentFrequency": "string"
15      },
16      "lendingRate": "string",
17      "lendingRates": [{
18              "lendingRateType": "FIXED",                            // Fixed rate, defined as 24 months by additionalValue (existing field)
19              "rate": "0.0456",
20              "comparisonRate": null,
21              "calculationFrequency": "P1D",
22              "applicationFrequency": "P1M",
23              "interestPaymentDue": "IN_ARREARS",
24              "repaymentType": "PRINCIPAL_AND_INTEREST",
25              "loanPurpose": "OWNER_OCCUPIED",
26              // Option 1. Two new properties below. This is the proposed position and naming derived from #567 and #569
27              "rateEffectiveFrom OR revertstartdate": "2022-12-14",  // rateEffectiveFrom/To names could be appropriate for any rate
28              "rateEffectiveTo OR revertenddate": "2024-12-13",      // revertstartdate/enddate names would only be appropriate for a revert rate
29              "tiers": [{
30                      "name": "string",
31                      // Option 2. New unitOfMeasure enum 'DATE'. min/max fields express dates as the number of days since 1 Jan 1970 (field is 'Number' type)
32                      "unitOfMeasure": "DATE",
33                      "minimumValue": 19340,                         // Rate start date = 2022-12-14. minimumValue field is mandatory.
34                      "maximumValue": 20070,                         // Rate end date = 2024-12-13
35                      "rateApplicationMethod": "PER_TIER",
36                      "applicabilityConditions": {
37                          "additionalInfo": "string",
38                          "additionalInfoUri": "string"
39                      },
40                      "additionalInfo": "string",
41                      "additionalInfoUri": "string"
42                  }
43              ],
44              "additionalValue": "P24M",                             // The period of time fixed, starting 2022-12-14 (existing field)
45              "additionalInfo": "string",
46              "additionalInfoUri": "string"
47          }, {
48              "lendingRateType": "VARIABLE",                         // Variable rate with no end date defined, or until loanEndDate
49              "rate": "0.0567",                                      // Current variable rate for this product incorporating any applicable discount
50              "comparisonRate": null,
51              "calculationFrequency": "P1D",
52              "applicationFrequency": "P1M",
53              "interestPaymentDue": "IN_ARREARS",
54              "repaymentType": "PRINCIPAL_AND_INTEREST",
55              "loanPurpose": "OWNER_OCCUPIED",
56              // Option 1. Example with end date not defined
57              "rateEffectiveFrom OR revertstartdate": "2024-12-14",
58              "rateEffectiveTo OR revertenddate": null,              // End date not defined
59              "tiers": [{
60                      "name": "string",
61                      // Option 2. Example with end date not defined
62                      "unitOfMeasure": "DATE",
63                      "minimumValue": 20071,                         // Rate start date = 2024-12-14. The day after the above FIXED rate tier ends.
64                      "maximumValue": null,                          // End date not defined. maximumValue field is optional.
65                      "rateApplicationMethod": "PER_TIER",
66                      "applicabilityConditions": {
67                          "additionalInfo": "string",
68                          "additionalInfoUri": "string"
69                      },
70                      "additionalInfo": "string",
71                      "additionalInfoUri": "string"
72                  }
73              ],
74              "additionalValue": "string",
75              "additionalInfo": "string",
76              "additionalInfoUri": "string"
77          }
78      ]
79  }

[anzbankau]

We support Option 1.

Observations:

1. Option 1:
   a. 'Revert' applies to the end of one period (typically fixed rate before a variable rate period). It does not apply to the start of the first period nor the start of the next contiguous period. So revertStartDate is not appropriate.
   b. rateEffective is more general, so more in line with CDS principles i.e. more flexible/extensible.
   c. Appreciating that the sample JSON is also demonstrating the current structure, an interval in additionalValue (e.g. "P24M" in the first rate) would not be necessary/applicable as rateEffectiveFrom and rateEffectiveFrom define the period.
2. Option 2:
   a. minimumValue has type Number as this fits the common generic pattern of number + unit of measurement. Dates don't fit this pattern, whereas the existing date intervals (unitOfMeasure = 'DAY', 'MONTH') do.

[nils-work]

Following discussion in the MI call today and initial feedback provided (1, 2), the below example provides a third option to capture the rate discount which was noted as being significant for comparison use cases (1, 2).

• Option 3 provides the suggested lendingRateType enum of REVERT_RATE to avoid any conflict with other enum values that may be currently being used in additive or exclusive combinations, for example to avoid having both FIXED and VARIABLE types together, or a DISCOUNT rate with two VARIABLE rates (one to which the discount applies, plus one to describe the revert rate), even though the proposed 'effective' dates may help to differentiate. The REVERT_RATE type could be used to convey details of a rate that may be subsequent to a currently applicable personalised or offer rate. Once the 'revert' rate becomes effective, it may be expected that the lendingRateType for that revert rate would change to a standard VARIABLE type, for example. The rateDiscountFromBase field provides an indication of all discounts that apply (or applied ***) to the associated rate. The tiers structure in this option would not be changed from the existing schema.

*** Question re: lines 13 and 29 - Where a rateDiscountFromBase is provided, would participants expect this value to be as of 'now' (against a known base) or as of the start date of the FIXED rate term, for example?

 1  "lendingRates": [
 2      {
 3          "lendingRateType": "FIXED",           // A fixed rate currently in effect
 4          "rate": "0.0456",
 5          "comparisonRate": null,
 6          "calculationFrequency": "P1D",
 7          "applicationFrequency": "P1M",
 8          "interestPaymentDue": "IN_ARREARS",
 9          "repaymentType": "PRINCIPAL_AND_INTEREST",
10          "loanPurpose": "OWNER_OCCUPIED",
11          "rateEffectiveFrom": "2022-12-14",    // Rate start date. Preferred field name from Option 1 provided above
12          "rateEffectiveTo": "2024-12-13",      // Rate end date if applicable
13          "rateDiscountFromBase": "0.0234"      // Option 3 addition - new field to convey the level of discount incorporated into the 'rate' ***
14          "tiers": [],
15          "additionalValue": "P24M",
16          "additionalInfo": "string",
17          "additionalInfoUri": "string"
18      }, {
19          "lendingRateType": "REVERT_RATE",     // Option 3 - New enum only applicable when the current rate is expected to revert to another rate at a future date
20          "rate": "0.0456",                     // A revert rate is stated as of 'now' and may be different once it becomes effective (after the 'rateEffectiveFrom' date)
21          "comparisonRate": null,
22          "calculationFrequency": "P1D",
23          "applicationFrequency": "P1M",
24          "interestPaymentDue": "IN_ARREARS",
25          "repaymentType": "PRINCIPAL_AND_INTEREST",
26          "loanPurpose": "OWNER_OCCUPIED",
27          "rateEffectiveFrom": "2022-12-14",    // Rate start date (e.g., the day after the FIXED rate above ends)
28          "rateEffectiveTo": null,              // Rate end date not defined
29          "rateDiscountFromBase": "0.0123"      // Option 3 addition - new field to convey the level of discount incorporated into the 'rate' ***
30          "tiers": [],
31          "additionalValue": "string",
32          "additionalInfo": "string",
33          "additionalInfoUri": "string"
34      }
35  ]

[AdamGrockeSherlok]

We support Option 3 with an few changes.

Line 13 & 29 should reflect that the actually current discount that is currently applied rates and revert rates. This should correctly reflect what the DH has at that point in time and the customer will is receiving at that point in time. There is minimal value in knowing what it was in the past.

we propose a change from "rateDiscountFromBase" to "rateDiscountFromSVR" or "rateDiscountFromBenchmark"

we propose "rateSVR" or "rateBenchmark" to be included for each "lendingRateType". Wording to align with Discount wording.

[nils-work]

Thanks to those that have provided feedback on this issue so far.

As discussed in the MI calls, the lendingRates array is shared with the Get Product Detail endpoint.
As the extent of the desired change has become clearer, it is now felt that modifying the lendingRates array to hold a broader range of rate detail for an account in operation may not be ideal.

A new change request will be raised to propose an option for supporting the details suggested through a UType structure at the top level of the Banking Account Detail schema, possibly in the existing loan object, or through a new more specific object such as residentialMortgage.

The new issue will be prioritised in MI15, scheduled to start on 19th April 2023.

[nils-work]

Closing this maintenance issue, consultation will continue through Decision Proposal 306.