Signal timestamps and execution delay

Published October 6, 2026

When was the data behind a signal available, and when could its order first execute?

For each signal, record when its last input became observable, calculation time, order submission time and earliest executable quote. Compare these timestamps with the actual fill path; a documented Tick replay contract alone does not establish graph execution.

The Tick replay contract is documented, but executable graph behavior still needs a tested run before being described as available.

Each simulated trade has three times: when its input data closed, when its signal was computed and when its order could fill. A fill dated before the data that produced it inflates the result.

Three timestamps per trade

The bar timestamp marks the interval that a price bar covers; providers label bars by their open time or by their close time, and the convention has to be read before series are aligned. The signal timestamp is the earliest moment at which the inputs were complete, usually the bar close. The execution timestamp is when an order could reach the market and receive a fill.

Perold's implementation shortfall compares a paper portfolio traded at decision prices with the portfolio actually executed; the delay between signal and fill is one source of that gap. Lo and MacKinlay give an econometric analysis of nonsynchronous trading, the case where prices stamped with a common time were last traded at different moments.

Earliest fill time = signal time + computation and transmission latency

The one-bar shift

A common causal convention for bar data computes the signal at the close of bar t and fills the order at the open of bar t + 1. TradingView describes this default for Pine Script strategies: an order placed when a bar closes can be filled by its broker emulator at the open of the following bar at the earliest. Its strategy settings can set the order delay on closed bars to zero ticks, which permits a fill at the close of the signal bar.

“each new order in the strategy’s simulation has a one-tick delay by default.”
TradingView (n.d.), Strategies

A same-bar fill, calculated

Suppose a daily rule buys when the close exceeds 100. Monday closes at 101, which triggers the signal. Tuesday opens at 103 and closes at 104, where the position is sold.

A fill at Monday's close returns 104 / 101 - 1 = 2.97%. A fill at Tuesday's open returns 104 / 103 - 1 = 0.97%. The same-bar fill adds 2.00 percentage points in this example, because a trader who sees Monday's close can act no earlier than the next tradable price, here Tuesday's open.

Shifted return = exit price / next-bar open − 1

In Stochastly

The execution guide in the documentation places an entry at the open of the bar after the signal and checks stops and targets against the high and low of each bar.

The documented Tick replay contract describes bid and ask quotes supplied as CSV or Parquet; executable graph behavior needs a tested run. An order intention becomes available at the close of the signal bar plus a stated latency in milliseconds, then fills at the first quote observed at or after that time: the ask for a buy and the bid for a sell. Stops and targets fill at market on the quotes, gaps and spread included. The replay has no queue-position model and no partial fills. Live trading through a broker is planned once the applicable regulation is in place.

Frequently asked questions

What is the one-bar shift?

Computing the signal on bar t and filling its order no earlier than bar t + 1. On daily bars this usually means the open of the next session.

Does a next-open fill remove timing bias?

It removes the same-bar fill. Data published after the bar close, mislabeled bar times and stops checked inside a bar can still place a trade at the wrong moment.

How much latency should a backtest assume?

Measure the delay from signal computation to order acknowledgment on the intended route, then test the result across a range of delays. A latency taken from another venue is an assumption for the new one.