Credit card loyalty program data: significant gaps and lack of structure

[af-stayorgo]

Description

Loyalty programs are one of the most important feature of credit card products, however the CDS does not currently include a structured way to accurately, completely or consistently describe these programs. Instead, data holders have attempted to partly describe these programs via free text fields, and in some case, the are not described at all.

By not including well structured and complete data on loyalty programs, the CDS data can not be reliably used to assess or compare the suitability of different credit card products, and material changes such as the devaluing of a loyalty program, may not be detected.

Specifically, issues with the current approach include:

1. The critical information (point currency, points earn rate, tiers and caps), sometimes included in the “additionalInfo” field, is not structured / machine readable
2. Program details have been omitted, for example, it may be noted that points are earned on 'everyday' or 'eligible' purchase, however definitions of such purchases are not included;
3. In some cases, information about introductory bonus points offers is omitted;
4. In some cases, data holders haven’t included any Loyalty Program information in their Product APIs, presumably because they consider it to be ‘optional’ data.
5. There is no information about the value of a points currency - for example, the number of points required to redeem a $100 gift card.

Area Affected

APIs such as "get product detail" and "get account detail", and schemas such as BankingProduct and BankingProductDetail.

Change Proposed

Given points-based Loyalty Programs dominate the credit card market, and are as important to many customers as the annual fee and interest rate, I recommend a separate schema is required, similar to the BankingProductDepositRate schema, to ensure well-structured and machine-readable information. Like annual fees and interest rates, this data should be mandatory, not options, give the materiality of the points earned by customers through such programs.

In addition to a schema for describing the ongoing function of a loyalty program, there should be a schema for describing the details of any introductory offer connected to the loyalty program (such as bonus points and the conditions attached to them).

[alex-histon]

Noting if proceeded with, this schema should not be mandatory - rather conditional, as not all DHs offer loyalty programs and not all card products participate.

[af-stayorgo]

Hi Alex - I'd suggest that it be mandatory for any credit card products that have a loyalty program, which is roughly 50% of all credit card accounts on issue. If a product doesn't have a loyalty program, then that should be clearly flagged with a relevant field (rather than it being unclear or ambiguous).

[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 has the following comments on the issues raised by @af-stayorgo:

• A number of Westpac group credit card products have multiple rewards programs available to customers. These variations are often marketed separately to consumers and have distinct additionalInfoURIs, fees and so on. Each customer account will only ever have one associated rewards program. It may be worth considering if flexibility to represent rewards point program variations as part of a single payload would be useful for data recipients.
• We do not recommend including an indicative dollar value for points. Although in principle of value for customers, valuation of points is not standardised or required across industries and the value and utility of points may depend on the context in which they are used. For example one rewards scheme might be favourable for the purchase of airline tickets and another might be favourable for the purchase of consumer electronics or groceries.

[commbankoss]

CBA requests that the DSB considers raising this issue as a separate Decision Proposal due to complexity arising from the multitude of loyalty program constructs within the banking sector, and the additional complexity that will be introduced as new sectors, many of which also have loyalty programs, are designated.

[nils-work]

As part of a backlog review in Maintenance Iteration 21, it was suggested that this issue could be closed.
If there are no further comments, this issue will be closed on 25 October 2024.

[af-stayorgo]

@nils-work - We raised this issue 4 years ago, and in the context of "consumer finance and borrowing", one of Treasury's three stated priority use cases, we believe this is still an important issue to resolve. It should therefore not be close until an adequate solution has been defined and implemented.

As noted above, many consumers choose a credit card based on its reward program - in fact roughly 50% of cards on issue offers rewards. For this reason, the data included in PRD on reward programs should be improved to help consumers better understand the value of such programs, and the trade-off they are making when choosing such a card, vs a lower cost option (i.e. lower fee and interest rate).

We'd be happy to propose a potential solution if that would be helpful. The goal here should be to include critical information required for consumer decision making, while also keeping it manageable for data holders.

I'd encourage this change to be considered as part of the broader DP338 set of changes.