Bank Identification Number (BIN): How Issuers and Merchants Stop Card Fraud

Every payment card in your wallet starts with a number that has nothing to do with your personal account and everything to do with routing a transaction to the right bank. That number is the Bank Identification Number, or BIN, and it is read, checked, and acted on by a merchant’s payment system every single time a card is used online. Merchants, payment service providers, and fraud teams rely on it to route transactions, screen for suspicious activity, and decide how much of a card number they are allowed to display or store under PCI DSS.

This guide covers what a BIN actually is, how it fits into the structure of a card number, how payment systems use it during a live transaction, the fraud patterns built around it, and the cryptographic and compliance controls that apply to it under PCI DSS. It also covers where a BIN falls short as a fraud control on its own, and the questions merchants and issuers ask most often when they build BIN-based screening into their payment stack.

Quick Answer: What Is a Bank Identification Number, and Why Does It Matter?

A Bank Identification Number is the leading block of digits on a payment card, six digits historically and up to eight digits under the current standard, that identifies the card’s industry, network, and issuing financial institution before any transaction is authorized. It matters because it is the first piece of information a payment system can act on: it tells a merchant or processor which network to route a transaction to, which issuer to contact for authorization, and, when something looks wrong, which bank to call. The recommended action for any organization that touches card data is to treat the BIN as a routing and fraud-signal field, not as sensitive data on its own, while still applying PCI DSS’s display and storage rules to the full card number it belongs to.

What Is a Bank Identification Number (BIN)?

A Bank Identification Number (BIN), also called an Issuer Identification Number (IIN) since not every card issuer is a bank, is the leading portion of a card’s Primary Account Number (PAN) that identifies the card network and the financial institution that issued it. It is defined under ISO/IEC 7812, the international standard jointly maintained with the American National Standards Institute (ANSI) that governs how payment card numbers are structured worldwide.

For decades, the BIN was fixed at six digits. As card issuance grew, particularly for Visa and Mastercard, the available six-digit combinations began running out, and the 2017 revision of ISO/IEC 7812-1 allowed card networks to expand the BIN to eight digits. Both lengths remain valid today; a card’s PAN stays at a maximum of 19 digits either way, so an eight-digit BIN simply leaves fewer digits for the individual account identifier that follows it. Every payment card type, including credit, debit, charge, and prepaid or gift cards, carries a BIN.

Major Industry Identifier: What the First Digit Means

The single leading digit of the BIN is the Major Industry Identifier (MII), and it places the card into a broad industry category before the rest of the BIN narrows it down to a specific issuer.

Leading digit	Industry
0	ISO/TC 68 and other future industry assignments
1	Airlines
2	Airlines, and future industry assignments
3	Travel and entertainment (American Express, Diners Club)
4	Banking and financial (Visa)
5	Banking and financial (Mastercard)
6	Merchandising and banking/financial (Discover, and others)
7	Petroleum and future industry assignments
8	Healthcare, telecommunications, and future industry assignments
9	National assignment, followed by a three-digit country code

PAN Structure: BIN, Account Identifier, and the Luhn Check Digit

A full Primary Account Number breaks down into three parts. The BIN or IIN, six or eight digits, identifies the industry, network, and issuer. The individual account identifier, a variable number of digits that shrinks as the BIN grows, since the total PAN length is capped at 19 digits, identifies the specific cardholder account within that issuer’s range. The final digit is the Luhn check digit, a single digit calculated with the Luhn algorithm that lets a payment system quickly reject a mistyped or malformed card number before it is ever sent for authorization. None of these three components, on their own, identify a specific person; that link exists only in the issuing bank’s own account records.

How Does a Payment System Use a BIN During a Transaction?

When a customer enters a card number at checkout, the merchant’s payment gateway or processor reads the BIN before it does anything else with the card. A BIN lookup against the card network’s published ranges or a licensed BIN database returns the card brand, whether the card is credit, debit, or prepaid, the card tier, such as standard or platinum, and the country and identity of the issuing bank. That information determines which network the authorization request is routed over and gives fraud systems their first signal, before the transaction is ever approved or declined by the issuer. Without a readable BIN, a processor has no way to route the request at all, which is why a corrupted or truncated BIN fails a transaction outright rather than simply reducing available fraud data.

• Card brand, such as Visa, Mastercard, American Express, or Discover.
• Card type and tier, such as debit, credit, corporate, or platinum.
• Country and identity of the issuing bank.

What Is the Fraud Threat Model Around BINs?

A BIN is public information printed on every card of that type, so it cannot be kept secret, and both merchants and fraudsters use it. The threat model splits into two distinct patterns.

BIN Attacks: Card Testing and BIN Sweeping

A BIN attack, sometimes called BIN sweeping or card testing, is an automated attempt to generate valid full card numbers by starting from a known, publicly available BIN and brute-forcing the remaining account digits, expiration date, and CVV, usually against a low-value or free transaction endpoint that returns an approve or decline response quickly. Because the BIN and Luhn check digit narrow the search space significantly compared to guessing a full sixteen-digit number at random, this remains one of the most common automated attacks against payment gateways. Rate limiting on authorization attempts, CAPTCHA on checkout forms, address verification (AVS) checks, and monitoring for a spike in declines from a single IP range or BIN are the standard defenses.

BIN-Based Social Engineering Scams

The second pattern targets people, not systems. A caller impersonates the cardholder’s bank, sometimes using a spoofed caller ID, and states that the account has been compromised. Because the BIN is public and easy to look up from any card of that type, the caller can recite the first six or eight digits back to the victim to sound legitimate, then ask the victim to “confirm” the remaining digits and the CVV, which is the actual information the scam is designed to extract. A bank already knows its own BIN and never needs a customer to read it back; a request to confirm the digits after the BIN, especially over an unsolicited call, is the reliable signal that the call is fraudulent. The right response is to hang up and call the number printed on the back of the card, not any number or callback line the caller provides. Our guide on reducing human error in security programs covers how to build this kind of scam awareness into staff and customer training.

What Cryptographic and Data Protection Controls Apply to BIN and PAN Data?

The BIN itself is generally not treated as sensitive authentication data, since it identifies an issuer and network rather than an individual account, but it is part of the PAN, which is. PCI DSS v4.0.1 sets the controls that apply once a BIN is attached to the rest of a card number.

• Masking when displayed (Requirement 3.4): where a PAN is shown on a screen or receipt, only the minimum digits needed for the business purpose may be visible. The maximum permitted display is the first six and last four digits for a six-digit BIN, or the first eight and last four for an eight-digit BIN; every digit in between must be masked.
• Rendering stored PAN unreadable (Requirement 3.5): a full PAN kept in storage has to be protected with strong cryptography, meaning encryption, tokenization, truncation, or keyed cryptographic hashing. A BIN and the last four digits, stored on their own without the digits in between, generally fall outside this requirement because they do not reconstruct a usable PAN.
• Format-preserving tokenization: most tokenization systems replace the sensitive middle digits of the PAN while preserving the real BIN and last four, which is why fraud screening, loyalty programs, and analytics built on BIN data keep working even after the underlying card number has been tokenized.

Encrypting or tokenizing cardholder data end to end depends on where the cryptographic keys are generated, stored, and rotated. If your PCI DSS scope includes on-premises encryption or tokenization infrastructure, our guide on HSMs and PCI DSS compliance covers the hardware key management side of this requirement in detail, and Encryption Consulting’s HSM-as-a-Service can operate that key management layer for you.

What Are the Compliance Implications for Merchants and Issuers?

Any organization that stores, processes, or transmits card data falls under PCI DSS, and BIN handling touches several parts of that scope at once. Display logic in customer service tools and receipts has to respect the Requirement 3.4 masking limits described above. Storage systems, including fraud and analytics platforms that key off the BIN, have to be reviewed to confirm they are storing only the BIN and last four rather than a reconstructable PAN. Card networks are also actively enforcing the shift to eight-digit BINs; Visa and Mastercard have both issued mandates requiring acquirers, processors, and merchants to support eight-digit BIN recognition, so any system that still assumes a fixed six-digit BIN length is a compliance and operational gap that needs to be closed, not just a display inconvenience. Payment providers operating in the European Economic Area also need to account for the Payment Services Directive 2, which layers its own strong customer authentication requirements on top of PCI DSS for card-not-present transactions; see our guide on PSD2 for how the two frameworks interact. For a full walkthrough of scoping and validating against PCI DSS itself, see our comprehensive PCI DSS compliance guide.

Decision Table: How Should You Handle BIN and PAN Data in Different Situations?

Situation	Recommended approach
Customer support agents need to identify a card during a call	Display BIN plus last four only; mask every digit in between per Requirement 3.4
Fraud or analytics platform needs issuer, network, and card-tier data	Store the BIN and last four only; avoid retaining the full PAN or the digits in between
Full PAN must be retained for a documented business reason	Render it unreadable per Requirement 3.5: strong encryption, tokenization, truncation, or keyed hashing
Payment stack still assumes a fixed six-digit BIN	Update BIN parsing logic to support eight-digit BINs before the network-mandated cutover in your region
Sudden spike in low-value declines from a narrow BIN range	Treat as a likely BIN attack; apply rate limiting, CAPTCHA, and AVS checks rather than only blocking the BIN
Customer reports a caller who recited their BIN and asked for the rest of the card number	Treat as a confirmed social engineering scam; instruct the customer to hang up and call the number on the card

Numbered Workflow: How Do You Implement BIN-Based Fraud Screening and Compliance Controls?

1. Inventory every system that touches PAN or BIN data: payment gateway, fraud engine, customer service tools, receipts, and analytics platforms.
2. Confirm which of those systems can parse both six-digit and eight-digit BINs, and update any that assume a fixed six-digit length.
3. Apply Requirement 3.4 masking rules everywhere a PAN is displayed, limiting visible digits to the BIN and last four.
4. Apply Requirement 3.5 protections, meaning encryption, tokenization, truncation, or keyed hashing, to any system that stores a full PAN.
5. Integrate BIN lookup into your fraud engine to flag geographic mismatches, card-tier anomalies, and known high-risk issuer ranges.
6. Define an escalation procedure for suspicious BIN-related activity, both automated card testing and customer-reported social engineering calls.
7. Test your payment stack against your card networks’ published eight-digit BIN test ranges before their regional enforcement date.
8. Document the above in your PCI DSS Self-Assessment Questionnaire or Report on Compliance evidence.

What Are the Limitations of BIN-Based Fraud Screening?

• Portfolio sales blur issuer data: a BIN range can be sold or reassigned between issuers, so BIN lookup databases occasionally return an outdated or incorrect issuing bank.
• Geolocation is approximate: a BIN identifies the country where a card was issued, not where the cardholder currently is, so a genuine traveler or expatriate will regularly trigger a country mismatch that is not actually fraud.
• It is a signal, not a verdict: a BIN mismatch or unusual card tier should raise a transaction’s risk score, not automatically decline it; treating BIN data as a sole fraud decision produces false positives that cost legitimate sales.
• It does not replace the rest of the fraud stack: BIN checks work best alongside 3-D Secure authentication, velocity and device fingerprinting, and address verification, not as a standalone control.
• Fraudsters know it too: because BIN ranges are public, sophisticated fraud rings deliberately select BINs and shipping addresses that match plausible cardholder geography specifically to defeat BIN-based screening.

Our Recommendation

Treat the BIN as one input into a layered fraud and compliance program, not as a control on its own. In practice, that means three things. First, get your masking and storage logic aligned with PCI DSS Requirements 3.4 and 3.5 before you spend engineering time on fraud analytics, since a BIN-based fraud program built on top of non-compliant PAN storage creates more risk than it removes. Second, confirm your entire payment stack, including systems your team may not think of as “payment systems,” such as loyalty platforms and customer service tools, correctly parses eight-digit BINs; this is a compliance deadline as much as a technical one. Third, pair BIN screening with tokenization so that a full PAN is not sitting in your fraud or analytics database at all; our Compliance Advisory team can assess where your current PCI DSS scope has gaps, and our HSM and PCI DSS guide covers the key management side of getting tokenization and encryption right.

Conclusion

A Bank Identification Number is a small piece of a card number that does a disproportionate amount of work: it routes every transaction, gives fraud teams their first signal, and determines exactly how much of a card number a business is allowed to show or store. Used well, alongside PCI DSS-compliant masking and storage, tokenization, and the rest of a layered fraud stack, it is a genuinely useful tool. Used carelessly, whether that means a payment system that cannot parse an eight-digit BIN or a customer service script that reads back too many digits, it becomes either a compliance gap or a tool fraudsters can use against your own customers. If you need help closing either gap, Encryption Consulting’s Compliance Advisory and HSM-as-a-Service teams work with payment organizations on exactly this kind of PCI DSS and cryptographic key management program.

Frequently Asked Questions

Is a BIN the same as a full card number?

No. The BIN is only the leading six to eight digits of the Primary Account Number (PAN). The full PAN also includes the individual account identifier and a Luhn check digit, and it is the full PAN, not the BIN alone, that identifies a specific cardholder account.

Can merchants store BIN numbers without violating PCI DSS?

Generally yes. Storing the BIN together with the last four digits, without the digits in between, does not reconstruct a usable PAN, so it typically falls outside PCI DSS Requirement 3.5’s protections for stored PAN data. Storing anything closer to the full card number still requires encryption, tokenization, truncation, or keyed hashing.

How do I recognize a Bank Identification Number scam call?

The reliable signal is being asked to “confirm” card digits after the caller has already read your BIN back to you. A legitimate bank already has your full account information and never needs you to read digits back to verify your identity over an unsolicited call. Hang up and call the number printed on the back of your card instead.

Why did BINs expand from six to eight digits?

Six-digit BINs were running out of available combinations as card issuance grew, particularly for Visa and Mastercard. The 2017 revision of ISO/IEC 7812-1 allowed card networks to issue eight-digit BINs, and both lengths remain valid today, with the total PAN length capped at 19 digits either way.

Does a BIN reveal my identity or account balance?

No. A BIN only identifies the card network, card type, and issuing bank, information that is the same for every card of that type. It reveals nothing about a specific cardholder’s identity, account balance, or transaction history.