BIN Attack Protection: Stop Card Testing at Checkout

BIN attack protection stops scripted attempts to guess live card numbers inside one bank identification number range. The controls that do the work are per-BIN velocity caps, mandatory CVC and AVS checks, 3-D Secure challenges on risky traffic, and monitoring of decline and approval patterns as they happen.

related article

An attacker takes a single BIN, fires thousands of small test charges, and keeps the cards that approve. Each guess costs almost nothing, so the point of protection is to make guessing slow, visible, and unprofitable before a stolen number is used for a real purchase.

Top Bin Attack Software for CVV Transactions

Prerequisites

• Access to gateway or processor settings for velocity rules, CVC, AVS, and 3-D Secure.
• A log pipeline that keeps declines, approvals, device fingerprints, IP addresses, and card BIN for at least 90 days.
• A named owner for fraud rules and a rollback plan if approval rates drop.

Steps

1. Export 30 days of authorization logs and group them by BIN, response code, IP subnet, and device ID.
2. Mark every BIN whose decline count runs past your baseline by a set multiple, for example five times the 95th percentile.
3. Cap attempts per BIN and per IP. A workable starting rule: block the source when one BIN sees more than 20 authorization attempts in 10 minutes from the same IP or device.
4. Cap attempts per card number across the whole estate, so one card cannot be tested from many addresses. Set the limit at 3 to 5 attempts in 24 hours.
5. Require CVC and AVS on card-not-present transactions and decline a failed CVC match instead of sending it to manual review.
6. Turn on 3-D Secure for traffic that trips any risk rule, and use the low-risk exemptions your acquirer supports for clean traffic.
7. Block or challenge requests from datacenter IP ranges, mismatched billing and IP countries, and device fingerprints that touch many cards in a short window.
8. Add a floor on test amounts. Declines for repeated charges between $0.00 and $1.00 from one BIN catch most card testing scripts.
9. Send flagged orders to a fraud queue with a hard response deadline, so held orders do not turn into false declines.
10. Alert your acquirer and the issuing bank when an attack runs for more than an hour. Acquirers can push a BIN-level block and issuers can tighten their own rules.
11. Review thresholds each week against your false-decline rate and change one rule at a time.

Signals that separate an attack from normal traffic

• Many card numbers from one BIN, arriving within minutes of each other.
• Small amounts that repeat, or amounts that step up by a cent.
• One device or IP touching dozens of card numbers.
• Approval rate for a BIN that jumps far above its own history.
• Billing addresses that repeat with different card numbers.

Metrics to track

• Authorization attempts per BIN per hour.
• CVC failure rate and AVS mismatch rate.
• False decline rate on good customers.
• 3-D Secure challenge rate and challenge pass rate.
• Chargeback count tied to cards from the flagged BIN.

What not to do

Blocking a whole BIN shuts out every real customer of that bank. Scope the block to the attacking IP, device, or card range, and lift it as soon as the traffic stops. Keep CVC and AVS responses in your decisions, because velocity rules alone miss slow, low-volume guessing.

related article