-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BankingProductLendingRate - move properties Rate & ComparisonRate to RateTier #184
Comments
This looks related to #94. |
@markt-amp , the original standards had This proposal seems to include product sub-types (e.g. variable + P&I + investor, variable + P&I + owner-occupier) as the primary objects in the array with rates and tiers within them. This imposes a schema-based structure 'above' the rates and tiers rather than allow the data consumer to interpret the structure as they prefer based upon properties 'beneath' the rate. The proposal either forces a single tier object for simple rates or would require properties that have been 'pushed down' into the tier to be repeated at the sub-product level to allow the tier to be optional. Tiers are optional in the current standards because they are merely to qualify for the rate, not to specify the rate. Additional properties that may be required for |
Thanks for your constructive feedback @anzbankau - where the standards are now in v3 have already incorporated a With regards to this:
And this:
In practice, you'd no doubt agree that leaving lending rates subject to interpretation by a consumer for a mortgage are far more risky than deposit rates. Sure you could capture more information in |
The current standards are for flexibility and extensibility and shouldn't cause misinterpretation. The proposal is a structural change, 'inverting' the structure, but doesn't really change the content or reduce the risk of misinterpretation - especially with the example provided with a single tier for a single sub-product. It just has the potential to impose a data holder's product structure (e.g. a Variable Rate Home Loan) into sub-products on the data consumer. The objects in the proposed `lendingRate' array are sub-products represented by a combination of attributes values rather than rates. It's not obvious in the home loan example because they are one-to-one so data consumers can treat each sub-product with rates as a single object. In principle, if a three-level sub-product hierarchy was required (e.g. Variable > P&I|IO > Investment|Owner Occupied), the schema above the rate would require an additional level whereas the current standards allow data consumers to create a hierarchy from a 'flat' list of properties as they need it (e.g. Variable > Investment|Owner Occupied > P&I|IO). I'm using this just to emphasise the point about a sub-product > rate structure versus a rate > sub-product structure. Perhaps the more concrete problem with the proposal is that it doesn't support rates that apply to a combination of properties - the purpose of the tiers array property. The rate can't be at the tier level because it doesn't apply to one tier e.g.:
Could you please expand on this? How does the proposal solve this?
The LendingRate and DepositRate schema were different from the start in recognition of the different properties that determine the rates. The |
As this issue hasn't been proposed for consideration in maintenance iterations or had any further comments for three years, a summary and general guidance is provided below to foster any further feedback. If there are no further comments this issue will be regarded as a query with an answer provided and closed on 30 June 2023. The original issue suggests moving rate values from the top of the rate object, into the tiers array so each rate is at the same level as the tier, as described in the diff below. {
"productId": "string",
"lastUpdated": "string",
"productCategory": "RESIDENTIAL_MORTGAGES",
"name": "string",
"description": "string",
"brand": "string",
"isTailored": true,
"lendingRates": [{
"lendingRateType": "variable",
- "rate": "0.0459",
- "comparisonRate": "0.0462",
"repaymentType": "PRINCIPAL_AND_INTEREST",
"loanPurpose": "INVESTMENT",
"calculationFrequency": "P1D",
"applicationFrequency": "P1M",
"interestPaymentDue": "IN_ARREARS",
"tiers": [{
"name": "investor_lvr_0_100",
"unitOfMeasure": "DOLLAR",
"minimumValue": 0,
"maximumValue": 99999999,
+ "rate": "0.0459",
+ "comparisonRate": "0.0462",
"rateApplicationMethod": "WHOLE_BALANCE",
"applicabilityConditions": {
"additionalInfo": "Max LVR 90% + LMI",
"additionalInfoUri": "string"
}
}]
} There was feedback against this proposal, suggesting it changes the 'rate' (parent) -> 'tier' (child / details to qualify for the rate) relationship, noted in this comment:
As further demonstrated in the sample in the above comment, the purpose of Also as shown in that comment, a holder may specify multiple dimensions that a rate may be qualified against, using their own familiar naming convention to provide the labels (or 'keys') for a set of common
This convention is expected to enable the consolidation of the tier values matching the common key, to provide an interpretation like below:
The name of a tier may be any value, but it is expected to be most useful as a common key for all equivalent tiers based on the same dimension. In contrast, tier objects provided with unique names such as That approach may result in a more complex and repetitive interpretation of the rate detail, such as:
|
We appreciate your excellent guidance on the use of tiers, with good examples. Since the first version of the schema we considered proposing an additional |
Description
Mortgage products often use LVR based pricing with specific rates being applied to particular tiers of LVR. The current version of the standards results in repetition of data unnecessarily for the same product and leaves the API ambiguous by the presence/absence of BankingProductRateTier.
For mortgages this fundamentally means the creation of a rate and rate tier tier for each LVR level.
This same change could be adopted to DepositRates to support term deposits, but isn't being suggested in this change request.
Area Affected
Change Proposed
At the moment the standards represent the rate as applicable to LendingRate at the object level, we feel the rates would be better represented within the tier itself. This change proposal assumes that #48 is adopted
This change would:
Change details
BankingProductLendingRate
BankingProductRateTier
JSON tree
Current:
Proposed:
Payload samples
Current
Proposed
The text was updated successfully, but these errors were encountered: