Credit card balance plans and payment hierarchy: inadequate information within the CDS

[af-stayorgo]

Description

Credit cards include a variety of "balance plans" such as the "purchase plan", the "cash plan", the "balance transfer" plan, and "instalment plans". Each plan has its own interest rate and features such as interest free days, introductory interest rate periods, minimum repayment amounts, and instalment amounts. Additional each plan has a place in the "payment hierarchy" - i.e. the order in which a customer repayment is applied to reduce the balances of each plan.

Other details that are important:

• When a plan expires (e.g. ‘balance transfer plan’ or ‘instalment plan’), where will any remain balance be transferred to (usually the ‘purchase plan’ or the ‘cash plan’)?
• At what points in time were ‘interest free days’ on the ‘purchase plan’ available on the account, and are they available currently?
• Does having a Balance Transfer triggers ‘interest free days’ on the ‘purchase plan’ to be removed?

These details are fundamental to the accurate calculation of interest on a credit card, and the accurate comparison of different products, including the assessment of product suitability for any given customer.

Currently the CDR contains very little of the above mentioned information, and therefore it cannot be reliability used to evaluate or compare credit card products.

Please see the attached example for more detail.

Balance Plans and Payment Hierarchy Example.pdf

Area Affected

APIs such as 'get product detail' and 'get account detail', and schema such as BankingProduct and BankingProductDetail

Change Proposed

A potential solution to the above issues is to enhance the BankingBalance schema to allow for multiple ‘plans’ (in a similar way to how it currently allows for multiple ‘purses’ for multi-currency Travel Cards), as well as the BankingProductLendingRate schema (in a similar way to how it currently allows for multiple interest rate ‘tiers’). For example, adding a list of plans with the following fields to the appropriate schema:

• Plan Name
• Plan Type (e.g. Purchase, Cash Advance, Balance Transfer, Instalment Plan)
• Interest Rate
• Term
• Plan Creation Date
• Plan Expiry Date
• Payment Hierarchy Position
• Starting Balance
• Current Balance
• Instalment Amount
• Instalment Frequency

Additionally, an appropriate way to capture historical changes to a plan's "interest free" status is likely required.

[CDR-API-Stream]

This issue was discussed in the 7th maintenance iteration call: https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-7:-Agenda-&-Meeting-Notes-(19th-May-2021)#meeting-minutes

Participants agreed to prioritise this change request at the top of the backlog. It has been updated accordingly in the Banking Maintenance Kanban. The intention will be to address this issue once all in-flight iteration candidates have been dealt with. Time permitting, they will be consulted on during Iteration 7, otherwise they will form part of the scope for Iteration 8.

[WestpacOpenBanking]

Westpac requests 9 months lead time for any changes identified as part of this proposal or as part of issue #291. We recommend that DSB broadly consider loan products as part of this change product before identifying any of the required changes to the balances and account detail APIs.

In particular, a number of lending products, not just credit cards, may have accounts with multiple ‘sub-loans’. The Westpac Margin Loan is an example of a product of this type. For this product, different sub-loans may have different start dates, loan amounts, loan currencies, end dates and so on. Additionally it is possible for one or more sub-loans to be closed, but the loan account to still be open. The loan has an overall balance, but each individual sub-loan under a facility also has potentially distinct balances and interest rates. We have previously sought guidance via ZenDesk on providing balances and account detail for that product under the current standards.

Noting that some of the additions suggested by @af-stayorgo are already in the BankingLoanAccount definition, we suggest that the BankingAccountDetail object definition is changed to allow a list of BankingLoanAccount objects rather than one. This is similar to a previous change made for term deposits. Noting that BankingLoanAccount objects may need to be linked to the sub-loan balances, we are supportive of extending the balance endpoint to support multiple loan balances for a single account.

We also remark that the order of application of payments for balance plans, for most institutions, requires balances to be paid off in the order of the annual percentage rate they attract from highest to lowest – this has been required by legislation for new accounts since 1 July 2012. Hence. the inclusion of payment hierarchy information is likely of limited additional value for data recipients and customers in many cases. If included, we recommend that omission is taken to mean that balances will be paid off in the order of highest annual percentage rate to lowest.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration call.

The following considerations were discussed:

• Credit Cards balance plans have their own interest rate
• Cash advance rates don't typically have an interest free feature / rate
• Instalment plans are an array of different rates
• It's common for credit cards to have three or more balance plans for a loan
  • each has its own minimum repayment amount and payment date
• hierarchy in the balance plan interest rates will help to calculate payments
  • It was noted that existing legislation already requires banks to pay off balances with the highest interest rates first
  • In this respect, having a hierarchy may not be useful other than as a representation of that or combining similar rates within a single plan
  • May require hierarchy to be ordered by / nested by highest interest rate
• Noted that lendingRateType includes cash advance and purchase rates already but doesn't include balance transfer and instalment rate types
• Could represent balances similar to purses in the BankingBalance structure
• Lending rates need to reference or tie together to the balances so it is obvious what rate applies to which balance
• This may be done via a unique reference ID
• Balances should have a display name to represent the individual plans so ADRs can easily render them
• Similar issue to credit cards with home loans supporting a portfolio loan structure (e.g. overall rate + separate fixed and variable rates)

[commbankoss]

Like Westpac, CBA requests 9 months lead time for any changes identified as part of this proposal due to the technical complexities with making this data available.

[nils-work]

Hi @af-stayorgo The DSB is proposing this issue be addressed as part of Decision Proposal 306. Any feedback would be welcome.

[nils-work]

Hi @af-stayorgo

Structure for cardPlans has been included in the Get Account Detail enpoint in the Candidate Standards for Banking.

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