Skip to main content
Commerce Security Authority
Category: Fraud Typologies

BIN Attack

Also known as: BIN scamming, Brute-force BIN attack, Bank Identification Number attack
Simply put

A BIN attack is a type of payment card fraud in which criminals use automated, trial-and-error methods to guess valid card details, such as the full card number, expiration date, and security code. They start from a known Bank Identification Number (the leading digits that identify a card issuer) and systematically test many possible combinations until some are accepted. The goal is to discover working card credentials that can then be used for unauthorized transactions.

Formal definition

A BIN attack is a brute-force fraud technique in which an attacker fixes a known Bank Identification Number (BIN) prefix and programmatically enumerates the remaining card fields, including the primary account number (PAN), expiration date, and card verification value (CVV/CVC2/CVV2), to identify valid combinations at scale. Because the issuer-identifying digits are known, the attacker constrains the search space and iterates candidate values, often testing them against merchant or payment endpoints to determine which are live. Note that per the evidence, some descriptions also reference PINs; PIN blocks are protected under PCI PIN and related requirements and are handled separately from the CVV and PAN elements typically enumerated in these attacks. Effective figures for success rates and volumes depend on source, period, and methodology and are not established here; controls such as velocity limits, rate limiting, and authentication checks may help reduce but do not guarantee prevention of such attacks.

Why it matters

BIN attacks target a structural feature of the payment card system: the Bank Identification Number, the leading digits that identify a card issuer, is publicly known and shared across many cards from the same issuer. Because attackers can fix a valid BIN and then enumerate the remaining fields, the search space is meaningfully constrained, allowing automated tools to test large volumes of candidate card details against merchant and payment endpoints. This means that even without stealing card data directly, criminals can attempt to discover working credentials through sheer trial and error.

For merchants, processors, and issuers, BIN attacks create both direct and indirect harm. Beyond the risk of fraudulent transactions on any successfully guessed credentials, the testing activity itself can generate high volumes of authorization requests, declines, and small-value or verification transactions that burden systems and can trigger card brand monitoring thresholds. The consequences of successful attacks and the operational costs of the testing traffic depend heavily on the specific environment, controls in place, and card brand and network rules, which vary by region and change over time.

Exact figures for how often BIN attacks succeed, the volumes involved, or associated losses depend on source, period, and methodology and are not established here. What is clear qualitatively is that no single control eliminates the threat: measures such as velocity limits, rate limiting, and authentication checks may help reduce the effectiveness of these attacks but do not guarantee prevention, and they involve trade-offs between blocking malicious traffic and disrupting legitimate customers.

Who it's relevant to

Merchants and e-commerce operators
Merchant payment endpoints are common targets for the automated testing traffic that characterizes BIN attacks. Merchants should understand that controls such as velocity limits, rate limiting, and authentication checks may help reduce this activity but do not guarantee prevention, and that each control involves trade-offs against legitimate customer experience.
Payment processors and acquirers
Processors and acquirers may see elevated volumes of authorization attempts and declines generated by enumeration against their merchants. They are positioned to apply monitoring and controls across many endpoints, but must weigh detection sensitivity against false positives and account for card brand and network rules, which vary by region and change over time.
Issuers and issuing banks
Because a BIN identifies a specific issuer, cards under an attacked BIN belong to that institution's cardholders. Issuers have a role in monitoring for testing patterns against their card ranges and in the authorization decisions that determine which candidate credentials are accepted as live.
Fraud analysts and merchant risk teams
These teams design and tune the velocity, rate-limiting, and authentication controls intended to reduce BIN attack effectiveness. They must manage the inherent trade-off between catching malicious enumeration and disrupting legitimate transactions, recognizing that both false positives and false negatives are possible.
Compliance officers
While BIN attacks are primarily a fraud concern, the data elements involved span cardholder data such as PAN and expiration date and sensitive authentication data such as the CVV, and where PINs are referenced, PIN blocks fall under PCI PIN and related requirements handled separately. Compliance teams should confirm the applicable controls against the current published standards rather than assuming a fixed requirement number.

Inside BIN Attack

BIN/IIN enumeration
The starting point of the attack, where an attacker takes a known Bank Identification Number (also called Issuer Identification Number), the leading digits of a PAN that identify the issuing institution and card product, and systematically generates candidate account numbers within that range.
PAN generation and validation
Attackers combine the fixed BIN with generated account digits and typically apply the Luhn check digit algorithm to produce structurally valid candidate PANs, reducing the number of clearly invalid guesses before submitting them.
Guessing of expiration date and CVV2/CVC2/CID
Because the expiration date has a limited range of valid values and the card verification value is a short numeric field, attackers may brute-force these elements. The CVV2/CVC2/CID is sensitive authentication data and must not be stored after authorization; a BIN attack instead attempts to discover valid values through repeated authorization attempts.
High-volume authorization or verification requests
The attack relies on submitting large numbers of authorization or account-verification (for example, zero-value or low-value) requests, often against card-not-present acceptance points such as e-commerce checkout or stored-credential flows, to identify which generated combinations are approved.
Detection signals
Indicators can include a spike in declines, an unusually high proportion of transactions sharing the same BIN, elevated velocity from single sources or distributed across many IPs, and abnormal ratios of verification attempts to successful approvals. These signals carry false-positive and false-negative trade-offs and should be tuned rather than treated as definitive.
Downstream fraud outcome
Successfully validated card combinations may be used or sold for subsequent card-not-present fraud. The attack itself is a discovery technique; the resulting unauthorized use is governed by card brand and network rules that determine chargeback and liability treatment, which vary by region and change over time.

Common questions

Answers to the questions practitioners most commonly ask about BIN Attack.

Is a BIN attack the same as a data breach where card numbers are stolen?
No. A BIN attack does not rely on stolen cardholder data. Instead, an attacker takes a known Bank Identification Number (or IIN) prefix and systematically generates or guesses the remaining PAN digits, then tests candidate card numbers—often paired with guessed expiration dates and CVV2/CVC2/CID values—against payment systems to find combinations that authorize. Because the attacker is generating candidate values rather than exfiltrating them from a compromised store of data, a BIN attack is a validation and enumeration technique, not a breach of stored cardholder data. The two can be related if generated values are later used for fraud, but they are distinct events with different detection and response implications.
Does tokenizing or encrypting stored card data stop a BIN attack?
Not directly. Tokenization, encryption, truncation, and masking address the protection of data you store or transmit; they help reduce the impact of a compromise of your own environment. A BIN attack, by contrast, targets your authorization flow with externally generated candidate values, so protecting stored data does not prevent an attacker from submitting guessed PANs to your payment endpoints. Mitigating BIN attacks is primarily about controlling and monitoring authorization and validation traffic—for example, rate limiting, velocity checks, and challenge mechanisms—rather than about how data is stored. These controls may reduce exposure but should not be described as guaranteeing prevention.
What signals can help detect a BIN attack in authorization traffic?
Detection typically relies on patterns rather than any single indicator. Common signals include a spike in authorization attempts sharing the same BIN or a narrow range of BINs, a high proportion of declines (especially declines tied to invalid card number, expired card, or incorrect CVV2/CVC2/CID responses), many low-value or zero-value authorization or account-verification requests, sequential or clustered PAN values, and traffic concentrated from particular IP ranges, devices, or short time windows. These heuristics can produce false positives during legitimate high-volume periods, so they are generally tuned and combined rather than used in isolation.
Which controls can help slow or limit BIN attacks at the payment endpoint?
Controls that are commonly applied include velocity and rate limiting per BIN, IP, device, and session; CAPTCHA or other bot-mitigation challenges on public payment or verification forms; blocking or throttling after repeated declines; monitoring and alerting on decline-rate and attempt-rate anomalies; and coordination with your acquirer or processor, which may offer network-level or card-brand-provided screening. Because each control has trade-offs between blocking attackers and disrupting legitimate customers, they are intended to reduce risk and slow enumeration rather than to eliminate it entirely.
How should low-value or zero-value authorizations be handled given their role in BIN attacks?
Because account-verification, zero-value, and small-amount authorizations are frequently used to test whether a generated card number and its associated data authorize, teams often apply additional scrutiny to these request types—such as tighter velocity thresholds, correlation of verification requests to subsequent purchase attempts, and monitoring for high volumes of verification traffic that do not convert to genuine transactions. Handling should be coordinated with your acquirer or processor and aligned to applicable card brand and network rules, which vary by region and change over time; confirm current requirements rather than assuming fixed thresholds.
Who should be involved when responding to a suspected BIN attack, and what is out of scope for the merchant?
Response typically involves internal fraud, security, and engineering teams alongside your acquirer or payment processor, and may require notifying card brands per their rules. The merchant generally controls its own authorization endpoints, rate limiting, and monitoring, while network-level detection, issuer-side authorization decisions, and card brand rule enforcement are outside the merchant's direct control. Chargeback and liability outcomes for any fraudulent transactions that result are governed by card brand and network rules, which vary by region and change over time, so those determinations should be confirmed against current published rules rather than assumed.

Common misconceptions

A BIN attack means the issuer or a merchant database was breached to obtain the card numbers.
A BIN attack does not require stolen data. It generates candidate PANs from a publicly identifiable BIN range and tests them through authorization or verification requests, so it is a guessing or enumeration technique rather than the result of data exfiltration.
Requiring the CVV2/CVC2/CID at checkout prevents BIN attacks.
Requiring a card verification value raises the effort but does not by itself stop the attack, because attackers can also attempt to brute-force that short numeric field. It is one control among several and helps reduce success rates rather than guaranteeing prevention; it must be paired with velocity limits and other detection.
Passing a Luhn check confirms a real, active account.
The Luhn algorithm only validates the structural check digit of a PAN. It filters out obviously malformed numbers but does not indicate that an account exists, is open, or is funded; only an authorization or verification response can suggest that, which is precisely why attackers submit high volumes of requests.

Best practices

Implement velocity and rate limiting on authorization and account-verification requests, scoped by source IP, device, session, and BIN, and tune thresholds to balance false positives against missed enumeration activity.
Monitor for concentration patterns such as a surge of attempts sharing a single BIN, abnormal decline ratios, and sequential or Luhn-valid PAN patterns, treating these as investigative signals rather than conclusive proof.
Add friction to card-not-present flows for suspected automated traffic, for example bot mitigation, CAPTCHA or challenge steps, and device fingerprinting, recognizing these reduce but do not eliminate automated enumeration.
Apply layered authentication such as 3-D Secure where appropriate, understanding it addresses cardholder authentication at a specific transaction point and does not by itself stop enumeration of the underlying card data.
Coordinate with your acquirer, processor, and card brands on network-level detection and applicable rules, since chargeback and liability treatment for resulting fraud are governed by card brand and network rules that vary by region and change over time.
Ensure that sensitive authentication data, including the CVV2/CVC2/CID, is never stored after authorization even when encrypted, and validate cardholder data handling against the current published PCI DSS standard rather than assuming a fixed requirement number.