BIN Lookup: Using Bank Identification Numbers to Make Smarter Routing and Fraud Decisions

The first six to eight digits of a card number carry more information than most payment teams ever put to use. Before an authorisation request is sent, before a routing decision is made, before a fraud score is calculated, the Bank Identification Number (BIN) identifies the issuing bank, the card type, the issuing country, and the card programme. Most merchants look at this data. Few actually act on it.

BIN lookup is the foundation of the card intelligence stack. This article covers what BIN data contains, how BIN lookup works, why the 8-digit BIN migration raised the stakes on accuracy, and how payment teams use it to improve authorisation rates, reduce fraud, and route more intelligently.

To learn more about how card intelligence solutions can be used and work end to end, check our guide.

What is a BIN (Bank Identification Number)?

The Bank Identification Number is the first six to eight digits of a payment card number. It is defined under ISO/IEC 7812 and published by card networks. Looking it up returns a structured set of attributes about the card: the scheme (Visa, Mastercard, Amex, Discover, JCB, UnionPay, or a domestic scheme), the type (credit, debit, or prepaid), whether it's a consumer or commercial card, the issuing bank and its country, and, where applicable, co-brand information and whether the number is a raw PAN or a token. Fields like card product tier or currency aren't part of a standard response, richer scheme-direct feeds can expose more, but a baseline BIN lookup does not.

The 6-digit to 8-digit BIN migration: why your BIN table may be wrong

For decades, BINs were six digits long. In 2017, ISO published an update to IEC 7812 mandating the transition to 8-digit BINs to address BIN exhaustion, the global payment industry was simply running out of 6-digit ranges as card issuance grew. The original deadline for full implementation was April 2022, though adoption has been uneven across markets and processors. The commercial consequences are real. A 6-digit BIN table can carry a single entry for a range that, at 8 digits, splits into multiple distinct products, issuers, or different countries. Merchants running 6-digit lookups see blended, inaccurate results.

Why 8 digits often isn't the finish line

The move to 8-digit BINs fixed the worst of the accuracy problem, but it did not fully solve it. Both major schemes structure card data more granularly than the BIN itself: account ranges can be flagged as shared across more than one issuer or product at the 6- or 8-digit level, and the schemes' own lookup services resolve meaningfully further than that when given more of the card number to work with. In practice, an 8-digit-only lookup can still return a range that blends more than one issuer, product, or country, particularly on newly issued fintech ranges, co-branded cards, and any BIN flagged as shared.

The practical fix is to send more of the card number than the classic 6-8 digit BIN. As a working rule of thumb, many payment teams treat around 12 digits as the point where lookups start resolving to genuine account-range accuracy rather than a blended BIN-level result, still well short of the full 16-to-19 digit card number. At that point you are no longer querying "the BIN" in the strict sense, you are querying an account range, but for merchants with meaningful co-brand, fintech, or shared-BIN exposure the accuracy gain is usually worth it.

This comes with a trade-off worth naming honestly: a bare 6- or 8-digit BIN is non-sensitive range data that sits outside PCI DSS scope, but the more of the actual card number you send to get a sharper answer, the closer you get to handling the primary account number itself. For that reason, higher-digit lookups are typically run from whichever system already sits inside PCI scope for the raw card, such as a tokenisation provider, rather than bolted on as a separate standalone call. This is the same pre-authorisation integration point discussed in the pillar article: the accuracy gain from more digits is real, but it is usually captured by the system already handling the card, not by sending raw PANs to an additional third-party service.

The real cost of inaccurate BIN data: what the research shows

BIN account ranges change constantly. Issuers create, discontinue, modify, and reallocate ranges to new fintech and co-brand partners every day. With 8-digit BINs producing more granular allocations, the pace of change is accelerating. A BIN database that is not updated daily is drifting from accurate continuously.

An independent study commissioned by Mastercard in November 2024, covering 120,000 BIN account ranges tested across multiple third-party data vendors and aggregators, found that on average 23 percent of BIN data provided by uncertified sources was either incorrect or missing, with the figure reaching 31 percent in some cases. The inaccuracies were not limited to obscure fields: the study found errors across every BIN data field, including issuer name, funding source, and country of issuance. Uncertified providers were also found to update their databases monthly or quarterly rather than daily, meaning data drift compounds over time.

The downstream consequences of inaccurate BIN data map directly to the decisions that depend on it. False declines occur when transactions are rejected because BIN data incorrectly classifies a card, for example, routing to an acquirer with a poor approval rate for a card type because the card product is misidentified. Unauthorized transactions occur when prepaid card flags are missing or funding source data is wrong, allowing card types that should be blocked to pass merchant eligibility checks. Incorrect routing decisions increase processing costs. Failed subscription billing charges occur when non-reloadable prepaid cards are stored on file because the BIN data at onboarding did not correctly flag the card type.

Real-world results back this up: one major e-commerce processing platform reported that daily BIN data updates from a certified scheme source arrived roughly 90 percent faster than from its previous source, with a direct improvement in routing and fraud detection accuracy. Microsoft reported a 30 percent improvement in BIN card labelling accuracy after switching to daily-updated BIN data.

What BIN lookup returns: reading the response

Exact field names vary by provider, but a typical BIN lookup response looks like this:

How BIN lookup works: the technical flow

BIN lookup operates as a pre-authorisation API call. The merchant or payment platform submits the first six to eight digits of the card number to a BIN lookup service, which queries a continuously updated database of BIN ranges maintained from official scheme sources. The response is returned in milliseconds, before any authorisation request is initiated.

The lookup can be triggered at several points in the payment flow: at card number entry (many payment UIs use this to display the card brand logo as soon as it's known), before routing, before fraud scoring, and before applying business rules such as prepaid or geographic restrictions.

For implementation details, check our BIN lookup API documentation.

BIN data as a fraud signal: what it can and cannot tell you

BIN data is a strong pre-authorisation signal but it is not a fraud detection system on its own.

Country of issue mismatch is a meaningful fraud signal. If a cardholder is in Germany (based on IP geolocation) but the BIN indicates the card was issued by a bank in Nigeria, this is a risk flag worth routing to additional scrutiny. Commercial card identification matters for B2B merchants, where corporate, fleet, and purchasing cards have different interchange rates, different SCA exemption rules, and different chargeback dynamics than consumer cards.

BIN data tells you about the card programme, not the cardholder. A fraudster with a stolen standard Visa credit card presents exactly the same BIN data as the legitimate cardholder. BIN lookup answers 'what kind of card is this?' not 'is the person presenting this card who they say they are?' For the identity question, see Article 5 on account name verification.

Airlines: BIN data and surcharging

Airlines are one of the clearest examples of BIN data driving a direct pricing decision rather than just a risk decision. Where card surcharging is legally permitted, airlines commonly use the card type field from a BIN lookup, credit versus debit, and sometimes the specific product, to decide whether a surcharge applies at all. Getting this wrong cuts both ways: surcharging a card that should be exempt is a compliance and customer-trust problem in markets that restrict surcharging, while failing to surcharge a card that qualifies means quietly absorbing that cost on every transaction. Because surcharging rules vary by country and by card type, this is one of the use cases where 8-digit accuracy (and, for high-value bookings, the additional digits discussed above) genuinely changes the revenue outcome, not just the fraud outcome.

Subscription businesses: catching prepaid cards at card-on-file

For subscription businesses, the highest-value use of BIN data is often the simplest: flagging prepaid and virtual cards at the point a card is stored on file, not at the point of each recurring charge. Prepaid and single-use virtual cards, including those issued by fintechs for exactly this purpose, are disproportionately used to claim free trials without ever intending to pay for the subscription that follows. Catching this at onboarding, before the first trial period even starts, avoids a cycle of failed renewal charges that a subscription business would otherwise only discover weeks later.

BIN lookup and payment routing: the pre-authorisation layer

One of the least discussed but most commercially valuable uses of BIN data is in payment routing. When a merchant operates across multiple acquirers (as is increasingly common in payment orchestration architectures) the BIN determines which acquirer is likely to produce the best authorisation outcome for a given card. Some acquirers have preferential approval rates with specific issuing banks, based on historical transaction data and relationship agreements. A merchant with access to BIN-level data can use this to direct cards from certain issuers to the acquirer with the highest historical approval rate for that BIN range. Fintechs and payment orchestrators build entire routing engines around exactly this logic, refining the rules continuously as approval-rate data accumulates by issuer and acquirer.

Regulatory context: what regulators say about BIN data

BIN data is not regulated in the same way as cardholder data, it does not fall under PCI DSS as sensitive authentication data. But several developments have raised the operational stakes on getting it right. Under PSD2, the one-leg-out rule (where SCA does not apply if either the acquirer or issuer is outside the EEA) depends on knowing the issuing country of the card from BIN data; getting this wrong means either over-applying friction or creating regulatory exposure. Mastercard's data enrichment mandate (AN 4569) requires issuers and acquirers to provide enriched merchant and transaction data, with accurate BIN data flowing through this mandate. Both major schemes have also tightened certification and registration requirements for resellers and third parties over the past few years, so payment teams relying on a reseller or third-party BIN service should periodically confirm the provider's current access status directly rather than assuming a prior integration's terms still hold.