Velocity rules are the first fraud detection mechanism most teams build, and for good reason: they are straightforward to implement, easy to explain, and effective against concentrated attacks. If someone is running 200 transactions per hour from the same IP, a velocity rule catches it.
The problem is that chargeback cascades, the fraud patterns that actually accumulate into large loss events over time, are not concentrated attacks. They are slow, distributed, and below the velocity thresholds designed to catch concentrated attacks. By the time a cascade becomes visible in the chargeback data, the damage is done. The transactions are settled, the funds are extracted, and the chargebacks start arriving weeks later.
How a Chargeback Cascade Forms
A chargeback cascade typically starts with a period of successful fraudulent activity that goes undetected. Fraud operations that survive long enough to become cascades have learned to stay below the detection thresholds. They spread transaction load across time, across different account identities, and across different destination merchants to avoid triggering velocity rules.
The cascade starts arriving when cardholders notice unauthorized charges, or when their banks run automated fraud detection and issue chargebacks on their behalf. There is an inherent lag built into this: a cardholder who received their monthly statement might not notice a $40 unauthorized charge for three to six weeks after the transaction date. Card network dispute windows allow cardholders up to 120 days from transaction date to file a dispute for some reason codes.
This lag creates a compounding problem. Fraudulent transactions approved in month one start generating chargebacks in months two and three. If the fraud operation is still active in month two, it is generating a second wave of future chargebacks simultaneously with the first wave arriving. A platform that does not detect the fraud until the first chargebacks arrive is already two waves into a cascade.
Why Velocity Rules Arrive Too Late
Standard velocity rules measure activity in a time window: more than N transactions from account X in Y hours triggers a flag. This is effective for detecting the beginning of a concentrated attack. It does not detect fraud that is distributed across many accounts, many time windows, or many low-volume events that individually stay below the threshold.
A fraud ring operating 40 accounts simultaneously, each running 3 to 5 transactions per day, generates 120 to 200 transactions per day across the ring without any individual account triggering a per-account velocity rule. If your velocity rules evaluate individual accounts, you will not see this pattern. You need to either evaluate the ring as a unit (which requires identifying that these accounts are part of a ring, a graph problem) or detect the pattern at the platform level through aggregate metrics.
The platform-level signal is the chargeback rate trend. A rising chargeback rate, or a rising rate of chargebacks on transactions from a specific channel or merchant category, indicates that a fraud pattern has been running for long enough that victims are filing disputes. That signal is real, but it is retrospective: it tells you about transactions that were already approved and settled. The fraud is confirmed only after it has run.
Leading Indicators Before Chargebacks Arrive
The detection question is: what signals precede the chargeback wave and are detectable at or near transaction time?
Authorization decline patterns are the most accessible leading indicator. Before a fraud operation reaches a phase of successful approvals, it typically goes through a testing or calibration phase where it runs transactions that get declined, probing which card numbers work and which merchants have lower friction. An elevated authorization decline rate on transactions from a specific channel or source segment, without a business explanation, often precedes the approval phase of a fraud operation.
Account creation velocity combined with rapid transaction initiation is another leading indicator. Fraud accounts are typically created and used within a short window because the identity they are based on has a limited useful life before it is flagged or exhausted. An unusual cluster of account creations followed by transaction initiation within hours of creation, across accounts that share device or network infrastructure, is structurally different from organic account creation patterns even if no individual account triggers a velocity rule.
Transaction amount distribution shifts can also be informative. Fraud operations often have characteristic transaction amount distributions that differ from organic customer distributions in the same product category. A shift in the transaction amount distribution for a specific merchant category or product type, even if the aggregate volume looks normal, can indicate that a new population has started transacting in a way that does not match the established baseline.
The Time-to-Detection Gap and What It Costs
For most digital-finance platforms, the time from when a fraud operation begins to when it is detected through chargeback monitoring is weeks to months. During that window, every fraudulent transaction that is approved represents a future chargeback. Settlement is immediate; the cost arrives later, and at scale it arrives with interest: chargeback fees, dispute processing overhead, potential card network penalties if the rate exceeds thresholds, and the operational burden of the dispute process itself.
A crypto on-ramp that goes three weeks before detecting a coordinated synthetic identity operation might process $180,000 to $400,000 in fraudulent purchases before the chargeback wave becomes visible, depending on transaction volume and fraud operation scale. That is a realistic range for a growing platform that is under active attack. The fraud detection question is how much of that amount can be prevented by detecting the operation two weeks earlier rather than when the first chargebacks arrive.
The value of earlier detection is not symmetric. Preventing 80% of those transactions by identifying the operation earlier prevents 80% of the loss. Preventing 50% prevents 50%. The loss prevention value scales linearly with how much earlier the detection fires. That makes even modest improvements in leading-indicator detection worth significant engineering investment.
Combining Velocity with Cohort Signals
The detection approach that works better than pure velocity rules is combining velocity monitoring with cohort-level anomaly detection. Instead of asking "has this account exceeded its individual transaction limit," ask "is the aggregate behavior of this cohort of accounts, accounts with similar creation dates or similar behavioral characteristics, consistent with the established baseline for similar cohorts?"
Cohort-level anomaly detection can surface patterns that individual-account velocity rules miss because it aggregates signal across a population that the fraud operation is creating in bulk. The ring's accounts are individually unremarkable, but as a population their collective behavior has characteristics that differ from genuine customer cohorts: narrower creation-date distributions, similar transaction initiation timing, correlated transaction amounts, shared network infrastructure that appears in IP or device features.
This is the direction fraud detection moves when velocity rules alone are insufficient. It requires more sophisticated feature engineering and a model that can evaluate cohort properties rather than just individual account properties. The operational investment is higher. But for platforms where fraud losses are concentrated in cascade events, the detection value of catching a cascade early more than justifies the investment.
