Velocity checks watch for an abnormal rate of actions, like logins, payments, applications, or card attempts, over a short time window. They catch card testing, credential stuffing, bust-outs, and application bursts that no single event would ever reveal.
What are velocity checks, in plain English?
A velocity check counts how many times something happens in a defined window and flags when that count is abnormally high. Think five card attempts in a minute, twenty logins to different accounts from one IP in an hour, or ten loan applications from one device in a day. The individual events can each look fine. The rate is what gives the attack away.
The key design choices are the entity you count across and the window you count over. You can aggregate by account, device, IP, email, card number, or shipping address, over seconds, minutes, hours, or days. The same raw events counted three different ways surface three different attacks, so mature setups run many velocity counters in parallel.
Velocity checks are one of the oldest and most reliable tools in fraud, because most automated abuse is fundamentally about doing something at machine speed and scale. A human opens one account; a script opens two hundred. Counting is a cheap, robust way to see the difference.
How a velocity check works
Under the hood every velocity check follows the same shape:
Pick entity — Choose what to count across. Decide the aggregation key: card, device, IP, email, account, or address.
Pick window — Choose the time frame. Set the window, from a few seconds for card testing to several days for application rings.
Count — Tally the events. Increment a counter each time the action fires for that entity within the window.
Threshold — Compare to a limit. If the count crosses the threshold, trigger a decline, a step-up, or a review.
What they catch
Attack
What the velocity check sees
Card testing
Many small authorizations across different cards from one device or IP in minutes.
Credential stuffing
A flood of login attempts against many accounts from a narrow set of IPs.
Application fraud
Bursts of applications sharing a device, address, or funding instrument.
Bonus and promo abuse
One entity claiming the same offer far more often than a real customer could.
What it looks like in practice
In practice
Overnight, a merchant sees a spike of tiny one dollar authorizations. Each transaction uses a different card number, and most are declined. Looked at one at a time, they are unremarkable low-value attempts.
A velocity counter keyed on device fingerprint tells the real story: the same device tried more than three hundred cards in under an hour. That is impossible for a human shopper and unmistakable for card testing, where a fraudster checks stolen card numbers against a live endpoint to find the ones that still work. The rule blocks the device, and a second counter keyed on IP catches the two backup devices the same actor rotates to.
Why they matter to operators
Velocity checks give you leverage against volume attacks without needing to understand each event in depth. They are cheap to run, easy to explain to a regulator or a merchant, and they degrade gracefully: even when a fraudster evades your fancier models, they usually still have to move fast, and speed is exactly what a counter catches.
The catch is that fraudsters know this too. The main countermeasure is spreading activity out to stay under any single counter: rotating IPs, cycling devices, and pacing attempts across hours. That is why you aggregate across several entities and windows at once, so an actor who dodges the per-IP counter still trips the per-device or per-address one. The other risk is punishing legitimate spikes, like payday transfers or a flash sale, so thresholds need tuning against real traffic, not guesses.
What to watch
Spread-out activity. Fraudsters pace and rotate to stay just under limits, so watch counts that sit suspiciously close to thresholds.
Wrong entity. A counter on the wrong key misses the attack entirely; card testing hides from an account counter but not a device one.
Shared infrastructure. Many accounts funneling through one device, IP, or card is the pattern velocity is built to expose.
Legit spikes. Paydays, sales, and viral moments cause real bursts; tune thresholds so you do not decline good customers.
Window blind spots. A slow attack over days evades a one-minute counter; run long windows alongside short ones.
Quick questions
What is the difference between velocity and a simple rate limit?
A rate limit usually caps one action per one key. Velocity checks are broader: they can count many action types across many entities and windows and feed a risk decision, not just a hard cap.
Which window should I use?
It depends on the attack. Card testing needs seconds to minutes; application rings and bust-outs play out over days. Most programs run several windows in parallel per entity.
How do fraudsters beat velocity checks?
By staying under the limit: rotating IPs and devices, aging accounts, and pacing attempts. Aggregating across multiple keys makes this much harder, since evading one counter still trips another.
Do velocity checks cause false positives?
They can, when real life produces bursts, such as payday or a sale. Good tuning uses observed traffic to set thresholds and often pairs a velocity trip with other signals before acting.
Are velocity checks a rule or a model feature?
Both. They work as standalone rules and also as powerful inputs into a risk model, where a count over a window becomes a feature.
What entities should I count across?
At minimum device, IP, email, card, account, and shipping address. The right set depends on your product, but broad coverage closes the gaps a single-key counter leaves open.
---
title: What is Velocity checks?
source_page: https://www.sardine.ai/fraud-aml-glossary/velocity-checks
canonical: https://www.sardine.ai/fraud-aml-glossary/velocity-checks
format: text/markdown
description: Velocity checks watch for an abnormal rate of actions, like logins, payments, applications, or card attempts, over a short window, across an account, device, IP, or payment instrument. It catches card testing, credential stuffing, bust-outs, and application-fraud bursts that no single event reveals.
---
**Quick links:** [Human page](https://www.sardine.ai/fraud-aml-glossary/velocity-checks) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/customers) · [Blog](https://www.sardine.ai/blog) · [Demo](https://www.sardine.ai/demo)
---
# What is Velocity checks?
**Read time:** 4
Velocity checks watch for an abnormal rate of actions, like logins, payments, applications, or card attempts, over a short window, across an account, device, IP, or payment instrument. It catches card testing, credential stuffing, bust-outs, and application-fraud bursts that no single event reveals.
Velocity checks watch for an abnormal rate of actions, like logins, payments, applications, or card attempts, over a short time window. They catch card testing, credential stuffing, bust-outs, and application bursts that no single event would ever reveal.
What are velocity checks, in plain English?
A velocity check counts how many times something happens in a defined window and flags when that count is abnormally high. Think five card attempts in a minute, twenty logins to different accounts from one IP in an hour, or ten loan applications from one device in a day. The individual events can each look fine. The rate is what gives the attack away.
The key design choices are the entity you count across and the window you count over. You can aggregate by account, device, IP, email, card number, or shipping address, over seconds, minutes, hours, or days. The same raw events counted three different ways surface three different attacks, so mature setups run many velocity counters in parallel.
Velocity checks are one of the oldest and most reliable tools in fraud, because most automated abuse is fundamentally about doing something at machine speed and scale. A human opens one account; a script opens two hundred. Counting is a cheap, robust way to see the difference.
How a velocity check works
Under the hood every velocity check follows the same shape:
Pick entity — Choose what to count across. Decide the aggregation key: card, device, IP, email, account, or address.
Pick window — Choose the time frame. Set the window, from a few seconds for card testing to several days for application rings.
Count — Tally the events. Increment a counter each time the action fires for that entity within the window.
Threshold — Compare to a limit. If the count crosses the threshold, trigger a decline, a step-up, or a review.
What they catch
What it looks like in practice
In practice
Overnight, a merchant sees a spike of tiny one dollar authorizations. Each transaction uses a different card number, and most are declined. Looked at one at a time, they are unremarkable low-value attempts.
A velocity counter keyed on device fingerprint tells the real story: the same device tried more than three hundred cards in under an hour. That is impossible for a human shopper and unmistakable for card testing, where a fraudster checks stolen card numbers against a live endpoint to find the ones that still work. The rule blocks the device, and a second counter keyed on IP catches the two backup devices the same actor rotates to.
Why they matter to operators
Velocity checks give you leverage against volume attacks without needing to understand each event in depth. They are cheap to run, easy to explain to a regulator or a merchant, and they degrade gracefully: even when a fraudster evades your fancier models, they usually still have to move fast, and speed is exactly what a counter catches.
The catch is that fraudsters know this too. The main countermeasure is spreading activity out to stay under any single counter: rotating IPs, cycling devices, and pacing attempts across hours. That is why you aggregate across several entities and windows at once, so an actor who dodges the per-IP counter still trips the per-device or per-address one. The other risk is punishing legitimate spikes, like payday transfers or a flash sale, so thresholds need tuning against real traffic, not guesses.
What to watch
Spread-out activity. Fraudsters pace and rotate to stay just under limits, so watch counts that sit suspiciously close to thresholds.
Wrong entity. A counter on the wrong key misses the attack entirely; card testing hides from an account counter but not a device one.
Shared infrastructure. Many accounts funneling through one device, IP, or card is the pattern velocity is built to expose.
Legit spikes. Paydays, sales, and viral moments cause real bursts; tune thresholds so you do not decline good customers.
Window blind spots. A slow attack over days evades a one-minute counter; run long windows alongside short ones.
Quick questions
### What is the difference between velocity and a simple rate limit?
A rate limit usually caps one action per one key. Velocity checks are broader: they can count many action types across many entities and windows and feed a risk decision, not just a hard cap.
### Which window should I use?
It depends on the attack. Card testing needs seconds to minutes; application rings and bust-outs play out over days. Most programs run several windows in parallel per entity.
### How do fraudsters beat velocity checks?
By staying under the limit: rotating IPs and devices, aging accounts, and pacing attempts. Aggregating across multiple keys makes this much harder, since evading one counter still trips another.
### Do velocity checks cause false positives?
They can, when real life produces bursts, such as payday or a sale. Good tuning uses observed traffic to set thresholds and often pairs a velocity trip with other signals before acting.
### Are velocity checks a rule or a model feature?
Both. They work as standalone rules and also as powerful inputs into a risk model, where a count over a window becomes a feature.
### What entities should I count across?
At minimum device, IP, email, card, account, and shipping address. The right set depends on your product, but broad coverage closes the gaps a single-key counter leaves open.
Go deeper
NIST Digital Identity Guidelines (SP 800-63) ↗ — The US standard for identity proofing and authentication assurance levels.
FTC Consumer Advice: Scams ↗ — US consumer guidance on current scams and fraud, and how to report them.
