8 digit BINs and PCI DSS
On April 1, 2022, the payment brands Visa and Mastercard will expand the BIN (Bank Identification Number) of their cards worldwide from 6 to 8 digits. In future, the first 8 digits of a 16-digit credit card number (Primary Account Number, PAN) will be used to identify the card issuer. The BIN is used in many occasions where the use of the full PAN is not necessary — e.g. for routing of transactions, or for reporting.
BINs and PCI DSS
Wherever a full PAN is used, the systems, environments, processes and people must meet the requirements of the data security standard PCI DSS (Payment Card Industry Data Security Standard). As useful as the protection of the PAN by the PCI DSS is – it is not necessary for the BIN. The PCI DSS therefore describes the conditions under which parts of the PAN do not require the same protection as the full PAN. If not the full PAN is stored, processed or transmitted, but only parts of it, the PCI DSS refers to “truncation”. If the full PAN is stored in the background, but not all digits are displayed in an application, the PCI DSS refers to the display as “masking”. In everyday life, the term “crossing out” is also used for the two different measures; from PCI DSS point of view, however, they have to be differentiated.
The following rules previously applied to truncation and masking:
- Masking: PCI DSS Requirement 3.3 states that a maximum of the first six and last four digits (“first 6, last 4”) of the PAN may be displayed, as long as there is no business need to view the full PAN.
- Truncation: PCI DSS Requirement 3.4 lists truncation as an example of rendering PANs unreadable, but does not define it. The permitted formats are rather defined by the international payment card organizations and get summarized by the PCI SSC in FAQ entry #1091. Most of them had agreed on the rule “first 6, any other 4”, which had lasted for many years.
Changed rules for truncation and masking
However, due to the switch to 8‑digit BINs and the need for many companies to process them, the payment brands have now changed their specifications. The current summary in the PCI SSC FAQ entry now defines that “first 8, any other 4” is permitted for truncation for 16-digit PANs. The (test) card number 4012888888881881 is then allowed to be stored and processed in the form 40128888xxxx1881, for example — it is sufficient if any four digits are crossed out after the BIN. Only for shorter PANs, the existing rules “first 6, any other 4” (Discover) or “first 6, last 4” (American Express) remain in place. A corresponding adjustment of the PCI DSS requirement for masking is expected with the change to PCI DSS v4.0.
From a security point of view, removing so few digits is not an improvement — but from a business perspective, the change is probably necessary. It is to be hoped that, overall, this will be offset by other security measures.
In any case, the requirements of the PCI DSS will not prevent the use of 8‑digit BIN in the future.
Caution when combining different formats
Regardless of the length of the BIN, merchants and service providers who work with truncated card data should take care not to weaken the protection by mixing different formats.
- It must be considered that the extended truncation formats only apply to 16-digit PANs. The length of the PAN must therefore be taken into account for truncation during storage.
- Truncation formats such as “first 6, any other 4” theoretically allow the existence of different truncated versions of the same PAN. The above card number might be stored as 40128888xxxx1881 in one system and 401288888888xxxx in another. This is not prohibited — but it must be ensured that no one without an according business need can merge the two versions and thus reconstruct further digits of the PAN — right down to the complete card number.
This also applies if different formats are used for masking and truncation.
- If both truncated PANs and the hash values of PANs are stored in an environment, the two values themselves are initially uncritical. However, if the truncated PANs and their hash values can be related, the original full PAN can be easily reconstructed using rainbow tables. In this case, additional measures must also be taken to prevent the two versions from being merged.