What to know about Dual Network Debit Card Tokenisation
13 September 2019
Our recently published fraud report shows that the value of online payments in Australia increased by 27% in 2018. As online transactions continue to grow, there is an increased focus on ensuring the integrity of customer data, pushing tokenisation into the spotlight.
In this blog, we look at the different types of tokenisation and highlight the importance of continued choice for consumers and merchants.
Background on Dual Network Debit Cards (DNDC)
A dual or multi-network debit card is a card that allows transactions to be processed through two or more payments networks (card schemes). In Australia, they incorporate the functionality of two schemes – an international scheme (either Visa or MasterCard) and the domestic scheme (eftpos) – in one physical card. These cards typically feature the logos of both schemes: the ‘primary’ scheme on the front of the card and the ‘secondary’ scheme on the back. As part of the ISO BIN allocation process, the BIN is owned by the primary scheme.
The customer value proposition of DNDC is flexibility in access to accounts and use across different channels. CHQ, SAV and CR options can be separately configured to three underlying bank accounts at the same financial institution. This gives the customer access to those three different accounts via one card; the customer can select their preferred account at the point-of-sale (POS). Traditionally, the domestic scheme, accessed via the CHQ or SAV functions, allows customers to withdraw cash at ATMs and POS. International schemes, accessed via the CR function, allow customers to transact across all channels including online and while travelling internationally.
What is Merchant Tokenisation?
Merchant tokenisation is the process of substituting sensitive card information, such as the cardholder's 16-digit primary account number (PAN) and expiry date, with a non-sensitive equivalent, referred to as the ‘token’. Token provisioning and storage is often managed by an external Token Service Provider (TSP). The token has no extrinsic or exploitable meaning and cannot be passed through the payment system to the issuer for value.
Merchants often use tokenisation to meet their Payment Card Industry (PCI) obligations. This allows separation between the systems that store payment data and the systems that process payment data, helping to reduce fraud by adding protection to prevent a possible data breach or data hacking situation.
In a merchant tokenisation scenario, de-tokenisation by the TSP happens within the merchant domain. During a transaction, the merchant’s POS system will send the de-tokenised sensitive card information to the gateway, scheme and issuer for authorisation.
What is Network (or Scheme) Tokenisation?
Network Tokenisation is the process of a scheme replacing the cardholder’s PAN with a unique EMV Payment Token (Payment Token). Here, the scheme plays the role of the TSP, allowing the Payment Token to pass through the payments system for value, providing an end-to-end tokenised transaction.
Payment Tokens also have an additional layer of security in that each Payment Token can be configured with domain controls, designating it for a specific use. For example, a Payment Token can be nominated to a Merchant ID (for card-on-file payments) or in a particular device ID (for mobile payments).
In a Network Tokenisation scenario, de-tokenisation happens within the scheme domain. During a transaction, the Payment Token is passed to the scheme TSP, who validates the domain controls and de-tokenises the Payment Token back to the PAN. The PAN is then passed to the issuer for payment authorisation. Once authorised, the PAN is sent to the scheme for re-tokenisation before returning the Payment Token to the merchant. The Payment Token must be passed to the scheme TSP during the transaction for de-tokenisation.
Different Types of Network Tokenisation
There are two use cases for Network Tokenisation, both with the goal of having only Payment Tokens with appropriate domain controls, rather than PANs, traversing the payments system:
- Mobile Payment Tokenisation (for example, ApplePay, SamsungPay, and GooglePay)
The cardholder requests to add their card credentials into their digital wallet. Once they have been identified and verified by the issuer, a Payment Token is provisioned into the secure element of the cardholder’s device. During a transaction, the token is used instead of the cardholder’s PAN to perform the payment. Separate Payment Tokens are created for each card stored in the digital wallet.
At this stage, only a limited number of financial institutions and mobile wallets allow a cardholder to provision both schemes on a DNDC into a mobile wallet.
- Credential-on-File (CoF) Tokenisation
Sometimes referred to as ‘Card-on-File’ Tokenisation, rather than a merchant storing a cardholder’s PAN on file, the merchant requests a Payment Token from the nominated scheme. In this scenario, the primary scheme is always automatically chosen for tokenisation and the Payment Token is restricted to be used by only this particular merchant. The secondary scheme cannot be tokenised at any stage.
The RBA’s View on Dual Network Debit Card Tokenisation
In a note to all major schemes and issuers earlier this year, the RBA confirmed its support of the broad initiative to tokenise credentials on file as a way to reduce fraud. The RBA also reconfirmed its support for DNDCs as they provide convenience to cardholders and enable stronger competition between schemes at the point of sale.
However, the note also flagged that the RBA would be concerned if actions taken by schemes or scheme participants diluted or prevented competition between schemes. The note encouraged scheme rules and policies to ensure that consumers and merchants retained choice in routing transactions through their preferred network.
If you'd like to know more about dual network debit card tokenisation in Australia, please get in touch info@auspaynet.com.au.
