How this detection works
BIN attacks happen when fraudsters acquire valid BIN ranges (typically from breaches or BIN-list databases), generate card numbers within those ranges using the Luhn algorithm, then test them at scale against merchant checkouts. The successful cards get used for fraud — at which point chargebacks land, weeks later, after the funds have already moved.
The detection problem isn't after-the-fact: by the time chargebacks land you've already lost the money. The detection problem is before-the-fact: spotting the pattern in real time and pulling the trigger while damage is still containable.
Real-world impact
Illustrative scenarios drawn from operator practice. Numbers are realistic order-of-magnitude estimates, not measurements from any specific deployment.
Case 1: Card testing wave 47 days before chargebacks would land
SetupRisk analyst at a digital goods platform watching nightly BIN reports across roughly 1,800 active issuer ranges.
ProblemStandard transaction monitoring missed slow-burn card testing because no single transaction tripped scoring; the team usually only saw the damage after $60K to $120K in chargebacks posted.
Tool surfacedTwo prepaid BINs crossed all three thresholds simultaneously (velocity +210% vs baseline, $14K volume, 78 new users in 3 days), pattern matched the slow-burn attack signature.
OutcomeBoth BINs rate-limited for new users within 6 hours, projected chargeback exposure dropped from an estimated $90K to about $11K, roughly $79K saved on a single alert.
Case 2: Pre-Black Friday tuning to avoid alert fatigue
SetupFraud lead at a regional ecommerce site preparing for a holiday week with expected 3x to 4x organic volume across all BINs.
ProblemExisting single-signal alerts (just velocity) would fire on 40+ BINs during peak, drowning the on-call analyst and effectively disabling detection.
Tool surfacedCombining velocity AND volume floor AND new-user clustering kept the alert list to 3 real candidates during simulated peak, distinguishing organic holiday lift from coordinated attack patterns.
OutcomePeak week ran with 4 true-positive escalations and zero alert fatigue burnout, vs the prior year where 2 real attacks were missed under noise costing about $45K.
The three signals
This monitor combines three signals because no single one is reliable on its own:
Alert IF (volume velocity > X%) AND (3-day volume > minimum) AND (new-user count > threshold)
- Volume velocity — % change in 3-day volume vs the 7-day baseline. Real attacks spike fast. Real growth ramps slower.
- Volume floor — absolute 3-day volume must exceed a minimum. Tiny BINs with a 3x spike going from $100 to $300 aren't worth waking ops up for.
- New-user clustering — attacks generate accounts at velocity to match the cards. A volume spike with stable user count is usually legitimate growth (existing customers buying more). A volume spike with a wave of new users is the fingerprint of an attack.
Why AND instead of OR? Because each signal alone is too noisy. Volume velocity alone triggers on Black Friday. New-user count alone triggers on a marketing campaign. Volume floor alone is just a static threshold. The intersection — all three crossing simultaneously — is the fingerprint of an attack.
The status tiers
- Alert — all three signals cross. Pull a human investigator now.
- Watch — velocity is elevated AND one of (volume floor or new-user count). Early stage or ambiguous pattern. Track daily, no ops response yet.
- Safe — velocity normal or only one signal crossing. Stable large BINs with no velocity change land here even if they exceed the floor — that's intentional. The point is detecting change, not flagging size.
What this monitor does NOT do
- It doesn't decide whether a specific transaction is fraud. That's the job of your rules engine or ML model.
- It doesn't auto-block. Triggering an alert pulls a human into investigation; the block decision needs human judgment.
- It doesn't replace transaction-level monitoring. This sits at the BIN aggregate layer, complementing per-transaction defenses.
What this monitor IS good for
- Early warning before chargebacks land (which usually takes 30–90 days)
- Sizing the operational response (how many BINs are affected, how big is the volume)
- Pattern documentation for post-incident review
- Feedback to the rules engine on which BIN ranges need tighter scoring
Reference implementation
A Python reference of the same logic, with synthetic data and threshold gating, is available as bin-monitor-reference.py. Use it as a starting point for adapting the logic to your own data pipeline (BigQuery, Snowflake, Postgres, anywhere).
The mock data in this simulator
30 BINs across realistic issuer types (consumer credit, corporate, debit, prepaid). Patterns include normal operations, organic growth, marketing-driven volume spikes, and three injected attack scenarios that the default thresholds catch. Adjust the thresholds to see how sensitivity affects false positive rate. The art of running this in production is tuning the thresholds for your specific transaction baseline.