Anomaly Detection in Time Series

A trading venue reports 50,000 orders in an hour on a normal Tuesday and 50,000 orders in an hour on the day of a major index rebalance. The second number, identical to the first, is completely unremarkable on rebalance day and would be a serious anomaly — a possible feed outage or algo malfunction — on an ordinary Tuesday if the venue usually sees 500,000 orders that hour. A raw threshold ("flag if orders exceed X") can't capture this: what counts as anomalous depends entirely on what the series is expected to look like at that point, which itself might depend on time of day, day of week, or a broader trend.

Anomaly relative to a model, not a fixed line

Time-series anomaly detection almost always works in two stages: first, build a model of what "normal" looks like for this series at this point in time (a forecast, a seasonal baseline, a smoothed trend); second, flag points where the actual observation deviates from that model's prediction by more than expected, given the model's own uncertainty. A common approach fits a forecasting model that outputs both a predicted value $\hat{y}_t$ and a predicted spread $\hat{\sigma}_t$, then flags a point as anomalous when

$$\left| \frac{y_t - \hat{y}_t}{\hat{\sigma}_t} \right| > k ,$$

for some threshold $k$ (often 3 or so). In plain English: how many of the model's own predicted standard deviations away from expected is this point, given everything the model knows about typical patterns at this time — not how large the raw number is in isolation.

Point anomalies versus contextual and collective anomalies

A point anomaly is a single observation far from what's expected — one order-count spike. A contextual anomaly is a value that's normal in isolation but wrong given its context — 50,000 orders is a perfectly ordinary count, but wrong for a quiet Tuesday. A collective anomaly is a run of individually unremarkable points whose pattern together is wrong — order flow that stays flat for two hours when it should show its usual intraday U-shape, even though no single hour looks extreme. Most real monitoring systems care most about contextual and collective anomalies, since point anomalies alone miss the far more common failure mode of a feed quietly degrading rather than spiking obviously.

Worked example: flagging a feed problem

Suppose a market-data feed's message rate is modeled with an expected value and standard deviation that vary by time of day: at 10am the model expects 200,000 messages/minute with a standard deviation of 20,000. At 10am today the feed reports 90,000 messages/minute. The standardized deviation is

$$\frac{90{,}000 - 200{,}000}{20{,}000} = -5.5 ,$$

well beyond a typical threshold of $k=3$, so this point is flagged as anomalous — not because 90,000 is a small number in any absolute sense (it might be a perfectly typical rate at 3am), but because it's dramatically below what's expected specifically at 10am, which is exactly the kind of drop that indicates a partial feed outage rather than a genuine lull in trading.

Generate paths above and imagine one point suddenly jumping off the mean-reverting band — anomaly detection is formalizing exactly that visual judgment, using the model's own expected level and spread rather than eyeballing a chart.

What this means in practice

In trading infrastructure, anomaly detection runs on order flow, latency, and price-feed statistics to catch outages and bad ticks before they corrupt a strategy's inputs; in research, it's used to flag suspicious data points for manual review before they're allowed to influence a backtest or a live signal.