Update guidance for Banking account rate detail

[nils-work]

Description

Guidance on the BankingAccountDetail schema provides statements relating to accounts with Single rate, multiple and tiered rates.
Participants have raised concerns that the guidance allows important fields relating to account rates to be omitted from responses.

Intention and Value of Change

To support rate analysis and comparison use cases, ensure all details relevant to deposit and lending rates are disclosed.

Area Affected

Although a change to the Standards is not being proposed, it is anticipated that a change to guidance related to the BankingAccountDetailV3 schema could have an impact on live implementations.

Change Proposed

To update the current guidance with the following edits, to clarify that the rate array structure is always required, even when describing only a single rate. This ensures the additional fields including calculationFrequency, applicationFrequency, repaymentType, loanPurpose and additionalValue are always disclosed where applicable.

Single rate, multiple and tiered rates:

• If a product only has a single applicable rate, the array is not required, and the single rate can be provided in the depositRate field or in the lendingRate, as applicable.
• If a product has multiple one or more applicable rates, such as tiered deposit rates, then both the array of rate detail and the single rate field are required. The Data Holder (DH) supplies the current effective rate in the depositRate field or in the lendingRate field, as applicable. The DH is expected to know the current effective rate. Clients can read the current effective rate directly, and are not required to parse the full array.

[NationalAustraliaBank]

Thank you and we appreciate the opportunity to respond to this issue. We would like to propose that the standards and guidance are not modified, as part of this change request, for the change suggested might not apply to all the Banking Scenarios specially wherein more than one rate applies to a given account and interest rate calculations are done with all applicable rates, so there would not be a single “effective rate” that a data holder holds. Therefore, for one or more applicable rates of a product, both the array of rate detail and/or the single rate field could be provided as applicable.

[nils-work]

Hi @NationalAustraliaBank

No change to the Standards has been proposed by this issue.

Are you able to provide an example demonstrating how a single effective rate could not be determined for an account where multiple rate components or tiers are applicable?

This issue is not proposing to change the existing expectation that a single effective rate can always be provided by the Data Holder according to the context of the account (depositRate or lendingRate).

The intent of this change is to clarify the expectation that even where an account only has a single applicable rate component, that the array structure providing the detail of that rate is always provided as well. The detail would include key fields such as depositRateType, lendingRateType, calculationFrequency, applicationFrequency, comparisonRate, interestPaymentDue, repaymentType, loanPurpose.

Statements indicating the intent of the single field have been part of longstanding guidance:

• Question: the customer is receiving different interest rates on their tiered balances. [...] How do we represent this?
  Answer: The BankingAccountDetail schema supports the full complexity available in Product Reference Data (PRD). It also includes an additional field that is supposed to indicate the current interest rate for this specific account at the time of the API call. This could be considered the 'effective' rate. Currently, you would do the calculation as you suggest and then provide that. The alternative is that every Accredited Data Recipient has to implement the onerous calculation you describe, in order to show the customer their current effective rate. As with much of the standards, the choices balance implementation costs and use, across all participants.

  Representing multiple or tiered rates in BankingAccountDetail

• The DH is expected to know the current effective rate. Clients can read the current effective rate directly, and are not required to parse the full array.

  Guidance on the BankingAccountDetail schema