6-digit vs 8-digit BINs: the ISO/IEC 7812 change explained

If your code contains pan[:6], a CHAR(6) column called bin, or a masking function that prints 411111******1111, this change concerns you. Eight-digit BINs have been in circulation since 2022, they coexist with six-digit BINs, and the safe way to handle them is to stop assuming any fixed length.

What changed in ISO/IEC 7812

ISO/IEC 7812-1 is the international standard that defines how card numbers are built: an issuer identification number (IIN, commonly called the BIN), an individual account identifier, and a Luhn check digit. Its earlier editions used a six-digit IIN. The 2017 revision defined an eight-digit IIN and set out a path for converting the six-digit ranges.

The reason was capacity. Six digits give one million possible prefixes, and a large share of them begin with the few major industry identifiers used for bank cards. With new issuers, fintech programs, virtual cards and product-specific ranges, the supply of six-digit BINs was running short. Adding two digits multiplies the space by one hundred.

The total length of the card number did not change:

Nothing about the number tells you which kind of BIN it has. 4111 1111 1111 1111 looks the same whether its issuer owns the six-digit range 411111 or the eight-digit range 41111111. Only BIN data can say how long the prefix is.

The network timeline

The standard allows eight digits; the card networks decided when to use them. Visa and Mastercard set April 2022 as the date by which acquirers and processors had to be able to handle eight-digit BINs. As Deloitte summarized the plans at the time:

• Visa said it would only issue eight-digit BINs after April 2022.
• Mastercard began issuing eight-digit BINs after April 2022 but did not set a date to stop issuing six-digit BINs, and asked acquirers to be ready for eight-digit BINs and 11-digit account ranges.
• Other networks — American Express, Discover/Diners Club and UnionPay — had not announced timelines then.

Two consequences matter for developers. First, existing six-digit BINs were not forced to convert, so the payments industry runs on both lengths and will for years. Second, an issuer that converts can split one six-digit range into as many as one hundred eight-digit ranges and assign them to different products, countries or program managers. A six-digit lookup then returns a less precise — or simply wrong — answer.

What PCI DSS allows you to keep

Longer BINs raised an obvious question: if the BIN is eight digits, may you keep eight digits? The PCI Security Standards Council answers this in its FAQs, which distinguish between masking (hiding digits when displaying a PAN) and truncation (permanently removing digits from a stored PAN).

Masking: what may be displayed

PCI DSS Requirement 3.4.1 says no more than the BIN and the last four digits of the PAN may be displayed on screens, reports and similar outputs, unless a documented business need justifies more. PCI SSC FAQ 1492 confirms this applies to eight-digit BINs. In practice, most interfaces should show far less: a support agent rarely needs more than the last four digits.

Truncation: what may be stored

FAQ 1091 lists the maximum digits that may be retained when truncation is the method used to make stored PAN unreadable:

These are maximums, not targets. The PCI SSC blog on eight-digit BINs notes that first six, last four remains the format accepted by all payment brands, and that for PAN lengths not covered in the FAQ you should confirm your format with each brand. Truncation is also only one of the acceptable methods: FAQ 1492 lists encryption of the whole PAN, index tokens and one-way hashes too, and requires hashes generated after March 31, 2025 to be keyed cryptographic hashes (Requirement 3.5.1.1).

Where six-digit assumptions hide in your code

Most systems built before 2022 encoded the six-digit BIN somewhere. The usual places:

Extracting the BIN safely in code

Don’t slice a fixed number of digits and call it “the BIN”. Keep a bin6 and a bin8 candidate, let the lookup decide which one matches, and enforce the PCI limits in one place. This helper returns only what you are allowed to keep for the PAN length:

def card_prefixes(pan: str) -> dict:
    """Prefix candidates and last 4 for lookups and storage. Never returns the full PAN."""
    digits = ''.join(c for c in pan if c.isdigit())
    if not 12 <= len(digits) <= 19:
        raise ValueError('not a card number length')
    out = {'bin6': digits[:6], 'last4': digits[-4:], 'length': len(digits)}
    # PCI SSC FAQ 1091: "first 8, any other 4" applies to 16-digit PANs only.
    if len(digits) == 16:
        out['bin8'] = digits[:8]
    return out

def lookup(prefixes: dict, bin_table: dict):
    """Longest-prefix match: an 8-digit range wins over the 6-digit range it came from."""
    for key in ('bin8', 'bin6'):
        if key in prefixes and prefixes[key] in bin_table:
            return bin_table[prefixes[key]]
    return None

print(card_prefixes('4111 1111 1111 1111'))
# {'bin6': '411111', 'last4': '1111', 'length': 16, 'bin8': '41111111'}

On the database side, store ranges rather than single prefixes, so a six-digit row and the eight-digit rows carved out of it can live side by side:

CREATE TABLE bin_range (
  id          INTEGER PRIMARY KEY,
  prefix      VARCHAR(8) NOT NULL,     -- 6 or 8 digits
  prefix_len  SMALLINT   NOT NULL,     -- 6 or 8
  network     VARCHAR(20),
  issuer      VARCHAR(120),
  country     CHAR(2),
  funding     VARCHAR(10)              -- credit / debit / prepaid
);
CREATE UNIQUE INDEX bin_range_prefix ON bin_range (prefix);

-- Longest-prefix lookup for one card (pass bin8 and bin6 from application code)
SELECT * FROM bin_range
WHERE prefix IN (:bin8, :bin6)
ORDER BY prefix_len DESC
LIMIT 1;

A migration checklist

1. Inventory. Search code, SQL, ETL jobs, dashboards and log processors for six-digit assumptions: [:6], substr(pan, 1, 6), CHAR(6), \d{6}.
2. Get eight-digit BIN data. Ask your processor or BIN data provider for a table with both lengths and a defined update schedule.
3. Switch to longest-prefix matching and keep a fallback for “unknown”.
4. Review storage. Decide per use case whether you need six or eight digits. Document the business reason if you keep eight, and confirm the PAN length rules.
5. Review masking. Make the last four digits the default on every screen and export.
6. Re-test routing and fraud rules with cards from both kinds of ranges, including 15-digit American Express and 19-digit cards.
7. Re-baseline analytics. Metrics grouped by six-digit BIN will shift when issuers split ranges; group by issuer and product instead.
8. Update test fixtures. Add test numbers from eight-digit ranges so that regressions show up in CI.

Testing with eight-digit BINs

You don’t need real cards to test any of this. Generate format-valid numbers from a specific eight-digit prefix with our card generator (enter the prefix in the BIN field), run them through your lookup and masking code, and confirm that the eight-digit row wins over its six-digit parent. For end-to-end tests that reach a payment gateway, use the gateway’s documented test card numbers, because sandboxes only recognize those. Keep real card numbers out of these environments entirely; our guide to test data and PCI DSS explains why.

To see what a BIN record looks like, try any prefix in the BIN checker, and read what a BIN lookup tells you for the limits of that data.