Bank Identification Number (BIN): What It Is & How It Works

If you've ever looked at a payment card, the first 6 to 8 digits aren't random. They're the Bank Identification Number, or BIN. The card schemes also call it the Issuer Identification Number (IIN) — same thing, different name. Those digits tell the payment network who issued the card, which scheme it sits on, what type of card it is, and which country issued it.

BINs do a lot of quiet work. They route transactions, drive fraud rules, decide which 3D Secure flow fires, and shape the interchange you pay as a merchant. If you take card payments, the BIN is one of the first things your acquirer looks at before anything else happens.

What the BIN actually tells you

Decode a BIN and you typically learn:

• Issuer: the bank or fintech that issued the card (Barclays, Monzo, Chase, Revolut, etc.)
• Scheme: Visa, Mastercard, American Express, Discover, JCB, UnionPay, Diners
• Card type: credit, debit, prepaid, charge
• Product tier: standard, gold, platinum, world, business, corporate, purchasing
• Country of issue: often the single most useful field for fraud and pricing
• Funding source: for regulated EU/UK interchange, whether it's consumer or commercial

You don't need the full card number to learn any of this. The BIN alone is enough — which is exactly why it gets used so heavily upstream of the actual authorisation.

6 digits or 8 digits?

BINs used to be 6 digits everywhere. In April 2022 the card schemes finished a long migration to 8-digit BINs, which roughly quadrupled the number of available BIN ranges and let issuers carve up their portfolios into much finer slices.

Most processors and acquirers now expect 8-digit BIN data. Some older fraud rules and gateway configs still key off the first 6 digits — that works for routing in most cases but misses the granularity 8-digit BINs give you (for example, separating a UK consumer debit card from a UK commercial debit card on the same issuer).

If you operate a BIN allow-list or block-list, check whether it's 6 or 8 digits. The two can't be mixed without rewriting the lookup.

How BINs get used in real payment flows

A BIN doesn't sit in a database for show. It's actively used during a transaction:

1. Scheme routing

The first digit of the BIN identifies the scheme: 4 = Visa, 5 = Mastercard (with 2 added under the 2-series expansion), 3 = Amex/Diners, 6 = Discover/UnionPay. The acquirer uses this to send the auth request down the right rail.

2. Country-based fraud checks

If your customer's billing address is in the UK but the BIN resolves to a high-risk geography, that mismatch is one of the strongest fraud signals available. Most gateways score it automatically.

3. Issuer-side rules and 3D Secure

The issuer behind the BIN sets its own SCA rules. A Revolut card might step up differently from a high-street bank card. Your 3D Secure flow needs to handle both.

4. Interchange and surcharging

Commercial card BINs carry higher interchange than consumer debit. Card-not-present BINs are priced differently from card-present. If you're billed on interchange-plus, your effective rate is partly a function of the BIN mix in your traffic.

5. Acceptance decisions

Some merchants block prepaid BINs for subscriptions, or block non-domestic BINs to manage chargeback exposure, or restrict commercial cards on consumer SKUs. All of that runs off BIN lookups before the transaction reaches the acquirer.

BIN lookup services

A BIN lookup is a query — local database or API — that takes 6 or 8 digits in and returns the metadata above. The schemes publish authoritative BIN ranges to acquirers; commercial providers resell enriched versions to merchants and developers.

Quality varies. The schemes' own ranges are authoritative for issuer and country but slow to update on rebrands and portfolio sales. Third-party BIN databases catch portfolio moves faster but can lag on brand-new ranges. Real-time lookups via your acquirer tend to be the cleanest source if you're already using them for risk scoring.

BINs and PCI scope

Here's the part merchants get wrong. The full PAN (16 digits) is sensitive cardholder data and brings PCI scope. The BIN alone — the first 6 to 8 digits, with the rest masked — is not considered sensitive cardholder data on its own. You can store, log, and analyse BIN-only data without that triggering PCI obligations the way storing full PANs does.

That's why so many fraud and analytics tools store BIN + last 4 rather than the full number. You get most of the analytical value with none of the storage risk. If you're working out what data to retain, our piece on PCI DSS walks through what counts as cardholder data and what doesn't.

Where BINs trip merchants up

A few patterns we see regularly:

• Stale block-lists. A BIN range you blocked three years ago because of fraud has since been reissued to a different portfolio. You're now declining clean customers.
• 6-digit lookups against 8-digit ranges. The 6-digit prefix matches multiple 8-digit BINs with different attributes. You're making rules off the wrong row.
• Treating BIN country as billing country. They're often the same. They're not always the same. A UK resident might be using a US-issued Amex.
• Assuming BIN = bank brand. Many fintechs issue on top of partner BIN sponsors. The BIN might say "Bank of XYZ" when the customer thinks of it as a Monzo or Revolut card.

BINs in telephone payments

When a customer reads card details to an agent or keys them into a phone keypad, the BIN is still the first 6-8 digits — same rules. In a properly designed phone payment flow, the agent never sees or hears the full PAN, but the merchant can still know the BIN (and therefore the issuer, scheme, and country) because those digits are needed for routing.

Paytia's agent-assisted DTMF capture works this way. The customer types their card number directly on their phone keypad, the BIN is passed through to our processing partner for routing, and the agent sees a masked PAN. The BIN-derived data — issuer country, card type — is still available for fraud and analytics, just without the full number ever crossing your contact centre.