New 8-digit Bank Identification Numbers (BIN) could complicate PCI truncation rules and create compliance headaches for those required to maintain compliance. Many organizations build their PCI compliance around DSS requirements and how they use cardholder data. A common strategy to simplify compliance uses Primary Account Number (PAN) truncation to make cardholder data unreadable. PAN truncation rules haven't changed much since the early DSS. Today, organizations can keep the first 6 and last 4 digits of PAN (6-4/*). So, any rule changes could affect merchants, service providers, and many others.
Before considering changes, stakeholders should also be aware of all current truncation requirements:
Recently the card brands proposed two changes to help card issuers. The first extended the length of PAN to 19 digits. The second allowed for longer 8-digit BINs. These proposals will change PCI truncation rules. Masking rules shouldn't change as they deal with displays and not a storage.
When we originally saw these, we expected straightforward and easy to implement truncation rules. We imagined combining today’s rules with a first 8 and last 4 rule for the new 19-digit PAN (8-4/19). However, these proposals aren't linked and the possibility of 8-digit BIN with 16-digit PAN could create implementation and compliance challenges.
Notably Visa's bulletin on page 6 contains the following on the continued use of 16-digit PAN and PCI (note the underlined text):
Data Presented on Screens and Reports: PCI DSS provisions already allow users with a legitimate business need to see any or all of the PAN digits. No changes are expected to accommodate the expansion of the BIN length.
Data at Rest: Clients that use truncation as their only method of complying with the PCI requirement for protecting data at rest will need to add one or more of the other acceptable methods for data protection, such as encryption, hashing or tokenization.
Today's truncation rule destroys 6 digits. So, an attacker has a 1 in 100,000 chance of guessing the original PAN (the other 900,000 numbers fail the Luhn test). These odds permeate most PCI guidance and set a risk threshold. The table below shows how fictional PAN truncated under different rules would look:
| PAN | Rule | Trancation | Strength | Compliance |
|---|---|---|---|---|
| 9234567890123455 | 6-4/16 | 923456xxxxxx3455 | 1 : 100,000 | PCI 3.2 |
| 923456789012349 | 6-4/15 | 923456xxxxx2349 | 1 : 10,000 | PCI 3.2 |
| 9234567890120 | 6-4/13 | 923456xxx0120 | 1 : 100 | PCI 3.2 |
| 9234567890123455 | 0-4/16 | xxxxxxxxxxxx3455 | 1 : 50,000,000,000 | PCI 3.2 and FTC (customer receipts) |
| 9234567890123456787 | 6-4/19 | 923456xxxxxxxxx6787 | 1 : 10,000,000 | PCI 3.2 compliant |
| 9234567890123455 | 8-4/16 | 92345678xxxx3455 | 1 : 1,000 | Not PCI 3.2 compliant |
| 9234567890123456787 | 8-4/19 | 92345678xxxxxxx6787 | 1 : 1,000,000 | Visa, MasterCard, but not PCI 3.2 compliant |
Clearly either the rules for truncation or the risk tolerance of the card brands must change. If so, some key questions include:
Implementation uncertainty raises stakeholder concerns.
How will this affect applications that rely upon truncated data?
Consider these possible rule changes (see update note for 2017-5-10 below):
Many of these possible rules could be disruptive and have unforeseen and costly implications to:
Changing payment terminals can be expensive. Recent examples include:
We believe the payments industry needs to look at this important change as soon as possible. Stakeholders must understand the impact of any new truncation rules. In our opinion, the rules need to clear, simple, and easy to implement with a minimum of ambiguity and impact.
We hope this article leads to further industry discussion, analysis, and consensus.
Note: Updated 2017-4-21 to cite Visa Bulletin on Data at Rest
Note: Update: 2017-5-10 The PCI Council today clarified the truncation rules but issues and risks remain.