BIN / IIN in ISO 8583: Reading DE 2 and the 8-Digit Migration

Where is the BIN in DE 2, and is the IIN the same thing?

DE 2 carries the PAN and is a variable-length field, n ..19 — a 2-digit length prefix (LLVAR) followed by up to 19 digits. (If the dot notation is new to you, see how to read field format notation.) On the wire, using a synthetic test number — the length prefix is shown separated for clarity:

16 4000001234567899

Terminology first, because the two names cause real confusion in spec reviews: ISO/IEC 7812 calls this prefix the IIN (Issuer Identification Number). BIN (Bank Identification Number) is the older industry name for the same digits. Scheme manuals, processor docs and BIN files use them interchangeably; when a document mixes both, it is not describing two different things.

The very first digit of the IIN is the MII (Major Industry Identifier), which tells you what kind of institution issued the card:

In the field reference, DE 2 is one line: n ..19, primary account number. Everything this article discusses happens inside the first 8 of those digits.

What actually changes when the BIN goes from 6 to 8 digits?

ISO/IEC 7812 originally defined the IIN as 6 digits. The 2017 revision expanded it to 8 digits because the 6-digit space was running out, and the card networks required issuers, acquirers and processors to handle 8-digit IINs from April 2022. Both lengths are in circulation today.

What does not change: the PAN itself. It is still 13–19 digits, DE 2 is still n ..19, and the bytes on the wire are byte-for-byte identical. A parser that reads DE 2 by its LLVAR prefix needs no change at all. What moves is a boundary that exists only in your business logic: which of those digits belong to the issuer identifier.

What has to change is everything that treats the prefix as a key:

• BIN table storage — 6-character key columns, in-memory maps and tries keyed on substring(0, 6). Ranges are now published at mixed lengths, so store them at 8 digits (or as explicit ranges) and match longest prefix first.
• Routing rules — acquirer and switch rules that pick a network or an issuer endpoint from a 6-digit prefix, including on-us detection.
• Prefix-keyed decisions — interchange and fee qualification, debit/credit and consumer/commercial product detection, and risk rules that branch on the BIN. All of these need re-basing on 8 digits.
• PAN masking — display formats hard-coded to "first 6 + last 4" no longer show the whole IIN. PCI DSS v4 explicitly permits first 8 + last 4 for PANs long enough to keep the middle digits protected.

The classic failure mode is code that still slices 6 digits. Under a single 6-digit prefix there can now be different issuers and different card products. Two synthetic examples: 40000012… and 40000013… share the 6-digit prefix 400000 but may belong to entirely different institutions. Nothing throws — the message parses, a route is found, a fee program is applied — but the transaction lands in the wrong bucket: wrong issuer attribution, wrong interchange qualification, wrong product flags, wrong risk profile. It is a silent-wrong-answer bug, which is why it survives testing.

Finding one usually means looking at real DE 2 values from production, because test ranges almost never put two issuers under the same six digits. Those messages parse in your browser here and go nowhere — though if live PANs are not allowed near a website at all, the offline edition does the same job with no network involved.

What does the BIN control in a live transaction?

• Routing — before anything else happens, the acquirer and every switch in the path use the prefix to decide which network, and ultimately which issuer host, receives the authorization.
• Scheme identification — the well-known public ranges: first digit 4 is Visa; 51–55 and 2221–2720 are Mastercard; 34/37 American Express; 62 UnionPay; 35 JCB; 36/38 Diners Club. These map a PAN to a scheme, not to an issuer — issuer-level attribution needs the licensed BIN file.
• Cross-checks inside the message — on chip transactions the application on the card announces its scheme through the AID in DE 55 (decode one in the AID lookup); an AID that disagrees with the PAN's scheme range is worth a second look.
• Track data must agree — the PAN in DE 2 should equal the PAN inside DE 35 (Track 2, the digits before the = separator) and DE 45 (Track 1). A mismatch means either a badly built message or — more often in practice — a parser that lost its field boundaries somewhere upstream.

How do I spot a DE 2 parsing problem in the logs?

Because DE 2 is usually the first variable-length field in the message, a length mistake here corrupts everything after it. Patterns to recognize:

• PAN ends in non-digits, or DE 3 looks like two stray digits — the LLVAR prefix was read at the wrong width, so the parser consumed too few or too many bytes and every later field starts at the wrong offset. The mechanics are the same off-by-one described in field format notation.
• Declared length disagrees with the digits present — a prefix of 16 followed by 15 digits and an = usually means track data leaked into the PAN slot, or the message was assembled with the wrong length.
• Every PAN on one link is garbage, all other links are fine — check the encoding variant: on binary interfaces the LLVAR length is often one packed BCD byte rather than two ASCII characters, and a parser configured for the wrong variant misreads every message on that link.
• DE 2 and DE 35 disagree — see the cross-check above; treat it as a boundary bug until proven otherwise.

The fastest way to confirm any of these is to look at a message where DE 2 is known-good. This synthetic authorization (same one used in the annotated message examples) carries 16 + 4000001234567899 in DE 2 and the matching PAN in DE 35:

0100723C448028C08000164000001234567899000000000000005000081009302100012309302108102812541190200334000001234567899=2812101123450000622209000123TERM0001TESTMERCH000001840

Open this message in the parser →

Read next

• Reading ISO 8583 Field Formats: n..19, ans...999, LLVAR
• ISO 8583 Message Examples: Annotated Samples You Can Parse
• ISO 8583 Field Quick Reference
• Scheme Differences: Why "the Same" ISO 8583 Parses Differently
• Payment Tokenization: DPAN vs PAN, and How to Spot It
• The Complete Guide to Crypto Cards (ucardly.com)