BIN Attack

What Is a BIN Attack?

A BIN attack is card fraud that starts from the bank identification number (BIN), the first six or eight digits of a payment card. The BIN shows which bank issued the card, and it is the same for every card in that range. Attackers keep it fixed and let software guess the rest of the card details until an issuer approves one.

Visa calls this an enumeration attack. Its guidance to banks and merchants describes fraudsters who “systematically submit card-not-present (CNP) authorization attempts, while concentrating on a single Bank Identification Number (BIN) or multiple BINs.” The OWASP Automated Threats project files the guessing step as OAT-010 Card Cracking. Its other names there include PAN enumeration and distributed guessing attack.

The attack does not need a breach at the bank, because the card numbers are generated, not stolen. Europol’s 2025 Internet Organised Crime Threat Assessment puts it plainly: criminals “exploit the publicly available Bank Identification Numbers (BINs) on payment cards to generate valid card numbers for fraudulent use.”

What Does a Card Number Reveal to an Attacker?

A card number, or primary account number (PAN), follows a fixed layout. The BIN is public and the last digit can be computed, so only the account digits have to be guessed. The table uses the placeholder 4BBB BBBB AAAA AAAC instead of a real card.

The layout above follows Capital One’s explainer on bank identification numbers and the definitions in the UK Financial Conduct Authority notice used later on this page. The card number alone rarely completes an online payment. Checkouts also ask for the expiry date, the three-digit security code (CVV2 or CVC) and sometimes a postal code. Visa lists the card number and these three fields as the values an enumeration attack works through.

How Does a BIN Attack Work?

The steps below follow Visa’s description of enumeration and OWASP’s card cracking entry. The guessing runs on scripts or bots, so one attacker can send a very large number of attempts.

1. Pick a BIN. The attacker chooses an issuer’s prefix. It is printed on cards, and one card advertisement in our records let buyers choose the prefix.
2. Generate card numbers. A script fills in the account digits and calculates a valid check digit for each candidate.
3. Guess the other fields. Newcastle University researchers noted in 2016 that cards are typically valid for 60 months, so the expiry date takes at most 60 guesses. The three-digit security code takes fewer than 1,000.
4. Submit the guesses. Each guess goes out as a card-not-present authorization at an online merchant. Issuers decline wrong combinations until one returns an approval.
5. Keep what works. An approval tells the attacker the card is real and active. Stripe notes that testers then use the confirmed cards with merchants or resell them on the dark web.

The Newcastle team also showed why spreading guesses works. Online stores asked for different combinations of card fields, and each site typically allowed 10 or 20 attempts. By sending guesses to many sites at once, their attack built up the card details one field at a time, in as little as six seconds.

In 2021 Visa reported enumeration moving to authentication. Its guidance reports attackers sending “a high volume of authentication attempts to identify valid payment account details for specific issuing BINs.” It tells issuers to treat bursts of one-time password requests that are never completed as a warning sign.

How Is a BIN Attack Different From Card Testing and Carding?

The terms overlap, and payment firms use them loosely: a carding attack, card testing fraud and a BIN attack often describe the same burst of checkout attempts. Stripe, for example, lists “carding”, “account testing”, “enumeration” and “card checking” as other names for card testing. The split below follows Visa and OWASP, because their definitions turn on one useful question: what did the criminal hold before the attack started?

In practice the two halves meet. Visa notes that account testing attacks, too, generally “occur on multiple payment accounts within the same issuing BIN.” It adds that account testing is sometimes called BIN testing, which is one reason the terms blur. For a fraud team the signals and the controls are largely the same, so this page covers both.

OWASP’s OAT-001 Carding entry adds that stolen card data may come “from a criminal marketplace.” How that trade works is covered in our explainer on carding forums and card shops.

What Happened in the 2016 Tesco Bank Attack?

The clearest public case is a UK regulator’s report on Tesco Bank. In November 2016 the attackers “most likely used an algorithm which generated authentic Tesco Bank debit card numbers,” according to the Financial Conduct Authority (FCA). Over 48 hours they made thousands of unauthorized debit card transactions and netted £2.26 million. No customer personal data was lost or stolen.

The attack started at 02:00 on Saturday, 5 November. Most attempts came from Brazil as contactless magnetic stripe transactions, coded PoS 91, which the bank never meant its debit cards to use. Attempted Brazilian transactions peaked at 80,000 by Monday, with about 90% blocked. In the end 8,261 of 131,000 personal current accounts were affected.

The FCA’s findings read like a list of what makes a BIN attack work:

• The bank had issued debit cards with sequential PANs, which made the next valid number easier to find.
• Its authorization system checked only that the expiry date was in the future, not the exact date.
• Fraud rules ran at account level, so transactions on replaced cards skipped the fraud system.
• Visa had warned members about PoS 91 fraud in Brazil and the US. The bank blocked it on credit cards but not on debit cards.
• The first blocking rule failed because it used the euro currency code instead of Brazil’s country code.

The FCA fined the bank £16.4 million on 1 October 2018. The penalty was not for the theft itself. It was for failing to design its cards, set its controls and respond to the attack with due skill, care and diligence.

Why Do BIN Attacks Still Work?

Scale is the first reason. Visa’s spring 2025 threats report says enumeration led to around US$1.1 billion in follow-on fraud in a one-year period. From July to December 2024, enumerated transactions rose 22% and enumerated card numbers rose 8% over the prior six months, with a peak in November 2024.

Weak checkouts are the second reason. Visa says the most common way in is bots that inject card data into a legitimate merchant’s checkout pages. The main reason is weak fraud controls at merchants or their service providers.

Attackers also work through one merchant category for a while and then move on. In early 2021 Visa saw them target pharmacies, colleges, sellers of CBD products and golf merchants.

Quiet checks are the third. Stripe notes that testers prefer the card setup step, because validations there “don’t typically show up on cardholder statements.” When they do make payments, they keep the amounts small, so cardholders are less likely to notice and report them.

What Does a BIN Attack Cost?

The merchant whose checkout is used for testing pays even if no goods ship. Visa lists fees on every authorization, approved or declined, plus staff time for disputes and reissued cards. When the tested cards are later used at other merchants, those merchants face fraud disputes. Stripe adds that a high decline rate can make issuers treat all of a merchant’s payments as riskier, even after the attack stops.

The cardholder and the issuer pay next. Visa notes that enumeration and account testing “generally lead to compromised accounts and account takeovers,” and our glossary entry on account takeover explains what follows. The issuer handles the reissued cards and the cardholders’ disputes.

The card networks also measure it. Under the Visa Acquirer Monitoring Program (VAMP) rules effective 1 June 2025, acquirers must take steps to keep merchants below two monthly enumeration thresholds. These are an enumeration ratio of 2,000 basis points, or 20% of authorizations, and a count of 300,000 enumerated transactions. Approved and declined attempts both count.

How Do You Detect a BIN Attack?

Most attacks first show up as a pattern of declines. What you can see depends on where you sit in the payment chain.

Issuers see every attempt on their own BINs, from every merchant. Visa’s guidance tells them to watch for these signals:

• Spikes in authorization attempts from one merchant descriptor, card acceptor ID or terminal.
• Attempts on sequential, unissued, inactive or dormant card numbers.
• Sudden rises in card-not-present or cross-border activity on one BIN.
• Bursts of one-time password or step-up requests that the cardholder never completes.

Merchants and acquirers see attempts on many issuers’ cards at one checkout. Visa asks them to watch for these signals:

• High velocity to the same issuer or BIN, and attempts on sequential card numbers.
• Many identical or similar amounts.
• Approved authorizations that are not sent for clearing within 24 hours or longer.
• Merchant descriptors full of random characters, which Visa calls key smashing.

Stripe’s list for its merchants is similar. It names a spike in failed or blocked payments, a spike in API requests with 402 errors, and small payments with “nonsensical customer names and emails.”

Decline codes are the most direct signal. Visa’s guidance names the response codes below as indicators of enumeration or account testing. The right-hand column is our reading of what each code can mean during an attack.

A simple watch rule groups recent attempts by BIN. The query below is a sketch for a payments database. Field names will differ, and the window and limits are parameters you set from your own normal traffic.

SELECT card_bin,
       COUNT(*) AS attempts,
       COUNT(DISTINCT card_fingerprint) AS distinct_cards,
       COUNT(DISTINCT client_ip) AS source_ips,
       AVG(CASE WHEN status = 'declined' THEN 1.0 ELSE 0 END) AS decline_rate,
       SUM(CASE WHEN decline_code IN ('14', '54', 'N7') THEN 1 ELSE 0 END) AS guess_declines
FROM payment_attempts
WHERE created_at >= :window_start
GROUP BY card_bin
HAVING COUNT(DISTINCT card_fingerprint) >= :min_cards
   AND AVG(CASE WHEN status = 'declined' THEN 1.0 ELSE 0 END) >= :min_decline_rate;

Two columns carry most of the signal. Many distinct cards under one BIN at one checkout points to enumeration. Many attempts on one card with changing expiry dates or security codes points to card cracking.

What Do Criminal Listings Show About BINs?

The other half of the picture sits on criminal markets. Brandefense Blackhole, our cybercrime database, collects around 17 to 23 million dark web and Telegram posts a month. For the Fraud chapter of our Cybercrime Report 2026, we froze 1,413 carding-labelled posts from 1 January to 27 October 2026 and read selected ones in full.

Three findings tie directly to BINs and testing:

• A 20 October 2026 card advertisement offered “custom or random card prefixes”, so the buyer could pick the BIN.
• A deterministic sample of 20 carding records included card-prefix lookups and a declined-check message.
• A 9 July 2026 menu promised a replacement or refund for invalid material within a stated five-minute check time. A window that short means the buyer is expected to test the card at once.

Europol describes the same market from outside. Carding marketplaces “also offer card-testing services for criminals who have harvested or purchased unverified dumps of credit card information.” Visa’s guidance says such checks most often run through legitimate merchants’ checkout pages, which is where the detection signals above appear.

Our records have limits. The 1,413 posts are not 1,413 cards, and we did not test any card or service. We do not publish shares of listings by BIN or country, because a selection of posts cannot support a market share. The dated card evidence records and our analysis of what stolen card ads promise show the full wording and its limits.

For an issuer, the same BIN shows up in both places. A listing that offers your prefix tells you criminals hold, or want, cards from your range. A spike of code 14 or N7 declines on that prefix tells you someone is testing it.

How Do You Stop a BIN Attack?

No single control is enough. Stripe warns that filters “based on a single heuristic such as IP addresses are usually not sufficient,” and Visa recommends a layered approach. Split the work by role.

Merchants and payment teams can take these steps, drawn from Stripe’s and Visa’s guidance:

• Require a CAPTCHA on every request that saves a card or makes a payment, and validate it on the server side.
• Limit who can reach the payment form, for example by requiring a login or session check instead of open guest checkout.
• Rate limit new customers per IP address and cards added per account.
• Block payments and card setups that fail the security code (CVC) or postal code check, instead of only flagging them. Stripe’s Radar has built-in rules to block on bank checks such as CVC checks. An issuer may still approve a payment that fails these checks, so the merchant has to act on the result.
• Treat 3-D Secure as one layer, not a cure. It adds an issuer check, but Stripe notes that testers also collect 3DS responses, and Visa has seen enumeration through authentication. Visa tells issuers to detect BIN spikes on 3DS transactions, so watch 3DS attempts per BIN as closely as payment attempts.
• Combine controls. Let a first attempt through, then require a CAPTCHA for further attempts from the same address.
• Throttle HTTP sessions and expire them after a period of inactivity.
• Stop retrying cards saved by fake customers after an attack, because each retry repeats the test.

Issuers can take these steps, drawn from Visa’s guidance and the Tesco Bank findings:

• Stop issuing sequential or incremental card numbers, and avoid batch issuance of expiry dates.
• Block account ranges that are not in use.
• Check the exact expiry date and the CVV2 on card-not-present authorizations.
• Run fraud rules at card level, so replaced cards stay covered.
• Write rules for spikes in invalid CVV2 results and in the response codes in the table above.
• Keep an incident plan that covers blocking attack traffic and calling the acquirer directly during a large event.

During an active attack, Stripe’s checklist for merchants is short. Identify the activity, refund fraudulent payments to avoid disputes, add mitigations and check that they work. Tell your acquirer or payment processor as well, because Visa expects acquirers to keep merchants below its enumeration thresholds.

For the wider set of payment controls, see our guide to payment fraud detection and prevention. Cardholders can find practical steps in our post on credit card information safety.

Brandefense Dark Web Monitoring includes carding market surveillance that detects when payment card data tied to your customers or business accounts appears in underground shops or bulk dump offerings.