A card BIN, formally the Issuer Identification Number under ISO/IEC 7812, is the first six to eight digits of a payment card’s PAN. It identifies the issuing bank, card network (Visa, Mastercard, and similar brands), card type, and issuing country. That’s genuinely useful for payment routing and fraud screening, but a BIN cannot confirm a card’s balance, authorization status, or the cardholder’s identity.
TL;DR:
- Major networks are transitioning from 6-digit BINs to 8-digit BINs due to exhaustion of available combinations, requiring systems to support both formats.
- BIN lookup APIs return structured data such as issuer name, country, card type, and network but do not verify account funds, status, or cardholder identity.
- BIN data should be combined with other signals like IP geolocation, AVS, and 3DS results to effectively detect fraud and avoid false positives.
- Reassignments of BIN ranges and changes in issuer information happen frequently, so regular data refreshes are essential to prevent misclassification and routing errors.
- BIN checks are a regulatory light area, mainly supporting compliance with standards and risk assessment, but do not alone confirm genuine transaction approval or card validity.
Table of Contents
- What Is a Kortelių BIN Kodas and Where Does ISO/IEC 7812 Fit?
- How to Read a Card Number: MII, BIN, Account Number, and the Luhn Digit
- How BIN Lookup Tools and APIs Work
- What BIN Data Reveals and What It Does Not
- Practical Checklist: Using BIN Data in Payment Operations
- Common BIN-Related Fraud Schemes and Prevention Methods
- Regulatory and Compliance Aspects of BIN Usage
- BIN vs. PAN vs. IIN: Clearing Up the Terminology
- How BIN Changes Ripple Through Merchants and Issuers
- Real-World BIN Use Cases in E-Commerce and Banking
- Get Verified Payment Infrastructure Built Around Real Compliance
- Publisher Perspective: BIN Verification in Compliant B2B Payment Infrastructure
- Sources
What Is a Kortelių BIN Kodas and Where Does ISO/IEC 7812 Fit?
The BIN identification number, also called the IIN, is defined by the same international standard that governs the structure of every payment card number in circulation. A full primary account number (PAN) typically runs 13 to 19 digits, and the leading block, six to eight digits under ISO/IEC 7812, identifies the institution that issued the card.
For decades, the industry standard was a 6-digit BIN. That’s changing. Major networks pushed toward 8-digit BIN issuance because the pool of available 6-digit combinations was running out as card issuance scaled globally, according to PayCompass. Existing 6-digit BINs still work. Systems built today, though, need to support both lengths without breaking validation logic.
Two things sit inside that leading digit block:
- The Major Industry Identifier (MII), the single first digit, which flags the general category of issuer (4 and 5 signal banking and financial institutions, for instance).
- The BIN/IIN proper, the remaining five to seven digits, which narrows that down to a specific issuing bank or program.
Get this piece wrong in your code and every downstream lookup, from fraud scoring to routing, inherits the error.
How to Read a Card Number: MII, BIN, Account Number, and the Luhn Digit
A full PAN breaks into four functional pieces, and knowing where each one starts saves you from guessing. Copy the first six digits for a legacy BIN or the first eight for a modern one. Everything after that, up to the final digit, is the individual account number the issuer assigned to that specific card.
Brand prefixes are the fastest visual check available:
- Visa cards start with 4.
- Mastercard ranges span 51 to 55 and 2221 to 2720.
- American Express cards start with 34 or 37.
Pro Tip: Never assume a prefix guarantees the network. Some co-branded and prepaid programs use ranges assigned to a sponsor bank rather than the retail brand printed on the card, so treat the prefix as a strong signal, not proof.
The last digit of every PAN is the Luhn check digit, a simple checksum defined in the same ISO/IEC 7812 standard. Running the Luhn algorithm catches a mistyped or transposed digit before you waste an API call or a customer’s patience. It confirms the number is structurally valid. It says nothing about whether the account behind it is open, funded, or even real.
How BIN Lookup Tools and APIs Work
A BIN lookup tool takes those first six to eight digits and returns structured data about the issuing institution. Most production-grade APIs, including services like BinCheck, expose the response as JSON with a consistent field set so your application can parse it programmatically rather than scrape a web page.
A typical response includes:
| Field | What it tells you |
|---|---|
bin |
The digit sequence you queried |
brand |
Card network (Visa, Mastercard, etc.) |
type |
Debit, credit, or charge card |
level |
Product tier (standard, gold, platinum, business) |
issuer.name |
Issuing bank or institution |
issuer.website |
Issuer’s public website, where available |
country.name |
Country where the card was issued |
flags |
Prepaid, commercial, or corporate indicators |
isValid |
Whether the format passes structural checks |
A common integration flow looks like this: your checkout or onboarding form captures the card number, your backend extracts the BIN, sends it to the lookup API, and uses the returned brand, type, and country fields to route the transaction or feed a risk score. That call needs an authenticated API key, and nearly every provider enforces rate limits, so caching results locally rather than querying on every transaction cuts both cost and latency. Data freshness matters here too. Issuer ranges get reassigned, so a cached record from six months ago may already be stale.
What BIN Data Reveals and What It Does Not
A BIN tells you about the card, not the cardholder. It surfaces issuer name, network, product tier, and country. It does not contain personally identifiable information, and it cannot confirm whether the account has funds, is active, or belongs to the person attempting the transaction, a distinction Bincodes makes explicit in its own lookup guidance. Real-time confirmation of card status only happens through an authorization request routed to the issuing network.
Freshness is the other blind spot. Issuers reassign BIN ranges, sell portfolios, and use sponsor banks for card programs, so a range that pointed to one institution last year can point somewhere else now. A lookup that returns “unknown” for the issuer field often means the range was recently reassigned and the database hasn’t caught up, as shown in real BIN detail records where issuer data is simply unavailable.
Pro Tip: Never build a fraud rule that relies on BIN data alone. Pair it with signals your BIN provider can’t see: IP geolocation, address verification (AVS), 3D Secure results, and the authorization response code from the card network itself.
That layered approach is why serious fraud teams treat BIN checks as one input among several, not a verdict:
- BIN plus IP geolocation flags mismatches between issuing country and transaction origin.
- BIN plus AVS catches billing address inconsistencies a BIN alone would miss.
- BIN plus 3DS result adds cardholder authentication before authorization.
- BIN plus authorization response code is the only combination that confirms the transaction actually succeeded.
Practical Checklist: Using BIN Data in Payment Operations
Turning BIN lookups into a reliable production system takes more than dropping an API call into your checkout flow. Here’s how teams that handle this well structure it:
- Mask and minimize stored data. Keep only the digits you need for routing or reporting, and avoid logging full PANs anywhere near your BIN lookup calls, in line with PCI-conscious data handling.
- Call the API during authorization, cache for repeat traffic. A first-time BIN triggers a live lookup; repeat BINs from returning customers can pull from a local cache with a short time-to-live, hours to days depending on your risk tolerance, rather than an indefinite cache.
- Refresh anything that previously returned “unknown.” Reassigned ranges resolve over time, so schedule automatic re-checks instead of treating a stale null result as permanent.
- Build a fallback path. If the BIN API times out or errors, your system should still route the transaction through standard network authorization rather than blocking the payment entirely.
- Govern access to your BIN provider’s keys. Rotate API keys on a schedule, restrict who can query in bulk, and keep an audit trail of lookups tied to transaction IDs.
Pro Tip: When evaluating a BIN data vendor, ask about update cadence and uptime SLAs before you ask about price. A cheap feed that’s three months stale will cost you more in false declines than the subscription ever saved.
Demivolt’s own cross-border payment security checklist covers the broader governance controls that sit around BIN verification, including access management and audit logging for regulated accounts.
Common BIN-Related Fraud Schemes and Prevention Methods
BIN attacks exploit the fact that the first six to eight digits of any valid card are public knowledge, not a secret. Fraudsters run BIN attacks, where automated scripts generate thousands of card number combinations sharing a known BIN prefix and test them against small transactions to find ones that authorize. This is why repeated low-value authorization attempts from a single BIN range, especially across multiple merchants in a short window, is a red flag worth automated monitoring.
Card testing follows a similar pattern: criminals with a partial or stolen number use the BIN to identify the issuer and network, then attempt small “test” charges to confirm the full number works before running a larger fraudulent transaction. Merchants who see velocity spikes tied to a single BIN, particularly on low-dollar transactions with high decline rates, should throttle or flag that traffic automatically.
Prevention leans on the same layered approach that limits BIN-only reliance elsewhere in this guide. Velocity checks that count transaction attempts per BIN per hour catch testing patterns before they escalate. Combining BIN country data with IP geolocation flags cross-border mismatches common in stolen-card fraud. Requiring 3D Secure authentication on BINs associated with higher fraud rates adds friction exactly where it’s statistically justified, without punishing every customer. None of these methods work in isolation. A BIN-informed rule engine that also weighs authorization response codes and device fingerprints closes gaps that any single signal leaves open.
Regulatory and Compliance Aspects of BIN Usage
BIN data itself sits in a comparatively light regulatory zone because it identifies an issuer and card program, not an individual. That distinction matters for how you’re allowed to handle it. Since BINs are not classified as personally identifiable information, storing or processing them doesn’t trigger the same obligations under frameworks like GDPR that apply to cardholder names, full PANs, or transaction histories.
That said, compliance obligations still attach to the broader system a BIN lookup sits inside. PCI DSS governs how you handle any card data adjacent to a BIN check, including truncation rules for stored PANs and access controls on systems that process payment information. If your BIN lookup flow touches full card numbers before extracting the prefix, that flow falls under PCI scope even though the BIN itself doesn’t.
Anti-money laundering rules add another layer for regulated payment institutions. Country and issuer fields returned by a BIN lookup can feed sanctions screening and geographic risk assessments, since transactions tied to BINs from restricted jurisdictions may require enhanced due diligence. Demivolt’s overview of payment industry terminology walks through how standards like ISO/IEC 7812 intersect with the compliance vocabulary finance teams need to know. The practical takeaway: BIN data supports your compliance program, but it doesn’t replace the KYC and transaction monitoring obligations your license already carries.
BIN vs. PAN vs. IIN: Clearing Up the Terminology
These three terms get used almost interchangeably in casual conversation, and that’s where confusion starts. The PAN, primary account number, is the complete card number printed on the card, typically 13 to 19 digits depending on the network. The BIN and IIN refer to the same thing: the leading six to eight digits of that PAN. BIN is the older, more common industry term; IIN is the formal name used in ISO/IEC 7812 itself. If you see both terms in a vendor’s documentation, they’re describing identical data.
Where people get tripped up is assuming the BIN is somehow a separate number from the PAN. It isn’t. It’s a subset, a slice of the same digit string that carries issuer-identifying information because of how the numbering scheme was designed. The remaining digits, everything between the BIN and the final Luhn check digit, form the account number that’s unique to that specific card. Two customers at the same bank with the same card product will share an identical BIN and differ only in that account-number segment.
The MII, the single leading digit of the BIN, is sometimes treated as its own category, but it’s really just the first character of the BIN, not a fourth separate identifier. Getting this hierarchy straight, PAN contains BIN, BIN starts with MII, matters when you’re writing parsing logic, because miscounting digits by even one position returns garbage data from any lookup API.
How BIN Changes Ripple Through Merchants and Issuers
When an issuer reassigns or retires a BIN range, the effects reach further than most merchants expect. A merchant’s routing tables, fraud rules, and reporting dashboards that reference a specific BIN range by issuer name can silently start misclassifying transactions the moment that range changes hands. This is precisely why BIN databases occasionally show “unknown” issuer fields on ranges that were recently reassigned.
For card issuers, migrating from 6-digit to 8-digit BIN ranges required upgrading internal systems that had hardcoded assumptions about digit length, a nontrivial technical lift across the payments industry as the transition accelerated. Merchants and payment processors who built their own systems around fixed 6-digit parsing faced the same retrofit. Any system still assuming a fixed BIN length is running on borrowed time as adoption of longer ranges continues.
The practical impact for merchants shows up in three places. Fee calculations tied to BIN-based interchange categories can shift if a range moves between issuer tiers. Fraud rules keyed to specific BINs may need retuning if a range gets reassigned to a different risk profile. And customer support teams referencing “your bank” based on stale BIN data can give customers flatly wrong information about who issued their card. Refreshing BIN reference data on a regular cadence, rather than treating it as a one-time lookup, is the only way to avoid these quiet failures accumulating.
Real-World BIN Use Cases in E-Commerce and Banking
E-commerce platforms use BIN data to make split-second routing decisions before a transaction even reaches the card network. A merchant processing high volumes across regions can route a European-issued card to a European acquirer and a North American card to a domestic one, cutting cross-border interchange fees, an approach Pagos.ai documents as standard practice among processors optimizing for cost. This routing logic alone has become significant enough that smart routing is now a direct response to the billions merchants lose to avoidable declines industry-wide.
On the banking side, issuers use their own BIN ranges to segment card products, business cards, consumer debit, prepaid gift cards, and apply different authorization rules to each without touching the underlying processing infrastructure. A bank offering both consumer and business Visa cards, for instance, can assign distinct BIN ranges to each product line and configure separate fraud thresholds, since business card fraud patterns differ meaningfully from consumer ones.
Fraud teams at both merchants and issuers lean on BIN country and issuer fields as a first-pass filter, flagging a transaction for review when the card’s issuing country doesn’t match the shipping address, then escalating to full authentication only for flagged cases rather than friction for every customer. Pairing that BIN signal with AI-driven pattern detection, as outlined in Singleclic’s overview of real-time fraud detection, lets teams catch anomalies a static rule set would miss entirely. Subscription billing platforms use a lighter version of the same idea, checking BIN type to distinguish prepaid cards, which often fail recurring charges, from standard credit cards before scheduling the next billing attempt.
Get Verified Payment Infrastructure Built Around Real Compliance
BIN verification is one piece of a much larger payment integrity puzzle, and for growing businesses managing cross-border transactions, the harder problem usually isn’t reading a BIN, it’s building the account infrastructure that makes verified payments actually settle cleanly. Some platforms provide regulated business IBAN accounts, SEPA and SWIFT payment processing, and virtual and physical business cards designed for companies that need transparent, compliant financial infrastructure without stitching together multiple vendors.
If your payment stack needs to validate account details alongside card BIN checks, Demivolt’s free IBAN validator tool checks account numbers against the ISO 13616 standard in seconds. For teams still mapping out how IBANs fit into their broader verification workflow, the explainer on what an IBAN is and how it’s used covers the fundamentals alongside BIN-level card checks.
Publisher Perspective: BIN Verification in Compliant B2B Payment Infrastructure
Working alongside teams that build payment infrastructure, the pattern that stands out is how often BIN checks get treated as a finish line instead of a filter. A clean BIN lookup feels like confirmation. It isn’t. The businesses that cut declines and catch fraud earliest are the ones that pair BIN data with authorization response codes and AVS, then log every mismatch for review rather than trusting the first green flag.
…
Account infrastructure can be built with layered logic in mind, treating BIN data as one input, not the verdict, when validating cross-border transactions for business clients.
— dd