Velocity Checks

Velocity checks operate by grouping transactions on categorical attributes such as:

• Card Number (PAN): Detecting rapid repeated use of a single card.
• IP Address: Identifying a single source generating many transactions.
• Device Fingerprint: Linking sessions to a specific device.
• Email Address or Shipping Address: Spotting account creation or checkout velocity.

Each attribute dimension provides a distinct signal. A high velocity on a card number combined with a high velocity on an IP address from a different geolocation is a strong composite indicator of fraud.

Velocity is calculated over a continuously updating time interval, not fixed calendar windows. A sliding window of 15 minutes means the system counts events in the last 15 minutes from the current moment.

This is implemented using:

• Tumbling windows: Fixed, non-overlapping intervals.
• Hopping windows: Fixed-size, overlapping intervals.
• Session windows: Dynamic windows that group events by periods of activity separated by inactivity gaps.

The choice of window size is critical: too short misses patterns, too long introduces latency and dilutes the signal.

Maintaining exact counts for millions of attributes with sub-millisecond latency is memory-prohibitive. Velocity checks often leverage approximate algorithms:

• Count-Min Sketch: Estimates frequency with a tunable error bound, using sub-linear space. Ideal for heavy-hitter detection.
• Bloom Filter: Efficiently tests set membership to answer "have we seen this attribute before?" with no false negatives.
• HyperLogLog: Estimates the cardinality of unique attributes, useful for measuring the distinct number of cards used from a single IP.

These structures trade a small, controlled error rate for massive reductions in memory footprint.

A velocity check is not a binary rule; it compares a computed rate against a dynamic threshold. Effective tuning involves:

• Statistical baselining: Calculating the mean and standard deviation of velocity for a given attribute across a historical population.
• Percentile-based thresholds: Setting limits at the 99th or 99.9th percentile of normal behavior.
• Context-aware thresholds: Adjusting limits based on merchant category code (MCC), transaction amount, or time of day.

A threshold set too low generates false positives; too high allows fraud to pass. Continuous monitoring of threshold performance is essential.

Velocity checks require state management to remember previous events. In a distributed stream processor like Apache Kafka Streams or Apache Flink, this state is stored in a local, fault-tolerant state store backed by a changelog topic.

Key considerations:

• RocksDB: A common embedded key-value store for local state.
• State TTL: Time-to-live settings automatically expire old entries to prevent unbounded memory growth.
• Exactly-Once Semantics: Ensures that a single transaction does not increment the velocity counter more than once, even during system failures and retries.

Individual velocity checks are combined into composite rules to increase precision. A single high-velocity signal might be a false positive, but multiple concurrent signals create a high-confidence alert.

Example composite rule: IF (card_velocity_10min > 5) AND (ip_velocity_10min > 10) AND (amount_velocity_1hr > $50,000) THEN score += 850

These rules are often managed in a rules engine with decision tables, allowing fraud analysts to modify logic without deploying code. The output feeds into the overall risk scoring engine.

The computational backbone of velocity checks. Instead of fixed time buckets, a sliding window continuously updates metrics over a rolling interval (e.g., 'the last 15 minutes'). This provides smooth, real-time counts without the edge-of-bucket blind spots that fixed windows create. Implementations typically use hopping windows or cumulative sliding panes to balance accuracy with memory efficiency.

A probabilistic data structure that estimates event frequencies in sub-linear space. When tracking velocity across millions of keys (card numbers, IPs, device IDs), storing exact counts is memory-prohibitive. A Count-Min Sketch uses multiple hash functions and a fixed-size matrix to provide an upper-bound estimate of frequency with configurable error rates. It will never undercount, making it safe for fraud thresholds—false positives are possible, false negatives are not.

A rate-limiting primitive that controls throughput with a burst-tolerant design. A bucket holds a fixed number of tokens, refilled at a constant rate. Each transaction consumes a token; if the bucket is empty, the request is throttled. Unlike fixed windows, the token bucket allows short bursts of legitimate activity (e.g., a holiday shopping spike) while capping sustained velocity. This is the standard algorithm behind most API rate limiters and velocity-based blocking rules.

A space-efficient probabilistic set-membership test. Velocity checks often need to answer: 'Have we seen this card at this merchant before?' A Bloom Filter can definitively say 'no' (guaranteeing novelty) while allowing a configurable false-positive rate for 'yes.' This is ideal for first-seen velocity checks where memory is constrained and a small false-positive rate is acceptable. Multiple hash functions map each element to a bit array, enabling O(k) constant-time lookups.

A flow-control mechanism critical when velocity check pipelines are overwhelmed. If a downstream fraud service slows down, unchecked event ingestion can cause out-of-memory crashes or dropped transactions. Backpressure applies a feedback signal—often via Reactive Streams or TCP window sizing—to slow upstream producers. This ensures the system degrades gracefully under load rather than failing catastrophically, preserving audit trails even during traffic spikes.