search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

Addition of LVR in the enumerated values list for constraintType #657

Open NPBS-OBTeam opened 3 months ago

NPBS-OBTeam commented 3 months ago

Description

Our credit policy constrains the maximum LVR limit that we will accept in an application. This is displayed on our website. It is not specific to any particular home loan product or home loan interest rate. There is no current CONSTRAINT enum of LVR for us to be able to represent this in our Product Reference Data. We propose the addition of CONSTRAINT enum LVR. We note that this does match the proposal of DPs 306/338/387: Constraints are “only intended to provide details of constraints on application for the product”.

This could be met by the proposal within DPs 306/338/387 of an OTHER constraint type. However we understand product comparator ADRs require LVRs for their use case, and so we assume they would prefer an actual LVR constraint enum rather than us to use OTHER for this purpose.

LVR does exist as a variable within rate tiers, however the LVR in question is not a criteria for the available interest rate applicable to our products. Our interpretation of the BankingProductRateTierV3 Schema leads us to understand that a maximum LVR should only be included where that LVR is a criteria for the loan interest rate of that product specifically, in alignment with the Scheme description of ‘Defines the criteria and conditions for which a rate applies’. Where an LVR does impact available rates we have included these in the rate tier information.

Intention and Value of Change

The change would allow data holders to accurately reflect LVR product constraints within the CDR framework. This is needed to align to the information we provide on our website. It would allow ADRs to understand the application constraints on our home loan products.

Area Affected

GetProductDetail

Change Proposed

Addition of LVR in the enumerated values list for constraintType

nils-work commented 2 months ago

Hi @NPBS-OBTeam

It does seem like there could be a slight overlap with detail in rate tiers, but also that there could be value in defining a maximum LVR separately.

Would an additional constraintType like this be suitable?

Value Description Use of additionalValue Field
MAX_LVR A maximum LVR (Loan to Value Ratio) exists The maximum LVR in RateString format
NPBS-OBTeam commented 2 months ago

Yes, we agree with that mock up. Thank you.

kristimoneycatcha commented 1 month ago

Hi @nils-work

We think this is a good solution as well for instances where rates are not tiered based on LVRs.

However, in addition to MAX_LVR we would suggest included a MIN_LVR as well.

This is due to the wide variation observed in the way lenders are presenting their mortgage products in PRD after reviewing over 1,800 products.

Some lenders will break their products down by LVR and so in one product the LVR may be 0-60%, in another it may be >60-80%, etc. Including both MAX_LVR and MIN_LVR will provide a solution in these instances as well.

nils-work commented 1 month ago

Hi @kristimoneycatcha

Whether a Data Holder aggregates or disaggregates their products with different rates for different LVRs, it seems as though they both essentially have tiered rates (based on LVR). If Data Holders have difficulty including tier detail in the form specified, that could be seen as an implementation concern.

Providing the ability to specify LVR requirements in both rate tiers and constraints means clients need to check both places for that detail and deal with any discrepancy. Should the constraint detail prevail if there is a difference?

Do other participants have views on whether LVR min/max constraints should be added and how they may interact with LVR tier detail where available?

kristimoneycatcha commented 1 month ago

Hi @nils-work

Ideally if all rates in the product have the same LVR min and max values the min and max LVR would be specified in the constraints and there should be no need to use the LVR tier. However, if the rates in the product have different LVRs then the LVR tier would be specified for each rate and there should be no need to include LVR in constraints in this scenario.

Currently, we are sourcing LVR from multiple places in the products due to implementation discrepancies. There are a lot of products where the LVR is included only in the additionalInfo field, product name or productId with no LVR tier or constraint. We check about 5 or 6 different places for LVR information.

nils-work commented 1 month ago

Please provide feedback on support for this change, and the following suggested additions to the Product Constraint Types:

Value Description Use of additionalValue Field
LVR_MAX A maximum LVR (Loan to Value Ratio) exists The maximum LVR in RateString format
LVR_MIN A minimum LVR (Loan to Value Ratio) exists The minimum LVR in RateString format

This would require an update of the BankingProductConstraint schema and an increment of the Get Product Detail endpoint version.

kristimoneycatcha commented 2 weeks ago

Hi Nils,

We support this change.

Kind regards, Kristi.

On Wed, Oct 2, 2024 at 11:28 AM Nils Berge @.***> wrote:

Please provide feedback on support for this change, and the following suggested additions to the Product Constraint Types https://consumerdatastandardsaustralia.github.io/standards/index.html?examples#tocSproductconstrainttypedoc : Value Description Use of additionalValue Field LVR_MAX A maximum LVR (Loan to Value Ratio) exists The maximum LVR in RateString format LVR_MIN A minimum LVR (Loan to Value Ratio) exists The minimum LVR in RateString format

This would require an update of the BankingProductConstraint https://consumerdatastandardsaustralia.github.io/standards/index.html?examples#cdr-banking-api_schemas_tocSbankingproductconstraint schema and an increment of the Get Product Detail https://consumerdatastandardsaustralia.github.io/standards/index.html?examples#cdr-banking-api_get-product-detail endpoint version.

— Reply to this email directly, view it on GitHub https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/657#issuecomment-2387460603, or unsubscribe https://github.com/notifications/unsubscribe-auth/BLSAWN2JFCYT72V726I4K5LZZM44LAVCNFSM6AAAAABL3VQWG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBXGQ3DANRQGM . You are receiving this because you were mentioned.Message ID: <ConsumerDataStandardsAustralia/standards-maintenance/issues/657/2387460603 @github.com>

--

Regards,

Kristi Salmi

Head of Special Projects