A signal that works in a backtest has only solved half the problem. The other half is computing that same signal live, on streaming market data, fast enough and correctly enough to act on — without accidentally peeking at information that would not have been available at the moment of decision. This guide covers how to take a researched signal into real-time production: the streaming architecture, the latency budget, and the correctness checks that keep live behaviour faithful to the backtest.
From batch research to a live stream
In research, a signal is usually computed in batch: load the whole history, compute features over the entire series, evaluate. In production, the data arrives one event at a time and the signal must update as it goes. This shift from batch to event-driven processing is the defining change.
The practical consequence is that features are maintained incrementally. A rolling mean, a rolling standard deviation, or an exponentially-weighted moving average is updated from its previous state and the new observation, rather than recomputed from scratch on every tick. Done well, the live feature value at any moment is identical to what the batch computation would produce up to that timestamp — which is exactly the property you want.
The latency budget
"Real-time" does not mean "as fast as possible" — it means "fast enough for this strategy." The chain from a market event to a placed order has several stages, and the acceptable total time differs by orders of magnitude across strategies:
- Feed handling: receiving and decoding the market-data update.
- Feature update: folding the new event into the running state.
- Signal and decision: evaluating the signal and the resulting target position.
- Risk check and order: validating the order and sending it.
For a latency-sensitive strategy competing on speed, this whole chain must complete in microseconds, which drives hardware and language choices. For a strategy that rebalances daily, the same chain has a budget of seconds or minutes, and engineering effort is far better spent on correctness than on shaving microseconds. Knowing which regime you are in prevents both under-engineering a fast strategy and massively over-engineering a slow one.
Correctness: the lookahead trap, live
The most dangerous bugs in live signal processing are silent ones that inflate performance by using information from the future. They are easy to introduce when batch research code is hastily adapted to streaming. Guard against them deliberately:
- Use only known-at-the-time data: a bar is only complete after its close; a fundamental figure is only usable after its actual release time, not its period-end date.
- Handle late and out-of-order events: network reality means ticks can arrive out of sequence. The system must decide its policy explicitly rather than assuming perfect ordering.
- Respect corporate actions: splits, dividends, and symbol changes must be applied at the right moment so prices remain comparable.
- Synchronise clocks: when ordering of events matters, inconsistent timestamps across sources create phantom signals.
Backtest–live parity
A frequent and expensive failure is the strategy that made money in simulation but loses in production because the two run different code. The defence is parity: share as much logic as possible between backtest and live so they cannot drift apart.
- One code path: the same signal-computation code consumes either historical events (in simulation) or live events (in production), driven by the data source rather than by separate implementations.
- Replay testing: feed recorded live data back through the live system and confirm it reproduces the expected signals and orders.
- Realistic simulation: the backtest must model the same costs, latencies, and fills the live system will face, or parity in code is undone by optimism in assumptions.
Robustness and safety
Live systems operate without a human watching every tick, so they must protect themselves. The essential safeguards:
- Pre-trade risk checks: every order is validated against position limits, exposure caps, and sanity bounds before it leaves the system.
- Throttling and backpressure: when data arrives faster than it can be processed, the system degrades gracefully instead of falling behind or crashing.
- Circuit breakers and a kill switch: automatic halts on abnormal conditions — a data outage, runaway losses, or implausible signal values — and a clear manual override to stop everything.
- Data-quality monitoring: stale feeds, missing ticks, and frozen prices are detected and treated as faults, not traded on.
Monitoring in production
Once live, the job shifts from building to watching. Track the live information coefficient and realised performance against backtest expectations, and alert when they diverge — a sign the edge is decaying or that something in the pipeline has broken. Monitor latency, fill quality, and data integrity continuously. The goal is to learn that a signal has stopped working from your dashboards, not from your monthly statement.
Conclusion
Taking a signal real-time is an exercise in faithful translation: the live system must compute exactly what the research promised, using only information available at each instant, fast enough for the strategy's horizon, and with safety rails that assume things will eventually go wrong. The teams that succeed obsess less about raw speed than about point-in-time correctness and backtest-live parity — because a fast signal that quietly cheats or diverges from its simulation is worse than no signal at all.