REDUCING FRAUD WITH TOKENIZED PAYMENTS

Among the obvious advantages of chip and PIN and contactless payments via EMV*, major weaknesses have led to the banking industry suffering serious fraud. One of these weaknesses is the insecurity of the personal account number (PAN). PAN data can be compromised during EMV transactions or by breaching merchants’ databases that store consumer card details. PAN-related data can be used for cross-channel fraud, such as card-not-present (CNP) and counterfeit card transactions via the internet, telephone or mail order.

The payment industry has increasingly adopted tokenization to protect against PAN compromise in EMV transactions. This blog considers tokenization’s target architecture and benefits, particularly in the areas of fraud reduction, compliance and cutting costs. 

What is a PAN attack?

Traditionally, retailers and merchants have used standalone card readers to accept customer payments. However, modern point-of-sale (POS) systems used by many businesses are all-in-one systems that perform nonpayment-related functions in addition to accepting card payments. This opens additional attack channels for malicious actors.

Let’s review a simple example of a potential PAN compromise, which includes these potential stages:

1. Criminals target a POS system and infect it with malware by exploiting a vulnerability in the POS system or using the network connection (most POS systems are connected to the internet).
2. When the customer inserts, swipes or taps the payment card on the terminal attached to the POS system, the card details are transferred to the POS system. 
3. At this stage, the malware uses a technique called “memory scraping” to read the PAN and other card details that are in a readable format in the random access memory (RAM) of the POS system.
4. The malware then sends the infiltrated details, including the PAN, to the criminal.

Card fraud stats

A recent report by Financial Fraud Action UK found that CNP fraud – such as fraudulent purchases made using compromised card details – over the internet, telephone or by mail order, amounted to £432 million in 2016**. Total international fraud losses on U.K.-issued cards totaled around £200 million in the same year, according to the report. PAN compromise attacks, where criminals steal magnetic stripe details from cards issued in the U.K. to make counterfeit cards to use in countries that have not migrated to chip and PIN, account for a portion of this figure. 

In 2017, retail giant Target settled an $18.5 million claim originating from data breach. Around 40 million customer credit and debit card details were compromised by malware that infected more than 1800 branches***. The total cost of the breach mounted to around $202 million. 

Tokenization principle

The payment industry increasingly looks to tokenization as a measure against PAN compromise. Tokenization replaces the PAN with a surrogate value, called the token, a 13- to 19-digit value that does not contain the actual PAN. During a payment transaction, the token is presented to a card reader instead of the PAN. Even if an attacker managed to steal the token details, they are unique to a particular transaction and payment channel, and as a result, the attacker couldn’t use the token to attempt a subsequent fraudulent transaction. The payment portal and clearing venue would not recognize the token details as valid.

Following the standardization of the EMV tokenization specification by EMVCo****, contactless mobile payment applications have become one of the first markets to use this technology. Apple Pay, for example, is a mobile payment application based on tokenization. 

The most significant change to the current EMV payment architecture is the introduction of the token service provider (TSP). In some implementations, the scheme operator or the issuing bank can act as the TSP. In the case of Apple Pay, the scheme operator acts as the TSP.

Tokenization in action

Before a payment transaction occurs, upon request from the issuing bank, the TSP issues a transaction-specific token to the mobile device initiating the transaction. The TSP maps the PAN details to the token details and keeps everything in a secure digital vault. 

The token details include two main segments: the token itself and the token cryptogram, a set of data (currency value, token expiry, unique unpredictable number, etc.) encrypted using a security key. The key is shared between the TSP and the issuing bank only.

During a transaction the mobile device passes the token and the token cryptogram to the merchant’s terminal. The terminal forwards the payment request and token details to the acquiring bank, which then forwards it to the scheme operator. At this stage, the message flow is the same as a normal EMV PAN-based transaction. The differences are that a token is sent instead of a PAN and that a token-based cryptogram is sent instead of a PAN-based cryptogram. 

In a PAN-based payment transaction, the scheme operator contacts the issuing bank directly to authorize the transaction. In a tokenized payment transaction, the scheme operator first contacts the TSP to detokenize the token and retrieve the PAN. Using the shared security key to decrypt the token cryptogram, the TSP verifies the authenticity and integrity of the token data received. On satisfactory verification, the TSP retrieves the associated PAN. 

Subsequently, the scheme operator forwards the payment request together with the retrieved PAN to the issuing bank for authorization. The transaction flow then continues in the same manner for both token-based and PAN-based transactions: 

1. The issuing bank carries out necessary account-level checks and authorizes the payment request by generating an authorization response that is sent to the scheme operator. 
2. The authorization response is forwarded to the terminal via the acquiring bank. 
3. Once the terminal receives the authorization response, the transaction is approved or declined. 

Preventing other attacks

Tokenization is used specifically to prevent PAN compromise. However, it also prevents “replay attacks,” where the attacker captures data (not only the PAN/token but also the associated cryptogram and other details) passed to the payment terminal/POS system during a transaction. The captured details are then replayed in other transactions fraudulently. 

One of the details included in the cryptogram is the token expiry, which can be set to have a very short lifespan. The TSP can detect any replay attempts when it receives a cryptogram with expiry outside the expected time frame. Furthermore, it is possible to include additional details, such as unique transaction IDs and unpredictable numbers within the cryptogram to bind the cryptogram to a particular transaction. This ensures that any replay attacks fail. It must be noted that an attacker is unable to obtain or change these details, because the cryptogram is encrypted. 

What’s in it for banks?

The main benefit for banks is significant reduction of fraud losses related to PAN compromise. Reduced card and payments fraud also means fewer disputes and more satisfied customers.

In addition to protecting against PAN compromise, rolling out a tokenization-based contactless mobile payment application provides other benefits for banks. As an example, a PAN-based payment application that only provides payment functionality for POS-transactions can be optimized into a smart token application to provide payment functionality at online checkouts from mobile devices as well. Mobile payment applications based on smart tokens can also provide greater insights into customer payments (e.g., spending habits), enabling banks to recommend and provide bespoke products, services and promotional offers during payments and at checkout. 

Furthermore, banks can set accurate risk ratios and transactions limits and authorize high value transactions for genuine customers. These benefits are more difficult to achieve with a PAN-based solution because of security implications and incompatibility of supporting e-commerce checkouts. 

Compliance advantages

In the payments industry, merchants handling customer payment card details are required to comply with industry standards, such as the Payment Card Industry Data Security Standard (PCI-DSS). This costly and time-consuming compliance requires stringent audits and implementation of security controls. 

For merchants, tokenized customer payment records are exempt from PCI-DSS compliance. This is not to say that merchants should not implement adequate security controls to safeguard data from compromise, but the risk of tokenized records being breached is minimal. 

Summary

To sum up, tokenized payments add an extra layer of security for payment transactions and offer improved functionality and customer insights. Although used by contactless mobile payment applications such as Android Pay and Samsung Pay, token-based solutions market share remains small compared to that of the less secure PAN-based solutions.

The tokenized payments technology will likely gain more popularity in coming years. This would translate into fewer financial losses from fraud and greater cost savings for financial institutions, which can be passed on to consumers as well as merchants.

References:

* EMV (Europay MasterCard Visa) is a globally accepted standard that provides interoperability to Chip & PIN and contactless payment transactions. This standardises a common protocol for communication between smart cards and payment terminals (including ATMs) participating in the payment scheme. 
** Financial Fraud Action UK report Year-end 2016 fraud update: Payment cards, remote banking and cheque (March 2017) 
*** http://www.reuters.com/article/us-target-cyber-settlement-idUSKBN18J2GH (May 2017)
**** EMVCo facilitates worldwide interoperability and acceptance of payment transactions, overseen by its six member organisations - American Express, Discover, JCB, MasterCard, UnionPay, and Visa—and supported by dozens of banks, merchants, processors, vendors and other industry stakeholders who participate as EMVCo Associates.