BIN attack
What is a BIN attack?
BIN attack is a fraudulent scheme in which a scammer selects a BIN () and systematically tests random combinations to guess a valid 16-digit credit card number, along with its associated expiration date and CVV.
The first six digits of the card number are the BIN, and they identify the . Not all cards from one bank share the same BIN – larger banks hold several BIN ranges – but every card carrying a given BIN comes from that one issuer. That predictability is the whole point of the attack: the BIN is already known and published, so the attacker only has to brute-force what's left.
Key facts
- Also known as: BIN scamming, card number enumeration, brute-force card attack
- What's guessed: the digits after the BIN, plus the expiration date and the (CVV)
- Method: automated scripts firing high volumes of low-value attempts at a live checkout
- Not the same as card testing: a BIN attack generates and validates candidate card numbers; card testing typically follows a successful BIN attack and checks whether a working number can carry larger purchases
- Who's exposed: the merchant whose checkout accepts the attempts, the issuer behind the targeted BIN, and whose numbers happen to be hit
How it works
- Select a BIN. The attacker picks a live BIN belonging to a specific issuing bank. BIN lists are published and freely available, so this step costs nothing.
- Generate candidate numbers. Scripts cycle through the digits following the BIN. A Luhn checksum filters out sequences that can't be valid card numbers, which cuts the guess space before a single request is sent.
- Pair each number with an expiry and CVV. Expiration dates sit inside a narrow forward window, and the security code is three digits on most cards (four on American Express), so both are cheap to enumerate.
- Submit the guesses to a merchant's checkout. The attempts go to an online store rather than the bank, usually as small purchases or zero-value authorization requests. The approve-or-decline response tells the attacker which combination is real.
- Keep the approvals. Combinations that return an approval are recorded and sold, or moved into card testing, where they're run against progressively larger amounts before being used outright.
Why it matters
- Chargebacks: every approved guess becomes an unauthorized purchase the cardholder disputes. Each returns the transaction amount and adds a dispute fee on top.
- Strained relations with banks: merchants identified as "soft targets" for testing fraudulent cards face strained relationships with banks, which affects future collaboration and pricing.
- Reputational damage: cardholders who spot the shop's name on their bank statement associate that name with , regardless of whether the merchant was the victim.
- Falling approval rates: thousands of declines in a short window pull down the authorization rate that and processors monitor. A sustained drop can push an account into monitoring.
- Processing costs: every attempt is a billable authorization request. A merchant pays gateway and scheme fees on traffic that was never going to convert.
Common issues
Each individual attempt looks unremarkable: one card, one small amount, one checkout submission. The attack is only visible in aggregate, which is why single-transaction rules miss it. The signals that separate it from real traffic are volume and repetition – dozens or hundreds of attempts sharing the same BIN, near-sequential card numbers, one or IP range behind all of them, and the whole burst compressed into minutes. models that read these aggregate patterns flag the burst that a per-transaction check clears.
Guest checkout is the usual entry point, because it accepts a card without an account, a stored payment method, or any prior order history. Checkouts without a CAPTCHA, without velocity limits per BIN and per device, and without on unrecognised traffic give the script an unlimited number of free guesses. An check adds a second field the attacker has to guess, since a generated card number carries no billing address with it.
Detection often arrives late. Many merchants notice a BIN attack only after their volume spikes, after an issuer sends a , or after the first disputes land weeks later. By that point the harvested numbers have already been used elsewhere, and the merchant is dealing with the chargebacks rather than the attack.
