A BIN attack is a fraudster taking the first six to eight digits of a card, the bank identification number, and running through the remaining digits in sequence to find live cards. The attack shows up as a flood of small authorizations, most of them declined, and it costs you money even when every single one fails.
The numbers that give it away
A BIN attack starts with the first six to eight digits of a card, the bank identification number, which identifies the issuing bank and the card type. The fraudster knows the BIN and generates the remaining digits in sequence, testing each one to find which cards are live. The Luhn checksum, a simple algorithm that checks whether a card number is valid, does not stop this, because the fraudster can generate numbers that pass the check.
The attack shows up as a flood of authorization attempts, most of them declined. A normal merchant sees a decline rate of 5 to 15 percent. During a card testing attack, the decline rate jumps to 60 to 90 percent, because most of the generated numbers are not live cards. The spike in the decline rate is the clearest sign of an attack, and it is visible in the payment dashboard before any chargeback arrives.
The scale is large. Visa has attributed about $1.1 billion in ecosystem losses to card enumeration in a single year. The Merchant Risk Council's 2025 survey found that 33 percent of merchants reported card testing. The attacks are not rare. They are a routine cost of running a checkout.
Why the attack costs you even when it fails
A BIN attack costs the merchant money even when every attempt is declined, because the processor charges an authorization fee for every attempt, successful or not. Ten thousand authorization attempts in a weekend can cost $500 to $2,500 in fees alone. The fraudster pays nothing for the attempts. The merchant pays for all of them.
The attack also costs the merchant in a second way. When the fraudster finds a live card, the next step is to use it, usually for a high-value purchase or a cash-out. The chargeback that follows is the merchant's loss, and the cardholder's bank may also flag the merchant as a source of fraud, which raises the merchant's risk score and can lead to higher fees or a reserve hold.
The third cost is operational. A flood of authorization attempts can slow the checkout for real customers, trigger rate limits from the payment processor, and fill the fraud review queue with false positives. The attack does not have to succeed to disrupt the business.
The defenses that work
Velocity limits are the first defense. Limit authorization attempts to 3 to 5 per IP address per hour, and block an IP that makes more than 10 attempts in 5 minutes. The limits have to be tight enough to stop the attack and loose enough to let real customers retry a failed card. A customer who mistypes a card number and tries again is not an attacker. A customer who tries 50 numbers in a minute is.
CVV and AVS checks are the second defense. A BIN attack generates card numbers, but it does not generate the CVV or the billing address that goes with them. Requiring CVV and AVS on every authorization, and declining transactions that fail them, stops most generated numbers from ever reaching the authorization stage.
The third defense is friction after failure. Require a CAPTCHA or a 3DS challenge after a few failed attempts, and the attack slows to a crawl, because the fraudster has to solve a challenge for every attempt. The challenge does not have to be hard. It has to be slower than the attacker's automation.
What to watch for
Watch the decline rate daily, not weekly. A decline rate that jumps from 10 percent to 60 percent overnight is an attack in progress, and the response has to be same-day. Watch the authorization volume by IP address, and watch for a single IP or a small range of IPs generating most of the attempts.
Watch for the pattern across days. A BIN attack that fails on Monday will come back on Tuesday with a different BIN, or a different IP range, or a different time of day. The fraudster is testing your defenses, and the second attack will be adjusted to get past whatever stopped the first one.
When an attack is confirmed, block the IPs, tighten the velocity limits, and report the BINs to your processor. The processor can share the intelligence with other merchants, and the BINs that were attacked are the BINs that will be attacked again.
Keep reading
Related guides on this site: how card testing starts with small charges at checkout when 3DS2 challenges a payment and when it exempts it how chargeback alerts from Ethoca and Verifi work More from Bot Defense For Insurance.
Frequently asked questions
What is a BIN?
The bank identification number, the first six to eight digits of a card number, which identify the issuing bank and the card type. A fraudster who knows the BIN can generate the remaining digits in sequence and test which ones are live cards.
What is the Luhn checksum?
The Luhn checksum, a simple algorithm that checks whether a card number is valid. A fraudster can generate numbers that pass the Luhn check, so the checksum does not stop an attack. It only stops random numbers from being submitted.
How much does card enumeration cost?
Visa has attributed about $1.1 billion in ecosystem losses to card enumeration in a single year. The losses are spread across merchants, issuers, and processors, but the merchants pay the authorization fees and the chargebacks.
What decline rate signals an attack?
A normal merchant sees a decline rate of 5 to 15 percent. During a card testing attack, the decline rate jumps to 60 to 90 percent, because most of the generated numbers are not live cards. A sudden spike in the decline rate is the clearest sign of an attack.
How do I stop a BIN attack?
Limit authorization attempts to 3 to 5 per IP address per hour, and block an IP that makes more than 10 attempts in 5 minutes. Add CVV and AVS checks, and require a CAPTCHA or 3DS challenge after a few failed attempts.
Do I pay authorization fees on declined attempts?
Yes. Ten thousand authorization attempts in a weekend can cost $500 to $2,500 in authorization fees alone, because the processor charges for every attempt, successful or not. The fees are the merchant's cost even when the attack finds no live cards.