Feedback received on Conclusions Paper: The Australian Debit Card Market: Default Settings and Tokenisation

In September 2023 the Bank published a Conclusions Paper: ‘The Australian Debit Card Market: Default Settings and Tokenisation’, which included the Bank’s draft set of expectations for the industry relating to the tokenisation of payment cards and the storage of sensitive card details. Payments industry stakeholders were invited to provide feedback on these expectations, as well as the appropriate scope of cards to be covered by the expectations, particularly whether they should apply to prepaid and charge cards. Following this process, the Bank published its Expectations for Tokenisation of Payment Cards and Storage of PANs.

Feedback

The Bank received feedback from 10 stakeholders, which has been broadly supportive of the draft expectations. In particular, most stakeholders were supportive of the Bank’s proposal not to expect the industry to adopt network tokens and instead to allow merchants and providers to continue storing sensitive card information (including primary account numbers (PANs)), provided they meet a minimum security requirement.^[1] One stakeholder highlighted the benefit of using PANs as a backup option in situations where a tokenised transaction fails. These stakeholders argued that the minimum security requirement should align with the Payment Card Industry Data Security Standard (PCI-DSS), highlighting that it is global best practice and sufficiently stringent.^[2] Accordingly, these stakeholders sought clarity on what additional requirements the Bank envisaged might be imposed on top of the PCI-DSS and how they would be enforced. One stakeholder raised concerns regarding how the Bank might monitor and enforce compliance with this expectation, as well as the Bank’s other proposed expectations.

By contrast, a few stakeholders continued to argue that the Bank should push the industry towards network tokenisation, and so prevent the storage of sensitive card information by merchants and their providers. One stakeholder noted that, while mandating a minimum security requirement for merchants and providers would enhance the security of PAN storage, these data could still be stolen and used for fraud (unlike network tokens, which effectively would be useless if stolen as they are encrypted and do not contain sensitive card information). Another stakeholder also noted that solutions for token portability and synchronisation, particularly the required data sharing between parties to facilitate them, would be less secure and standardised than the scheme services that are already available (or would become available in coming years). This stakeholder suggested the Bank should instead encourage use of the existing ‘Click to Pay’ system which effectively operates as a scheme-agnostic digital wallet and already supports token portability and synchronisation.

With the change to allow merchants and providers to retain PANs – provided minimum security requirements are met – some stakeholders were not supportive of the expectation that the Payment Account Reference (PAR) should be widely shared and used throughout the payments ecosystem to link multiple tokens and aid token synchronicity. These stakeholders noted that PANs offer the same functionality as PARs in this case, such that PARs would be largely redundant (except for merchants that do not meet required security requirements). Some stakeholders also suggested that token synchronisation solutions already existed and were functional without the use of a PAR.

Some stakeholders noted that additional clarity could be provided with regards to some of the expectations. On the expectation regarding the rollout of eftpos’ eCommerce tokenisation service by the end of March 2024, one stakeholder sought clarity on whether this initial offering would include functionalities to meet the Bank’s expectations on token portability and token synchronisation. Noting this, some stakeholders highlighted that the deadline of the end of June 2025 for the removal of PANs should be conditional on fully functional tokenisation services being available, including the availability of robust and viable token portability solutions.

Some stakeholders expressed support for the Bank’s expectations applying to payment cards in general – notably credit and charge cards in addition to debit cards - provided it was technically and practically feasible to do so. These stakeholders suggested that prepaid cards should not be subject to the expectations, highlighting that it was not practical for single-load cards (such as gift cards), because a consumer is likely to use the card at a single merchant only and the merchant is unlikely to retain the card on file. One stakeholder also noted that prepaid cards are mostly issued by smaller issuers and account for a small share of card transactions, and so it would be more beneficial to focus industry efforts on the tokenisation of debit (and credit/charge) cards.

More generally, one stakeholder also argued that the Bank should wait until the amendments to the Payments Systems (Regulation) Act 1998 (PSRA) were enacted before setting any expectations around tokenisation. Relatedly, another stakeholder noted that the Bank should be considerate of the potential redundancies and interactions between the expectations and other regulations currently being developed and implemented by other bodies (e.g. reforms to the Privacy Act undertaken by The Attorney General’s Department and AusPayNet’s initiative to uplift encryption standards in the Australian card payment system).

Endnotes

Network tokenisation involves the card scheme tokenising the PAN and storing the PAN in a token vault. As such, both the merchant and the gateway do not store the PAN, instead using the token provided by the card scheme. By contrast, merchant (or proprietary/gateway) tokenisation is where a customer’s PAN is typically tokenised by the merchant’s payment gateway. When processing the tokenised payment, the merchant’s gateway extracts the PAN from its own token vault before sending it to the card scheme. In some cases, tokenisation is performed by the (typically very large) merchant itself, rather than the gateway. [1]

The PCI-DSS is a set of minimum technical and operational requirements designed to protect cardholder data and is set by the PCI Security Standards Council. These requirements relate to the collection, transmission and storage of cardholder data. In Australia, compliance with the PCI-DSS is enforced via contracts that card schemes have with their members (e.g. issuers, acquirers and payments service providers). [2]