Skip to main content

Limiting How Often Someone Can Try (Velocity Rules)

Last updated . Copy page as text

TL;DR
  • Velocity rules = Thresholds on transaction/action frequency to catch automated fraud
  • Example shadow settings: 3 txns/card/hour, 10/card/day, 5/IP/hour. Check legitimate bursts before using them
  • Backtest and shadow first; set the sample size and outcome window for the decision you're making
  • Enforce only inside the fraud-loss, customer-impact and review limits you chose before the test
  • Best for card testing, ATO; complement with ML at scale

A velocity rule is a cap on how many times something can happen in a set stretch of time: one card, one email, one IP address, one hour. Go over the cap and the next attempt gets flagged or blocked.

Velocity rules catch the lazy fraud. A single card hitting your checkout 47 times in an hour is obvious. The challenge is tuning thresholds that catch fraud without blocking legitimate customers during flash sales.

Those threshold recommendations you see everywhere (3 transactions per hour, 10 per day) are someone else's guess. Here's how to find yours using your own fraud metrics.

Need containment during an active attack? Open the incident playbook.

Experiment to Run: Backtest Before You Block

Hypothesis: Rule X would have blocked Y% of fraud with Z% false positives.

Method:

  1. Pull last 30 days of transactions
  2. Apply proposed rule in shadow mode (flag, don't block)
  3. Calculate:
    • Hit rate (% of traffic that would trigger)
    • Fraud rate inside hits
    • Good customer rate inside hits

Decision rule: Compare the loss prevented with blocked-good margin and review cost, using the Fraud Metrics definitions. Choose those budgets before testing. A high fraud share in hits alone doesn't authorize blocking.

Run length: Collect comparable traffic and enough confirmed outcomes for your decision. Two weeks is a possible monitoring start, not proof that a rule is ready. If results are uncertain, keep shadowing.

Finding Your Thresholds​

These are illustrative shadow settings, not processor limits or proven cutoffs. Use the Tune By column to choose your own, then test before enforcing:

DimensionStarting ThresholdTune By
Transactions per card per hour3Your flash sale patterns
Transactions per card per day10Your repeat customer behavior
Transactions per IP per hour5Your corporate/VPN traffic
Transactions per device per day15Your multi-account legitimate use
Failed auths per card in 10 min3Your retry patterns (see decline codes)
Scale Matters

Under $100K/month: Start with your processor's controls. A repeated attack can justify investigation at any size, but sparse outcomes may leave threshold tests inconclusive. Keep current controls while evidence builds.

$100K-$1M/month: Consider a small number of custom rules in shadow mode when you have a repeated pattern. Send flagged orders to manual review only when their expected benefit justifies the time.

Over $1M/month: Check whether review hours exceed capacity. Test automated decisions on confirmed patterns rather than declining a fixed share of customers.

Over $10M/month: Evaluate ML models if you have the labelled outcomes and staff to maintain them. Revenue alone doesn't establish readiness.

How to Actually Test a Rule​

Week 1: Shadow Mode​

Deploy the rule but only flag, don't block.

RULE: card_velocity_hourly
DIMENSION: card_number
WINDOW: 1 hour
THRESHOLD: 3 transactions
ACTION: flag_for_review (NOT block)

Week 2: Analyze Flags​

For every flagged transaction:

  • Confirm fraud after the outcome window closes
  • Investigate legitimate orders the rule would've blocked; activity alone isn't proof
  • Report confirmed legitimate would-blocks / All would-blocks, with unknowns separate

Week 3: Decision​

Compare the rule's expected loss savings with the margin lost on confirmed good orders and the review time it creates:

  • Inside the budgets you set, with mature outcomes: consider a limited live test
  • Too costly in good orders or review hours: change the conditions and retest
  • No useful fraud coverage after follow-up: consider retiring it, keeping a record of what it covered

Week 4+: Enforce and Monitor​

Enforcing is a live test. The chargebacks Week 2 tells you to check arrive weeks after the order, so decide on the outcome window you set, and write down the owner, the eligible orders and the loss cap before you switch to block (the checklist).

RULE: card_velocity_hourly
DIMENSION: card_number
WINDOW: 1 hour
THRESHOLD: 3 transactions
ACTION: block
EXCEPTION: customer_tenure > 12_months

Watch the legitimate share of fraud blocks and the block rate separately. Pause at the loss or customer-impact limit you set before launch. A block rate alone doesn't establish whether a rule is too aggressive.

Velocity by Fraud Type​

Card Testing​

High transaction count, low amounts, sequential card numbers, concentrated IP/device. The code below is an illustrative rule, not a proven cutoff. Test its windows and amounts against legitimate traffic; use the same approach for the ATO and ring examples below.

IF transactions_per_IP_1hr > 10
   AND average_amount < $5
   AND decline_rate > 50%
THEN block_IP

Backtest first: Pull last 30 days, apply this rule, check false positives. See fraud metrics for measurement guidance.

Account Takeover​

Login velocity spike, profile change velocity, transaction pattern change. Use with behavioral analytics for best results.

IF failed_logins_1hr > 3
   AND new_device = true
   AND password_changed_24hr = true
THEN lock_account + step_up_auth

Bust-Out / Fraud Rings​

Merchants can detect fraud ring patterns through coordinated velocity spikes across accounts.

IF utilization_change_7d > 40%
   AND current_utilization > 85%
   AND cash_advance_7d > $500
THEN flag_for_review

Velocity Windows​

WindowUse CaseWatch Out For
Real-time (seconds)Card testing, bot attacksHigh infrastructure cost
HourlyTransaction anomaliesFlash sales, legitimate bursts
DailySpending patternsTime zone issues
WeeklyApplication fraudLow sample size
MonthlyBust-out patternsSlow feedback loop

Advanced Rule Structure​

Start simple. Add complexity only when simple doesn't work.

Simple (start here):

IF transactions_per_card_1hr > 3
THEN block

Add exceptions for good customers:

IF transactions_per_card_1hr > 3
   AND customer_tenure < 6_months
THEN block

Add multiple conditions:

IF transactions_per_card_1hr > 3
   AND customer_tenure < 6_months
   AND total_order_value > $500
THEN manual_review

Metrics to Watch While You Experiment​

MetricWhat It Tells YouWhen to investigate
Block rateFraud-control blocks by this rule / Total attemptsOutside your expected traffic range or customer-impact budget
Block precisionConfirmed fraud / All blocks by this ruleLoss prevented no longer justifies blocked-good margin; report unknowns
Appeal/complaint rateCustomers contacting support about blocksRising = rule is too tight
Fraud rate on passed transactionsIs fraud sneaking through elsewhere?Rising = rule isn't catching what matters
Where Experiments Lie to You
  • Small samples: 3 days on 2K transactions isn't enough. Fraud is rare, so you need large samples to measure fraud rate changes.
  • Seasonality: Fraud patterns shift. A rule that works in December may fail in March. Re-test quarterly.
  • Risk shifting: Blocking one channel pushes fraud to another. Measure total losses, not just the channel you changed.
  • Correlation ≠ causation: Just because fraudsters do X doesn't mean everyone who does X is a fraudster.
  • Fraudster adaptation: If you tighten velocity rules, sophisticated fraudsters will slow down. Your rule may "work" but total fraud doesn't drop.

If a Single Rule is Dominating​

Review a rule when its block rate or share of all blocks moves outside the range you chose from comparable traffic. Check its cost and coverage before changing it:

  1. Is the threshold too tight?
  2. Is there a legitimate use case you're catching?
  3. Can you add exceptions for good customers?
  4. Should you split it into multiple rules?

Implementation Tips​

Counter Management​

  1. Atomic updates: Increment counters transactionally
  2. TTL-based expiry: Auto-expire old counts (Redis, DynamoDB)
  3. Distributed counting: Handle scale appropriately
  4. Pre-computation: For complex aggregations

Evasion Resistance​

Fraudsters adapt. Counter with:

  • Multiple overlapping rules (can't evade all at once)
  • Combined conditions (not just single thresholds)
  • Behavioral baselines (anomaly from normal, not absolute)
  • Network-level rules (device graphs, address clusters)

The Iteration Loop​

Velocity rules are never "done." Run this loop monthly:

  1. Review performance: Which rules are firing? What's their false positive rate?
  2. Check escapes: What fraud got through that a rule could have caught?
  3. Adjust thresholds: Tighten where false positives are low, loosen where they're high
  4. Retire stale rules: Use 60 days without a hit as an example review reminder, not an automatic expiry. Check whether the pattern has disappeared or is seasonal before disabling the rule.

Where This Breaks​

Edge Cases That Will Burn You

Flash sales and drops: Your velocity rule says "3 transactions per card per hour." Your marketing just announced a limited sneaker drop. Your best customers are trying to buy fast. You block them. They tweet about it. Test a promotion exception against earlier drops. Give it an owner, an end time and a loss cap.

Corporate cards: A company card might legitimately hit your site 20 times in a day. Different employees, same card. If you sell B2B, compare commercial-card purchase bursts separately before setting their limits. Don't apply a fixed multiplier.

Gift giving season: November-December, legitimate customers buy multiple items to multiple addresses. Your "1 shipping address per card" rule becomes a false positive machine.

VPN and shared IP traffic: College dorms, corporate offices, and VPN exit nodes concentrate thousands of users behind one IP. IP-based velocity rules will block your entire customer segment.

Mobile carrier NAT: Cellular carriers route many users through the same IP. Your IP velocity rule is blocking everyone on AT&T in that cell tower's range.

Test before you block. Start with a planned shadow period and extend it when outcomes or samples are too young to read. If you skip it, you'll learn about false positives from angry customer emails instead of your dashboard.

Next Steps​

Just starting with velocity rules?

  1. Enable processor defaults - Start with built-in rules
  2. Run in shadow mode - Test before blocking
  3. Set up measurement - Track false positives

Tuning existing rules?

  1. Backtest changes - Enough comparable traffic and mature outcomes
  2. Add customer exceptions - Protect good customers
  3. Review by fraud type - Match rules to attacks

Experiencing fraud despite rules?

  1. Check for edge cases - Flash sales, VPNs, corporate cards
  2. Consider ML augmentation - Rules + ML together
  3. Follow attack playbook - Emergency response

Something wrong on this page? Email matt at paymentsandrisk.com and say what needs fixing.