Open any deposit failure report and sort the declines by reason. After expired cards and insufficient funds, the largest group is usually something vaguer: do not honour, restricted card, transaction not permitted. A good share of those are geography. The card was issued in one country, the client is sitting in another, and somewhere between the checkout page and the issuer a rule decided that combination looked wrong.
This costs real money, because a declined deposit is not a deferred deposit. Most people try once, maybe twice, and then go somewhere else. Understanding what the systems are comparing is the difference between fixing the problem and adding another rule on top of it.
What the leading digits actually say
The first six to eight digits of a card number are the issuer identification range, still called the BIN by everyone in payments. Looked up against a BIN table, they return the issuing institution, the country of issuance, the scheme, the product type such as debit, credit or prepaid, and whether the card is consumer or commercial.
What they do not return is a person. The BIN says where the card was issued, which was true on the day it was printed and may have nothing to do with where the cardholder lives now. That single distinction is the source of most of the trouble, because risk rules written by people who have never moved country tend to assume the two are the same.
Why a mismatch trips a rule
Three parties can decline, and they decline for different reasons.
| Who declines | What it compared | What you see |
|---|---|---|
| Issuer risk engine | Merchant country and category against the cardholder's normal pattern | A generic decline code, no detail |
| Processor or acquirer rules | BIN country against IP country, billing address, or its own restricted list | A rejection before the transaction reaches the scheme |
| Your own fraud logic | BIN country against the country on the verified identity document | A block you configured and probably forgot about |
Only the first one is outside your control. The other two are policy choices that were probably made once, during launch, by someone copying a template. They are worth re-reading every quarter against the actual decline data, which is the same exercise described in payment approval rates.
Cross-border transactions also cost more. When the acquirer's country and the issuer's country differ, the interchange category changes and the economics of the transaction change with it. That is a pricing question rather than an approval question, and it is covered in interchange fees, but it explains why some processors quietly discourage the traffic.
The legitimate mismatches you are declining
Four populations produce mismatches constantly and none of them are fraud.
Expatriates and migrant workers keep a card from home while living somewhere else. A Filipino engineer in Qatar, a Romanian nurse in Italy, a British retiree in Spain. Second, digital bank customers: several large European neobanks issue every card from a single licence, so a customer in six different countries produces a BIN pointing at one of them. Third, travellers, who look like a country change for two weeks a year. Fourth, holders of virtual and prepaid cards issued by fintech programmes whose BIN country reflects the programme manager rather than the user.
The one mismatch that genuinely matters is a card that does not belong to the account holder. Third party funding is an anti-money-laundering problem regardless of geography, and the control for it is name matching between the card and the verified identity, not a country rule. Blocking by country catches almost none of it and blocks thousands of real clients.
Routing instead of blocking
The productive response is to treat the BIN as routing information. Perform the lookup at checkout, before authorisation, and use it to pick the acquirer with the best local footprint for that issuer country. Domestic-looking traffic approves better than cross-border traffic, and running more than one acquiring relationship is the only way to have that option, which is one of the arguments for payment orchestration beyond redundancy.
The lookup also tells you what not to attempt. If the BIN returns a prepaid product and your policy excludes prepaid, say so on the page before the client types sixteen digits rather than after. A clear message at input time converts far better than a failed authorisation followed by a generic error.
Where the mismatch persists, raise the evidence bar instead of dropping the client. Force strong authentication for that transaction. Ask for a card image showing the last four digits and the embossed name. Compare that name against the identity record you already hold from onboarding, which is exactly what identity verification exists to produce. A client who clears that check is a better client than average, not a worse one.
Where payments and compliance argue
Payments teams want approvals. Compliance teams want to know that the money came from the person who was verified. The fight usually happens over exactly these transactions, and it is resolvable if both sides agree on what the rule is protecting against.
A country mismatch by itself is a weak fraud signal and an even weaker AML signal. It becomes meaningful in combination: a mismatch plus a card name that differs from the account name, plus a first deposit at the maximum limit, plus an immediate withdrawal request to a different rail. That is a pattern worth stopping. A Lithuanian BIN on its own is a Tuesday. The same discrimination-by-geography problem shows up on bank transfers, where IBAN discrimination is the equivalent bad habit.
Write the policy as a scoring rule with named combinations, review the declines monthly, and count how many verified clients each rule rejected. If a rule blocked four hundred deposits and caught two genuine problems, it is not a control. It is a leak with a compliance justification attached.
"Half the country blocks I see were written in week one by someone copying a template. Nobody has looked at what they cost since. Pull the decline report, count the good clients you turned away, and the argument settles itself."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- The BIN identifies the issuing institution and its country, which is where the card was created and not where the cardholder lives today.
- Declines come from the issuer, the acquirer and your own rules, and only the first is outside your control.
- Expatriates, neobank customers, travellers and virtual card holders generate constant mismatches that have nothing to do with fraud.
- Use the BIN lookup to route to a better acquirer and to raise the evidence bar, and reserve blocks for combinations of signals rather than geography alone.
Frequently Asked Questions
What does the BIN on a card tell you?
The leading digits of the card number identify the issuing institution and, through a BIN table, the country where that institution issued the card, the scheme, the product type such as debit, credit or prepaid, and whether the card is consumer or commercial. It identifies the issuer, not the person, so it says where the card was issued and nothing about where the cardholder lives today.
Why do cross border cards get declined more often?
Two separate systems can reject them. The issuer's own risk engine sees a merchant in a country it does not associate with the cardholder and may decline for that reason alone. Separately, the merchant or processor may run a rule comparing the BIN country against the billing address, the IP country or the verified identity country, and block on any difference. The decline reason code tells you which one fired.
Should a mismatch between BIN country and account country be blocked?
Not automatically. Expatriates, students, migrant workers and holders of cards from digital banks issued in a single European country all produce legitimate mismatches. A better approach is to treat the mismatch as a signal that raises the evidence bar: request strong authentication, verify the card belongs to the account holder, and decline only when the mismatch sits alongside other risk indicators.