The Number
12.0 What this chapter gives you#
- You will be able to verify a card number by hand, on paper, in about ninety seconds, and to build the check digit rather than merely test it.
- You will be able to say exactly what a commercial BIN lookup can and cannot honestly tell you.
- You will be able to explain why hard-coding a six-digit issuer identifier is now a defect, and why six-digit and eight-digit identifiers coexist rather than one having replaced the other.
- You will be able to say why the schemes route on a nine-digit or eleven-digit account range rather than on the issuer identifier, and what a six-digit classification gets structurally wrong.
- You will be able to demonstrate the check digit’s two known blind spots by hand, and derive why 0 and 9 is the only adjacent transposition it misses.
- You will be able to explain why anchoring the doubling at the rightmost digit is the only safe implementation, and why anchoring from the left makes every American Express card appear invalid.
- You will be able to account for the four representations of one expiry date across the printed card, the stripe, the chip and the authorisation message, and say which one carries a day.
- You will be able to say why an expired card does not fail at the chip, and what the terminal verification results actually record.
- You will be able to give the five separate forces that make card number length vary, without conflating them.
- You will be able to store, mask and truncate an account number correctly, and explain why masking and truncation are different controls with different limits.
Take a card out of your wallet and look at the long number on the front of it. Sixteen digits, usually, in four groups of four. Most people assume it is a serial number — that somewhere there is a very large list, and your card is entry number four trillion and something on it.
It is not that. Almost none of those digits are about you. The number is an address. It is structured, it is hierarchical, and it is read from the left in exactly the way a postal address is read from the bottom up: which country, which town, which street, which house. The first digits say which institution in the world is answerable for this card. The middle digits say which account at that institution. And the final digit is not information at all — it is a checksum, a digit whose only job is to catch the mistakes made by human beings and card readers.
This matters more than it sounds. When a terminal in a petrol station in Carlisle reads a card issued by a bank in Manila, nothing in that terminal knows anything about Philippine banking. What it knows is how to look at the leading digits, find a matching row in a table it was given, and work out where to send the message. The number is the routing key for the entire global card system, and everything in the next several chapters — the cryptogram, the authorisation message, the interchange fee — depends on the leading digits of the number being correct and being interpreted correctly.
This chapter takes the number apart. By the end of it you will be able to verify a card number by hand, on paper, in about ninety seconds, and you will know exactly what a commercial “BIN lookup” can and cannot honestly tell you.
The plain version#
Think of a telephone number.
If someone reads you a number starting +44 20, you already know two things before you have heard the rest. 44 means the United Kingdom. 20 means London. You have not been told whose phone it is, or whether they are in, or whether they will answer. But you know where to send the call, and that is enough to get started.
A card number works the same way, with one extra trick at the end.
The first eight digits say which bank or card issuer this card belongs to. Not which country, exactly, and not which branch — which institution, out of the tens of thousands in the world that issue cards. Those eight digits are handed out by a registry, the way telephone dialling codes are handed out, so that no two issuers can ever claim the same ones.
The digits after that say which account at that institution. That part is the issuer’s own business. It might be sequential. It might be random. Nobody outside the bank needs to know which, and in fact banks deliberately make it hard to guess.
And the very last digit is a check digit. It carries no information about you, your bank or your account. It exists solely so that if somebody reads the number out wrong, or types it wrong, or a card reader misreads a smudged digit, the mistake is caught immediately instead of sending a payment to a stranger.
Why a check digit is worth a whole digit#
Imagine reading a sixteen-digit number aloud over a bad phone line. Two things go wrong constantly. Either one digit gets heard wrong — a five becomes a nine — or two neighbouring digits get swapped, because human beings swap things. ...4536... becomes ...4356... and nobody notices.
You could catch this by reading the number twice. That is slow and people cheat. So instead the last digit is made to depend on all the others, by a rule that both ends of the line agree on. If the sixteenth digit does not match what the first fifteen say it should be, something has gone wrong, and you know before you send any money anywhere.
Giving up one digit out of sixteen costs you a tenth of your available numbers. Catching essentially every single-digit typo and nearly every swap is worth vastly more than that.
Working it out by hand#
The rule is called the Luhn formula, and it is genuinely simple enough to do at a kitchen table. Here it is on a real card number — a test number published by payment gateways for exactly this purpose, so it belongs to nobody:
4012 8888 8888 1881
Write it out with the positions numbered from the left.
Step one: double every second digit, starting from the first one on the left. (That works because this number has sixteen digits, an even count. Come back to that in a moment.)
Step two: if a doubled digit comes out bigger than nine, subtract nine. So an 8 doubles to 16, and 16 minus 9 is 7. A 6 doubles to 12, and 12 minus 9 is 3.
Step three: add up everything.
| Position | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Digit | 4 | 0 | 1 | 2 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 1 | 8 | 8 | 1 |
| Double? | yes | no | yes | no | yes | no | yes | no | yes | no | yes | no | yes | no | yes | no |
| Becomes | 8 | 0 | 2 | 2 | 7 | 8 | 7 | 8 | 7 | 8 | 7 | 8 | 2 | 8 | 7 | 1 |
Add the bottom row: 8 + 0 + 2 + 2 + 7 + 8 + 7 + 8 + 7 + 8 + 7 + 8 + 2 + 8 + 7 + 1.
Take it in stages so you can check yourself: the first four come to 12. The next four (7, 8, 7, 8) come to 30, running total 42. The next four (7, 8, 7, 8) come to 30 again, running total 72. The last four (2, 8, 7, 1) come to 18. Total: 90.
Ninety ends in a zero. That is the whole test. If the total ends in zero, the number is well formed. If it does not, somebody made a mistake.
Watch it catch a mistake#
Now break the number deliberately. Swap the thirteenth and fourteenth digits, so ...1881 becomes ...8118. That is exactly the sort of slip a tired person makes.
Position 13 was a 1, doubled to 2. It is now an 8, which doubles to 16, minus 9 is 7. That is five more than before. Position 14 was an 8, not doubled, contributing 8. It is now a 1, contributing 1. That is seven less than before. Net change: minus two. The new total is 88.
Eighty-eight does not end in zero. Rejected, in one pass, before any message goes anywhere.
Try a single-digit error instead. Change the fifth digit from 8 to 3. It is a doubling position, so where it used to contribute 7 (from 16 minus 9) it now contributes 6. Total drops to 89. Rejected again.
Building the check digit rather than testing it#
The bank does the same arithmetic backwards. It decides the first fifteen digits — 401288888888188 — and then works out what the sixteenth must be.
Run the sum on those fifteen digits with a zero standing in for the check digit. Everything above stays the same except position 16, which is now 0 instead of 1, so the total is 89 instead of 90.
Whatever the check digit is, it sits in a non-doubling position, so it just gets added. You need a total ending in zero. 89 needs 1 more. The check digit is 1 — which is precisely what is printed on the card.
The general rule: take the total ending in whatever it ends in, and the check digit is the number that brings it up to the next multiple of ten. If your running total ended in 4, the check digit is 6. If it ended in 0 already, the check digit is 0.
Two warnings you can act on tonight#
First, you can verify your own card this way in about a minute and a half, on paper. Do it on paper. Do not type your card number into a website that offers to “check if your card number is valid”, because such a site has just been given your card number and you have learned nothing you could not have worked out with a pencil.
Second — and this is the part people get wrong — passing this test does not mean the card exists. It means the number is spelled correctly. A number can pass the Luhn test perfectly and correspond to no account anywhere on earth. It is a spell-checker, not a lock.
The date#
The other number on the front is the expiry date, printed as month and year: 09/28 means September 2028.
Cards expire for boring reasons rather than sinister ones. The plastic wears, the chip contacts corrode, the magnetic stripe demagnetises in a pocket next to a phone, and the bank wants a periodic excuse to check that you still live where it thinks you live. A typical card runs three to five years.
The single fact people get wrong: a card marked 09/28 is good through the whole of September 2028, right up to the last second of the 30th. It stops working on 1 October. “Valid thru” means exactly that.
Why some cards are shorter#
If you have an American Express card in the drawer, it has fifteen digits, not sixteen, grouped 4-6-5 rather than 4-4-4-4. Diners Club cards have historically had fourteen. Some debit cards abroad have nineteen.
The reason is history rather than logic. The card schemes invented their own numbering before there was an international standard, the standard was written afterwards to accommodate what already existed, and it set a ceiling — no more than nineteen digits — rather than a fixed size. Sixteen won because it was what the two biggest schemes chose, and because acceptance equipment built in the 1980s got used to it.
The arithmetic still works on all of them. But note the trap: because the doubling is anchored at the check digit on the right, a fifteen-digit number doubles a different set of positions counted from the left than a sixteen-digit number does. On a fifteen-digit Amex number you double the second, fourth, sixth digit and so on from the left. Get that backwards and every American Express card in the world will appear invalid to your software — which is, reliably, the first bug in every hand-written card validator ever shipped.
Where the plain version stops being true#
The telephone-dialling-code picture is the right shape and it is wrong in four specific places, each of which costs money when a working system relies on it.
The issuer prefix is not six digits, and hard-coding six is now a defect#
For roughly forty years the leading six digits were the issuer’s identifier, and an entire generation of payment software, database schemas, fraud rules and merchant reports was written on that assumption. The relevant international standard changed in January 2017. The issuer identifier is now eight digits, and both Visa and Mastercard made support for eight-digit issuer identifiers mandatory for their participants from their April 2022 releases.
The plain version above already used the correct figure, which is why it is worth stating the correction loudly: any system built before about 2019 almost certainly assumes six, and a great deal of tooling still in production does. Six-digit and eight-digit identifiers now coexist — the old ones were not withdrawn, they were subdivided — so code that assumes either number in isolation is wrong.
Even eight digits is not how the network actually routes#
Here is the correction that surprises practitioners. The issuer identifier tells you the institution. It does not tell you the product, and the product is what determines the interchange fee, the debit-or-credit distinction, whether the card is commercial, and which processing rules apply.
For that, the schemes route on something finer than the issuer identifier: an account range. Visa’s is nine digits; Mastercard’s is eleven. A single issuer identifier is deliberately carved into multiple account ranges so that one bank can put its consumer debit, premium credit and corporate cards on the same identifier with different behaviour.
Visa has told its acquirers explicitly, in its own operations bulletins, to process on the complete nine-digit account range record rather than the first six digits. A merchant system that classifies a card by its leading six digits is not merely out of date; it can and does classify cards into the wrong fee category.
Luhn is arithmetic, not security, and it never was#
The check digit’s rule was patented by an IBM engineer in the 1950s, has been published for over sixty years, and is in the public domain. It is in every standard, every textbook and roughly ten thousand GitHub repositories. It is designed to catch accidents, and it does that superbly. It is not designed to resist an adversary, and against one it is worthless — generating millions of Luhn-valid card numbers is a first-week programming exercise, and “card testing” attacks do exactly that, then hunt for the live ones by firing small authorisations at merchants.
There is a second, subtler failure that follows from the arithmetic itself. Luhn catches every single-digit error and every adjacent transposition except one pair, and it misses certain twin-digit substitutions. You can prove both by hand.
Take the four-digit number 1099. Doubling the first and third: 1 becomes 2, 0 stays 0, 9 becomes 18 which reduces to 9, 9 stays 9. Total 2 + 0 + 9 + 9 = 20. Valid. Now swap the middle two digits to get 1909. Doubling the first and third: 1 becomes 2, 9 stays 9, 0 becomes 0, 9 stays 9. Total 2 + 9 + 0 + 9 = 20. Also valid. Swapping an adjacent 0 and 9 is invisible to Luhn, always, everywhere, on every card number in the world.
The same trick works on twins. 1222 gives 2 + 2 + 4 + 2 = 10, valid. Replace the middle 22 with 55 to get 1552, and you get 2 + 5 + 1 + 2 = 10, also valid. The pairs that collide this way are 22 against 55, 33 against 66, and 44 against 77.
None of this makes Luhn a bad check. It makes it a known check with known blind spots, which is a different thing from a guarantee.
The number does not identify a card, and may not identify a bank account#
Three separate collapses of the plain version here.
A single card number can belong to several pieces of plastic. Replacement cards, and additional cardholders on the same account, may carry the same number distinguished only by a separate sequence number that is not printed on the card at all and lives only in the chip.
Worse for anyone building a lookup: the number in front of you may be a network token rather than a card number. When a card is added to a phone wallet or stored by a large merchant, the scheme can issue a substitute number, of the same length, that passes the Luhn test and looks in every respect like a card number, but resolves to the real one only inside the scheme’s own vault. This is the subject of a later chapter. Its consequence here is immediate: some of the numbers flowing through your systems are not the numbers printed on any card, and a lookup on their leading digits does not describe the issuer’s card product.
And finally, the number does not identify a bank account. A card is an access mechanism attached to an account. The mapping is the issuer’s private business, it is not one-to-one in either direction, and nothing in the number exposes it.
The technical version#
ISO/IEC 7812-1: what the standard actually specifies#
The governing document is ISO/IEC 7812-1, “Identification cards — Identification of issuers — Part 1: Numbering system”. The current text is the fifth edition, published January 2017, confirmed on systematic review in 2022 and still current as of writing in 2026. Its companion, ISO/IEC 7812-2, covers application and registration procedures rather than format.
The standard defines the Primary Account Number (PAN) as three concatenated components:
| Component | Length | Assigned by |
|---|---|---|
| Issuer Identification Number (IIN) | 8 digits | Registration Authority |
| Individual account identifier | 1 to 10 digits | The issuer |
| Check digit | 1 digit | Computed |
The maximum total PAN length is 19 digits, unchanged by the 2017 revision. The fifth edition’s substantive change was to fix the IIN at eight digits rather than six. The mechanics of that change matter: existing six-digit IINs were not invalidated, they were converted into a block of one hundred eight-digit IINs. The six-digit IIN 412345 becomes the eight-digit block 41234500 through 41234599, all still belonging to the same institution. This is why six-digit and eight-digit identifiers coexist rather than one having replaced the other.
Two further consequences are stated in the standard and are frequently missed. Issuers holding eight-digit IINs are required to issue a minimum PAN length of ten digits — you cannot have an eight-digit issuer identifier, a check digit and no account identifier at all. And with an eight-digit IIN and a nineteen-digit ceiling, the individual account identifier can be at most ten digits.
The Registration Authority for ISO/IEC 7812 is the American Bankers Association; administration passed to CUSIP Global Services acting on the ABA’s behalf, reported as of February 2024.
The Major Industry Identifier#
The first digit of the IIN is the Major Industry Identifier (MII), a classification inherited from the earliest days of the standard.
| MII | Category |
|---|---|
| 0 | ISO/TC 68 and other industry assignments |
| 1 | Airlines |
| 2 | Airlines and other industry assignments |
| 3 | Travel and entertainment |
| 4 | Banking and finance |
| 5 | Banking and finance |
| 6 | Merchandising and banking/finance |
| 7 | Petroleum |
| 8 | Healthcare, telecommunications and other industry assignments |
| 9 | National assignment |
Treat this table as archaeology, not as operational data. The MII is a historical classification with almost no present-day predictive value, and the clearest proof is Mastercard’s own expansion: when Mastercard ran short of numbers under its traditional 51–55 prefixes it was allocated the range 222100–272099, announced in November 2014 with participant systems required to be ready by October 2016. Every one of those cards is a mainstream consumer payment card whose MII digit is 2, a value the table above labels “airlines”. Any code branching on the first digit to guess what kind of card it is holding is guessing.
The one MII with a live structural rule is 9, reserved for assignment by national standards bodies, where the convention is that the three digits following the 9 are the ISO 3166 numeric country code and the remainder of the number is defined nationally. In practice the national card schemes largely did not take up this space, choosing ranges allocated to them under the banking MIIs instead.
BIN, IIN and account range#
The industry says BIN, for Bank Identification Number. The standard says IIN. For payment cards they denote the same leading digits; BIN is the older, commercial term and it has stuck so firmly that the schemes themselves use it in their bulletins. Where the two words genuinely diverge is scope: IIN is a general card-numbering concept covering non-payment cards too, whereas BIN in scheme usage carries specific commercial and licensing meaning.
The migration, scheme by scheme, as documented in the schemes’ own material:
Visa. Effective with the April 2022 VisaNet Business Enhancements release, Visa began assigning eight-digit issuer BINs and required all clients to process using the eight-digit BIN structure. Visa will not assign new six-digit issuing BINs after that release, but both six-digit and eight-digit BINs exist in the estate. Notably, acquirer numerics remain six digits and were renamed “Acquirer Identifiers” — the expansion applied to the issuing side only. Visa also confirmed that PANs and tokens remain sixteen digits, with V PAY in Europe called out as an exception using nineteen-digit PANs in some implementations.
Mastercard. Adoption of the eight-digit standard was announced in 2017, with April 2022 as the mandatory date for acquirers and service providers to support eight-digit BINs and eleven-digit account ranges.
American Express. Fifteen digits, prefixes 34 and 37. Amex is a three-party scheme, and its numbering, allocation and product identification are internal to Amex in a way that four-party scheme numbering is not.
The account-range arithmetic is worth doing explicitly, because it explains the schemes’ issuance policies. Take a sixteen-digit PAN with an eight-digit BIN. Subtract the BIN and the check digit and you have seven digits of individual account identifier: ten million accounts per BIN. Visa’s account range is nine digits — the BIN plus one more — so a single eight-digit BIN divides into at most ten account ranges, which is exactly what Visa’s own documentation states. Mastercard’s eleven-digit range is the BIN plus three, giving up to a thousand ranges of ten thousand accounts each.
This is also why Visa’s BIN utilisation policy, effective from its October 2017 release, instructs issuers not to randomise card issuance across an entire BIN but to randomise starting at the tenth digit — the tenth digit is the first digit that is not fixed by the nine-digit account range. The same bulletin instructs acquirers and processors to process transactions “based on complete nine-digit account range records in ARDEF tables rather than relying solely on the first six digits”. ARDEF is Visa’s Account Range Definition file, and it is a restricted product distributed to Visa clients through their account managers, not a public dataset.
Scheme prefixes and lengths#
The following table is the conventional industry summary. Treat it as indicative. The authoritative source for any given range is the scheme’s own account range file, not a published table, because ranges are added, moved and retired continuously.
| Scheme | Leading digits | PAN length | Luhn |
|---|---|---|---|
| Visa | 4 | 13, 16, 19 | Yes |
| Mastercard | 51–55 | 16 | Yes |
| Mastercard 2-series | 222100–272099 | 16 | Yes |
| American Express | 34, 37 | 15 | Yes |
| Discover | 6011, 644–649, 65 | 16–19 | Yes |
| Diners Club International | 30, 36, 38, 39 | 14–19 | Yes |
| JCB | 3528–3589 | 16–19 | Yes |
| UnionPay | 62 | 16–19 | Yes |
| Maestro | 5018, 5020, 5038, 5893, 6304, 6759, 6761–6763 | 12–19 | Yes |
| Mir | 2200–2204 | 16–19 | Yes |
| RuPay | 60, 65, 81, 82, 508 | 16 | Yes |
Two dated observations. Maestro is the widest-ranging length in the table and also the one being withdrawn: Mastercard began phasing Maestro out across Europe from 1 July 2023, with issuers required to replace expired or lost Maestro cards with a different product. And note the overlap: 65 appears against Discover, RuPay and other schemes, which is a reminder that a two-digit prefix identifies nothing reliably.
The check digit, formally#
The check digit is computed by the Luhn formula, described in US patent 2,950,048, “Computer for verifying numbers”, filed by Hans Peter Luhn on 6 January 1954, granted 23 August 1960 and assigned to IBM. The patent has long since expired and the algorithm is specified within ISO/IEC 7812-1 for PAN check-digit computation.
The exact procedure, stated so that an implementation can be written from it without ambiguity:
- Starting from the rightmost digit of the PAN, which is the check digit, and moving left, double the value of every second digit — that is, digits in positions 2, 4, 6 and so on counted from the right.
- If a doubled value exceeds 9, subtract 9 from it. Equivalently, sum its two decimal digits; the results are identical for all inputs 0 to 9.
- Sum all resulting values together with the undoubled digits.
- The PAN is well formed if and only if the sum is congruent to 0 modulo 10.
To generate a check digit for a payload of n−1 digits, append a placeholder 0, run steps 1 to 3, and set the check digit to (10 − (sum mod 10)) mod 10. The outer mod 10 is not decorative: when the running sum already ends in zero the check digit is 0, and an implementation that computes 10 − 0 = 10 and stores the low digit by accident will pass its own tests and fail in production on roughly one PAN in ten.
Anchoring at the right-hand end is the specification’s wording and it is the only safe way to implement it, because it makes the algorithm indifferent to PAN length. Implementations that anchor from the left must branch on odd versus even length, and this is the single most common defect in hand-rolled validators. Worked on a fifteen-digit American Express test number, 3782 8224 6310 005, the doubling positions counted from the left are 2, 4, 6, 8, 10, 12 and 14:
| Position | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Digit | 3 | 7 | 8 | 2 | 8 | 2 | 2 | 4 | 6 | 3 | 1 | 0 | 0 | 0 | 5 |
| Becomes | 3 | 5 | 8 | 4 | 8 | 4 | 2 | 8 | 6 | 6 | 1 | 0 | 0 | 0 | 5 |
The sum is 60, congruent to 0 modulo 10, and the number is well formed.
The blind spots demonstrated in the previous section are derivable rather than anecdotal. Define f(d) as the doubled-and-reduced value of a digit minus the digit itself. Then f(0) = 0, f(1) = 1, f(2) = 2, f(3) = 3, f(4) = 4, f(5) = −4, f(6) = −3, f(7) = −2, f(8) = −1, f(9) = 0. An adjacent transposition changes the checksum by f(a) − f(b), which is zero only when f(a) = f(b), and the only distinct pair for which that holds is 0 and 9. Every other adjacent transposition is detected.
For twin substitutions, define g(d) as the doubled-and-reduced value plus the digit. Modulo 10 the values are 0, 3, 6, 9, 2, 6, 9, 2, 5, 8 for digits 0 to 9. The collisions are g(2) = g(5), g(3) = g(6) and g(4) = g(7), giving the undetected substitutions 22↔55, 33↔66 and 44↔77.
Finally, a scoping note. Within ISO/IEC 7812 the check digit is mandatory and a PAN that fails Luhn is malformed. Numbers that merely look like PANs but are issued outside ISO/IEC 7812 — some private-label and closed-loop store cards, for instance — are under no obligation to use it, and refusing them on Luhn grounds is a category error.
Expiry: four representations of one date#
The expiry date exists in at least four forms in a live transaction, and they do not all have the same precision.
Printed on the card. Month and year, MM/YY, meaning valid to and including the final day of that month.
Magnetic stripe, ISO/IEC 7813:2006. On track 2, the fields in order are: start sentinel, PAN of up to 19 digits, field separator, expiration date as four digits YYMM (or the separator again if absent), a three-digit service code, discretionary data, end sentinel and a longitudinal redundancy check character, with a maximum record length of 40 numeric characters. On track 1, Structure B, the record is up to 79 alphanumeric characters with the expiry likewise four digits.
Note the capacity arithmetic that follows, because it is the constraint people reach for when explaining PAN lengths. Forty characters on track 2 less the start sentinel, end sentinel and LRC leaves 37 characters of data — which is exactly why ISO 8583 defines its track 2 field as a maximum of 37. Subtract the field separator, four digits of expiry and three digits of service code and you have 29 characters to share between the PAN and the discretionary data. A nineteen-digit PAN therefore leaves ten digits of discretionary data, which is tight but workable given that the discretionary data conventionally carries a PIN verification value and a card verification value; a sixteen-digit PAN leaves thirteen.
There is a live inconsistency here worth naming rather than papering over. ISO/IEC 7813:2006 still describes the PAN as comprising a six-digit IIN and a variable individual account number of up to twelve digits, because it predates the 2017 revision of ISO/IEC 7812-1. Two current ISO standards describe the same field differently. Implementers should follow ISO/IEC 7812-1:2017 for the IIN length and treat the 7813 text as historic in that one respect.
In the chip, EMV. The relevant data elements from the EMV Integrated Circuit Card Specifications, Book 3, Annex A:
| Tag | Name | Source | Format | Template | Length |
|---|---|---|---|---|---|
| 5A | Application Primary Account Number (PAN) | ICC | cn | 70 or 77 | var. up to 10 bytes |
| 5F34 | Application PAN Sequence Number | ICC | n 2 | 70 or 77 | 1 byte |
| 5F24 | Application Expiration Date | ICC | n 6 YYMMDD | 70 or 77 | 3 bytes |
| 5F25 | Application Effective Date | ICC | n 6 YYMMDD | 70 or 77 | 3 bytes |
| 57 | Track 2 Equivalent Data | ICC | b | 70 or 77 | var. up to 19 bytes |
Three things to read off that table. First, tag 5A is compressed numeric: two digits packed per byte, so ten bytes carry up to twenty digit positions of which at most nineteen are PAN, padded on the right with hexadecimal 'F'. Second, tag 5F24 carries six digits, YYMMDD — the chip holds a day, where the printed card holds only a month. What the issuer puts in the day field is a personalisation decision; a terminal performs a date comparison and must not assume a particular value. Third, tag 57, Track 2 Equivalent Data, reproduces the track 2 structure in binary with hexadecimal 'D' as the field separator in place of the = character and 'F' padding — which is why the chip and the stripe can produce byte-different but semantically identical data, and why comparing them naively as strings fails.
Tag 5F34, the PAN Sequence Number, is the field that resolves the “one number, several cards” problem raised earlier: it identifies and differentiates cards carrying the same PAN.
In the authorisation message, ISO 8583. The relevant data elements:
| DE | Name | Format |
|---|---|---|
| 2 | Primary account number | n ..19 |
| 14 | Date, expiration | n 4, YYMM |
| 35 | Track 2 data | z ..37 |
| 45 | Track 1 data | an ..76 |
DE2’s n ..19 is a variable-length numeric field of up to nineteen digits, carried with a two-digit length prefix. DE14 is fixed at four digits, YYMM — the message format drops the day that the chip carried.
What the terminal does with the date#
Expiry checking happens in EMV processing restrictions, where the terminal compares the Application Expiration Date, tag 5F24, against the Transaction Date, tag 9A. The outcome is recorded in the Terminal Verification Results, tag 95, a five-byte field. In byte 2:
| Bit | Meaning |
|---|---|
| b8 | Card and terminal have different application versions |
| b7 | Expired application |
| b6 | Application not yet effective |
| b5 | Requested service not allowed for card product |
| b4 | New card |
| b3–b1 | Reserved for future use |
Setting a TVR bit is not the same as declining. The TVR records observations; the decision of whether an observation causes a decline, an online authorisation request or nothing at all is made later, by comparing the TVR against the terminal action codes and issuer action codes. That comparison is the subject of a later chapter. The point to carry forward is that an expired card does not fail at the chip — it fails, if it fails, because somebody’s action codes said it should.
Why PAN length varies, definitively#
Five separate forces, and it is worth separating them because they are usually conflated.
The standard sets a ceiling and, since 2017, a floor. Nineteen digits maximum; ten digits minimum for issuers holding eight-digit IINs. Everything between is permitted.
History precedes the standard. American Express and Diners Club were issuing numbered cards before ISO/IEC 7812 consolidated the practice. The standard was written to accommodate the installed base, not to replace it, which is why fifteen and fourteen digit numbers remain conformant.
The magnetic stripe imposed a practical squeeze but never forced sixteen. As shown above, track 2 leaves 29 characters for PAN and discretionary data combined. Long PANs are possible and merely leave less room for the values that the stripe also had to carry.
Acceptance infrastructure calcified around sixteen. Merchant databases, printed forms, screen layouts and card-embossing conventions all standardised on four groups of four. This inertia is real enough that Visa, announcing the eight-digit BIN expansion, went out of its way to reassure the market that PANs and tokens remain sixteen digits and that card embossing alignment was unaffected. The nineteen-digit capability exists; it is used sparingly, and V PAY in Europe is the exception Visa itself names.
BIN capacity is the modern pressure. The whole reason for the 2017 expansion is that six-digit IINs ran out. Moving to eight digits multiplied the available issuer identifiers by a hundred, at the cost of two digits of account space per PAN — from nine digits of account identifier down to seven on a sixteen-digit PAN. That is the trade the industry made, and it is why the schemes now police BIN utilisation and instruct issuers to fill existing ranges before requesting new ones.
What a BIN lookup can and cannot tell you#
A BIN lookup is a table join. Its answer is only ever as good as the table, and the tables differ enormously in provenance.
The authoritative sources are the schemes’ own range files, distributed to their licensed participants: Visa’s Account Range Definition (ARDEF) file, restricted to Visa clients, and Mastercard’s equivalent account range data. Separately, in EMV 3-D Secure, the Directory Server supplies card range data to a 3DS Server in the PRes message, the response to a PReq, containing startRange, endRange, acsStartProtocolVersion, acsEndProtocolVersion, an optional threeDSMethodURL and an actionInd for each range. That is an authoritative, scheme-supplied range list, and it exists for one narrow purpose: to let the 3DS Server work out which protocol versions the issuer’s Access Control Server supports before it attempts an authentication.
Everything else on the market — the commercial BIN databases sold by the gigabyte — is derived, aggregated and of variable freshness.
What a good lookup can tell you, subject to the table being current: the scheme, the issuing institution, the issuer’s country, the product identifier and hence the broad product type (credit, debit, prepaid), and whether the card is a consumer or commercial product. Those attributes are genuinely useful, and they are used for real decisions: routing, fee categorisation, eligibility for dynamic currency conversion, fraud rules keyed on issuer country, and 3DS protocol version discovery.
What it cannot tell you, however good the table:
Whether the card exists. A range covers ten million potential accounts and a lookup does not know which are issued.
Whether the card is active, blocked, expired, or has any funds behind it. Those questions have exactly one answer, and it comes from an authorisation.
Anything about the cardholder. Not name, not address, not age, not creditworthiness.
Anything reliable at a granularity coarser than the account range. This is the correction that costs money: a six-digit lookup against a scheme that routes on nine or eleven digits can straddle several products with different funding sources and different interchange. If your table is keyed on six digits and the scheme’s is keyed on nine, your answers are not merely stale, they are structurally incapable of being right.
Whether the number is a card number at all. EMVCo’s Payment Tokenisation Specification – Technical Framework, which EMVCo publishes for public access, defines a payment token as a variable-length, ISO/IEC 7812-compliant numeric issued from a designated token BIN or token BIN range and flagged as such in the appropriate BIN tables; it passes the same basic validation rules as an account number, including the Luhn check digit, and it never takes the same value as a real PAN. A network token therefore has the length and shape of a PAN and satisfies Luhn, but its leading digits belong to a range set aside for tokens rather than to the issuer’s card product, so a conventional lookup describes the token range and not the card.
Which scheme a transaction will actually route on. Co-badged cards, particularly domestic debit schemes in continental Europe, carry more than one acceptance brand on a single PAN, and the routing choice is made by rules outside the number.
Handling the number in a system you are responsible for#
Four rules, each with a citable basis.
Store it as a string, never as an integer. IINs under MII 0 may begin with a zero, and integer storage silently destroys leading zeros. Separately, the largest signed 64-bit integer is 9,223,372,036,854,775,807 — itself nineteen digits — so the upper part of the nineteen-digit PAN space does not fit. And no arithmetic operation on a PAN is meaningful.
Accept the full permitted range of lengths. Twelve to nineteen digits will cover the schemes in circulation; ISO/IEC 7812-1 permits up to nineteen. Do not validate against sixteen.
Mask on display, truncate in storage, and know that these are different controls. PCI DSS separates them: Requirement 3.4.1 governs masking when the PAN is displayed or printed, and Requirement 3.5.1 governs rendering the PAN unreadable wherever it is stored. The PCI SSC’s own guidance puts the distinction plainly: masked data can be unmasked, but there is no un-truncation without recovering the PAN from another source.
Know the truncation limits. PCI SSC FAQ 1091, as updated in June 2022, gives the maximum digits that may be retained:
| PAN length | Brands | Minimum removed | Maximum retained |
|---|---|---|---|
| 16 digits (6- or 8-digit BIN) | Discover, JCB, Mastercard, UnionPay, Visa | At least 4 digits | First 8, any other 4 |
| 15 digits | American Express | At least 5 digits | First 6, last 4 |
| Fewer than 15 digits | Discover | — | First 6, any other 4 |
Three cautions on that table. It states maxima permitted where there is a documented business need, not defaults; first six and last four remains the format accepted by every brand and remains the sensible starting point. Mastercard’s own position paper states that its allowable truncation format is not mandatory and that entities are not required to change their existing truncation as a result of the eight-digit BIN migration, and recommends retaining the fewest digits possible. And the PCI SSC warns specifically that holding the same PAN truncated different ways in different data stores can expose more digits in aggregate than either format permits alone — a failure mode that only appears when two systems are correlated, which is to say during a breach.
The number in one paragraph#
A PAN is an eight-digit issuer identification number allocated by a registry, followed by up to ten digits of issuer-assigned account identifier, followed by one Luhn check digit, to a maximum of nineteen digits in total. The schemes route on finer account ranges than the issuer identifier — nine digits at Visa, eleven at Mastercard — because that is where product, funding source and fee category are determined. The check digit catches accidents and nothing else. The expiry date exists as four digits on the stripe and in ISO 8583, six on the chip, and means valid through the final day of the stated month. And a lookup on the leading digits tells you about a range, never about a card, and never about the person holding it.
12.98 Common wrong ideas#
Wrong: A card number is a serial number, and somewhere there is a very large list. Right: It is a structured hierarchical address: which institution is answerable, which account at that institution, and one final digit that is not information at all.
Wrong: The issuer identifier is six digits. Right: It has been eight since January 2017, Visa and Mastercard made support mandatory from their April 2022 releases, and the old six-digit identifiers were subdivided into blocks of a hundred rather than withdrawn.
Wrong: The issuer identifier is what the network routes and prices on. Right: The schemes route on a finer account range — nine digits at Visa, eleven at Mastercard — because that is where product, funding source and fee category are determined.
Wrong: Passing the check-digit test means the card exists. Right: It means the number is spelled correctly; it is a spell-checker rather than a lock, and a well-formed number may correspond to no account anywhere on earth.
Wrong: The check digit gives some protection against an attacker. Right: The rule has been public for over sixty years, generating millions of valid numbers is a first-week programming exercise, and card-testing attacks do exactly that before hunting for the live ones.
Wrong: The check digit catches every adjacent transposition. Right: Swapping an adjacent 0 and 9 is invisible to it always and everywhere, and the twin substitutions 22 against 55, 33 against 66 and 44 against 77 also pass.
Wrong: The doubling starts at the first digit on the left. Right: The specification anchors at the rightmost digit, which makes it indifferent to length; anchoring from the left requires branching on odd against even and is the single most common defect in hand-rolled validators.
Wrong: The first digit tells you what kind of card you are holding. Right: The Major Industry Identifier is archaeology, and Mastercard’s 222100–272099 range puts mainstream consumer cards under a digit the table labels “airlines”.
Wrong: Every number flowing through your systems is a card number. Right: Some are network tokens issued from token ranges, of the same length and satisfying the same check, and a lookup on their leading digits describes the token range rather than any issuer’s card product.
Wrong: A card number identifies one card and one bank account. Right: Replacements and additional cardholders can share a number distinguished only by the chip’s sequence number, and the mapping to accounts is the issuer’s private business and is not one-to-one in either direction.
12.99 Chapter summary in 20 lines#
- A card number is not a serial number but an address, read from the left in the way a postal address narrows from country to house.
- ISO/IEC 7812-1 defines the primary account number as an issuer identification number, an individual account identifier and one check digit, to a maximum of nineteen digits.
- Since the fifth edition of January 2017 that issuer identifier is eight digits rather than six, and each old six-digit identifier became a block of one hundred eight-digit ones.
- That is why six-digit and eight-digit identifiers coexist, and why any system built before about 2019 almost certainly assumes the wrong figure.
- Even eight digits is not how the network routes: Visa uses a nine-digit account range and Mastercard an eleven-digit one, because that is where product and fee category live.
- Visa has told its acquirers explicitly to process on the complete nine-digit account range record rather than on the first six digits.
- The first digit is the Major Industry Identifier, and it is archaeology, as Mastercard’s 2-series consumer cards under an “airlines” digit demonstrate.
- The last digit is a Luhn check digit: double every second digit from the right, subtract nine where a doubled value exceeds nine, and require the total to be congruent to zero modulo ten.
- Worked on 4012 8888 8888 1881 the total is 90, and both a transposition of the last two digits and a single-digit change push it off a multiple of ten.
- To generate rather than test, append a placeholder zero and set the check digit to ten minus the sum modulo ten, all taken modulo ten again, because the outer step is not decorative.
- Anchoring at the rightmost digit makes the algorithm indifferent to length; anchoring from the left forces a branch on parity and makes every fifteen-digit American Express number appear invalid.
- The check digit catches accidents superbly and adversaries not at all, and it has known blind spots rather than being a guarantee.
- Those blind spots are derivable rather than anecdotal, from the doubled-and-reduced value of each digit taken against the digit itself.
- The expiry date exists in four forms:
MM/YYprinted,YYMMon the stripe and in the authorisation message, andYYMMDDin the chip, which carries a day the other three drop. - A card marked 09/28 is good through the last second of 30 September 2028 and stops working on 1 October.
- An expired card does not fail at the chip: the terminal records the observation in the terminal verification results, and whether that becomes a decline is decided later by the action codes.
- Card number length varies for five separate reasons: the standard’s ceiling and floor, history that predates the standard, the stripe’s capacity squeeze, acceptance infrastructure that calcified around sixteen, and issuer identifier capacity pressure.
- Track 2’s forty characters leave twenty-nine to share between the number and the discretionary data, which is a squeeze rather than a rule forcing sixteen digits.
- A BIN lookup is a table join whose authoritative sources are the schemes’ own range files, and it can give scheme, issuer, country and product type but never whether a card exists, whether it has funds, or anything about the person holding it.
- Store the number as a string, accept the full permitted range of lengths, mask on display and truncate in storage knowing these are different controls, and remember that the same number truncated two ways in two stores can expose more digits in aggregate than either format permits alone.
Chapter sources: ISO/IEC 7812-1:2017 (5th edition, confirmed 2022) and ISO/IEC 7812-2:2017, with the ISO announcement of the eight-digit IIN change and the ISO/IEC 7812 Registration Authority information sheet published via ANSI; ISO/IEC 7813:2006 (track 1 and track 2 structure); EMV Integrated Circuit Card Specifications for Payment Systems, Book 3, Annex A (tags 5A, 57, 5F24, 5F25, 5F34, 95, 9A); EMV 3-D Secure Protocol and Core Functions Specification (PReq/PRes card range data); EMV Payment Tokenisation Specification – Technical Framework (definitions of Payment Token, Token BIN and Token BIN Range); Visa bulletin on the implementation of eight-digit BINs, Visa article AI09153 on BIN management policies, Visa’s eight-digit BIN numerics FAQ and Visa’s eight-digit BIN PCI position paper; Mastercard’s 2-Series BIN issuer impact checklist and its “8-Digit BIN Expansion and PCI Standards” paper; PCI DSS v4.0.1 requirements 3.4.1 and 3.5.1, PCI SSC FAQ 1091 (updated June 2022) and the PCI SSC masking-versus-truncation FAQ; US patent 2,950,048, Hans P. Luhn, IBM, filed 6 January 1954, granted 23 August 1960. Check-digit arithmetic, track capacity arithmetic and account-range capacity arithmetic in this chapter were computed and verified by hand rather than quoted.