On April 1, 2022, the payment brands Visa and Mastercard will expand the BIN (Bank Identi­fi­cation 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 trans­ac­tions, or for reporting.

BINs and PCI DSS 

Wherever a full PAN is used, the systems, environ­ments, processes and people must meet the require­ments 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 condi­tions 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 trans­mitted, 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 appli­cation, 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 previ­ously 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 inter­na­tional payment card organi­za­tions and get summa­rized 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 speci­fi­ca­tions. 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 suffi­cient 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 corre­sponding 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 require­ments 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” theoret­i­cally 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 recon­struct 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 recon­structed using rainbow tables. In this case, additional measures must also be taken to prevent the two versions from being merged.