Additional credit card fields

[JohnHarrison-Truelayer]

Description

A number of details relating to credit card accounts are available in other open banking regiemes but not in Australia. The addition of these fields would support additional functionality across use cases such as personal finance management, card wallets, bill tracking and product comparison.

Area Affected

The BankingCreditCardAccount object definition

Change Proposed

• Add the following additional fields to BankingCreditCardAccount (set to mandatory or otherwise as appropriate):

Field	Type	Description	Comments
Card Network	enum	The card network.	Enumerated values may include: ‘VISA’, ‘MASTERCARD’ and ‘AMERICAN_EXPRESS’
Card Type	enum	Type of card	Enumerated values may include: ‘CREDIT’` or ‘CHARGE’
Name on card	string	The name on the credit card.
Card valid from	DateString	The date from which the card is valid
Card valid to	DateString	The valid to which the card is valid
Card issuer	string	The issuer of the credit card.	This may be different to the entity that the customer has the account with. For example a Woolworths credit card customer may have a credit card issued by Macquarie Bank Limited
Last statement date		The date that the last statement was issued
Credit limit		The credit limit of the credit card.

• Consider adding similar relevant information to the product reference data.
• These changes may best be considered in conjunction with those raised in Credit card balance plans and payment hierarchy: inadequate information within the CDS #292 and Credit card loyalty program data: significant gaps and lack of structure #291

[perlboy]

Card Validity Dates and Card Holder Names are subject to PCI obligations (https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf) and as such a large number of Banking Holders would be unable to comply because they are not PCI certified nor currently need to be (ie. the details are held on their behalf by a third party).

[RobHale-Truelayer]

Thanks for raising this point @perlboy - it's a great topic 👏

@JohnHarrison-Truelayer and I debated this at length and felt it was important to post. We're interested in prompting a healthy discussion to understand how the CDR data standards might safely navigate concerns and potential conflicts with standards such as PCI while remaining compliant. This seems like a good forum to explore such things.

Stepping back just a little and looking at CDR Schedule 2 part 2, there is a very strong correlation with PCI DSS. Of course, PCI compliance requires independent QSA review but arguably CDR has an equivalent via ASAE3150...

We're not suggesting including the PAN or the CVV here, but the additional proposed attributes would seem to enable powerful consumer benefits if we are able to get comfortable as an industry with their sharing. Somewhat ironically (and positively), providing secure access to this data may actually enable use cases that combat card and identity fraud.

• Having a card expiration date could support consumer nudges associated with up-coming card-based payments that would fail without attention
• Including the credit limit could help with alternate product guidance, debt consolidation, failed payment warnings
• Including name on card could assist with identify verification use cases, especially when combined with other data sources

PCI applies overseas and yet other geographies have managed to get comfortable. It would be great to challenge current thinking on the topic and hear from others what would need to be done in order to allow this.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call as part of finalising the list of iteration candidates. Because there are a large number of change requests affecting the same API endpoint as this issue it was agreed to consider this issue from Maintenance Iteration 12 onwards.

[nils-work]

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

[nils-work]

Hi @JohnHarrison-Truelayer

Additional card details have been specified in the Get Products, Get Product Detail and Get Account Detail endpoints in the Candidate Standards for Banking.

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

[joshuanicholson]

We'd like for this to be considered for inclusion at some point soon, as we have several business cases for accounting services to utilise some of this extra data. With PCI data, our primary task is to identify each card a transaction relates to. Consider an SME with a 'corporate card' and 30 staff members each with their card. For accounting purposes, the poor accountant/bookkeeper gets a dump of all transactions from all cards and cannot identify 'who (staff member)' charged the account. To achieve this the name or card number is not required (certainly nice to have) but any unique identifier for each card would achieve the result, a masked number with last four digits would be ideal.

[perlboy]

Many holders do not hold PANs locally and possibly can't because that requires PCI DSS and many holders do not meet this threshold (surprising but true) - which is why they outsource issuance and don't hold locally. I like the idea of a card number from @joshuanicholson though but I'm not sure if that is in many source systems but it'd neatly work around the PCI DSS problem.

I guess arguably a Standard could be made and for these organisations since they don't have the data they can't disclose it.

[joshuanicholson]

yeah @perlboy I think we will see a rather extreme range of possibilities from DH's in relation to this.

Having run this idea past a couple of DH's outside this forum, the idea of the masked card number was met with general positive feedback, as it was made available via IB. One DH noted it wasn't available, but they did have a unique account number which was used to identify each card, and this was even included on statements, so this was a number consumers could reference.

To take the harsh angle on this issue, many DH's offer a rather useful digital experience for each card holder, that is each card holder has their own login, each receives their own statement, has limits, abilities to export data etc. The current CDR experience is nothing like the digital experience offered to consumers. As such this issue is quite valid in requesting data to match the digital experience sold and promoted to business consumers.

I would suggest for an ADR to only ask for a card identifier on transactions is a significant concession to what actually should be provided per the "intention" of CDR.

[perlboy]

Hmm interesting, my personal experience has been the opposite @joshuanicholson. I've had 4 different credit cards from Top 10 banks, all with an additional card holders and the closest I've got to separation per card has been printed statements 🤮 . On the corporate card side it's been even worse with a "fake" card with a PAN being the master account (but no physical) for a sub account attached to the card itself.

Here's how a NAB corporate card looks, this has 1 physical card.

The real physical card gets the transactions first:

Then they get replicated into the "master" account (which doesn't have a physical card) roughly every few days and associated with the master accounts (fake) PAN:

I can imagine in CDR this would essentially show up as duplicated transactions on both "cards" which would be quite bad. The transaction count difference is also because paying the account off occurs via the master account and card fees for everything are put directly onto the master as well.