What is a BIN number, and what does a BIN lookup tell you?

Every card number starts with a short prefix that says who issued it. Payment systems read that prefix on every transaction to decide where to send the authorization request, and merchants read it to learn what kind of card a customer is about to use. If you build checkouts, run fraud rules or analyze payment data, this prefix is the single most informative part of a card number you are allowed to keep.

BIN and IIN: two names for the same prefix

BIN stands for bank identification number. IIN stands for issuer identification number, the term used by the international standard ISO/IEC 7812-1, which defines how card numbers are structured. The standard prefers “issuer” because cards are issued by organizations that are not banks too — retailers, airlines, fuel companies, telecom operators and fintechs. In everyday payments language, both terms mean the same thing: the leading digits of the primary account number (PAN) that identify the issuer’s range.

A card number has three parts:

The maximum length of a card number is 19 digits. With a six-digit IIN the account identifier can be up to 12 digits; with an eight-digit IIN it is limited to 10. The move from six to eight digits is explained in detail in our guide to 6-digit vs 8-digit BINs.

The first digit: the major industry identifier

The very first digit of the IIN is the major industry identifier (MII). It is a coarse category set by ISO/IEC 7812, not a brand code, but it explains why almost all bank cards start with 3, 4, 5 or 6.

Network ranges at a glance

Card networks own large blocks of the IIN space and allocate sub-ranges to their member issuers. These are the ranges a checkout form typically uses to detect the brand while the customer types:

Two practical warnings. First, ranges overlap across networks through co-branding and local schemes, so brand detection should check the most specific prefixes first. Second, the network is not the issuer: 4 tells you a card runs on Visa, but only a BIN database tells you which bank issued it. Our card number format reference lists the details per brand.

What a BIN lookup returns

A BIN lookup takes the prefix and returns what is known about the range it belongs to. Fields vary by provider, but a good record covers:

Payment processors return a subset of this with each payment. Stripe’s Card object, for example, exposes brand, a two-letter country, and funding with the values credit, debit, prepaid or unknown. You can try any prefix with our BIN checker or browse issuers by country in the BIN list.

What a BIN lookup can’t tell you

A BIN describes a range that can hold anywhere from hundreds to millions of cards. Everything a lookup says is true of the range, not of the specific card in front of you. In particular, a lookup cannot tell you:

• Who holds the card. BINs contain no personal data, and the account digits that follow are private to the issuer.
• Whether the card exists or is active. A number can have a perfectly valid BIN and still not belong to any open account. Only the issuer answers that, during authorization.
• Whether a payment will be approved. Approval depends on the account’s status, available funds, the security code, address checks, 3-D Secure and the issuer’s risk model.
• Where the customer is. The country field is the issuer’s country. Travelers, expatriates and cross-border online shoppers use cards far from home every day.

Why BIN data is sometimes wrong

Ranges change hands when banks merge, when portfolios are sold and when issuers split a six-digit range into eight-digit sub-ranges for different products. Public databases are compiled from many sources and update at different speeds, so two lookups can disagree. The most reliable BIN data for a live transaction is the data your processor returns with the authorization; use third-party databases for pre-checks, analytics and research, and design rules that degrade gracefully when the answer is “unknown”.

How merchants use BIN data

Routing and acceptance

Acquirers and payment platforms use the BIN to send each authorization to the right network and issuer. Merchants with several processors also route by BIN — for example, sending domestic cards to a local acquirer and foreign cards to a cross-border one — to improve approval rates and fees.

Fraud screening

BIN data adds context to a risk score. A mismatch between the card’s issuing country, the IP address and the shipping address is a classic signal, and a sudden burst of attempts from the same BIN with different account digits is a common sign of card-testing attacks. Treat these as signals to weigh, not automatic blocks, or you will turn away legitimate travelers.

Card-type rules

Some business rules depend on the funding type. A subscription business may require a credit card for a deposit, or flag prepaid cards for review. In the United States, card network rules also matter: Visa’s merchant surcharging FAQ states that U.S. merchants cannot surcharge debit or prepaid card purchases, so a merchant that surcharges must tell credit from debit — and the BIN is how that is done.

Customer experience

Detecting the brand from the first digits lets the form show the right logo, apply the correct spacing (4-6-5 for American Express), and ask for a four-digit security code when needed. Knowing the issuing country lets you preselect a currency or explain foreign transaction fees before checkout.

How developers use BIN data

For engineers, BIN data shows up in a handful of places:

• Brand detection and validation in the payment form, before anything is sent to the gateway (see our credit card regex guide).
• Analytics — approval rates by issuer, country and card type are among the most useful payment metrics you can build.
• Test fixtures — generating test numbers from a specific BIN lets you exercise country- or product-specific logic. Our card generator accepts a BIN or pattern for this.
• Data minimization — PCI DSS lets you display no more than the BIN and the last four digits, so storing the BIN separately (properly protected) gives you most of the analytic value without the full PAN.

A lookup against a local BIN table is a longest-prefix match. Store ranges with their prefix length so that eight-digit entries win over six-digit ones:

BIN_TABLE = {
    # prefix: (network, issuer, country, funding)  - illustrative rows
    '41111111': ('Visa', 'Example Bank A', 'US', 'credit'),
    '411111':   ('Visa', 'Example Bank', 'US', 'debit'),
    '4':        ('Visa', None, None, None),
}

def lookup_bin(pan: str):
    digits = ''.join(c for c in pan if c.isdigit())
    for length in (8, 7, 6, 5, 4, 3, 2, 1):   # most specific prefix first
        hit = BIN_TABLE.get(digits[:length])
        if hit:
            return {'prefix': digits[:length], 'network': hit[0], 'issuer': hit[1],
                    'country': hit[2], 'funding': hit[3]}
    return None

print(lookup_bin('4111 1111 1111 1111'))   # matches the 8-digit row

BINs, privacy and test data

Because a BIN identifies a range rather than a person, it is not cardholder data on its own, and it is routinely shown on receipts and screens together with the last four digits. The full card number is different: it must be protected under PCI DSS wherever it is stored, processed or transmitted. That is why development and test environments should use synthetic numbers or gateway test cards rather than real cards; our guide to test data and PCI DSS covers the rules.

BINs are also why a format check can never prove a card is genuine. Anyone can put a real issuer’s prefix in front of random digits and calculate a valid check digit. A lookup will then correctly name the issuer — of the range — while the account itself does not exist.