BIN Attack: What It Is and How Merchants Stop It

A BIN attack is a card-not-present fraud technique in which criminals take a known bank identification number and use it as the starting point for guessing large batches of card numbers against an online checkout. The goal is to find a few live accounts that can be used or resold. For a merchant, a BIN attack shows up as a sudden wave of small, similar orders that mostly fail, and it can bring chargebacks, processor penalties, and higher fees.

What the term means

The first six to eight digits of a card number are the bank identification number, or BIN. Those digits identify the issuing bank and the card product, and they are not secret. Anyone who has handled a card, seen a receipt, or bought a BIN list knows the range.

What attackers do not have is the rest of the number. So they keep the known BIN and generate the remaining digits, then submit the results to a payment form. Each submission that comes back approved confirms a working account. The merchant's own checkout page becomes the testing tool.

BIN attack vs. card testing

Card testing is the broad category: any attempt to check whether stolen card data works. A BIN attack is a specific variant that starts from the BIN and guesses outward, which is why the same term appears in fraud literature alongside enumeration attacks.

Why these attacks work

• Automation. Bots can submit many attempts per minute, far faster than a human could type.
• Distribution. Attempts are spread across many IP addresses, devices, and email addresses, which keeps any single signal low.
• Small amounts. Attackers favor low-value orders or free trial signups because those rarely trip manual review thresholds.
• Normal-looking traffic. The requests arrive at a real checkout page, so they blend into legitimate order flow.
• Shared risk. One compromised merchant can validate numbers that are then used elsewhere.

Warning signs to monitor

• A spike in declined authorizations while order volume stays flat
• Many attempts sharing one BIN, or card numbers that look sequential
• Several orders from the same device or IP with different card data
• Heavy volumes of low-price orders, especially for digital goods
• Address verification and security code mismatch rates above your normal baseline
• A rising authorization-to-chargeback ratio

How detection works

Fraud teams combine three layers. Rule-based checks catch known patterns, such as more than a set number of attempts from one IP in an hour. Velocity checks watch how often a card, email, device, or shipping address appears. Machine learning models score each order against the wider pattern of traffic, including signals the merchant cannot see alone.

Issuers and card networks see the same behavior across many merchants at once, which is why they often flag a BIN range before any single merchant notices.

Prevention checklist for merchants

• Turn on 3-D Secure or another step-up authentication method at checkout
• Add bot detection and a challenge on payment, signup, and password reset forms
• Rate limit attempts per IP address, device fingerprint, and BIN
• Set velocity rules on cards, emails, phone numbers, and shipping addresses
• Require the security code and decline high-risk orders when it fails
• Use network tokens so real card numbers never sit in your systems
• Alert on authorization decline rate changes, not just on completed orders
• Report confirmed attacks to your processor and acquiring bank so the BIN range can be watched

What happens on the issuing side

When an issuer confirms that a BIN range is under attack, it can decline transactions in that range, tighten its own rules, and reissue affected cards. Networks publish alerts and rules that shift liability when merchants skip authentication. That combination is why a quick response matters: the faster a merchant blocks the pattern, the fewer bad authorizations and chargebacks it absorbs.

Key takeaways

A BIN attack exploits public information, the BIN, plus guessed digits. Defense depends on making guessing expensive through authentication, rate limits, and monitoring that looks at failed attempts as closely as successful ones.