"Vol-forecast research — does TimesFM width earn its keep? (2026-09-20)"

Follows reports/timesfm_edge_hunt.md. The risk tool (production/vol_forecast.py) is only justified if the model width beats free volatility estimates (trailing realized vol, HAR). This is the head-to-head. All PIT-safe; expanding-window OOS calibration (fit on prior dates only).

Scripts: validation/timesfm_vol_research.py (+ timesfm_quantile.py --universe crypto). Reports: timesfm_vol_research_equities.md, timesfm_vol_research_crypto.md.

#Equities (78 monthly dates × 50 names)

21-session OOS accuracy (lower QLIKE/log-MSE better):

• Width is the worst standalone; HAR is best. Free trailing vol ≥ width on magnitude accuracy.
• Cross-sectional per-date rank-corr: width +0.631, trail21 +0.626, HAR +0.659 (CIs overlap) — width ≈ trailing, HAR best.
• But within prior-vol terciles, width beats trailing: low 0.312 vs 0.270, mid 0.290 vs 0.169, high 0.488 vs 0.422 (HAR ≈ width).
• Incremental joint regression log-vol ~ log(width)+log(trail21): b_width +0.41 (t=16.7), date-clustered CI [+0.33,+0.49] — width adds information beyond trailing, robustly.
• Sizing head-to-head (mom top-decile): equal +2.59%, inv_width +2.13%, inv_trail21 +2.04%, inv_HAR +2.03% (all ≤ equal; maxDD −32.5% vs ~−30%). No sizing edge from any vol forecast.

#Crypto (42 monthly dates × 8 names)

• Cross-sectional per-date rank-corr: width +0.415 < trail21 +0.555 < HAR +0.604 — width is the worst here.
• Incremental b_width +0.41 (t=2.9) but clustered CI includes 0.
• Sizing degenerate (8 names → 1-name book); not informative.

#Verdict

The width→vol relationship is real but not superior to free estimates. HAR/trailing match or beat width on magnitude accuracy in both asset classes; width edges trailing only cross-sectionally within vol regimes (equities) and in a joint model, but never converts to a sizing/Sharpe improvement, and is outright worse for crypto. So:

• Do not adopt width-based sizing/vol-targeting. If a vol forecast is wanted, HAR/trailing is as good and costs nothing.
• production/vol_forecast.py stays as a fail-open framework (pure, tested, observe-only) with the blend API intact for future data; its default should lean on trailing/HAR, not the model width. No sleeve wiring.
• Width's one defensible use is a second opinion in the equity cross-section (mid-vol regime); not enough for a vote.

#Follow-ups (not adopted)

1. Vol-scaled stops (stop distance = k×forecast_vol) vs fixed stops — a different use of a vol forecast, untested.
2. Rolling/EWMA and GARCH vol benchmarks (stronger than HAR) before ever claiming any model-based vol edge.

#Benchmarks + jumps + skew (2026-09-20) — closes the question

validation/timesfm_vol_bench.py (timesfm_vol_bench_{equities,crypto}.md). GARCH unavailable (no arch package); EWMA (RiskMetrics) is the adaptive free benchmark. Expanding-OOS calibration.

Equities (n=2700):

A free one-line EWMA(0.97) beats the model width on every metric (and beats HAR). Crypto is the same (EWMA94+width marginally best; width alone worse). So follow-up (2) is answered: no model-based vol edge exists — don't fit EWMA/GARCH to chase it, the answer is already in.

Timeliness (B): anticipating a vol increase (AUC) — every estimator scores < 0.5 (width 0.425 equities / 0.465 crypto; trail21 0.285 / 0.330). That is vol mean-reversion (high current vol → vol falls), not anticipation. Width is merely less mean-reverting than trailing — not a jump predictor.

Predictive skew (C): the quantile fan's skew has no directional IC (equities −0.047, CI spans 0; crypto −0.007). p_up likewise null.

#Final verdict (vol angle closed)

No TimesFM-width vol edge over free estimates, no jump timing, no skew signal — in either asset class. If a vol forecast is ever wanted for risk sizing, use EWMA/HAR (free, superior, one line). production/vol_forecast.py remains an observe-only framework only; it must not be sold as a TimesFM win.