PAN truncation and PCI DSS compliance

In July, Visa Inc. got out ahead of the Payment Card Industry (PCI) Security Standards Council and issued its own best practices for tokenization and PAN truncation. While quite a lot of attention has been paid to the tokenization side of the recently issued guidance, the truncation side has received less attention. We thought it would be useful to address the other side of this vital PCI Data Security Standard compliance issue.

Truncation is, at its most basic, simply the act of making something shorter than it originally was -- cutting something off from a whole. In the case of a credit card number, this means eliminating some portion of the full PAN -- the "primary account number" or the 16-digit number embossed on the front of the card. In practice, this is typically accomplished via "masking" of the number -- substituting another character such as 'X' or an asterisk instead of the actual credit card digits (for example, on receipts, screens and reports).

Generally, in PAN truncation, the first 12 characters are removed, leaving only the final four numbers visible and readable. Most of us have already encountered truncation in practice; when we receive merchant receipts that show a series of asterisks or X'es in front of the last four digits of our credit card number, that's truncation.

The concepts of truncation and masking are not new to PCI DSS compliance. They have been mandatory in requirement 3.3 (Mask PAN when displayed) and a component of requirement 3.4 (Render PAN at a minimum unreadable) of the PCI DSS for years. So why issue PAN truncation best practices now? And what, if anything, does this mean to merchants and their acquiring banks?

The crux of the issue is not whether or not it's a good idea to mask/truncate PANs --it is, and the PCI DSS explicitly requires it. The issue instead centers around whether or not storing the truncated PAN information will negatively impact a merchant's ability to resolve disputes. From a merchant perspective, dispute resolution is probably the biggest deal that there is when it comes to accepting credit cards. The reason for that is the chargeback.

Most cards limit cardholders to $50 worth of liability; meaning, that if someone steals their card, they're not liable for what the thief charges with it. But someone still has to pay. Who decides who gets left "holding the bag?" In practice, the onus is on the merchant to keep and be able to provide very meticulous records (like a signed authorization) in order to successfully resolve disputes. An issuing bank, when a dispute occurs, will issue a "copy request" to the merchant -- this is a request for the original receipt for the product or service. If the merchant cannot respond to the copy request --provide the original sales receipt in a timely fashion -- they automatically get the chargeback.

So what's a truncated PAN or unique token got to do with any of this? As it turns out, quite a lot. Until now, many merchants have believed -- because they were told this by their acquirers -- that they needed to store the full PAN in order to be able to settle disputes and respond appropriately to copy requests prior to chargeback. Some legacy dispute resolution practices (and legacy acquirer systems) required the PAN in order for an acquirer or merchant to even look up a particular transaction record. Merchants saw the problem this way: Keep the PAN and potentially avoid the chargeback or truncate the PAN and start losing dollars.

The PAN truncation best practices spell out in detail how merchants should approach deciding what to keep and what to truncate in the credit card numbers they themselves process. But there's also a message in there for acquiring banks and issuers as well: Support merchants in their efforts to truncate the PAN should they choose to use that approach. Don't require, for example, merchants to retain PANs for dispute resolution; issue merchants alternate identifiers to find transactions in acquirer systems, and don't require merchants to include PAN data in reports/correspondence on the back end. In some cases, this could require changes to an acquirer's processes and/or merchant-supporting applications; however, acquirers are ultimately responsible to the card brands for the compliance status of the merchants they support, so investing in improvements in this area will ultimately pay off in the long term.

So the upshot on the PAN truncation guidance: From a merchant perspective, it's not going to change the world. Truncation remains a viable alternative to meeting the PCI DSS requirements. However, for merchants who have been told by their acquirers that truncation isn't possible because they need to retain the PAN, this should be some good ammunition to effect change and get to a better place. For acquirers, this guidance represents a call to action: Assist your merchants in moving PAN data out of the merchant environment by not requiring PAN storage.

Visa is accepting industry feedback on the PAN truncation best practices until Aug. 31, 2010.

About the authors:

Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.

Ed Moyle is currently a senior manager with CTG's information security solutions practice, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner of SecurityCurve. Ed was previously vice president and information security officer for Merrill Lynch Investment Managers (MLIM,) where he was responsible for coordinating all aspects of information security within the business unit. Ed is co-author of "Cryptographic Libraries for Developers,", and a frequent contributor to the information security industry as author, public speaker, and analyst.