Interest paid at maturity guidance for applicationFrequency in BankingProductDepositRate

[anzbankau]

Description

Fixed term deposit products such as term deposits may have the interest payment paid at the end of the term (i.e., 'at maturity') or periodically e.g., monthly (as a cash flow or to benefit from compounding). Three usage patterns have been observed to present this information in the applicationFrequency property in BankingProductDepositRate:

1. null or excluded - meaning Not Applicable (in contrast to Unknown)
2. Matching the term e.g. 'P6M' for a 6 month term
3. Exceeding the term of a range e.g. 'P1Y' for a 6-7 month term

Note: Another approach is to match the maximum term e.g. 'P7M' for a 6-7 month term.

Proposal

1. null or excluded

Rationale

1. null is commonly used in computer systems to indicate the value is Unknown or Not Applicable. Excluding the property is equivalent to null, as per the Payload Conventions.
2. The property name applicationFrequency implies the interest rate is applied more than once during the term of the deposit, so it's not applicable to interest paid only at maturity
3. Providing the value of the additionalValue property (meaning 'The period of time fixed' for depositRateType of 'FIXED') as the value for applicationFrequency to align the single payment at maturity is redundant information
4. BankingProductRateTierV3, the object in the tiers[] property permits the term to be specified as a range (e.g., 6-7 months) to allow customers to align the cash flow with their requirements. The applicationFrequency property is elementary so a range can't be provided to align with the term - either in Get Product Detail or Get Account Detail.

Reference

Zendesk ticket 1960 listed in Q&A section of ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 1st of June 2023 and discussed in that call.

Area Affected

Schema:

• BankingProductDepositRate

This schema is incorporated in endpoints:

• Get Product Detail
• Get Account Detail

Change Proposed

Additional sentence appended to the description of applicationFrequency to clarify its usage:

Before:

The period after which the calculated amount(s) (see calculationFrequency) are 'applied' (i.e. debited or credited) to the account. Formatted according to ISO 8601 Durations (excludes recurrence syntax)

After (following style in standards)

The period after which the calculated amount(s) (see calculationFrequency) are 'applied' (i.e. debited or credited) to the account. Formatted according to ISO 8601 Durations (excludes recurrence syntax). If absent for a fixed-term deposit it indicates the calculated amount(s) are only applied at the end of the term i.e., at maturity.

Note: Bolding is only to highlight the additional text.

[anzbankau]

Nils,
While traditional fixed-term lending products tend to have monthly interest charges due to longer terms, new lending products may have shorter terms where interest is charged at the end of the term. Could you please consider whether similar guidance text should also be added to applicationFrequency in BankingProductLendingRate.
Thanks

[nils-work]

Hi @anzbankau

Thanks for this proposal. I've provided a summary below and an alternative which could apply to both the deposit and lending usage, for review and further feedback.

As you noted, this change could result in a different meaning being drawn from existing values, so I've marked this issue as a 'Breaking change'. As such, it may be preferable to incorporate this with the change proposed in #306 Decision Proposal 306 - Updates to Banking Product and Account Detail.

Current description:

The period after which the calculated amount(s) (see calculationFrequency) are 'applied' (i.e. debited or credited) to the account. Formatted according to ISO 8601 Durations (excludes recurrence syntax).

Proposed additional text:

If absent for a fixed-term deposit it indicates the calculated amount(s) are only applied at the end of the term i.e., at maturity.

Alternative additional text:

If not specified for a FIXED or INTRODUCTORY rate type, it indicates that the calculated amount(s) are only 'applied' at the end of the associated period.

[anzbankau]

Thanks for the suggestion @nils-work.

We agree that it's effectively a breaking change and agree with incorporating it in #306 Decision Proposal 306 - Updates to Banking Product and Account Detail rather than the current Maintenance Iteration (where it is now).

While the changes to 'not specified' and 'associated period' and removal of 'deposit' are sensible, could you please explain the addition of INTRODUCTORY? Do you have examples of applying a credit (or debit) interest at the end of an introductory/honeymoon period - current or future?

The 'fixed-term deposit' and 'end of the term i.e., at maturity' were included to provide guidance on how to represent term deposits paid (only) at maturity, which are common products/accounts. If you make the description more generic, the meaning is somewhat less clear. Are you averse to providing examples in property descriptions (in this case at-maturity term deposits) to provide more guidance?

[nils-work]

Hi @anzbankau

As an INTRODUCTORY rate also requires a period, I was thinking it may be applicable for a type of offer that only credits an account at the end of that period (and when certain criteria have been met, for example), but happy to be less specific and remove that part.

Would this be clearer?

The period after which the calculated amount(s) (see calculationFrequency) are 'applied' (i.e. debited or credited) to the account. Formatted according to ISO 8601 Durations (excludes recurrence syntax). If not specified for a FIXED rate type, it indicates that the calculated amount(s) are only 'applied' at the end of the associated period. e.g., TERM_DEPOSITS with interest paid only at maturity.

if you think it's appropriate, the lending version could substitute the example:

e.g., PERS_LOANS with interest charged only at maturity.

Happy for further feedback.

[anzbankau]

Hi @nils-work

We figured that INTRODUCTORY was included because it's the only other enumeration with a period, but, being an 'adjustment' type, it's likely be added to (i.e., layered on top of) a 'base' FIXED, VARIABLE etc. rate to which the applicationFrequency really applies.

We're happy with the Description you provided. However, while I'm personally a fan of using enumerations to be specific, using those from a different domain (BankingProductCategory) may cause confusion. And I suspect we'll need a new enumeration for short term loans or buy now, pay later schemes, so 'PERS_LOANS with interest charged only at maturity' may not make much sense in the traditional banking sense.

Perhaps 'term deposits' and 'short-term loans' would suffice.

[nils-work]

Hi @anzbankau

Seems like we're getting close, how about this?

The period after which the calculated amount(s) (see calculationFrequency) are 'applied' (i.e. debited or credited) to the account. Formatted according to ISO 8601 Durations (excludes recurrence syntax). If not specified for a FIXED rate type, it indicates that the calculated amount(s) are only 'applied' at the end of the associated period. e.g., term deposits with interest paid only at maturity.

The lending version could substitute the example:

e.g., short-term loans with interest charged only at maturity.

[anzbankau]

Thanks @nils-work.

ANZ agrees with your changes to the description for the applicationFrequency property in BankingProductDepositRate and BankingProductLendingRate. It addresses the entirety of this change proposal.

[nils-work]

This issue was discussed in the Maintenance Iteration (MI) call on 9 Aug 2023.

Key points from the discussion included:

• Concerns with conveying a certain meaning through a null value
• Potential opportunity to consider other scenarios which may be presented by Non-Bank Lending and 'Buy Now, Pay Later' products/accounts
• Whether, if an additional field was provided to give supporting detail, the applicationFrequency field description would still need to state that null implies that a frequency is not applicable (or that interest is only applied at maturity, as proposed), or if the field could simply remain optional, or if it could be made conditional based on the value of that new field
• A suggestion to add a [rate] applicationType field where applicationFrequency would be mandatory only if the value is PERIODIC. The enum suggestions included:
  • PERIODIC
  • UPFRONT
  • MATURITY
• As this issue is being treated as a breaking change, participants questioned whether the focus should be on providing the more specific field instead, for future flexibility
• DSB to consider the discussion held in the MI call and determine whether to continue with this proposal and/or raise a new CR for an additional field (e.g., applicationType)
• Suggestion that any change related to this proposal could be incorporated with future changes to the affected endpoints (for example, resulting from DP306)

[nils-work]

For reference, the change suggested in the previous comment - the addition of the applicationType field - is now demonstrated in the Candidate Standards for Banking Decision Proposal 306.

As this issue was determined to be a breaking change, it was considered along with related changes as part of DP306, as noted.

Further comments related to this request may now be made on Decision Proposal 338 which is seeking feedback on making the Candidate Standards binding.