Learn→Fraud Detection & Anomaly Detection→Feature Engineering (Temporal Patterns, Aggregations, Velocity)→3 of 6
Fraud Detection & Anomaly Detection • Feature Engineering (Temporal Patterns, Aggregations, Velocity)Medium⏱️ ~2 min
Velocity Features: Measuring Rate and Acceleration
Velocity features quantify how fast something is changing. They capture rate of change, event frequency per time window, and acceleration. In fraud detection, high velocity is one of the strongest signals: attackers test stolen cards rapidly, generating 10 to 50 authorization attempts in minutes compared to typical legitimate use of 2 to 5 transactions per day.
Event velocity counts occurrences per entity per time window. For payment fraud, track attempts per card in 1 minute, 5 minutes, 1 hour, and 24 hours. Track attempts per IP address, per device fingerprint, and per billing address in the same windows. Cross entity velocity reveals coordinated attacks: if 50 different cards from the same IP each attempt 3 transactions in 5 minutes, the IP level velocity of 150 attempts signals a fraud ring even though individual card velocity looks moderate. PayPal monitors merchant velocity, flagging when a merchant processes 10x typical volume in an hour, indicating possible compromise or money laundering.
Rate of change compares current value to a prior baseline. Compute current window aggregate divided by prior window or long term average. For example, if transaction amount in the last hour is $2000 but the 7 day hourly average is $200, the 10x ratio signals anomaly. Acceleration captures second order change: how quickly is velocity itself increasing. If attempts per minute go from 2 to 5 to 12 over three consecutive minutes, acceleration is rising and indicates an escalating attack. Combine rate and acceleration: flat high velocity might be legitimate high volume usage, but rising acceleration is almost always adversarial.
Velocity features are cheap to compute online because they use simple counters, but they require careful state management. At scale, tracking 10 million cards with 6 windows per card and 10 features per window means 600 million numeric values in memory. Limit active keys by evicting entities with no activity for 24 hours. Use hierarchical windows: keep 1 minute and 5 minute exact online, compute 24 hour and 7 day in batch, and refresh hourly. This hybrid approach balances responsiveness with memory cost.
💡 Key Takeaways
•Event velocity counts occurrences per entity per time window: attempts per card in 1 minute, 5 minutes, 1 hour, 24 hours reveal attack tempo
•Cross entity velocity detects coordinated attacks: 50 cards from one IP each with 3 attempts in 5 minutes flags fraud ring despite moderate per card velocity
•Rate of change divides current aggregate by baseline: transaction amount in last hour divided by 7 day hourly average catches 10x spikes indicating anomaly
•Acceleration measures second order change: attempts per minute rising from 2 to 5 to 12 over three minutes signals escalating attack, not legitimate usage
•PayPal flags merchants processing 10x typical hourly volume as possible account compromise or money laundering based on merchant level velocity
•Scale requires hierarchical windows: keep 1 minute and 5 minute exact online for 10 million active cards, compute 24 hour and 7 day in batch with hourly refresh to limit memory
📌 Examples
Stripe card testing attack: stolen card attempts 18 authorizations in 2 minutes, compared to legitimate baseline of 5 per day; velocity ratio is 18 / 0.003 = 6000x
Uber geographic surge: ride requests per geohash jump from 10 per minute to 50 per minute in 5 minutes during concert exit; acceleration triggers dynamic pricing
Amazon account takeover: user places 8 orders in 10 minutes from new device after 6 months dormant; velocity spike plus device change triggers step up authentication
PayPal fraud ring detection: IP address shows 200 authorization attempts in 5 minutes across 80 distinct cards; IP velocity of 2400 per hour is 1000x normal and triggers block