In that article, we will explain what is tokenization in the context of the fintech companies and we will list the available technologies.
Table of Contents
What is Tokenization in Fintech?
If you’re involved in fintech, you have certainly already heard the buzzword “tokenization”. Let us explain what it is.
Tokenization is the art of substituting meaningless data to meaningful data. It’s different from encryption in the sense that, to perform tokenization you build a dictionary where the token entries are mapped to the original entries. Without the knowledge of the dictionary – which acts as the “key” – there is no way to understand the nature and value of the tokenized data.
Tokenization is, therefore, a way to scramble data, protecting them to be stolen.
Of course, encryption can be used to perform tokenization. It is enough to cipher the original data and consider the ciphered output as tokens, but the whole dictionary security lies in the encryption key!
Tokenization is usually achieved either by one-time hashes, either by random generation, either by both.
As an example let us take a list of (fake) customer credit cards:
We, of course, do not wish to expose these data, so we will tokenize them and store the original values in a vault where they will get un-mapped on demand.
We will use a mix of random numbers and random English words to create token values:
At first, the PAN is being submitted by the customer to the merchant website. The merchant website transfers the PAN to the TSP via point-to-point encryption, then the TSP stores the PAN in a token vault and sends a token to the merchant website.
The merchant website will then send the token to the credit card processor all along with cryptogram information. The credit card processor will request the TSP to de-tokenize the token so as to retrieve the banking information and change the corresponding account to the cardholder bank. Authorization is forwarded to the merchant which stores it with the token in a database. The customer will then be delivered to the product that was bought.
There are many possible implementations and many other data could be tokenized. The token itself… could be tokenized then stored into the database.
The term mobile payments refer to financial transactions where mobile phones (“smartphones”) are used to store and process payment information.
There are various standards governing mobile payments (aka M-payments), such as EMV contactless or NFC (Near-Field Communications). Besides these standards, many companies have developed their own mobile payment systems with proprietary norms. Currently, Apple Pay, Google Pay or Samsung Pay are the most prevalent mobile payment applications available. Usually, they consist of a digital wallet and/or a mobile payment application (Android, IOS, Windows Mobile) that resides inside the smartphone.
Mobile payment environments can be very irregular. There is a broad range of payment options and channels. For example, AliPay, Amazon Pay, WalMart Pay, Starbucks Pay (which was the most popular payment app in 2018 in the USA), PayPal One Touch, Square Cash, Zelle, or Venmo are very different mobile payments systems developed by companies with very different backgrounds.
Mobile payment applications are usually digital wallets. These wallets allow you to store and organize all sorts of cards, documents, concert tickets, airline tickets, bank details, crypto coins, and payment cards. Mobile payment apps can be installed on a mobile phone, a computer, a tablet, or a smartwatch.
Mobile payments look very easy and convenient to use; just “wave” the phone over the terminal of the cashier. However, they need a lot of security because consumers will store a lot of personal data there. Their payment card data stored in the digital wallet is transmitted to other devices via wireless technologies like NFC or Bluetooth to make a payment. That data is transferred to different environments over-the-air where it could be potentially intercepted.
According to research from Simon-Kucher & Partners, 90% of U.S. consumers prefer to pay by cash, debit, or credit card rather than using mobile payment. The study mentions “Lack Of Confidence” (70%) and “Security Concerns” (40%) as the main reasons for refusal to use mobile payments. Obviously, tokenization is becoming a de-facto standard in M-payments as a way to address these issues.
Security risks with M-Payments usually involve trojans or malware because Android and iOS operating systems used by most smartphones, tablets, and smartwatches aren’t very secure by nature. Besides, if data are not properly stored in a secured component, for instance, a SIM chip or secure memory card, it can be intercepted through the operating system.
Why Tokenization Could Be a Question of “Survival” for Mobile Payments
The use of mobile payments is expected to continue to rise and become the second most popular payment method after debit cards by 2022. In 2017, China’s mobile payments market was estimated at $17 trillion. The growth of mobile payments depends totally on the prevention of data breaches, and for this, there is but one technology: Tokenization.
Tokenization is the act of replacing sensitive data like the PAN (Primary account number) with tokens, which is useless data that can be mapped to the original data that is kept in secure vaults.
Linking or registering a payment card (credit or debit) with most mobile wallets is usually a very straightforward process. The payment card data are manually entered or scanned into the application and sent for validation to the payment network. Once validated, users can make payments at terminals using their smartphones, tablets or wearable devices instead of using the physical card.
Even if the card’s PAN is stored within a secure location in the device (secure element), this doesn’t totally prevent data breaches. For instance, the PAN could be intercepted during the transaction workflow.
Hence it is “general” practice in M-Payments to replace the PAN with a token using the like-to-like format rule. Simply put, 16-digit PAN is replaced by a 16-digit token that is usually randomly generated. For example instead of using the PAN:
4085-8800-8378-3527
the mobile payment operator will use the token:
1454-0989-2121-8954
The token is completely useless unless it can be de-tokenized to the original PAN.
In a continuing growing environment where maintaining the security of data are critical, for “survival,” using tokenization is already a constraint.
Here we present some of the most popular mobile wallets and how they use tokenization technology.
Wallet
Tokenization
WeChat
No indication of Credit Card Tokenization. Cards are saved in “safe” PCI-DSS databases.A token ID is used to identify the user online and getting the credit card data, however this is not credit card tokenization.
Alipay
No indication of Credit Card Tokenization. More or less the same system as WeChat. Tokenization via access token.
Apple Pay
Credit Card Tokenization. The PAN is replaced by the Device Account Number (DAN), an Apple-Pay specific token.
Google Pay
Credit Card Tokenization. The PAN is replaced by a “virtual account number.”
Wal-Mart Pay
No Tokenization. Cloud-based.
Samsung Pay
Host Card Emulation (HCE) and Credit Card Tokenization (DPAN).
PayPal One Touch
Apparently uses Credit Card Tokenization. PayPal has been using Credit Card Tokenization for a long time with its web version.
Zelle
Tokenization is being used.
Venmo
Venmo is a cardholder side multi-merchant tokenization system
Square Cash
Tokenization
Amazon Pay
Tokenization
Visa Pay
Host Card Emulation (HCE) and Credit Card Tokenization.
Starbucks Pay
No Credit Card Tokenization. Cloud-based.
In fact, most if not all mobile payments are using some form of tokenization with access tokens, even if they do not explicitly use credit card tokenization, where the user:
Authenticates itself using passwords, biometrics, etc;
Gets identified on the payment servers;
Gets his credit card details been used to charge his bank account.
For example, Square Wallet uses the picture of the user’s face as a “token” to mask the payment card data. Braintree (Venmo) uses the fingerprint of the device, the user’s location, and a password to generate the access “self-authenticating” token. It is not exactly the philosophy of credit card tokenization because sensitive data is masked by other sensitive data.
Nevertheless, all mobile payments are capitalizing on several tokenization systems. Credit card data are stored in the cloud, and even if it is not explicitly tokenized, it certainly does not reside on the mobile device. This is a big difference with EMV payments, where credit card data is stored (publically) on the card.
Some mobile payments are using “high-value” tokens that can be used in lieu of credit card data to place transactions, while others do not. M-Payments that seem to implement a “true” credit card tokenization are Apple Pay, Google Pay, and Samsung Pay. Let’s see how the latter is working under the hood.
Mobile Payments Tokenization: The Samsung Pay Example
Samsung Pay is an interesting example of tokenization that combines HCE (Host Card Emulation) and tokenization. This application is only available for compatible Samsung phones or watches.
Samsung Pay works through NFC, but is also able to simulate a bank card magnetic stripe (Samsung’s MST technology). Therefore, it can be accepted in any shop where “traditional” credit cards are accepted.
The tokenized PAN is known as a “token PAN”. This is sometimes also called Digitized PAN (DPAN in short). The real credit card number is protected by the token from being intercepted and fraudulently used.
The Samsung Payment tokenization then adds a cryptogram to the payment information + DPAN. The cryptogram is unique and generated by the device. It shows the card network that the card has been legitimately used.
Samsung Pay primarily utilizes the global payment networks tokenization services, depending on the card issuer. However, third parties TSPs are also supported. The rules and parameters of the token service is decided by the card issuer and it performs account verification during the token request, and then authorizes transactions.
Interestingly enough, the DPAN has its own expiration date and it acts as a “super-credit card” because it is not linked to the original credit card data, but to the FPAN, the Funding Primary Account Number. So, even if the card has to be renewed, there is no need to change the DPAN.
Yet, the DPAN cannot be used by an attacker without the cryptogram and other Samsung Pay data. For instance, it is totally useless for any CPN (Card-Not-Present) fraud.
The cryptogram sent with the DPAN and the transaction information is generated by a cryptographic key contained in the Samsung Phone’s TEE-(trusted execution environment). The cryptogram also contains a counter (ATC) to prevent replay attacks in a design similar to EMV.
It is an interesting aspect that the Knox™ secure platform used by Samsung has several certifications, including Common Criteria, FIPS, and DoD. This makes Samsung Pay a true rival of EMV, but with the advantage of using “natively” credit card tokenization.
The following schema presents a typical workflow in Samsung Pay:
Initially, the cardholder enrolls his card to a TSP that is designated by the card issuer.
A token, the DPAN is generated in the card vault of the TSP and securely sent to the Samsung device where it will be stored.
When the cardholder performs a transaction, the token, the payment information, and the cryptogram are sent to the payment network through the acquirer. The token is unmapped and the real PAN, in fact, the PFAN is sent back to the payment network, which will ask the issuer bank to charge the account.
During the workflow, the cryptogram is authenticated as proof of the validity and authenticity of the transaction request.
The authorization is eventually sent back to the merchant.
As you can see, well-thought-out credit card tokenization is an essential part of Samsung Pay security. Even if the phone, quite secure in itself would be hacked, only useless information would be leaked.
Let’s review what could happen to a mobile wallet solution iftokenization has not been used.
This is a fictional sample to illustrate why mobile-payments need tokenization. In this story, we will imagine a fictional company named Green Water Payments who has developed a mobile payment application named Water Pay.
Water Pay is available as an Android 4+ application. It is extremely popular in some countries where you can buy water with it; especially in non-developed countries where water is not available in all homes.
The application asks the user to register a credit card at enrollment. It will encrypt the credit card data with keys located in the secure element of the phone and then it will store it, ciphered by AES encryption in the memory of the phone.
When a cardholder wants to pay with Water Pay, he just waves the phone over a small POS device. The small POS will communicate a request for payment to the mobile application. The application will then decipher the credit card information, generate a cryptogram with the payment data, and send everything as an XML flow to the acquirer, inside a TLS 1.2 secure channel. The customer then presents the screen with the payment approved and gets the water he bought (water bottles, water delivered by a truck, etc.)
The only problem is that, in some countries, especially outside the big cities, the preferred way of communication with the internet is via Wi-Fi. Often a “collective” Wi-Fi is shared by many users.
Still, communication is done via a secure channel. But inside the collective Wi-Fi, some local criminals, who access the Wi-Fi administration have deployed an SSL proxy. The data are then routed to the proxy who pretends to be the acquirer because the network has been configured that way.
The phones are supposed to accept the SSL proxy certificate with a custom root authority when they initially connect to the Wi-Fi so the SSL connection to the SSL proxy will look like a real valid connection with a valid SSL certificate. The SSL proxy ( which can be MITM proxy or splitSSL for instance ) will decipher the data, store the card information, re-cipher the data, and send them to the real acquirer server. The transactions will go on, and the proxy will act totally unnoticed.
The credit card data of the users will then be collected for further use.
For example, this could happen in China or Indonesia where millions of card data could be fraudulently collected from Water Pay customers. This is just a fictional story, but it could happen anywhere as the use of mobile payments continues to grow and more applications are released.
Obviously, in our story, Water Pay should have opted for a tokenized solution.
As the Fintech space is growing drastically, with many new pathbreaking fintech applications coming into the market, tokenization is going to be an inevitable thing for M-payments.
Conclusion: Tokenization in fintech for M-Payments is almost a de facto standard. It is conceivable to imagine that fintech applications won’t be allowed to operate in M-Payments in the near future without a strong and solid tokenization solution.
Acodez is a leading website design and software development company in India. We offer all kinds of web design and web development services to our clients using the latest technologies. We are also a leading digital marketing company providing SEO, SMM, SEM, Inbound marketing services, etc at affordable prices. For further information, please contact us.
Looking for a good team
for your next project?
Contact us and we'll give you a preliminary free consultation on the web & mobile strategy that'd suit your needs best.
Rithesh Raghavan, Co-Founder, and Director at Acodez IT Solutions, who has a rich experience of 16+ years in IT & Digital Marketing. Between his busy schedule, whenever he finds the time he writes up his thoughts on the latest trends and developments in the world of IT and software development. All thanks to his master brain behind the gleaming success of Acodez.
Thanks for providing the detailed information. Very nice article. Lot of information which can be useful to the readers. Keep sharing!