Guide to Card BIN Compliance: Storage and Display of PANs
In recent years, the surge in card issuance has exhausted the traditional 6-digit BIN (Bank Identification Number) space, accelerating the transition to 8-digit BINs. This migration has left many payment, e-commerce, and security professionals with critical compliance questions:
"Does displaying the 'First 8, Last 4' to customer service violate PCI DSS?"
"What are the actual logic differences when handling 6-digit versus 8-digit BINs?"
Bypassing complex theoreticals, this article breaks down the practical compliance requirements under the PCI DSS v4.0.1 standard, focusing directly on the two most common operational scenarios: PAN Display (Masking) and Storage (Truncation).
1. Display: How Much of the PAN Can Be Visible? (PCI DSS Masking Limits)
This is a frequent question from customer service and fraud analysts. The core principle of PCI DSS regarding PAN display is simple: Do not display the full PAN unless there is a legitimate business need.
1.1 The Secure "Universal Display Format"
According to PCI DSS v4.0.1, the Primary Account Number (PAN) must be masked when displayed on screens, paper receipts, or logs. The universally accepted "maximum allowed digits" for display is the "BIN prefix + last 4 digits."
- 6-Digit BIN Cards: 123456******1234 (First 6, Last 4)
- 8-Digit BIN Cards: 12345678****1234 (First 8, Last 4)
Conclusion: Whether dealing with 6-digit or 8-digit BINs, displaying the "BIN + last 4" is the safest baseline. It fulfills operational routing and identification needs without crossing compliance red lines.
1.2 When Is It Allowed to View More Than the Masked Limit?
It is permissible to view the full PAN, but only if two strict conditions are met:
- There is a clear, documented business justification (e.g., fraud investigation or anomalous transaction verification).
- Access is explicitly authorized, restricted by role, and generates an automated audit trail.
Level 1 (General Customer Service): Display only the last 4 digits (***********1234) for basic identity verification.
Level 2 (Fraud Detection / Risk Management): Only when risk rules are triggered (e.g., verifying a stolen card) does the system reveal more digits (or the full PAN), automatically logging a strict audit trail of "Who accessed it, When, and Why."
2. Storage: What Data Can Be Kept? (PAN Truncation Rules)
Aside from strong cryptography, the most common method for storing a partial PAN is Truncation. This allows systems to retain part of the card number for business logic without securing the entire PAN.
2.1 Truncation Boundaries: 6-Digit vs. 8-Digit
To facilitate marketing, discounts, transaction routing, and customer receipts, systems often store the "truncated PAN." The acceptable truncation formats vary slightly by Card Brand. Here are the standard guidelines:
Acceptable PAN Truncation Formats
| PAN / BIN Length | Card Brand | Acceptable Truncation Format |
|---|---|---|
| 16-digit PAN 6 or 8-digit BIN |
Discover JCB Mastercard UnionPay Visa |
Remove at least 4 digits. Maximum storage: First 8 digits + any other 4 digits. |
| 15-digit PAN | American Express | Remove at least 5 digits. Maximum storage: First 6 digits + last 4 digits. |
| < 15-digit PAN | Discover | Maximum storage: First 6 digits + any other 4 digits. |
Storage Formats and Security Implications
| Permitted Storage Format | Example (16-digit PAN) | Security Implication & Recommendation |
|---|---|---|
| 6-digit BIN + Last 4 | 456318******1234 | 6 digits are missing. The cost to brute-force is high (approx. 1 in 100,000 probability). |
| 8-digit BIN + Last 4 | 52395310****1234 | Only 4 digits remain unknown. When combined with PAN validation rules (Luhn algorithm), the brute-force probability increases significantly (approx. 1 in 1,000). |
Although the PCI SSC and most Card Brands permit the storage of the 8-digit BIN, from a strict Data Security perspective, it is highly recommended to continue storing only the "First 6 + Last 4" unless your business logic explicitly requires the 8-digit BIN. Storing more digits exponentially increases the risk of PAN reconstruction in the event of a data breach.
