BIN Attack

A BIN attack is a brute-force payment fraud technique in which fraudsters take a known bank identification number – the first six or eight digits of a payment card – generate candidate card numbers from it, and submit them as small authorization attempts to learn which numbers, expiry dates and security codes belong to live accounts.

The attack needs no data breach. The card numbers are derived from the issuer's numbering range rather than stolen, so cardholders are often affected without having exposed their card anywhere. The business whose checkout or card form is used for testing absorbs much of the cost: authorization fees, a surge in declines and closer attention from its acquirer.

How a BIN attack works

The BIN, formally the issuer identification number (IIN), tells anyone who reads it which institution issued the card and often which card product it belongs to. Since its 2017 revision, ISO/IEC 7812-1 defines the IIN as eight digits rather than six.

The remaining digits follow a known structure and end in a check digit, so software can produce long lists of numbers that are structurally valid. Whether an account actually stands behind a number can only be confirmed through an authorization. Fraudsters route the generated numbers through any form that triggers one – an online checkout, a donation page, a free trial, a card-linking step – usually with scripts or bots, often as low-value or zero-amount requests, and rotate expiry dates and CVV values between attempts. Decline responses can reveal which field failed, which narrows the next round. Details that pass are used for fraudulent card-not-present purchases or sold on.

BIN attack, card testing and card cracking

The three terms overlap and are often used interchangeably. In one common usage, card testing checks whether card details obtained elsewhere still work, card cracking brute-forces the missing fields of a partly known card, and a BIN attack generates the card numbers themselves from an issuer range. Issuers, acquirers and vendors draw these lines differently.

How card networks and issuers track BIN attacks

Card networks treat enumeration as a separate risk. Visa's Acquirer Monitoring Program tracks it monthly alongside fraud and disputes. Under the thresholds in Visa's 2025 program fact sheet, a merchant exceeds the enumeration threshold when, in a given month, enumerated authorizations reach 20% of all authorization attempts and number at least 300,000. Issuers see the other side of the same activity: a burst of attempts against one BIN range, spread across many merchants.

How BIN attacks are detected

Per-card controls see little, because each generated number appears once or twice and then disappears. Detection relies on aggregates. Signals commonly used include:

• spikes in authorization attempts within a single BIN range

• sequential or near-sequential card numbers

• an unusual share of declines for invalid card number or CVV mismatch

• clusters of identical low amounts

BIN attacks typically run on automation, which leaves traces outside the payment data. Many cards submitted from one device, session or IP range, scripted timing between attempts, headless browsers, emulators, virtual machines and device configurations that change from one attempt to the next all point to tooling rather than customers. Velocity checks keyed to the device and session, and not only to the card, are one common way to surface this distribution.

Common responses

Typical responses include:

1. Rate-limiting authorization and card-linking endpoints.

2. Adding a challenge when automation is suspected (see bot mitigation).

3. Applying 3-D Secure where the market and product allow it.

4. Enforcing CVV and address verification where available.

5. Notifying the acquirer or issuer.

Temporarily blocking a BIN range stops an attack quickly but also turns away legitimate customers of that issuer, so the cost in false declines has to be weighed against attack volume.