Leading payment-card number sequence, formally the Issuer Identification Number, used to identify the card issuer and support transaction routing.
A Bank Identification Number (BIN) is the leading portion of a payment card’s Primary Account Number used to identify the card issuer and support network routing. The formal ISO term is Issuer Identification Number (IIN), and the current ISO/IEC 7812 structure uses an eight-digit IIN, although “six-digit BIN” remains common in legacy systems and commercial data products.
“Bank Identification Number” is familiar in merchant and fraud operations, but not every card issuer is a bank. ISO/IEC 7812 therefore uses Issuer Identification Number.
The IIN occupies the first eight digits of the Primary Account Number. The rest of the PAN contains an issuer-assigned account identifier and a final check digit.
Historically, the first six PAN digits were treated as the BIN or IIN. ISO expanded the issuer identifier to eight digits to increase numbering capacity. Existing six-digit allocations were divided into blocks of eight-digit IINs.
That transition creates an important data distinction:
| Data field | What it can represent | Main limitation |
|---|---|---|
| First six PAN digits | Legacy BIN range or broad issuer grouping | Can combine multiple current eight-digit IINs |
| First eight PAN digits | Current ISO IIN | Still requires current network or issuer metadata |
| Full PAN | Specific payment-card account credential | Sensitive cardholder data subject to protection requirements |
| Payment token | Substitute value mapped to a PAN in a token system | Token domain and requester context affect how it can be used |
A field labeled BIN6 should not silently receive eight digits, and a field labeled BIN should document whether it stores six or eight.
A simplified PAN structure is:
1[ eight-digit IIN ][ issuer account identifier ][ check digit ]
PAN length varies, so the issuer-account portion does not have one fixed length. The last digit commonly supports Luhn validation of the full PAN.
The IIN does not contain the cardholder’s bank-account routing number, IBAN, deposit-account number, PIN, or card verification code.
Assume two hypothetical PAN ranges begin with:
151234567...
251234589...
Both share the legacy six-digit prefix 512345, but their current eight-digit IINs are 51234567 and 51234589.
Suppose a merchant’s old BIN table stores only six digits and assigns the whole 512345 range to Product A. Transactions from the second eight-digit range can then be mislabeled even if they route successfully. Possible consequences include:
The solution is not to guess digits seven and eight. The merchant should update its data model and obtain current authorized range data from its acquirer, processor, network, or another appropriate source.
Payment participants can use IIN data for:
Each use has limitations. For example, an issuer-country attribute describes the card range, not necessarily the cardholder’s nationality, residence, current location, or shipping address.
A BIN or IIN match does not prove:
Authorization, authentication, fraud screening, clearing, settlement, and chargeback rights are separate layers of the card-payment process.
IIN data can be one input to fraud models, but rigid rules can reject legitimate transactions or miss fraud. A country mismatch may reflect travel, relocation, a multinational issuer, or remote commerce. A matching country does not prove legitimacy.
More useful controls combine available signals such as:
Do not store or expose the full PAN merely to perform an IIN lookup. The required leading digits should be handled under the organization’s approved data-security design.
Systems built around six-digit BINs can fail when eight-digit IINs are introduced. Review:
PCI SSC guidance notes that moving to eight-digit BINs affects PAN masking and truncation decisions. Combining differently truncated values can expose more PAN digits than intended and can affect PCI DSS scope.
Card-network rules, range data, and security requirements can change. This page provides general education, not payment-processing, PCI-compliance, cybersecurity, or fraud-management advice.