The acceptable format for the truncation of 16-digit PANs with both 6-digit and 8-digit BINs has been changed for all card brands to “first 8, any other 4” (PCI SSC FAQ 1091).
My observation is that the brands’ risk appetite for protecting PAN has changed, and that this change may signal a direction of travel for PCI DSS which now, effectively, exists to protect just three digits of a PAN.
1. Background
The bank identification number (BIN) identifies the issuer of a payment card. Typically this was the first six digits of the card, so for a card with the primary account number (PAN) of 1234 5678 9012 34561, the BIN (in italics) is 123456. It is often important for merchants and processors to retain the BIN because it can determine how they route transactions for authorisation and for validating their acquiring charges.
The payment card industry is running out of BINs and so some card brands (initially Visa) are issuing payment cards with 8-digit BINs. So now, for a card with an 8-digit BIN and the primary account number (PAN) of 1234 5678 9012 3456, the BIN is 12345678.
2. Truncation
Permanently removing a number of digits from a PAN is known in PCI terms as truncation. The digits removed are replaced by a character - typically an X.
For a 16-digit PAN, this required removing six digits from the PAN, which means the truncated version of the PAN 1234 5678 9012 3456 would be 1234 56XX XXXX 3456. The permissible ways of truncation a PAN is described in PCI SSC FAQ 1091.
For 16-digit BINs from all the card brands, this used to be expressed as “First six digits, any other four”.
This truncation format meets the needs of entities to use the BIN for routing and accounting reasons, but also allows the last four numbers to be printed or revealed to the cardholder.
2.1 A truncated PAN is not a PAN
Many entities only store, process or transmit truncated PANs in their entire environment, or within discrete environments that are isolated from their cardholder data environment(s). Environments that contain just truncated PANs do not need to be protected by PCI DSS’s requirements (see FAQ 1117).
“Systems that store, process, or transmit only truncated PANs (where a segment of PAN data has been permanently removed) may be considered out of scope for PCI DSS if those systems are adequately segmented from the cardholder data environment, and do not otherwise store, process, or transmit cardholder data or sensitive authentication data. This applies to any truncation that meets the acceptable PAN truncation formats specified in FAQ 1091.”
2.2 Is a truncated PAN of use to a criminal?
If a criminal gets access to a truncated PAN and they want to turn it back into the ‘real’ PAN to make fraudulent transactions, they are going to have to repeatedly guess the missing six digits. They do this by making multiple authorisation requests.
Because of how the Luhn checksum in a PAN works, the criminal would only need to guess five of the missing digits, but that still gives them 100,000 (10^5) different possibilities. Therefore you can deduce that all the brands who issued payment cards with 16-digit BINs originally decided that if there were 100,000 possibilities to reconstruct a real PAN from a stolen truncated PAN, this was within their risk appetite.2
3. How to truncate a 16-digit PAN with an 8-digit BIN
With the addition of 8-digit BINs, the card brands obviously had a problem — what would be the right truncation format for it to not be classed as a PAN? If you’ve been following FAQ 1091 you’ll have noticed that there have been three answers to that question over the past 10 months.
3.1 First answer : First 6 any other 4, for 6- and 8-digit BINs
Initially the card brands decided that the same “first six any other four” truncation rule would also be fine for PANs with 8-digit BINs.
Source: Internet Archive Wayback Machine FAQ 1091 from April 2021
Therefore, if an entity wanted to truncate an 8-digit BIN PAN, to take our example of 1234 5678 9012 3456 (the BIN is in italics) the correct truncation which maintains the entire BIN would be 1234 5678 XXXX XX56.
But the problem with truncating PANs like this is that only the last two digits of the PAN are available, which doesn’t allow many existing uses of truncated PANs, specifically verifying which card a consumer used or including a reference on a consumer receipt, which traditionally would show the last four digits of the PAN - i.e. XXXX XXXX XXXX 3456. It may also have been incompatible with some regional regulations.
So FAQ 1091 changed.
3.2 Second answer: First 8 any other 4, for 8-digit BINs only
The next decision of Visa and Mastercard (but not Discover or UnionPay3) was to have different truncation rules for PANs with 6- or 8-digit BINs.
Source: Internet Archive Wayback Machine FAQ 1091 from September 2021
So any (Mastercard or Visa) PAN could be truncated to BIN+last 4 (whether the BIN was 6- or 8-digits):
For a 8-digit BIN, 16-digit PAN — 1234 5678 XXXX 3456
For a 6-digit BIN 16-digit PAN — 1234 56XX XXXX 3456.
But having different truncation rules for different BIN lengths is complex because:
Every entity would need almost real-time updated BIN tables to know how to correctly truncate every PAN. Any errors would potentially bring an entity’s environment into scope of the PCI DSS requirements. In some cases that would mean every POI4 would need to make this decision in real-time.
Every assessor would need to verify all truncated PANs against BIN tables to validate that they were truncated correctly and that they were “not a PAN”.
I shudder to think how sensitive data detection software and DLP tools would have coped!
I guess after industry feedback, FAQ 1091 changed again.
3.3 Third answer: First 8 any other 4, for both 6- and 8-digit BINS
Now - as of January 2022 - 16 digit PANs with both 6- and 8-digit BINs can be truncated in the same way:
At least 4 digits removed. Maximum digits which may be retained: “First 8, any other 4”
Source: PCI SSC FAQs, January 2022
Any 16-digit PANs can be truncated to 1234 5678 XXXX 3456, irrespective of the BIN length.
4. Now PCI DSS only protects three digits!
What’s interesting is not how the rules have changed over the past ten months5 but that it illustrates that the brands’ risk appetite has changed.
With just four digits of a PAN removed, a criminal now in possession of a truncated PAN only has 1,000 possible guesses (10^3 because of the Luhn check digit) to find the ‘real’ PAN — and I assume that this must now be within the brands’ risk appetite.
It also means that the whole of PCI DSS now just exists to protect three digits of a sixteen digit number.
To be clear, according to FAQ 1091 and FAQ 1117, 1234 5678 9012 3456 is a PAN6 and needs to be protected by all of PCI DSS’s 280-ish requirements; 1234 5678 XXXX 3456 is not, and it doesn’t.
Over the next couple of years it will be interesting to see:
If the industry continues to agree that protecting those three digits with all of the PCI DSS requirements is still a reasonable “ask” from the brands.
How will regulators (e.g. those enforcing the GDPR) view a truncated PAN that only protects 3 digits — will their risk appetite for what’s “appropriate” to protect a payment instrument match the brands? Is a truncated PAN personal data?
Or because of EMV, device-based payments, and secure customer authentication, is PAN alone not a payment instrument and so it doesn’t really need to be protected anymore?
5. This story hasn’t finished
The move to 8-digit BINs still leaves many questions, and I’m sure this is a topic I’ll be revisiting. Some final thoughts:
The industry has invested millions in systems that truncate PANs to remove them from the merchant environment but create what are effectively payment-tokens using format-preserving tokenisation (FPT). Will those systems be able to be changed?
Where systems use format-preserving encryption (FPE), can these solutions adapt to the new truncation format? Will new NIST-approved FPE algorithms be required?
How will P2PE solution providers change their products?
How will a merchant ensure that they don’t have two different “first 8 plus any other four” truncation solutions (perhaps from different vendors) meaning that in an environment a merchant may have the same PAN truncated twice as 1234 5678 XXXX 3456 and as 1234 5678 9012 XXXX - ie the whole PAN effectively exists in the environment?
If you found this analysis useful or informative, subscribing will encourage me to write more (and if you thought it rubbish, the converse is also true).
I know this isn’t a real PAN - the BIN range isn’t a payment card BIN range and it doesn’t pass the Luhn check. Reading this post does not bring your computer into scope of PCI DSS :-) and hopefully it also means some idiot DLP software doesn’t block this email.
This is a brand risk decision, not a decision of the PCI SSC, which is why the table in FAQ 1091 may list separate rules on a per-brand basis.
Sometime between April and September 2021, UnionPay became a Strategic Member of the PCI SSC, which is why their information now appears in this table.
POI: Point of Interaction, PCI-speak for the terminal that reads the card, also generally know as PEDs or in the UK “Chip and PIN machines”. Many POIs just would not have the processing or RAM capacity to lookup every PAN in a BIN table.
Which indicates how the brands have obviously been responsive to industry’s concerns (which is good thing).
See 1 above.