Add structured fields for rate applicability

[nils-work]

Description

The Get Product Detail endpoint includes the BankingProductDepositRate and BankingProductLendingRate structures, which include BankingProductRateTier objects. The details in the tiers objects are expected to support querying and displaying detail about appropriate rates (and therefore products) based on structured criteria corresponding to the common data contained within them.

Within tiers are applicabilityConditions which may be expected to describe any conditions that need to be met in order to receive a respective deposit or lending rate, for example, a BONUS or DISCOUNT.

Some products in the Banking sector offer bonus or discounted rates only to new customers, or only for new accounts, but there is currently no structured way to indicate these common types of applicability requirements for a specific rate.

Area Affected

The options provided below are intended to apply to the Get Product Detail endpoint. The Get Account Detail endpoint currently incorporates the same schema that may be affected, but it is not the focus of this proposal.

Change Proposed

Incorporate a new rateApplicabilityType enum and additionalValue field similar to their use in BankingProductEligibility, to support indicating where a rate is only applicable to NEW_CUSTOMERS, NEW_ACCOUNTS or other common conditions that may apply to specific rates offered through a product.

Option 1. Add enum to the BankingProductRateCondition schema to make it similar to BankingProductDiscountEligibility. This would allow a single applicability value per rate tier, corresponding to the associated rate.

"applicabilityConditions": {
+   "rateApplicabilityType": "NEW_CUSTOMERS",
+   "additionalValue": "string",
    "additionalInfo": "string",
    "additionalInfoUri": "string"
}

Option 2. Add enum and also make BankingProductRateCondition an array. This would allow a combination, or specialisations of applicability types to correspond to a rate tier.

-"applicabilityConditions": {
+"applicabilityConditions": [{
+   "rateApplicabilityType": "NEW_CUSTOMERS",
+   "additionalValue": "string",
    "additionalInfo": "string",
    "additionalInfoUri": "string"
}
+]

Option 3. Add an applicability array structure to the 'rate' objects (one level above tiers) to make them similar to BankingProductFee, which includes eligibility details for a fee discount through BankingProductDiscount. This would allow a combination, or specialisations of applicability types to correspond to the associated rate, separate to the tier structure.

"depositRates": [{
        "depositRateType": "BONUS",
        "rate": "string",
        "calculationFrequency": "string",
        "applicationFrequency": "string",
        "tiers": [{
                "name": "string",
                "unitOfMeasure": "DAY",
                "minimumValue": 0,
                "maximumValue": 0,
                "rateApplicationMethod": "PER_TIER",
                "applicabilityConditions": {
                    "additionalInfo": "string",
                    "additionalInfoUri": "string"
                },
                "additionalInfo": "string",
                "additionalInfoUri": "string"
            }
        ],
+       "rateApplicability": [{
+               "rateApplicabilityType": "NEW_CUSTOMERS",
+               "additionalValue": "string",
+               "additionalInfo": "string",
+               "additionalInfoUri": "string"
+           }
+       ]
        "additionalValue": "string",
        "additionalInfo": "string",
        "additionalInfoUri": "string"
    }
]

Option 4. A combination of Options 1 and 3, or Options 2 and 3. This may allow the applicability to be defined at either or both levels depending on requirements.

[nils-work]

The DSB is proposing this issue be addressed as part of Decision Proposal 306. Any feedback would be welcome.

[af-stayorgo]

Please also consider that "new customer" is often defined as new to the banking group (e.g. Westpac Group = Westpac, St George, Bank or Melbourne, BankSA, RAMS). Almost all banking groups apply such conditions on acquisition offers. Ideally this would be captured in the structured data, not an unstructured text field.

[af-stayorgo]

I'd also recommend that this change solves for offers that are limited to "existing customers" only, and also "online" only. There are a number of examples of such offer currently in market, including Westpac and St George Term Deposits which have a 'Special Offer' for existing customers, plus a 0.10% p.a. bonus when the TD is opened or renewed online.

Importantly, sometimes these offers can be combined, such as these Westpac and St George.

https://www.westpac.com.au/personal-banking/bank-accounts/term-deposit/

https://www.stgeorge.com.au/personal/bank-accounts/term-deposits

"Existing customer only" offers also appear across other products - e.g. Westpac has multiple special credit card offers for existing customers. Ideally this would be solved at the same time.

[nils-work]

Hi @af-stayorgo

In terms of the rateApplicabilityType being proposed, would these options accommodate those examples? Options 2 and 3 proposing an array would mean that these could be combined.

enum	Description (example)
NEW_CUST_TO_GROUP	New customer to a group of brands, or the legal entity
NEW_CUSTOMER*	New customer to a data holder brand
EXISTING_CUST*	Existing customers only
NEW_ACCOUNTS	New accounts or cards only
ONLINE_ONLY*	Originated or renewed online

* These are existing values inspired by EnergyPlanEligibility.

Regarding the fee example provided - "we'll waive your first year's card fee", that may better be described as a 100% discount on the fee, with discountType: ELIGIBILITY_ONLY and discountEligibilityType of OTHER (with "Existing customers only" in the additionalInfo field). If specifying EXISTING_CUST instead of OTHER for that example would be preferable, or if any of the other enums above should be considered for BankingProductEligibility and BankingProductDiscountEligibility please add a comment or raise a new issue. Thanks

[af-stayorgo]

Hi @nils-work - thanks for sharing the above.

Adding those enums to rateApplicabilityType would seem to address the current use cases. An array would be a better option, given this allows for combinations such as EXISTING_CUST & ONLINE_ONLY.

In terms of Option 2 vs 3, without having analysed this thoroughly, 3 would seem to be the better solution as there are sometimes multiple 'tier' objects within one rate (for example LVR + Lending Amount), where as the rate eligibility criteria (rateApplicability) applies to the combination of the tiers, not one tier alone.

For fee discounts, adding EXISTING_CUST as an enum option for discountEligiblityType would be sensible. Further, it may be sensible to include the other enums listed above as they are likely to come up as use cases at some point. This design, however, doesn't seem to allow for the combination of such conditions / enums (e.g. in an array, as proposed for rates), should that be required.

[nils-work]

Hi @af-stayorgo

As the eligibility property in BankingProductDiscount is an array, the discountEligibilityType values can be combined to refine the eligibility. That could be used to convey, for example, a requirement of EXISTING_CUST + ONLINE_ONLY.

[nils-work]

The applicabilityConditions fields have been updated in the Candidate Standards for Banking.

@af-stayorgo - detail from your comments (1, 2) has also been incorporated to support those scenarios.

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