Tokenizing with Your Payment Service Provider? Think Again Part 1 of 2

Tokenizing with Your Payment Service Provider? Think Again Part 1 of 2

Tokenization has the attention of industries worldwide due to its effectiveness in securing sensitive data sets and reducing PCI compliance scope. Most importantly, people are taking note of the simple fact that if your tokenized data is breached, all that has been exposed is a meaningless token, not the sensitive data. However, not all tokenization solutions are the same, nor do they all function at the same level of effectiveness in your environment. In part 1 of this blog we will compare/contrast payment service provider (PSP) tokenization with an agnostic cloud tokenization platform. Are you utilizing a PSP tokenization solution that was offered to your organization for free?  Are you only able to tokenize payment card data (PCI)? What about the rest of the sensitive data sets {PII, NPI, ACH, CSV, HIPAA, etc.} that are currently coursing through your internal systems? Should you enlist a 2nd platform to secure your other sensitive data sets? What are the potential pitfalls of utilizing multiple tokenization platforms? What happens when you want your payment gateway to return your data?

Free Tokenization Is Not Free

Your payment processor had such a great pitch, enticing you to utilize their tokenization platform with a first-year-free offer. Nothing is free, however, and in the back of your mind you knew there would be a catch. Once that first year is up, you are subject to the processor’s transactional pricing, where you are charged per transaction to use each token. This is dramatically more expensive than volume-based tokenization would have been, had you decided to just pay for your first year of tokenization. When you partner with a tokenization platform, there should be no lock-in either for accessing your own data or receiving your detokenized data for internal initiatives. Your data should always be your data, with the tokenization provider’s role limited to acting as custodian, keeping the data secure and out of your environment.

Processors Only Tokenize PCI

The vast majority of tokenization solutions from PSPs deal only with PCI– not ACH, PII, HIPAA data, or the vast amount of sensitive data sets covered by diverse international rules and regulations that vary from country to country. We have several customers who were simply told NO by their processors when asked if they would be able to tokenize other data sets. Their PSP acknowledged that they did not want the liability of handling PII or any other sensitive data set outside of PCI. If your PSP guarantees secure tokenization, then why would they not tokenize your other sensitive data sets? Unfortunately, their platforms were intentionally architected to only handle PCI, so organizations are left to find a separate solution that will safely tokenize the rest of their sensitive data sets. It is uneconomical and much more work to maintain two separate tokenization platforms. Even worse than the economics, though, is having two sets of tokens–using different methods for tokenizing data–as this can lead to the risk of commingling token sets and, ultimately, data corruption.

Cross-domain Tokenization

Among the main culprits of cross-domain tokenization are payment processor service providers who also supply tokenization. Payment Processors can introduce cross-domain tokenization conditions when they use the same token-to-PAN mapping schema for all the merchants they are servicing. For example, Merchant A and Merchant B are both using Payment Processor Z. Processor Z takes a unique PAN and generates the same token for every merchant. So, in this instance, the same token is generated for a PAN used by both Merchant A and Merchant B. If a token from Merchant A’s vault is used at Merchant B, it could be processed for a fraudulent payment because it represents the same PAN. A true tokenization solution always generates unique token/PAN combinations for each Merchant and stores them in separate vaults.

When selecting Service Providers and Payment Processors to perform your tokenization, ask about their cross-domain tokenization and cross-vault contamination policies. Before committing to a tokenization vendor, perform a Proof of Concept with the service providers to ensure that the resulting token and PAN data is unique to each data vault.

Transactional Based Tokenization

After your first year of “free” tokenization, your PSP will begin to tack additional tokenization fees onto every payment card transaction. That’s in addition to the cost of setting up your tokenization solution (integration to your environment), the cost for converting your data to tokens, and—the ultimate insult—the cost of giving your token vault back when you decide you want to utilize your data for 3rd party analytics or customer storage profiles. Heaven forbid, you may even find yourself looking for a new PSP that better suits your organization, a scenario that entails this caveat– your PSP may not be contractually obligated to return your token vault, making it even more difficult and expensive to change PSPs and tokenization solutions. So before acquiescing to your PSPs’ tokenization “deals”, scrutinize the contract to ensure that your data remains your data, regardless of the end goals.

Transactional pricing quickly becomes cost prohibitive for most organizations. While you may accept the payment card company’s processing fee-per-transaction as the cost of doing business, there is no reason to have to pay extra for accessing your stored payment account numbers (PANs) and the associated tokens each and every time a payment is processed. The same applies to fraud detection, a process which is not necessary to run for every recurring payment. Yet, a payment processor will try to charge for each service every time, inflating the cost-per-transaction and adding to their bottom line.

You Have Options

Commingling tokens, data corruption, cost prohibitive transactional pricing, the inability or unwillingness due to liability of tokenizing sensitive data sets outside of PCI, and having to pay for your “own” data should cause you to rethink that first year of free tokenization. Securing PII is not going away, and organizations will have to deploy data security solutions that will secure this very sensitive data set. Moreover, for international organizations new initiatives like the Global Data Protection Regulation (GDPR) mandate the securing of PII through data anonymization. Tokenization is a recognized solution for data anonymization, but your PSP is years away from securing PII, or may never secure PII. Your PSP is really good at brokering payments, but they can potentially put your organization in major harm’s way when trying to act as a holistic data security solution. The good news is that there are flexible tokenization solutions that do not create this litany of expensive and unsafe problems for your organization.

In part 2 of this blog series we will investigate the hard costs of tokenizing with your PSP, managing the solution, as well as the benefits of working with a truly “flexible” tokenization solution. TokenEx is the industry leader for cloud tokenization. Follow us on Twitter and LinkedIn.

TokenEx Cloud Tokenization

Topic(s): payments , data security , PCI DSS , PII , tokenization

Keep Up With Our PCI & Privacy Blog