A BIN attack is when fraudsters take a known card-number prefix, the BIN that identifies the issuing bank, and mass-generate full card numbers, guessing the expiry and security code. They fire the guesses at weak checkout or verification pages to find combinations that work, so one leaked BIN can spawn thousands of live cards.
What is a BIN attack, in plain English?
Every card number starts with a BIN (Bank Identification Number), the first six to eight digits that identify the issuing bank and card program. The BIN is not secret; it is shared across every card in that program. A BIN attack exploits that by taking a known BIN and algorithmically generating the remaining digits, then guessing the expiry date and the security code to assemble complete, plausible card numbers.
The generated numbers are guesses, so most are dead. The attack works by testing them at scale against a soft target: a checkout page, an account-verification endpoint, or a donation form that will happily tell the fraudster, through an approval or a specific decline, which combinations are real. Because card numbers within a BIN are structured and the checksum is predictable, the search space is smaller than it looks.
A BIN attack sits right next to enumeration and card testing. Enumeration is the guessing of valid numbers; card testing is the confirming of them with small charges. A BIN attack is often the front end of that pipeline: it manufactures candidate cards that then get tested and, if live, sold or cashed out elsewhere.
How a BIN attack runs
- Seed — Pick a known BIN. The fraudster starts from a leaked or observed BIN for a specific bank and card program.
- Generate — Mass-produce numbers. Software fills in the remaining digits and guesses expiry and security codes, creating many candidate cards.
- Fire — Hammer a weak endpoint. Automated requests hit a checkout or verification page with little rate limiting or bot defense.
- Harvest — Keep the winners. Approvals and telling declines reveal which cards are live; those get tested further, sold, or used.
Who is involved?
Who | Their role |
The attacker | Runs the generation and testing scripts, usually automated across many IPs and devices. |
The targeted merchant | Provides the endpoint being hammered. Absorbs processing fees, declines, and reputational cost. |
The issuing bank | Owns the attacked BIN and its cardholders, who face declines, reissues, and potential fraud. |
Downstream buyers | Purchase or receive the confirmed live cards for the real fraud at higher-value targets. |
What it looks like in practice
In practice
A small nonprofit runs a simple online donation form with no CAPTCHA and no rate limiting. Overnight, its payment logs explode: tens of thousands of one-dollar donation attempts, almost all declining, the card numbers marching in near-sequence and nearly all sharing the same first eight digits.
This is a BIN attack using the donation form as a free oracle. The handful of attempts that approve are the live cards the fraudster was hunting for. The nonprofit wakes up to a spike in gateway fees, a decline rate that triggers its processor's monitoring, and a cleanup job. The confirmed cards, meanwhile, are already being tested at a retailer for the real loss.
Why it matters to operators
A BIN attack rarely causes the big loss at the site being attacked; the damage is spread. The attacked merchant eats processing fees, a wrecked approval rate, and processor scrutiny for hosting the testing. The issuer faces mass reissues and cardholder friction. And the confirmed cards move on to become someone else's chargeback. Treating a decline spike as merely a technical nuisance misses that you are the launchpad for downstream fraud.
The good news is that BIN attacks have a loud signature and respond well to friction on the payment path. Velocity limits per BIN and per IP, CAPTCHA or device checks on payment and verification forms, and rate limiting turn a cheap automated attack into an expensive one. The goal is to make your endpoint a poor oracle, so the attacker cannot cheaply learn which cards are live.
What to watch in the data
- Decline bursts on one BIN. A sudden spike of declines concentrated on one or a few card-number prefixes is the core tell.
- Sequential numbers. Card numbers arriving in near-order rather than the random spread of real customers.
- Few devices or IPs. Very high attempt volume from a small set of devices, IP ranges, or automation signatures.
- Uniform tiny amounts. Repeated small or zero-dollar attempts, typical of probing rather than genuine buying.
- Off-hours automation. Machine-paced traffic overnight or at inhuman speed hitting checkout or verification endpoints.
Quick questions
How is a BIN attack different from card testing?
A BIN attack generates candidate card numbers from a known prefix by guessing. Card testing confirms whether specific numbers are live with small charges. In practice they chain together: the attack manufactures candidates, testing verifies them.
Where do attackers get the BIN?
BINs are not secret. They appear in breached data, in published BIN lists, and simply from observing real cards. Once a fraudster has a BIN tied to a specific bank program, they can generate structurally valid numbers around it.
Does a BIN attack cost the attacked merchant money?
Yes, even without a chargeback. You pay gateway and authorization fees on every attempt, your approval rate drops, and a high decline ratio can push you into your processor's monitoring programs. You are also enabling downstream fraud.
What stops a BIN attack fastest?
Friction and rate control: velocity limits per BIN and IP, CAPTCHA or device fingerprinting on payment and verification forms, and blocking obvious automation. The aim is to make your endpoint too slow and costly to use as a testing oracle.
Why do fraudsters guess the security code too?
Because a full working card needs the number, expiry, and security code. There are limited combinations for the code and expiry, so at scale a small fraction of guesses land, which is enough when you are firing thousands of attempts.
Go deeper
- EMVCo ↗ — Maintains the EMV chip and 3-D Secure specifications for card payments.
- PCI Security Standards Council ↗ — Security standards for handling cardholder data, including PCI DSS.