Why Velocity Checks Catch What Fingerprints Miss

Device signals describe one client at one moment. Velocity checks describe how often an event occurs across a population, and that difference lets them catch behaviour no per-session inspection can reach.

Rate is a property of the operation

An operation exists to do something repeatedly, whether that is testing credentials, creating accounts or extracting content. Repetition is not incidental to it, it is the objective.

Any single one of those actions is indistinguishable from a legitimate one. A login attempt looks like a login attempt regardless of what else the same actor is doing.

Counting the actions therefore observes the thing the operation cannot hide, because reducing the rate to something unremarkable removes the reason for the operation.

The counting key determines what is detected

Counting per address catches concentrated activity and misses anything distributed across a proxy pool. Counting per account catches credential misuse and misses distributed account creation.

More revealing keys count the other side of the interaction: attempts against a single account from many sources, or registrations using variations of a single contact detail.

Choosing keys that the operation cannot vary cheaply is the whole design problem. Whatever the operation must reuse is where the counter belongs.

Windows and thresholds encode assumptions

A short window catches bursts and misses slow activity, while a long window catches patient operations and accumulates false positives from ordinary users over time.

Running several windows simultaneously covers both, at the cost of more thresholds to maintain and more ways for a legitimate user to trip one.

Thresholds also have to account for shared infrastructure, since a value that a single person could never reach is easily reached by a shared address or a corporate gateway.

They complement rather than replace device signals

Velocity says something is happening too often. Device signals say something about who is doing it. Neither answers the other's question.

Combined, they are considerably stronger: elevated rate from clients that also share characteristics is far more convincing than either observation alone.

The combination also reduces false positives, since a high rate from clients that look entirely unrelated is more likely to be genuine popularity than coordination.

Distributed operations force wider counting

Operations that spread activity thinly across many addresses and many clients defeat per-key counting by construction, since no individual key sees an unusual rate.

Detecting them requires counting at the level of the target rather than the source: how many distinct clients touched one account, one product, one endpoint, within a window.

That reframing is what makes distributed activity visible, because the target is the one thing the operation cannot distribute.