Growth is a good problem to have, but it breaks your fraud detection in ways that are not immediately obvious. The signals you built when you were processing 10,000 transactions a month start behaving differently at 200,000 transactions a month, not because the underlying fraud risk changed, but because the statistical context around your signals changed.
This is one of those places where a fraud team can be doing everything right, watching the same metrics they always watched, and still end up either over-blocking legitimate customers or missing a growing fraud pattern. The signals are the same. What changed is what they mean.
Absolute Counts vs Rates
The most common manifestation of this problem is velocity-based rules configured as absolute counts rather than rates. "Flag any account that makes more than 5 transactions in 24 hours" is a reasonable rule when 5 transactions represents an outlier in your customer base. When your customer base grows to include power users who naturally make 8-10 small transactions daily, that same rule generates false positives at a rate that scales with your growth rather than with your fraud rate.
The fix seems obvious in hindsight: convert absolute velocity rules to rate or percentile rules. Instead of "more than 5 transactions in 24 hours," use "more than the 99th percentile of 24-hour transaction count for accounts at this age and activity level." The threshold floats with your population rather than staying fixed.
But the less obvious version of the same problem occurs in ML model features. If your model was trained at a time when the 95th percentile transaction count per account per day was 4, and your current 95th percentile is 8, the model's internal sense of what constitutes "high activity" is now calibrated to a distribution that no longer describes your platform. The model has not changed, but the meaning of the feature values it is receiving has changed substantially.
The Law of Large Numbers and Anomaly Detection
Anomaly detection depends on having a stable baseline from which to measure deviation. At low transaction volumes, any day with unusual activity is visible precisely because the volume is small enough that individual unusual events are statistically distinguishable from random variation.
At high volumes, the law of large numbers creates its own signal suppression problem. If your platform processes 5,000 transactions per hour and your fraud rate is 0.3%, you should expect approximately 15 fraudulent transactions per hour. The statistical variance around that expectation means that observing 18 fraudulent transactions in an hour is well within normal variation, not an anomaly. The same absolute count of 18 fraudulent transactions when you were processing 500 transactions per hour would have been a 1.2% fraud rate and would have been visible immediately.
High-volume operations need anomaly detection methods that account for the expected statistical dispersion at their volume level, not methods that look for absolute count deviations. A z-score approach that normalizes fraud counts against the expected distribution for your current volume is more appropriate than a simple threshold or alert rule.
Population Mix Shifts and Their Effect on Signal Meaning
When you grow, you grow by acquiring new customers. New customers are a different population than your established customers. This seems obvious, but its implications for fraud signal interpretation are significant and frequently underestimated.
Your behavioral baseline is built from your established customer population. New customers, by definition, have no baseline. Their first transactions look different from established accounts doing their first transaction on a new device, for example, because the new-account context itself is different from the established-account context. A fraud model trained primarily on data from your established customer population will systematically mishandle new-account scoring because the features it relies on are not well-defined for new accounts.
Rapid growth amplifies this. If 40% of your monthly transaction volume comes from accounts less than 30 days old, you have a model that is scoring a large fraction of your transactions in a population regime it was not well-trained to handle. The model will produce scores, but their calibration against actual fraud probability in the new-account population may be substantially worse than the headline AUC suggests.
One practical approach is to maintain separate scoring tracks for new accounts (less than 30 or 60 days old, depending on your product) with features and thresholds calibrated specifically to the new-account fraud risk profile. New accounts have different fraud dynamics: the fraud that targets new accounts is concentrated in account setup and first-few-transactions, not in established behavioral patterns. Treating new and established accounts identically in your scoring model averages over two very different risk profiles.
Feature Drift in High-Volume Growth Phases
Features that were predictive at launch may become less predictive as your platform matures, not because the underlying relationship between the feature and fraud has changed, but because the feature distribution in your legitimate population has shifted.
A clear example: early in a platform's life, using an anonymizing VPN service was a mild positive fraud indicator because a disproportionate share of VPN users in the early-adopter cohort correlated with unusual transaction patterns. As the platform matured and VPN usage became more mainstream in the general population, this same feature became less predictive. The platform's VPN-using legitimate customer base grew faster than its VPN-using fraudster base, diluting the signal.
Feature drift is slow and hard to detect without explicit monitoring. The standard approach is to track feature importance scores across rolling model evaluation windows. When a historically important feature shows declining importance across multiple evaluation windows, it is a candidate for review: is the underlying relationship changing, or is the feature distribution shifting in a way that is suppressing the signal?
The Volume-to-Labeled-Data Ratio Problem
Fraud models require labeled training data. Fraud labels take time to materialize: chargebacks come in 30-90 days after the fraudulent transaction, disputes take time to process, manual review decisions accumulate slowly. When you are growing fast, your labeled data always lags your current transaction volume. At 10x growth over 12 months, your labeled training set may be dominated by transaction patterns from when you were 3x smaller.
This creates a structural latency in your model's awareness of current fraud patterns. A model trained on data from your 50,000-transaction-per-month phase, applied to a platform now processing 500,000 transactions per month with a different customer mix and different fraud attack surface, is an increasingly poor fit. Not dramatically poor on any individual transaction, but systematically miscalibrated in ways that compound.
The practical implication is that model refresh frequency should scale with your growth rate. A team growing at 20% month-over-month needs to retrain or at minimum recalibrate more often than a team at steady state. The six-month retraining cadence that worked at a stable volume regime is likely not sufficient during a high-growth phase when the underlying data distribution is changing substantially between refreshes.
What Stable Metrics Actually Indicate During Growth
There is a specific failure mode worth flagging directly: stable fraud metrics during a period of rapid growth may indicate that your detection is not scaling with your actual fraud exposure, not that fraud is proportionally under control.
If your fraud rate stays flat as your volume triples, you should ask whether your detection methods are capturing the same proportion of fraud they always captured, or whether the absolute fraud volume is growing in proportion to your legitimate volume but your detection methods are catching less of it (which makes the rate look stable even as your losses grow in absolute terms). Stable metrics are not always good news. They can also indicate that your detection is not scaling with your volume, and that the portions of your fraud population you are missing are growing faster than the portions you are catching.
