Key Highlights
- A BIN attack searches a whole Bank Identification Number range for card credentials that work. Four fields get guessed together: account number, expiry date, CVV2 and billing postal code.
- Cards in a programme share a BIN, so a single working pattern puts the whole range in reach.
- The attack is visible in authorisation data before the losses land. A decline spike inside one narrow band of a BIN range, e.g. sequential numbers, is the clearest early signal.
- Fraud loss is the smallest of the costs an attack imposes. Authorisation processing, disputes and re-issuance across the affected range all carry more.
- No control stops enumeration completely. The work is raising the cost of each attempt while keeping good transactions approved.
Guidance on BIN attacks is written almost entirely for merchants, because the merchant-side monitoring thresholds are the ones the card networks publish and the merchant population is larger. A company that issues the cards sits on the other side of the same attack, and the exposure there works differently.
What Is a BIN Attack?
A BIN attack is a brute-force attempt to find a working combination of payment card credentials. An attacker starts with a known Bank Identification Number, then uses software leveraging Luhn algorithm to generate possible account numbers and guess the corresponding expiry date, CVV2 security code and billing postal code.
The BIN is the first six to eight digits of a card number which identifies the issuer and programme. So because every card in a programme shares the same BIN, repeated testing can expose multiple accounts across the range.
The attacker tests these combinations through online merchants or payment gateways, often using low-value authorisations. An approval confirms that the credentials are live.
The process of generating and testing these combinations is known as card enumeration.
How Does BIN Attack Work?
Typically, a BIN attack runs in four steps, and volume is what makes it work.
1. Take a known BIN. BIN lists are published and traded openly, so the starting point costs an attacker nothing.
2. Generate candidate numbers. Software produces patterned account numbers under that BIN. It then filters them against the Luhn checksum, which discards the combinations no issuer would ever assign.
3. Test each one with a low-value authorisation. A small charge is submitted to a merchant. The request travels from that merchant to its acquirer, and then to the issuer that holds the BIN. The issuer is the party that approves or declines it, so an approval confirms the number is live.
4. Keep what approves. Working numbers are used directly, sold on, or held.
Two characteristics make a BIN attack hard to detect at first:
1. Low-value attempts. Attackers keep amounts small because these may be less likely to trigger risk controls or attract a cardholder's attention.
2. Automated, high-volume bursts. Attackers test thousands of combinations within minutes. Each guess has a low chance of success, so the method relies on volume.
How Do You Know a BIN Attack Is Happening?
A risk team sees a BIN attack first in its decline rate. Ordinary declines move slowly and spread thinly across a whole portfolio, so a sharp rise inside one narrow band of a BIN range, e.g. sequential numbers, is the clearest early signal. The rise builds over minutes.
Three further patterns confirm an attacker is working the range.
- Authorisations that never settle. An attacker needs only the approval, so most of these attempts never clear.
- Repeated low-value attempts across sequential card numbers. Genuine cardholders do not walk a number range in order.
- Concentration on one merchant or merchant category code. Attackers reuse whichever endpoint approves them, so the attempts cluster there.
A team can only read a spike against a baseline it already holds, so a programme that never tracks its ordinary decline rate by BIN range and by hour has nothing to compare the attack against.
What Does an Enumeration Attack Cost a Card Programme?
A card programme pays for an enumeration attack in 5 places, and the fraud losses are the smallest of them. North American financial institutions absorb about USD 5 of total cost for every USD 1 lost to fraud, up 25% in four years.
- Authorisation processing: An attacker submits hundreds of thousands of authorisations in one run, and the issuer pays to process every one. None of it produces revenue.
- Fraud losses, then disputes: Few guesses approve, and an attacker uses those until something blocks them. Each transaction the cardholder disputes becomes a chargeback the programme processes and represents.
- Re-issuance, and the hours before it: A programme would need to re-issue every card in a compromised range and pay production, delivery and staff hours on every one.
- Good cardholders declined: A team tightening velocity caps mid-attack turns away genuine transactions alongside the attacker's, and those cardholders just see a card that stopped working.
- Brand reputation damage: The attack itself may happen behind the scenes, but cardholders experience the consequences. Unexpected declines, disputed transactions and replacement delays can weaken trust in the programme.
How To Prevent a BIN Attack
A programme prevents a BIN attack by raising the cost of each attempt until the method stops paying. Five controls do most of that work, in rough order of effect.
- Rate limits on the BIN range. Cap authorisation attempts per range per interval and the attacker loses the volume the method depends on. A slow attack that stays under the cap still gets through.
- Non-sequential card numbering. Issue account numbers from a randomised pool and an attacker has a far larger space to search. Cards already issued in sequence stay exposed. Visa tells issuers to avoid sequential or incremental account numbers and batched expiry dates.
- 3D Secure on card-not-present transactions. An authentication step defeats an attacker holding only a number. It also adds friction for genuine cardholders, and does nothing where the merchant never invokes it.
- Merchant and category blocking. Suspend the endpoint a run is using and that run stops. Attackers move to another merchant, so treat this as containment.
- Real-time anomaly detection. Only this control catches a pattern nobody wrote a rule for in advance, and it needs a baseline a new programme does not yet have.
Every one of these declines some genuine transactions by design, so a programme is choosing which cost to carry.
What Should a Programme Do in the First Hour of an Attack?
In the first hour of a BIN attack, a team can still limit how much of the range gets exposed. How fast it detects and contains the attempt, rather than whether the attack could have been prevented, decides the outcome. Five actions fill that hour.
1. Confirm the pattern. Pull authorisation attempts for the affected BIN range by minute, then check for sequence, for repeated amounts and for merchant concentration.
2. Throttle at the range level. Apply a velocity cap across the affected range. An analyst blocking card by card stays permanently behind the attacker.
3. Block the endpoint. Suspend the merchant or category code the attempts run through. That buys a team the time to work.
4. Identify what approved. Separate the numbers that returned an approval from the full attempted set. An attacker can only use that smaller list, so it is the real exposure and it drives re-issuance.
5. Notify. Tell the issuing partner, and report confirmed fraud through the scheme's reporting process on its normal schedule.
Document the attack window while the authorisation data is still fresh. Authorisation logs age out on their own retention schedule, and an analyst rebuilding the picture a week later spends far more time for a much thinner result. Do it on the day.
How Reap Can Help
Reap Sentry is a managed card fraud function operated by Reap's Risk team for card issuing programmes. Reap configures and continuously tunes the fraud controls, screens authorisations in real time, and investigates alerts. This gives programmes a way to operate card fraud monitoring without building their own tooling or hiring a dedicated fraud team.
For enumeration and BIN attacks, Reap monitors the authorisation layer for emerging patterns and can respond by updating the controls applied to the affected programme. Reap also handles confirmed fraud reporting to Visa, chargeback processing and representment, and ongoing fraud performance reporting.
Sentry covers external card fraud, including compromised credentials, enumeration, BIN attacks and coordinated third-party activity. It does not cover anti-money laundering, counter-terrorist financing, sanctions screening, KYC or the programme's wider regulatory obligations. These remain with the programme manager.
Disclaimer
The information provided in this material is for general informational purposes only and does not constitute legal, financial, tax, or business advice. It should not be interpreted as a recommendation, offer, solicitation, or inducement to engage with Reap’s products or services. Any use of Reap’s services is at the user’s sole risk and discretion.
Reap makes no representation or warranty, express or implied, regarding the accuracy, completeness, or reliability of the information provided. Services are governed exclusively by Reap’s applicable legal agreements. Service availability, features, and eligibility may vary by jurisdiction and are subject to regulatory, card network, and operational limitations.
All trademarks, logos, and brand names are the property of Reap and/or their respective owners. References to third-party platforms or services are for descriptive purposes only and do not imply endorsement, partnership, or affiliation.
Reap’s services and information are provided on an “as is” and “as available” basis, without warranties of any kind. Reap shall not be liable for any loss or damage arising from the use of, or reliance on, this information or its services.
