BIN and IIN are the same thing under two names. IIN — Issuer Identification Number — is the term in ISO/IEC 7812. BIN — Bank Identification Number — is what the payments industry says. Both refer to the leading digits of a card number that identify which institution issued it: historically six digits, now moving to eight.
Those digits are the routing information of the payment system. They decide which network a transaction enters, which bank is asked to authorise it, and often what it costs the merchant to accept.
This guide is about the system behind the prefix — how the numbers get allocated, who actually stands behind a BIN, and how much of what a lookup tells you is safe to act on. The practical companions are linked in place below: one for calling a commercial database safely, one for testing your own prefix handling with synthetic data from the all-network generator.
BIN or IIN — which term to use
There is no technical distinction, only a difference in dialect.
ISO/IEC 7812-1 says IIN, and standards-adjacent documents follow it. The industry says BIN, and so does virtually every piece of tooling: BIN range, BIN table, BIN file, BIN sponsor, BIN attack. Nobody says “IIN attack”.
The practical rule: write IIN when you are quoting the standard, write BIN everywhere else, and never assume a colleague means something different by the other word. Where confusion does arise, it is almost never about the term — it is about the width, which is a real question with a real answer below.
How IINs are allocated
The chain has three links, and knowing all three explains most of the surprising results a lookup can return.
The registration authority. ISO/IEC 7812 designates a registration authority to maintain the global register of issuer identifiers; that role is held by the American Bankers Association. It is the body that assigns identifiers and publishes the register — a clerical function rather than a commercial one.
The schemes. Card networks hold large blocks and subdivide them. Everything beginning with 4 is Visa; 51–55 and 2221–2720 are Mastercard; 34 and 37 are American Express. Within their block, a scheme allocates ranges to the institutions it licenses. This is why the first digit tells you the network with high confidence — that assignment sits at the top of the tree and effectively never moves. The rest of the structural picture is in the card number structure guide.
The issuers. An institution receiving a range subdivides it further across its own products: a credit portfolio in one sub-range, a debit portfolio in another, a co-brand programme in a third, a different country’s operation in a fourth. A single bank can hold dozens of BINs, and two cards from the same bank can differ in the sixth digit because they belong to different products.
BIN sponsorship, and why the issuer name lies
Here is the part that is rarely written down, and that explains most “wrong” lookup results.
Issuing cards requires a licence from the scheme, and most fintechs do not have one. Instead they work with a BIN sponsor: a licensed bank that holds the BIN and issues the cards on the fintech’s behalf. The card carries the fintech’s brand, its app, and its customer relationship. The BIN belongs to the sponsoring bank.
So when a lookup returns an issuer name, what you often get is the sponsor — a bank the cardholder has never heard of and whose name appears nowhere on the card. The data is not wrong. It is answering “which licensed institution issued this?” while you were asking “whose card is this?”, and those have been different questions since programme-managed issuing became normal.
The consequences are practical. Issuer-name matching for fraud rules produces false signals. Analytics that group customers by bank will merge unrelated card programmes into one sponsor bucket. And an “unknown issuer” is more often a new programme than a bad number.
The six-to-eight digit migration
The short version: six digits allow on the order of a hundred thousand practical assignments, the space ran short, and ISO/IEC 7812-1:2017 defined an eight-digit identifier. Visa and Mastercard moved new assignments to eight digits from April 2022, as set out in Visa’s numerics guidance.
Two properties of the change are worth holding on to, because they follow from how allocation works rather than from any implementation detail:
It was an extension, not a renumbering. Existing six-digit assignments kept their first six digits; two further digits subdivide them. No card was reissued and no cardholder noticed anything, because the card number stayed exactly as long as it was. What moved was the internal boundary between “issuer” and “account”, which is invisible from outside.
Both widths are permanent. Six-digit assignments were not withdrawn. A card issued under one is still valid, still in wallets, and will be for as long as it keeps getting renewed. There is no cutover date after which everything is eight digits.
Together those produce the failure mode: two different issuers can now share the same first six digits and diverge only at the seventh or eighth. A system keyed on six digits maps both to whichever it learned first, silently, with no error raised — the payments still succeed, they just take the wrong route, carry the wrong interchange assumption, or land at the wrong acquirer. Nobody files a bug for a payment that worked.
The implementation checklist for handling both widths — schema, provider granularity, longest-prefix matching, and generating eight-digit test fixtures — is on the BIN generator page, next to the tool that produces the test data for it.
What a BIN lookup actually returns
Most sources present BIN data as fact. It is a commercially compiled best effort, and the fields differ enormously in how much they deserve your trust:
| Field | Example | Reliability |
|---|---|---|
| Network / scheme | Visa | High — derived from ranges that effectively never move |
| Country | GB | High |
| Card type | debit / credit / prepaid | Medium-high — usually right, occasionally stale after a product change |
| Card level | classic / gold / platinum / corporate | Medium — granular, frequently repackaged, often behind |
| Regulated status (EEA) | regulated / unregulated | Medium — depends on both country and issuer type being current |
| Issuer name | Example Bank plc | Low — BIN sponsorship routinely obscures it |
The two questions worth asking about any field before you build on it: how badly does it
break if it is wrong, and what does the provider return when it does not know? A service
that guesses rather than answering unknown will quietly corrupt every decision downstream.
What BIN data cannot decide on its own
The uses — routing, interchange estimation, surcharge rules, currency conversion offers, fraud scoring, authentication flow, approval analytics — are covered on the BIN lookup page. What is worth adding here is the other half: the limits, because BIN-driven logic fails in a characteristic way.
It is a lookup, not a fact about the card. Every field is a claim from a file that was compiled at some point and shipped through a distribution chain. Recency is a property of your provider, not of the number. This is the opposite of the Luhn check, which is pure arithmetic over the digits in front of you and needs no external data to be correct — one of the two checks is self-contained and one is a database query, and they fail in completely different ways.
It cannot see the account. Nothing in the prefix knows whether the card is active, what its limit is, or whether this particular transaction will be approved. A number that is structurally perfect and sits in a real issuer’s range can still be attached to nothing at all — that is the normal state of every number this site generates.
It should never be a decision on its own. A country mismatch between BIN, IP, and delivery address is an input to a fraud model, not a verdict. Blocking on a single BIN signal declines travellers, expatriates, and anyone using a card issued somewhere they no longer live.
Free lists are a provenance problem. Beyond being stale, downloadable “free BIN databases” of uncertain origin are sometimes compiled from leaked or scraped data, which makes ingesting one a decision about your own compliance posture as much as your data quality. If your gateway already returns brand, country, and funding — Stripe’s card object does — start there and add a vendor only when you have identified a field you genuinely cannot live without.
BIN attacks, and why prefixes are sensitive
BIN data has a fraud use as well as a business use: it is targeting information. A BIN attack generates numbers within a known issuer range and tests them at scale against a merchant’s payment endpoint, looking for combinations that authorise. This is why commercial providers gate their data behind accounts and terms of use, and why this site publishes no BIN lists and no mapping between prefixes and institutions.
If you run a checkout, the defence is entirely on your side of the transaction:
- Rate limit by IP, by device, and by card prefix — bursts are the signature, and a single-number-per-minute limit is not one.
- Block on failure patterns, not just volume — many declines from one BIN in a short window is the specific shape to alert on.
- Protect zero-amount and one-unit authorisation endpoints. Card testing gravitates to them because they are cheap, quiet, and often unauthenticated.
- Add friction at the right layer — a CAPTCHA or device attestation on the payment step, not on the whole site.
- Turn on your gateway’s card-testing protection. Stripe Radar and its equivalents exist for this and are usually a configuration change rather than a project.
The attacker’s economics matter here: card testing is profitable because it is cheap to run at volume. Anything that raises the per-attempt cost works, which is why rate limiting outperforms cleverness. The carding guide covers the broader picture, and the brand detection guide covers identifying a network from a prefix without a lookup service at all.