Velocity-Based Fraud Rules for Affiliate Platforms: 2026 Implementation Guide

Velocity rules are the workhorse of [affiliate fraud detection](/glossary/affiliate-fraud-detection). They run before fingerprinting, before behavioural modelling, before manual review. A well-tuned velocity layer catches 60 to 80 percent of bot-driven and ring-driven fraud at near-zero compute cost. A poorly-tuned velocity layer floods the review queue with false positives and burns out the ops team. The difference is not the rule definitions; it is the calibration and the cascade. This guide walks through the mechanics of sliding-window counters, the patterns velocity rules can and cannot catch, a 12-rule starter library with concrete thresholds, and the calibration method that keeps false positives under one percent on legitimate conversions.

What Velocity Rules Detect

Affiliate fraud has a velocity signature. Bot farms produce 500 clicks in 5 minutes. Self-referral rings produce 30 sign-ups from the same IP in an hour. Bonus-abuse rings produce 15 deposits from 15 fresh emails in 2 hours. Incentivized-traffic schemes produce a burst of conversions immediately after a paid campaign launches. In every case the fraud looks normal at the per-event level (one click, one sign-up, one deposit) but anomalous at the aggregate level. Velocity rules quantify that aggregate.

Velocity rules are also the layer with the cleanest legal posture. Counting events per IP or per affiliate ID requires no consent, no fingerprinting, no biometric processing. The data is already in the event log. Velocity detection therefore runs even on EU/EEA traffic where stricter signals (fingerprinting, behavioural biometrics) require consent banners and DPIAs. For an operator launching fraud detection in a new market, the velocity layer ships first and the consent-bound layers follow.

How Sliding-Window Counters Work Mechanically

A velocity rule has four components: an identifier (what we count by), an event (what we count), a window (over what duration), and a threshold (above what level we flag). The simplest implementation is a fixed-window counter: at minute 0 we reset to zero, at minute 1 we evaluate, at minute 1 we reset again. Fixed windows have a known weakness: a fraudster who times their bursts at minute boundaries doubles the effective threshold (50 events in second 59 and 50 events in second 61 looks like 50 events per minute, but is actually 100 in 2 seconds). Production systems use sliding windows.

A sliding window keeps a continuous count of events in the last N seconds. Implementations vary by precision and cost.

Most affiliate-platform velocity layers run a mix. Token buckets for click-stream rate limits (high volume, no audit need). Sliding logs for conversion-level rules (lower volume, full audit trail). Fixed-window-with-lookback for cross-day windows where boundary error of a few percent is acceptable. Track360's implementation uses Redis sorted sets for sliding logs on conversion events and in-memory token buckets for click-stream rate limits, giving sub-millisecond latency on the per-click path and audit-quality counts on the per-conversion path.

Threshold Calibration: The Step Operators Skip

Rule definitions are the easy half. Thresholds are the hard half. A threshold of 'block when 5 sign-ups from one IP in 1 hour' sounds reasonable until you find that one of your highest-volume legitimate affiliates uses a corporate proxy that routes 50 employees through one IP, all of whom converted during a sales event. Set the threshold too low and you block legitimate revenue. Set it too high and you catch nothing.

The calibration method that works is data-driven, not intuition-driven. Step one: query historical data. For each candidate rule, count how many legitimate events would have been flagged at thresholds from 1 to 100 over the last 90 days. Step two: plot the distribution. Legitimate traffic typically follows a power-law (most identifiers produce 1 to 3 events; a long tail produces 5 to 20; very few produce 50+). Step three: choose the threshold at the 99.5th percentile of legitimate traffic, then validate against known fraud events to confirm coverage. Step four: run the rule in shadow mode for 30 days. Adjust if the false-positive rate exceeds 1 percent of legitimate conversions or the true-positive recall drops below 60 percent on known fraud.

12-Rule Starter Library with Worked Thresholds

The rules below cover the most common affiliate fraud patterns. Thresholds are starting points calibrated against B2C operator traffic with 30,000 to 500,000 monthly conversions. Adjust by traffic volume: smaller programs need tighter thresholds (more legitimate signal per fraudster), larger programs can afford looser thresholds.

Three observations about this library. First, every rule has an action level. Throttling slows the bot down without alerting it; flagging holds the event for review; blocking refuses the event. The action level reflects the rule's precision: high-precision rules can block, lower-precision rules flag. Second, the identifiers cascade. The same fraud event hits rules 1, 3, 5, 7, and 12 simultaneously when a click burst from one IP produces multiple sign-ups across one affiliate using a disposable-email domain via a VPN. Cascading multiplies confidence. Third, several rules look across windows (rule 6 compares 1-hour activity to a 7-day baseline). These are the highest-value rules because they catch patterns that look normal on any single dimension.

Rule Cascading and Score Aggregation

A single rule flagging an event is rarely enough to block. A high-volume affiliate with a corporate proxy might trip rule 3 (sign-ups per IP) without any fraudulent intent. The reliable signal is multiple rules firing on the same event. Production fraud platforms aggregate rule outputs into an [affiliate fraud score](/glossary/affiliate-fraud-score) and act on the score, not on individual rule outputs.

The aggregation pattern that works in practice is weighted sum with action thresholds. Each rule has a weight (1 to 10) and a maximum contribution. Rule outputs are summed for each event. The action follows the total score: score 0-20 = clear, 21-50 = flag for review, 51-80 = hold payout, 81+ = block. Worked example: a sign-up that trips rules 3 (IP, weight 5), 4 (fingerprint, weight 7), 7 (email domain, weight 5), and 12 (geo mismatch, weight 4) scores 21, landing in 'flag for review'. The same sign-up if it had additionally tripped rule 11 (click-to-conversion delta < 3 sec, weight 8) would have scored 29, still flag for review but higher in the queue. If rule 6 (conversion rate spike, weight 6) had also tripped at the affiliate level, the score would have been 35, placing the case at the top of the ops queue.

Implementation Playbook: 10 Steps from Empty Rule Engine to Live Scoring

1. Audit the conversion event schema. Velocity rules need a consistent event schema (timestamp, identifier fields, conversion amount, geo, fingerprint, click_id). Patch missing fields before writing rules; rules on incomplete data produce noise. (Timeline: 1 week)
2. Choose the counter implementation. For most affiliate platforms, Redis sorted sets give the right tradeoff: sub-millisecond writes, exact sliding windows up to a few hundred thousand events per identifier, easy expiry. (Timeline: 3-5 days)
3. Build the first 4 rules: IP click burst, IP sign-up velocity, affiliate sign-up burst, fingerprint sign-up. These four alone catch the majority of crude fraud and validate the counter pipeline before more complex rules are added. (Timeline: 1 week)
4. Run all rules in shadow mode for 30 days. Log rule fires alongside conversion outcomes (paid, refunded, charged back). Do not block anything. (Timeline: 30 days)
5. Calibrate thresholds from shadow data. For each rule, query the false-positive rate (legitimate conversions flagged) and the true-positive recall (known fraud caught). Adjust thresholds until the aggregate FPR is below 1% and recall is above 60% on patterns you know exist in your traffic. (Timeline: 1-2 weeks)
6. Add the next 4 rules: email domain, same-amount deposits, refund velocity, geo-IP mismatch. These require more historical data to calibrate; do not deploy until step 5 is complete. (Timeline: 1 week)
7. Build the score aggregation layer. Each rule output is a (weight, signal) pair. The aggregator sums weights into a fraud score and writes the score to the conversion record. Track360 exposes this score in the affiliate portal for ops review and in the API for downstream systems. (Timeline: 1 week)
8. Define action tiers. Score 0-20 clear, 21-50 review, 51-80 hold, 81+ block. The exact tier boundaries depend on cost: blocking has zero false-positive recovery cost (the affiliate complains, you unblock), holding has medium cost (delayed payout damages trust), review has the highest cost (analyst time). Calibrate boundaries against ops capacity. (Timeline: 3-5 days)
9. Move from shadow to live by tier. Start by activating 'flag for review' actions. Run for 2 weeks. Then activate 'hold payout' for high-score cases. Finally activate 'block' for cases scoring 81+. Never activate all tiers simultaneously on day 1. (Timeline: 4 weeks)
10. Operate the review queue. Every flagged case needs a disposition (clear, hold, block, lifetime ban) within 24 hours. The disposition feeds back into rule weights: rules whose flags are consistently overturned by analysts have their weights reduced. Track this overturn rate monthly. (Timeline: ongoing)

Edge Cases and False Positives

Velocity rules are noisy in predictable ways. Knowing the patterns reduces ops time.

• Mobile network NAT: Carrier-grade NAT means thousands of legitimate mobile users share a small pool of IPs. Rule 3 (sign-ups per IP) will false-positive on any mobile-heavy affiliate. Mitigation: maintain a list of known carrier-NAT IP ranges and exempt them from rule 3, or replace the rule with a (IP + fingerprint) combined identifier.
• Corporate networks: A B2B SaaS company onboarding 100 employees from one office produces 100 sign-ups from one IP. Mitigation: exempt verified corporate domains, or pair rule 3 with a 'distinct email domain' check.
• Marketing campaigns: A legitimate paid campaign produces a conversion burst that looks like fake leads. Rule 6 (conversion-rate spike) will false-positive on the first hour of every campaign launch. Mitigation: pre-register campaign launches with the fraud system, suppress velocity rules for the first hour.
• Promo codes: When an operator emails an exclusive promo code to a partner list, the cohort converts in a tight window from many IPs. Rule 5 (sign-ups per affiliate) can false-positive. Mitigation: suppress for known promo windows, or condition the rule on geo dispersion (no flag if geo dispersion is high).
• Affiliate testing: Legitimate affiliates sometimes test their own funnel and produce 5-10 sign-ups from their own IP within minutes of going live. Mitigation: build a 'test mode' that the affiliate can enable for 1 hour at a time, exempting their IP from the rules.

Operator Audit Checklist

• Conversion event schema includes all fields velocity rules need: timestamp (ms precision), IP, fingerprint visitor_id, click_id, affiliate_id, email, amount, geo.
• Sliding-window counter implementation chosen and load-tested. Latency budget below 5ms per event.
• 30-day shadow mode completed for every rule before activation. Logs retained for audit.
• Threshold calibration documented. Each rule has a recorded false-positive rate, true-positive recall, and threshold rationale.
• Score aggregation layer in place. Action tiers (clear, review, hold, block) defined.
• Review queue staffed. Average disposition latency below 24 hours. Backlog tracked weekly.
• Overturn-rate monitoring active. Rules with overturn rates above 30% are flagged for retuning.
• Exemption lists in place for known false-positive sources: carrier NAT, corporate domains, campaign windows, affiliate test mode.
• Audit log of every rule fire retained for at least 12 months (typically a compliance requirement for [chargeback](/glossary/chargeback) disputes and [AML](/glossary/aml) audits).
• Quarterly review scheduled. Rules with low fire rates and rules with high overturn rates are revisited.

Frequently Asked Questions

External References

• ACI Worldwide - Industry-standard reference for velocity-checking patterns in payment fraud, transferable to affiliate fraud with minor adaptation.
• PCI SSC - Compliance-side guidance on velocity checks for cardholder-data environments, useful for operators with payment-fraud overlap.
• FATF Risk-Based Approach - The international standard for risk-based controls, often cited in compliance audits for regulated iGaming/forex operators.
• NIST SP 800-53 Rev 5 - The control library (AC-7 unsuccessful login attempts, SI-4 system monitoring) that maps directly to velocity-rule design.
• Sift State of Online Fraud - Annual industry analysis with velocity-pattern benchmarks across e-commerce verticals.
• Stripe Radar - Public documentation of one of the most mature production velocity-rule systems; useful reference for rule design.
• OWASP Authentication Cheat Sheet - The reference for account-lockout and authentication-velocity controls, foundational for any fraud-rule library.

Velocity rules are the most operationally honest layer in an affiliate fraud stack. They run cheaply, they scale, they catch the obvious patterns, and they fail gracefully when miscalibrated (a noisy rule swamps the queue but does not generate legal exposure the way miscalibrated biometric checks do). The operators who get value from velocity rules treat calibration as the work, not the rule definitions, and they accept the 12-week timeline from design to fully-live blocking. The starter library above is a reasonable v1; everything else is tuning.