Tokenization FAQ

Frequently asked questions.

Cybersecurity Protection

Secure Payments, PII, PHI and ACH Account Data

With more data and payment security regulations than ever, it’s imperative that organizations protect all payment and sensitive data upon entry and in storage. Learn more about tokenization and its value, as well as Bluefin’s ShieldConex® tokenization platform to secure payments, Personally Identifiable Information (PII), Protected Health Information (PHI) and ACH account data entered online.

About Tokenization

What is Tokenization?

Tokenization is the process of removing sensitive information from your internal system — where it’s vulnerable to hackers — and replacing it with a one-of-a-kind token that is unreadable, even if hackers manage to breach your systems. The token is usually a random sequence of numbers or letters that the organization’s internal systems can use at little risk while the original data is held securely in a token vault.

To learn more, see our article What is Tokenization and Why is It Important?

What is Tokenization of Payments?

Digital tokenization has been around for over 20 years and was primarily designed to secure credit and debit cards. In the early days of digital payments, merchants and payment processors would store Primary Account Numbers (PANs) – the 16-digit debit/credit card number – alongside other transaction information. Because this sensitive payment information was stored in clear text, it was visible to anyone with system access and especially vulnerable to data breaches and theft. Inspired by physical token systems like casino chips and vouchers, digital tokens were created to substitute sensitive data in storage.

What is Tokenization of Data?

Historically, tokenization has been deployed to protect credit card and debit card data in storage. Storing this data is essential for recurring and subscription transactions so that the customer can be billed on a regular basis without having to re-enter their information. Storing clear-text credit and debit card data in any form violates PCI compliance rules, as well as data privacy rules.

In recent years, tokenization has been expanded to now also “mask” Personally Identifiable Information (PII), Protected Health Information (PHI) and banking information, especially pertaining to ACH account details. Examples of the type of data a tokenization system can secure include:

  • A real name or alias, signature, or physical characteristics or description
  • Postal address or telephone number
  • Unique personal identifier, account name, online identifier Internet Protocol address, or email address
  • Education and employment, including employment history
  • Social security number, driver’s license number, state identification card number, passport number, or other similar identifiers
  • Medical information or health insurance information
  • Bank account number, credit/debit card number or any other financial information

Additionally, tokenization is no longer exclusively used for protection of data in storage. It can also be used to immediately tokenize data upon entry into a web form or Ecommerce page.

What is Vaultless Tokenization?

Vaultless tokenization refers to tokenization which does not require a token mapping table and relies on an algorithm to transform data into tokens. Implementations deemed secure using this method rely on industry approved algorithms and modes of operation and, when outsourced, can be implemented such that compromise of the tokenized (encrypted) data renders zero value to the malicious actor. As with standard encryption, a malicious actor in possession of tokenized data without a secret key has no means to recover the clear-text data.

Vaultless tokenization provides the easiest way to secure an organization’s data: the general population of the organization’s systems never see the original data strings, and only a very few and limited amount of heavily controlled systems are allowed to transform tokens back to sensitive data.

What is Vaulted Tokenization?

Vaulted tokenization typically involves creating a token mapping table, where sensitive data is centralizd on that table. This reduces the number of systems processing and/or storing sensitive data, thereby reducing the risk of the overall environment by centralizing that risk in the systems storing and managing the mapping table. Since the mapping table becomes the most desirable target, sensitive data stored in the token mapping table should be encrypted and the secret key managed securely.

What is Format Preserving Tokenization (FPT)?

Tokenization is the process of devaluing sensitive data by substituting sensitive data elements with randomly generated symbols that represent the original sensitive data. In format-preserving tokenization (FPT), the randomly generated symbols use the same alphabet as the original data. Bluefin leverages FPT to allow your tokenized data to exist within your legacy systems without requiring any refactoring.

How Does Detokinization Work?

Detokenization is the process of returning previously tokenized data back to its original value format. This can work a number of different ways depending on the tokenization solution provider that you use and if you are using a vaultless or vaulted solution. Most often, companies will set up certain personnel with rights to request detokenization from the solution provider.

How Does Tokenization Apply to PCI DSS Standards?

Any organization that accepts credit or debit card payments is required to keep that data as safe and secure as possible. The Payment Card Industry (PCI) Data Security Standard (PCI DSS) is the set of regulations established by credit card companies to help protect payment information and are mandated by the credit card companies to ensure the security of credit card transactions.

Tokenization addresses PCI DSS requirement set #3: protecting cardholder data (CHD) at rest. PCI DSS seeks to reduce retention of sensitive data and safely govern its storage and deletion. Tokenization satisfies this critical requirement by eliminating stored CHD from as many systems as possible. Credit card tokenization not only replaces sensitive data, but it also minimizes the amount of data an organization needs to keep on file, which ultimately helps to reduce the cost of compliance with industry standards and government regulations.

Additionally, the responsibility to protect stored CHD and maintain the proper level of PCI DSS certification then falls on the token (solution) provider, so it ultimately reduces the cost of PCI compliance. This makes an especially big difference for organizations that want to support card-on-file or recurring payments.

To learn more, see our article Tokenization, Cardholder Data and PCI Compliance: What you Need to Know.

How Does Tokenization Apply to Data Privacy Compliance Standards?

While data privacy regulations do not mandate the type of technology adopted to secure data, they both discuss pseudonymization and encryption as relevant data security measures.

  • Pseudonymization encodes personal data with artificial identifiers such as a random alias or code. While pseudonymization is a “false” anonymization because the data can be linked back to a person, the personal identifiers are stored outside of the company’s system or network. These personal identifiers would be required to re-identify the data subject, thus making it a secure practice. Tokenization is an advanced form of pseudonymization.
  • Encryption renders data unintelligible to those who are not authorized to access it. Data encryption translates data into another form, or code, so that only those with access to the decryption key can read it.

One reason for tokens’ increasing use for sensitive, personal information is that they are versatile – they can be engineered to preserve the length and format of the data that was tokenized. Tokens can also be generated to preserve specific parts of the original data values; by adapting to the formats of conventional databases and applications, tokens can eliminate the need to change the database scheme or business processes. Organizations can treat tokens as if they were the actual data strings.

To learn more, read our article Understanding PHI, PII, Data Privacy & Tokenization.

What is the Difference Between Tokenization and Encryption?

Encryption, simply put, is taking a known piece of data and locking it up so that the data can only be retrieved with a key. In more technical terms, encryption uses an algorithm and a key to take the data and make it unreadable. Of course, this key must be controlled, typically called key management, to keep the data safe. If your data is “123,” and you encrypt the data with key “ABC,” resulting in “98zy65x,” and protect the key properly, all an attacker will be able to see is 98zy65x, which is useless to them.

Tokenization is taking a known piece of data and replacing it with a new random value. For example, the value “123” could be replaced with an unrelated value, such as “978.”

Learn more about the differences and use cases in our article Tokenziation vs. Encryption.

About Bluefin’s ShieldConex® Data Tokenization Platform

What is the ShieldConex Tokenization Platform?

ShieldConex is Bluefin’s vaultless tokenization platform that secures any PII, PHI or payment element entered online. Our cloud-based solution can be implemented via API or an iFrame. Users can choose to protect their data with either Format Preserving Tokenization (FPT) or Format Preserving Encryption (FPE). ShieldConex also provides omnichannel tokenization across the POS and online, and in 2023, will support network tokenization.

 

Learn more about ShieldConex.

How are iFrames Used within ShieldConex?

The use of an iFrame allows ShieldConex customers to outsource the capturing of sensitive data, in a scenario where the end-user sends its data directly to Bluefin for tokenization without traversing the customer’s production systems. This allows for greater scope (and therefore risk) reduction of the Page customer environment as no sensitive data is ever handled by those front-end systems in terms of transmission, processing or storage. The responsibility for the capture and encryption of this data rests with Bluefin as a Tokenization Service Provider.

The use of iFrame Forms in the capture of data means that once the end-user enters the data to a data capture form, the sensitive data is sent directly to Bluefin’s servers for tokenization and only the tokenized data need be received by the partner. This removes the transmission, processing and storage of the sensitive data elements from the partner environment and Bluefin effectively acts as a tokenization service provider without the need to store its own copy of the tokenized data. Neither the partner organization nor Bluefin possesses the original clear text data.

Is There Any Latency in Tokenization or Detokenization?

In legacy “vaulted” tokenization solutions, data is stored on a token server and must be retrieved to use. This form of tokenization requires large databases to map tokens to their original data.

Unlike those legacy vaulted solutions, ShieldConex leverages vaultless tokenization. In this case, tokens are generated using Hardware Security Modules (HSMs), eliminating the need for storing any sensitive data. Typical response times are about 1/10th of a second – not perceptible by humans – meaning data is available instantaneously.

Does ShieldConex Store Data?

ShieldConex is a “vaultless” token solution, so the actual data is never stored in a “vault” or database. Secured data can be unmasked at any time by calling the ShieldConex service using your assigned API key.

Can ShieldConex Secure Data Through a Mobile Application?

Yes, ShieldConex also protects data in a mobile environment. If the app is written in a native app framework, the app would need to call Bluefin’s ShieldConex API. If the app is written within a web app framework, it will be able to either leverage the ShieldConex API or leverage the ShieldConex iFrame, depending on your organization’s preference.

Can ShieldConex Protect my Webpage from Being Compromised?

ShieldConex can add protection. When using the ShieldConex iFrame, the sensitive data is being captured by ShieldConex directly – not on the webpage of the customer. It also requires an out-of-band, 2-step process to retrieve this data from ShieldConex, adding an additional layer of security. Even with this in place, Bluefin recommends:

  • Regularly analyze all of your own website scripts throughout the development lifecycle
  • Implement client-side protections such as web skimming or malware protection
  • Deploy a bot management solution that is able to detect and defend against sophisticated botnets that result from browser-based attacks.

How is ShieldConex Implemented?

ShieldConex is an entirely cloud-based product that leverages APIs and secure iFrames configured through our ShieldConex Manager administration portal. Bluefin will provide access to the ShieldConex APIs, login credentials to ShieldConex Manager, and online integration documentation. We also provide integration assistance as needed to get your organization live with ShieldConex in a timely and successful manner.

Didn’t find what you are looking for?

Ask us your question.

"*" indicates required fields

Name*
This field is for validation purposes and should be left unchanged.