Skip to main content

Velocity Rules

Prerequisites

Before configuring velocity rules, ensure you have:

  • Access to processor or fraud platform rules dashboard
  • At least 30 days of transaction data for backtesting
  • Understanding of card testing and ATO attack patterns
  • Familiarity with rules vs ML trade-offs
TL;DR
  • Velocity rules = Thresholds on transaction/action frequency to catch automated fraud
  • Start with: 3 txns/card/hour, 10/card/day, 5/IP/hour—then tune from your data
  • Always backtest: run in shadow mode 2 weeks before blocking
  • Target: over 30% of flagged transactions are fraud, under 0.5% of traffic blocked
  • Best for card testing, ATO; complement with ML at scale

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.

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: Only enforce if more than 30% of flagged transactions were fraud AND fewer than 0.5% of total traffic is blocked.

Run length: At least 2 weeks or 5,000 transactions, whichever is longer.

Finding Your Thresholds​

Start here, then adjust based on your data:

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: Turn on your processor's default velocity rules and stop. You don't have enough data to tune anything meaningful. When you see a pattern, come back.

$100K-$1M/month: You can start experimenting. Run 1-2 custom rules in shadow mode. Manual review anything over $300 that gets flagged.

Over $1M/month: Manual review is now a bottleneck. You need automated reject thresholds for the bottom 10% of trust scores. Custom velocity rules become worth the effort.

Over $10M/month: You have enough data to train ML models. Velocity rules become backstops for ML misses, not your primary defense.

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:

  • Was it fraud? (Check chargebacks 30-60 days later)
  • Was it a good customer? (Check if they're still active)
  • Was it a false positive? (Legitimate customer blocked)

Week 3: Decision​

If the rule would have blocked:

  • More than 30% fraud: Consider enforcing
  • 10-30% fraud: Tighten the threshold or add conditions
  • Less than 10% fraud: Kill the rule, it's not worth it

Week 4+: Enforce and Monitor​

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

Watch your false positive rate for the first two weeks. If you're blocking more than 0.5% of transactions, your thresholds are probably too aggressive.

Velocity by Fraud Type​

Card Testing​

High transaction count, low amounts, sequential card numbers, concentrated IP/device.

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 (Issuers)​

Utilization velocity, cash advance velocity, balance increase rate. See portfolio monitoring for issuer-side detection.

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 YouRed Flag
Block rate% of traffic blocked by this ruleOver 1% is probably too aggressive
Block-to-fraud ratio% of blocked transactions that were actual fraudUnder 30% means too many false positives
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​

If one rule is blocking more than 1% of traffic or driving more than 20% of all blocks, review 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: If a rule hasn't fired in 60 days, consider removing it

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. Rule of thumb: have a flash sale exception flag that relaxes velocity rules for 2 hours around announced promotions.

Corporate cards: A company card might legitimately hit your site 20 times in a day. Different employees, same card. If you sell B2B or have corporate accounts, your velocity thresholds need to be 3-5x higher for commercial BINs.

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. Run every rule in shadow mode for 2 weeks minimum. If you skip this step, you'll learn about false positives from angry customer emails instead of from 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 - 2 weeks minimum
  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