Market Data Engineering, Tool
Timestamp Lag Explorer
Investment Education, Research & Tools for Smarter Decisions.
Exchange timestamps record when an event happened at the matching engine. Receipt timestamps record when your system received the message. The gap between them, the network latency, determines how stale your data is when your signal fires. This tool visualizes that gap and shows how it affects signal timing relative to your strategy's holding period.
Direct Answer
A timestamp lag explorer visualizes the gap between an exchange timestamp (when an event happened at the matching engine) and a receipt timestamp (when your system received the message), and shows how that network latency affects signal timing relative to a strategy's holding period. The visualization makes stale-data risk concrete instead of abstract. It matters most for short-holding-period strategies, where a few milliseconds of lag can flip a signal's edge.
Latency Parameters
Time from matching engine to feed handler receipt. SIP feeds: 1-10 ms. Direct exchange: 0.05-1 ms.
Internal processing latency after receipt. Parsing, indicator update, signal evaluation.
Time from signal fire to order reaching the exchange. Network + order router latency.
Shortest holding period the strategy is designed for. E.g., 500 ms for a momentum burst, 3600000 ms (1 hr) for intraday swing.
Systematic offset between your clock and exchange clock. NTP: 1-50 ms. PTP: <0.1 ms.
Concepts Behind This Tool
Three Timestamp Types
- Exchange timestamp (T_exch): When the matching engine processed the event. The authoritative record of when a trade or quote occurred. Used by regulators for audit purposes.
- Receipt timestamp (T_recv): When your feed handler received the message. T_recv − T_exch = network latency + any feed processing delay. Always positive (you receive after the event).
- Processing timestamp (T_proc): When your signal computation actually ran. T_proc − T_recv = internal processing latency. The sum T_proc − T_exch is total end-to-end data staleness.
Why It Matters for Backtesting
A backtest that uses exchange timestamps assumes you acted exactly when the event occurred. In reality, by the time the signal fires, the market has already moved by T_proc − T_exch milliseconds. For a strategy with a 500 ms holding period, a 5 ms total latency represents 1% of the decision window, marginal. For an ultra-short-term strategy with a 50 ms holding period, the same 5 ms latency represents 10% of the window, significant. Use the "latency as % of holding period" metric to gauge whether your strategy's holding period is long enough to be robust to your actual latency.
Clock Skew vs Latency
Clock skew is a systematic offset between your system clock and the exchange's reference clock. If your clock is 5 ms ahead of the exchange clock, a trade that happened at 09:30:00.000 at the exchange will appear in your logs with T_exch = 09:30:00.005. This inflates measured latency and can cause "receipt before exchange" anomalies if your clock is ahead. NTP reduces skew to ±1-50 ms. PTP reduces it to ±100 ns. GPS oscillators achieve <1 ns but require hardware investment.
FAQ
Which of the three timestamps should be treated as authoritative?
The exchange timestamp is the authoritative record of when an event occurred, which is why regulators and audit processes use it. The receipt and processing timestamps describe your own system and are authoritative only about it. The practical rule is that event ordering and reconstruction of what happened use exchange time, while any claim about what your system could have known at a moment uses processing time. Mixing the two is the mechanism behind most accidental lookahead in a backtest.
Why would a receipt timestamp appear earlier than the exchange timestamp?
Physically it cannot, so the appearance means the two clocks disagree. A local clock running ahead of the exchange reference produces receipt times that look earlier than the event they describe, and the size of the anomaly is a direct measure of the skew. Treating any negative measured latency as a clock problem rather than a data problem, and correcting the offset before drawing latency conclusions, avoids building a latency profile that is partly an artefact of an unsynchronized clock.
What does latency as a percentage of holding period tell you?
It converts an absolute delay into a measure of how much of the decision window it consumes, which is what determines whether the delay matters. The same few milliseconds is negligible against an hour-long hold and substantial against a fraction of a second. Reading the ratio rather than the raw figure is what makes latency comparable across strategies, and a strategy whose ratio is uncomfortably high has a design problem that reducing latency may not fully solve.
Does the explorer model latency variance or only a fixed value?
The inputs are single figures, so the output describes one scenario rather than a distribution. Real latency is variable and the tail matters more than the average, because the slowest messages tend to arrive during exactly the volatile periods when timing is most consequential. A practical way to use a single-value model is running it several times with a typical figure and with a pessimistic one, and treating the gap between the two results as the range the strategy needs to tolerate.
How should the exchange to feed handler latency be estimated for a real setup?
By measuring rather than assuming. Subtracting the exchange timestamp from the receipt timestamp across a large sample of live messages gives the actual distribution, provided the clocks are synchronized well enough for the difference to mean anything. The figures suggested as guidance in the inputs describe typical ranges for feed categories and are a starting point, not a substitute. Measuring across different times of day is worthwhile because the profile usually differs between quiet periods and the open.
Does improving clock synchronization make a strategy faster?
No. Synchronization changes how accurately delay can be measured, not how long anything takes. A poorly synchronized system may report latency that is too high or too low, and can produce impossible orderings, but correcting the clock leaves the physical path unchanged. The value is that latency measurements, event ordering across systems, and audit records all become trustworthy, which is a prerequisite for deciding whether a latency reduction effort is worth undertaking.
How should this result change a backtest rather than the live system?
The usual application is delaying the point at which a backtest is allowed to act. If total staleness is measured at a given figure, a simulation that acts on the bar or tick timestamp is assuming information it would not have had, so shifting the decision point forward by the measured delay produces a more honest result. Where that shift materially degrades performance, the strategy depends on timing it cannot achieve, which is information the original backtest concealed.
Where does order acknowledgement latency fit into this picture?
It sits after the signal to order submission input rather than inside it. Submission latency covers getting an instruction to the venue; acknowledgement latency is the venue response coming back, and fill reporting can be later still. For a strategy that acts once and holds, the outbound path is what determines whether the intended price is available. For anything that reacts to its own order state, the round trip matters and the model here covers only half of it.
What does this tool deliberately not model?
Queue position and whether an order would actually have executed, venue matching behavior, market impact, latency variance and its tails, the effect of message bursts on processing time, and any broker or risk system delay between submission and the venue. It is a way to reason about staleness relative to a holding period, not an execution simulator. Conclusions about achievable fills need a model that represents the order book rather than a latency budget.