BIN routing explained: picking a provider by card issuer

Two cards can arrive at the same checkout, for the same amount, from the same kind of customer, and have completely different chances of approval. One is a debit card from a domestic bank that knows your acquirer well. The other is a credit card from a foreign issuer that treats your merchant category with suspicion. The card number tells you which is which before you send anything, and BIN routing is the practice of acting on that.

This article explains what a BIN contains, how BIN routing decides the provider, what an example rule set looks like for a cross-border merchant, and the mistakes that make BIN rules worse than none.

What is a BIN, and what does it tell you?

The BIN, or bank identification number, is the first part of the card number. It identifies the issuer, the bank or institution that issued the card. Looked up in a BIN table, it usually returns:

• Issuer name and issuing country.
• Card brand, such as Visa, Mastercard or a domestic scheme.
• Funding type: credit, debit or prepaid.
• Product: consumer or commercial, and sometimes the card tier.

Visa’s guidance to merchants on eight-digit BINs lists the jobs merchants use BINs for: identifying prepaid cards, identifying issuers, fraud and chargeback analytics, routing, and optimising approval rates.

The length is changing. ISO expanded the issuing BIN from six to eight digits under ISO/IEC 7812-1, announced in 2017. Visa required its acquirers and processors to support eight-digit issuing BINs from April 2022 and lets issuers set their own migration timelines. Its merchant action sheet warns that as eight-digit BINs spread, it will no longer be possible to rely on the first six digits of the card number for authorization, routing and clearing. Any BIN rule you write should handle both lengths.

Why does the issuer matter so much for approval?

Because the issuer makes the decision, and issuers judge each request partly by who sends it. Stripe’s guide on authorization rates notes that banks are often more likely to approve domestic payments, which is why local acquiring can raise acceptance. A card issued in Mexico and sent by a Mexican acquirer looks like a domestic transaction to the issuer; the same card sent by a European acquirer looks cross-border, with the extra risk and fees that implies.

Issuers also differ from each other. One bank may approve card-not-present payments in a merchant’s category from a particular acquirer and decline them from another, because of its relationship with that acquirer or its risk models. These differences are invisible in a provider’s average approval rate and obvious once you split results by BIN.

How does BIN routing work?

At the moment of payment:

1. Look up the BIN of the card, from the first six or eight digits.
2. Filter providers by eligibility. Remove providers that cannot take this card at all: wrong country, unsupported brand, a funding type that is not allowed, or a customer the provider does not accept.
3. Apply the routing rules in order of specificity, from the narrowest (a single issuer) to the broadest (a whole region).
4. Send the payment to the first provider chosen, with the others forming the cascade order if it fails.
5. Log the decision: which rule matched, which providers were eligible, which was chosen.

Steps 2 and 3 should stay separate. Eligibility holds hard constraints, such as what is legal or contracted. Routing holds preferences, such as which eligible provider approves best.

What does a good BIN rule set look like?

Short, ordered and explainable. Here is an example for an online store taking card payments in Brazil, Mexico and Uzbekistan, with three providers: A acquires domestically in Brazil, B acquires domestically in Mexico, and C acquires cross-border. Provider names and rules are for illustration only.

Order	Condition (from BIN data)	Action	Why
1	Funding type prepaid, subscription sign-up	Decline for the subscription; offer another card or PIX	The merchant’s own policy for recurring billing
2	Issuing country Brazil, debit or prepaid	Route to A; fallback C	Domestic acquiring
3	Issuer X in Mexico (approves better at C)	Route to C; fallback B	Measured difference on enough volume
4	Issuing country Mexico	Route to B; fallback C	Domestic acquiring
5	Domestic scheme cards in Uzbekistan (Humo, Uzcard)	Route to the local processor only	Domestic schemes need local processing
6	Prepaid cards on first purchases	Route to the provider that accepts them, with lower limits	Provider appetite differs
7	Everything else	Route to C	Default

Rule 1 shows that BIN data is also a policy tool. The funding type in the BIN lookup tells the checkout whether a card is credit, debit or prepaid before the customer presses pay, so a merchant’s own rules, and a market’s rules where they exist, can be applied before anything is sent. Rule 5 reflects that Uzbekistan’s domestic schemes, Humo and Uzcard, are processed domestically in UZS.

Worked example: what does a country rule add?

Example figures, for illustration only.

A merchant sends 20,000 Mexican card payments a month, all through cross-border provider C, which approves 62% of them. A trial shows domestic provider B approving 78% of the same segment, and issuer X as an exception: 71% at C against 58% at B on 2,000 payments a month.

Setup	Calculation	Approved
Everything to C	20,000 × 62%	12,400
Everything to B	18,000 × 80% + 2,000 × 58%	15,560
Country rule to B, issuer X to C	18,000 × 80% + 2,000 × 71%	15,820

At B, the 18,000 payments from other issuers approve at 80%, which with issuer X’s 58% gives the 78% seen in the trial. The country rule alone adds 3,160 approvals a month over the starting point, and moving issuer X back to C adds another 260. The issuer rule is only worth having because it rests on 2,000 payments a month; on 50 it would be noise.

What are the common mistakes with BIN routing?

• Too many rules. A rule per issuer splits traffic into samples too small to measure, and the rule set becomes impossible to explain. Start with country and funding type; add issuers only with evidence.
• Stale BIN data. Banks merge, reissue ranges and move to eight-digit BINs. A stale table silently sends cards to the wrong route.
• Six-digit assumptions. Code that cuts the card number at six digits will misidentify a growing share of cards, as Visa’s guidance warns.
• No fallback. Every rule needs a second route, so one provider’s outage does not decline a whole country or issuer.
• Expecting routing to beat issuer blocks. If an issuer refuses a merchant category, it refuses it from every acquirer. The answer is another payment method, not another route.
• Ignoring decline codes. A BIN rule that moves an issuer to a new provider should be checked against the decline codes it produces, not only the approval rate. Stripe’s list of network codes shows how much the codes reveal, for example 62 for a card restricted in a region or country.

How do you keep BIN rules honest over time?

Review approval rates by issuing country, issuer and funding type every month, on payment intents rather than raw attempts. Keep a small share of each segment on the alternative provider so the comparison stays live. Annotate every rule change with a date and the evidence for it, and retire rules whose advantage has disappeared. Our guide on how to calculate approval rate explains how to segment the numbers.

How does Omno support BIN routing?

In Omno, card attributes are among the conditions routing and PSP eligibility rules can use, alongside country, method, currency, customer group and customer verification level, so cards can be routed to the provider with the strongest history for that issuer or issuing country. Card blocking stops cards that should not be processed at all. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. The routing-decision log records which providers were eligible and which was chosen for every payment. The smart routing and cascading page covers the settings.