What is the difference between recurring fraud and velocity abuse in crypto?

Recurring fraud is when a fraudster returns after a successful scam and tries to exploit the same platform again. Velocity abuse is a specific tactic where the attacker exploits approval processes to get accepted as many times as possible. Both aim to bypass trust controls, but recurring fraud is about repeat targeting, while velocity abuse is about repeated attempts at scale.

How recurring fraud differs from velocity abuse

recurring fraud and velocity abuse both exploit trust decisions, but they fail at different points in the abuse chain. Recurring fraud is a pattern of return targeting after a prior successful scam. Velocity abuse is about repeated submissions at speed, often to overwhelm approval logic, exploit lenient review thresholds, or farm multiple accepted attempts from the same actor or infrastructure.

The practical difference matters because the defensive question changes. Recurring fraud asks whether a previously successful fraudster can come back under a new account, device, payment method, or profile. Velocity abuse asks whether the system is allowing too many attempts, too quickly, across identities or sessions, so the attacker can exploit process volume rather than one isolated compromise.

In crypto, the same user journey can be affected by both. A wallet, exchange, on-ramp, or rewards platform may see repeat abuse from a known bad actor, but the specific pattern tells you whether to focus on re-entry controls, velocity thresholds, or both. Treating them as the same problem usually leads to the wrong control response.

Where the control failure occurs

Recurring fraud is usually a trust-reputation failure. The platform has already been harmed once, but the attacker returns because detection, device reputation, account history, or identity correlation did not persist strongly enough to block re-entry. The core issue is that the platform did not make prior abuse durable in later decisions.

Velocity abuse is a control-rate failure. The attacker is not mainly relying on a single successful deception, but on the ability to repeat attempts faster than human or automated review can keep up. That makes thresholds, burst limits, retry rules, queue design, and manual review capacity part of the security boundary. OWASP API Security Top 10 is a useful reference point when rapid repeated requests are used to exploit business logic or approval pathways.

In practice, recurring fraud often shows up as the same scam objective against a familiar target, while velocity abuse often shows up as many near-identical attempts that succeed only because volume creates blind spots. One is primarily about persistence of the fraudster’s relationship with the platform, the other about exploitation of throughput and acceptance rules.

Why the distinction changes investigation and response

When the problem is recurring fraud, investigators should look for linkage across attempts, such as shared devices, funding sources, wallets, IP ranges, addresses, referral patterns, or reuse of behavioural signals. The response should improve correlation and re-entry blocking, not just add a stronger first-pass approval rule.

When the problem is velocity abuse, the better question is whether the platform can be gamed by scale. If the same actor can submit many applications, transactions, or verifications before a defender reacts, the control is probably too slow, too permissive, or too easy to reset. That is where rate limits, step-up checks, queue controls, and tighter approval sequencing matter most. FinCEN is relevant for crypto businesses that must also align fraud patterns with suspicious activity monitoring and reporting obligations.

For crypto teams, the response should be driven by the abuse pattern, not just the outcome. A repeated scammer and a high-speed approval abuser can produce similar losses, but they demand different evidence, different detection logic, and different operational fixes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API6 — Unrestricted Access to Sensitive Business Flows	Velocity abuse exploits repeated approval flows at scale.
Recommendation — Throttle and gate repeated business-flow attempts that should not be mass-submitted.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Recurring fraud and velocity abuse both need repeat-pattern correlation across events.
Recommendation — Correlate repeated abuse signals and review them as a linked pattern, not isolated events.
CIS Controls v8	CIS-17 — Incident Response Management	Both abuse patterns require a clear response path once repeat misuse is identified.
Recommendation — Use defined fraud-response playbooks to contain repeat abuse and preserve evidence.

Practitioner Guidance

What to verify: Determine whether the bad actor is reusing a known fraud relationship or flooding the system with fresh attempts. If the same entity returns, focus on linkage and reputation persistence; if attempts are high-frequency, focus on throughput controls and approval bottlenecks.

Decision rule: If loss comes from the same attacker coming back, strengthen cross-session and cross-account correlation. If loss comes from many attempts in a short window, tighten velocity thresholds, deduplication, and escalation rules before increasing manual review headcount.

Common mistake: Teams often tune only one side of the problem. Blocking a single account will not stop recurring fraud if the attacker can re-enter cheaply, and slowing review will not stop velocity abuse if the attacker can still brute-force approval volume.

Practitioner takeaway: The key judgement is whether you are defending against repeat trust abuse or against scale-driven approval abuse, because each one fails a different control assumption and needs a different detection strategy.