Addition of LVR in the enumerated values list for constraintType

[NPBS-OBTeam]

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

DSB Proposed Solution

The current DSB proposal for this issue is in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/657#issuecomment-2387460603

[nils-work]

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]

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

[kristimoneycatcha]

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]

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]

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]

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

Value	Description	Use of additionalValue Field
MAX_LVR	A maximum LVR (Loan to Value Ratio) exists	The maximum LVR in RateString format
MIN_LVR	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]

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

[nils-work]

The DSB proposal has been referenced in the original post. As this would be a breaking change resulting in Get Product Detail v5, the DSB propose the FDO date Y25 #3: 2025-07-14.

[nils-work]

This has been staged - https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/462/files

[perlboy]

Curious why LVR_MAX and LVR_MIN were chosen when existing constraints use MAX/MIN as the prefix. Was there a desire to be deliberately inconsistent? Every other occurrence of enumerations prefixes with max/min not suffixes. This seems like a deliberate divergence for stylistic reasons at the cost of developer muscle memory.

[nils-work]

Apologies, the names should probably be swapped for consistency. The consistent format was noted originally, but changed when 'MIN' was proposed in addition. These can be aligned unless there are any concerns.

[nils-work]

The staged change has been updated - https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/462/files