Bank Identification Number (BIN)

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.

Key Takeaways

  • BIN and IIN are often used interchangeably, but IIN is the standards-based term and does not assume the issuer is a bank.
  • Current IINs have eight digits; older systems and reports may still group cards by the first six PAN digits.
  • The IIN is part of the PAN, not a separate number printed beside it.
  • An IIN can support issuer, network, product, and routing decisions, but its exact metadata depends on current authoritative card-network or issuer data.
  • A BIN lookup does not authenticate the cardholder, prove that a transaction is authorized, or establish the card’s physical location.
  • Moving from six- to eight-digit issuer identification can expose systems that store, route, price, or report using hard-coded six-digit assumptions.

Why IIN Is the More Precise Term

“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.

Six-Digit BINs vs. Eight-Digit IINs

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 fieldWhat it can representMain limitation
First six PAN digitsLegacy BIN range or broad issuer groupingCan combine multiple current eight-digit IINs
First eight PAN digitsCurrent ISO IINStill requires current network or issuer metadata
Full PANSpecific payment-card account credentialSensitive cardholder data subject to protection requirements
Payment tokenSubstitute value mapped to a PAN in a token systemToken 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.

PAN Structure

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.

Worked Example: A Six-Digit Lookup Collision

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:

  • incorrect debit, credit, prepaid, or commercial-card classification;
  • wrong country or issuer metadata;
  • inaccurate fee estimates or routing choices;
  • distorted fraud rules and approval reporting; and
  • customer-service confusion.

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.

How BIN/IIN Data Is Used

Payment participants can use IIN data for:

  • routing an authorization toward the appropriate network and issuer;
  • identifying card brand or product attributes;
  • applying acceptance and processing rules;
  • estimating interchange or commercial-card treatment;
  • fraud and anomaly screening;
  • transaction monitoring and reporting; and
  • customer-service routing.

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.

What a BIN Lookup Does Not Prove

A BIN or IIN match does not prove:

  • the full PAN passes its checksum;
  • the account is open or has available credit or funds;
  • the cardholder authorized the transaction;
  • the card verification value or PIN is correct;
  • the device is trusted;
  • the merchant will receive final settlement; or
  • the transaction is free of fraud or later dispute.

Authorization, authentication, fraud screening, clearing, settlement, and chargeback rights are separate layers of the card-payment process.

BIN Data and Fraud Controls

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:

  • issuer and product attributes;
  • merchant category and transaction amount;
  • device and authentication data;
  • velocity and prior behavior;
  • billing and shipping evidence;
  • token and wallet context; and
  • issuer authorization response.

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.

Migration and Data-Quality Risks

Systems built around six-digit BINs can fail when eight-digit IINs are introduced. Review:

  • database field lengths and keys;
  • routing and fee tables;
  • fraud-rule inputs;
  • token-vault metadata;
  • PAN masking and truncation formats;
  • reports grouped by issuer range;
  • test fixtures and regular expressions; and
  • interfaces shared with processors and acquirers.

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.

Common Mistakes

  • Defining every BIN as the first four to six digits.
  • Assuming only banks receive issuer identifiers.
  • Treating a six-digit commercial lookup as current eight-digit IIN data.
  • Using BIN country as proof of cardholder location or identity.
  • Assuming an IIN match authenticates or authorizes a transaction.
  • Publishing a full PAN when only an IIN or masked value is needed.
  • Ignoring eight-digit impacts on routing, fraud, reporting, and PCI controls.

Authoritative Sources

  • Primary Account Number: Full card-account credential containing the IIN, issuer account identifier, and check digit.
  • PCI DSS: Security standard governing environments that store, process, or transmit covered payment-card account data.
  • Bank Account Number: Deposit or loan account identifier, distinct from a card PAN.
  • Fraud Detection: Controls and models used to identify potentially unauthorized or deceptive activity.

FAQs

Is a BIN six digits or eight digits?

The current ISO IIN structure uses eight digits. Six-digit BIN terminology remains common in legacy datasets, so systems and reports should state which length they use.

Is a BIN the same as a PAN?

No. The BIN or IIN is the leading issuer-identification portion of the full PAN.

Can a BIN lookup confirm that a card transaction is legitimate?

No. It supplies issuer-range metadata. Authentication, authorization, fraud screening, settlement, and dispute outcomes require additional evidence.

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.

Browse Banking