Alpha decay when models are cheap
Every edge has a half-life. What changed is that the tooling to find and copy an edge got cheap, so the half-life got shorter — and planning for that is part of the design.
Vizanix engineering · about the author
- SECTION
- Markets and AI
- PUBLISHED
- 2026-08-29
- CHAPTERS
- 5
- READ NEXT
- 3
- LANGUAGE
- written in English
An edge decays for exactly one reason: other people find it and act on it. Everything else — regime change, liquidity shifts, venue rule changes — is a second-order version of the same thing.
What is different now is that the discovery loop is faster. Cheap compute, commodity models, public data and a large population of people running the same experiments mean the time from “this works” to “this is priced in” has compressed.
Decay is not uniform
| Edge type | Typical persistence | Why |
|---|---|---|
| Simple technical pattern | Weeks to months | Trivial to discover and copy |
| Public factor / anomaly | Months to a couple of years | Known but capacity-limited |
| Microstructure execution | Longer, but infrastructure-gated | Requires spending, not insight |
| Proprietary data | As long as the data stays proprietary | Not reproducible without it |
| Capacity-constrained niche | Long | Too small to attract the capital that would kill it |
The pattern: edges based on information anyone can derive decay fastest. Edges based on things people will not build or cannot access persist.
Measure it, do not assume it
Most operators discover decay from the equity curve, which is the slowest possible detector. Better instruments exist and they are cheap:
- Rolling signal quality. Track the correlation between prediction and realised outcome over a moving window. This moves before P&L does.
- Hit rate by cohort. Split trades by month and compare. A gradual slide is visible here and invisible in a cumulative curve.
- Realised versus expected edge. If you predicted 12 bps and captured 4, you have either a slippage problem or a decay problem, and the split tells you which.
- Time-to-fill on limit entries. Getting filled faster than before often means someone is now in front of you.
Design for a finite lifetime
If you accept that the edge will die, several decisions change:
- Amortise the build over a realistic horizon. A six-month engineering effort for an edge with a nine-month half-life is a bad trade even if the edge is real.
- Separate strategy from infrastructure. The execution layer, risk engine, data pipeline and monitoring outlive any particular signal. Build them once; treat strategies as replaceable modules. This is the core argument in bot architecture.
- Keep the research loop running. An operation with one strategy has a deadline. An operation that can validate a new hypothesis in a week has a process.
- Prefer edges you can maintain. An edge that requires continuous data collection or infrastructure investment is a moat precisely because it is annoying.
The uncomfortable arithmetic
If an edge has a twelve-month half-life and the build takes four months, you have eight months of decaying returns to cover the cost and produce a profit. That can work — but it needs to be the plan rather than a surprise.
This is why our honest advice on a first project is usually to spend less than the client expected: validate cheaply, deploy small, and put the saved budget into the pipeline that lets you do it again. The second strategy is much cheaper than the first if the infrastructure was built to be reused.
What does not decay
Execution quality. Risk discipline. A data pipeline nobody else has. The ability to test a hypothesis honestly and quickly. Knowing when not to trade.
None of those are edges in the strict sense — they do not predict anything. They are the things that determine whether you are still operating when the next edge shows up, which over a long enough horizon matters more than any individual signal.
This article describes engineering practice. It is not investment advice. Vizanix develops software and does not promise trading returns.