What’s in a number? Tokenization

Recently, Visa Europe launched its Private BIN (Bank Identification Numbers) range for organisations that want to create internal identifiers. These have the same format as Visa Primary Account Numbers (PANs) but will never be used in the ‘real world’. There are two main reasons to do this:

1. For test purposes – to test a payment system for instance
2. To create tokens which can be used in place of a PAN within internal systems
3. Companies can therefore use these two 6-digit numbers internally, knowing that Visa will never issue them to real entities. The numbers are:

• 468738
• 468739

These 6-digit numbers are important. They represent something quite special in the world of PCI DSS, tokens, and PCI audit de-scoping. It means that when service providers issue tokens (like Eckoh’s OneProx system) we can be confident that by starting the tokens with 468738 or 468739, our clients will know the difference between a payment card number and a token. Even when tokens are Luhn-compliant, they can still be detected as tokens, and not be mistaken for real PANs.

So why is this such a big deal?

Like many applications which use tokens, both OneProx and our CallGuard DataShield software have always been able to issue Luhn-compliant tokens which plug straight into our clients’ existing websites, CRM systems, payment gateways and applications. Luhn-compliant tokens are great, because they can be used in exactly the same systems or processes as card data without requiring any changes to them. And after all, Luhn-compliant tokens will pass any existing client-side Luhn checking functions. However, it’s always been very difficult (or impossible) to determine whether a given number residing in a database field is a token, or a real PAN. So how does a merchant know whether all the card data has truly been flushed out after implementing a token system?

By starting a token with a Visa Private BIN number, Luhn-compliant tokens are easily differentiable from card data. And yet these tokens are NOT cardholder data, so merchants’ systems can be removed from PCI DSS scope.

The Visa Private BIN range also has another important benefit for companies already using data discovery tools. Once the cardholder data discovery companies (such as Ground Labs and Foregenix) ‘lock’ these two magic numbers into their detection systems, companies will be able to run tokens and ‘actual’ cardholder data on the same databases, networks etc. and easily be able to determine which is which. This is great for companies transitioning from ‘live’ cardholder data to tokens over a period of time (not instantly). Of course, there are two important caveats here:

1. Token providers will need to start their tokens with 468738 or 468739. This isn’t always possible, particularly if ‘first 6’ formatting is being preserved.
2. Merchants will need to make sure that the Private BINs are not submitted for processing. (They aren’t the beginning of real card numbers, so they won’t work!)

However, at least the payments industry now has one sensible way of detecting token needles in a haystack of PANs.