What Every Digit in a Card Number Means

A card number is not random. The first digit says which industry issued it, the first six to eight identify the issuing institution, the digits after that identify your account within that institution, and the last one is a checksum. The structure is defined by a public standard, ISO/IEC 7812, and it is the same on every payment card in the world.

Knowing which digits mean what changes how you write validation code, how you size a database column, and how you decide what is safe to print in a log. It also settles a surprising number of arguments about what a card number does and does not reveal.

The anatomy, visually

Here is a 16-digit number broken into its four parts. The number is synthetic — it follows the format correctly and belongs to nobody.

4  5  3  9  1  4  8  8  0  3  4  3  6  4  6  7
│  └──────────┬─────────┘  └────────┬──────┘  │
│             │                     │         │
│             │                     │         └─ Check digit (Luhn)
│             │                     └─────────── Individual Account Identifier
│             └───────────────────────────────── IIN / BIN (digits 1–8)
└─────────────────────────────────────────────── MII (Major Industry Identifier)

The formal name for the whole string is the Primary Account Number, almost always written as PAN. It is worth adopting the term: PCI DSS, gateway API references, and acquirer documentation all use PAN precisely because “card number” is ambiguous between the printed number, the token that replaced it, and the account behind both.

Note that the MII is not a separate field. It is simply the first digit of the IIN, called out separately because it carries meaning on its own.

The same layout at a different length

Nothing above is specific to 16 digits. Here is a 15-digit American Express number — the canonical test PAN that Amex itself publishes — split the same way:

3  7  8  2  8  2  2  4  6  3  1  0  0  0  5
│  └──────┬──────┘  └───────┬───────┘     │
│         │                 │             │
│         │                 │             └─ Check digit (Luhn)
│         │                 └─────────────── Individual Account Identifier (8 digits)
│         └───────────────────────────────── IIN / BIN (6 digits)
└─────────────────────────────────────────── MII 3 — travel and entertainment

Same four parts, same order, same check digit rule. Only the middle section changed size, absorbing the difference between a 15-digit total and a 16-digit one. That is the property worth internalising: the layout is fixed, the account identifier is elastic, and any code that assumes otherwise is assuming something the standard never promised.

It is also worth saying plainly that all of this is public. ISO/IEC 7812 is a published standard, network prefix ranges appear in every acquirer’s integration documentation, and the Luhn formula has been in the public domain since its patent expired. There is nothing confidential in the structure of a card number — the security of a card has never rested on the layout being secret, which is why explaining it costs nobody anything.

The first digit — Major Industry Identifier

The MII was assigned when the standard was written, in an era when card issuance was expected to spread across industries rather than concentrate in banking. Several ranges still reflect that original intent more than current reality.

Two rows deserve a second look.

MII 2 is where Mastercard expanded. The 51–55 space filled up, so in 2017 Mastercard began issuing in the 2221–2720 range, which sits under an MII originally earmarked for airlines. Any brand-detection code written before that migration and never revisited will classify a 2-series Mastercard as unknown — a real and still-common bug.

MII 9 is reserved for assignment by national standards bodies, which is how domestic card schemes get their space without going through the international allocation process. Troy, Türkiye’s national scheme, begins with 9792 for exactly this reason, and India’s RuPay occupies part of the same range. If you have wondered why Troy numbers look nothing like Visa or Mastercard numbers, this is the answer: they were allocated by a different authority under a different part of the standard.

Digits 1–8 — the IIN / BIN

The Issuer Identification Number identifies the institution that issued the card. In payment engineering it is nearly always called the BIN, for Bank Identification Number — an older term that the standard replaced but the industry never stopped using. Treat IIN and BIN as synonyms in practice.

The IIN was six digits for decades. ISO/IEC 7812-1:2017 extended it to eight, because six digits allow only a million issuer assignments and the space was running out. The allocation is managed by the ISO Registration Authority, a role held by the American Bankers Association.

For a developer, the extension has one immediate consequence: code that slices the first six characters to identify an issuer is now wrong for any card in the extended ranges. The two lengths coexist — some issuers hold six-digit IINs, others hold eight — so you cannot simply change 6 to 8 either. The lookup has to handle both, which is the subject of the BIN and IIN guide.

What a BIN can tell you, given the right data: the network, the issuing bank, the country of issuance, whether the card is credit, debit, or prepaid, and its product level. What it cannot tell you: any of that, without a licensed BIN database. None of it is encoded in the digits. The number is an index into commercial data, and the data is what carries the meaning. The BIN lookup tool shows the difference between what the prefix implies structurally and what an actual database would resolve.

The middle — Individual Account Identifier

Everything between the IIN and the check digit is the issuer’s own account identifier. Its length is whatever is left over:

account identifier length = total length − IIN length − 1

On a 16-digit card with an eight-digit IIN, that leaves 16 − 8 − 1 = 7 digits. On a 15-digit American Express card with a six-digit IIN, it leaves 8. The field has no fixed size, and nothing about its length is standardised across issuers.

Two things about this section are commonly misunderstood.

It is not your bank account number. There is no relationship — not an encoding, not a hash, not a truncation. The issuer maintains an internal mapping from card numbers to accounts, and that mapping is private to the issuer. Nobody holding your card number can derive your account number, your IBAN, or your sort code from it.

It is not stable. Because the card number points at your account rather than containing it, the issuer can hand you a new number whenever it needs to — after a reported loss, after a breach at a merchant, or at natural expiry — while your account, balance, and history carry on untouched. That indirection is the whole design, and it is also why a stolen card number is a smaller problem than a stolen bank account number.

The last digit — check digit

The final digit is a Luhn checksum over everything before it. It catches single mistyped digits and almost every transposition of two adjacent digits, which is precisely the class of error a human makes reading a number off a card.

It proves nothing else. Roughly one in ten random digit strings passes a Luhn check, so a number can be perfectly well-formed and correspond to no account anywhere. The arithmetic, the reference implementation, and the errors it misses are covered in the Luhn algorithm guide; the card validator runs the same check against a number you paste in.

How long is a PAN?

ISO/IEC 7812 permits 12 to 19 digits. Networks picked their formats inside that range and have mostly stayed put.

Sixteen digits dominates so heavily that it gets hard-coded into validation rules, database columns, and input masks by developers who have never held a 15-digit Amex or a 19-digit UnionPay card. The per-network detail, including which prefixes actually occur at each length, is in the length reference.

What is not in the card number

The negative space is as informative as the structure. A PAN does not contain:

• A name. Cardholder name is a separate field, and on virtual cards it may not exist at all.
• A balance or credit limit. Those live in the issuer’s ledger, not in the digits.
• An expiry date. Separate field, printed separately, sent separately.
• A CVV. Separate value, computed by the issuer from the PAN and expiry using keys only the issuer holds.
• A credit-or-debit flag. That comes from a BIN database, not from the number.
• A country. Also BIN data. The MII does not encode geography.
• An account number. As above — the mapping is internal to the issuer.

If you need any of those facts, you need a source other than the number. Inferring them from digit patterns is how validation code acquires assumptions that break the first time an unusual card arrives. The generator exposes this clearly: it produces structurally correct numbers with no issuer behind them, which is exactly what a format test needs and exactly what an authorisation test cannot use.

Storing and displaying a PAN

If a card number reaches your systems at all, PCI DSS applies. The practical rules:

Masking. Display no more than the first six and the last four digits. Most interfaces show only the last four, which is enough for a customer to recognise a card and not enough to reconstruct one. The PCI Security Standards Council publishes the current requirement text.

Storage. If you store a PAN it must be rendered unreadable — strong cryptography, with key management to match. The better answer is not to store it: let your processor tokenise, keep the token, and stay out of scope entirely.

Logging. A PAN must never reach application logs, error trackers, analytics events, or a bug report screenshot. This is where card data leaks in practice — not through a database breach but through a stack trace containing the full request body.

Schema. Use VARCHAR(19) at minimum. Two failure modes are worth naming because both are silent:

• VARCHAR(16) truncates 19-digit cards. The row saves without error and the number is now wrong.
• An integer column drops leading zeros and overflows: a 19-digit value exceeds the range of a 64-bit signed integer. Card numbers are strings from input to storage, always.

A minimal masking helper:

function maskPan(pan) {
  const d = String(pan).replace(/\D/g, '');
  if (d.length < 8) return '••••';
  return `${'•'.repeat(d.length - 4)}${d.slice(-4)}`;
}
// 4539148803436467 → ••••••••••••6467
// 378282246310005  → •••••••••••0005

The length guard matters: without it, a short or empty input would produce a “mask” that reveals most of what it was given. The full compliance picture — what puts a system in scope, what takes it out, and what auditors actually ask for — is in the PCI DSS guide for developers.