The mechanics behind automated execution.

Backtesting runs a strategy's rules against historical price data to see how it would have performed, before any capital is put at risk. It's the primary way an algo trader validates an idea rather than just believing it should work.

A backtest is only as trustworthy as how closely it mirrors real execution — one that ignores transaction costs, uses future data the strategy couldn't have known at the time (lookahead bias), or assumes perfect fills at the exact signal price will show better results than the strategy could realistically achieve live.

The standard practice is testing on one period of data, then validating on a separate, later period the strategy wasn't tuned against, to check whether the edge holds up out-of-sample rather than being an artifact of over-fitting to one specific stretch of history.

Slippage is the difference between the price a strategy expected to trade at and the price it actually got filled at. It happens because price moves between the moment a signal fires and the moment the order reaches the exchange and executes, and because market orders consume available liquidity at successively worse prices during fast moves.

Slippage tends to be worse in low-liquidity instruments, during high-volatility periods, and with market orders versus limit orders — though limit orders trade a different risk, the chance of not being filled at all.

A backtest that doesn't model slippage will systematically overstate performance, especially for strategies that trade frequently or in less liquid instruments where the gap between expected and actual fill price is largest.

A market order executes immediately at the best available price, prioritizing speed of execution over price certainty. A limit order specifies the worst price you're willing to accept, prioritizing price certainty over guaranteed execution — it may not fill at all if the market never reaches that price.

A stop-loss order becomes a market (or limit) order once price crosses a trigger level, used to exit a losing position automatically rather than relying on a trader to react in time. In fast-moving markets, a stop-loss triggered as a market order can still suffer slippage, filling at a worse price than the trigger level itself.

Product type also matters for how an order behaves: intraday (MIS) orders are squared off before market close and typically offer more leverage, while positional (CNC/delivery) orders can be held overnight but usually require full capital upfront.

Position sizing determines how much capital or how many contracts a single trade uses, independent of whether the trade wins or loses. A common approach is risking a fixed percentage of capital per trade (e.g. 1%), so that a string of losses reduces size proportionally rather than compounding into an outsized drawdown.

Risk management extends beyond individual position size to overall exposure — how much capital is allocated to correlated positions at once, and what the maximum acceptable drawdown is before a strategy is paused rather than left running unmonitored.

In automated systems, these checks need to be enforced at the execution layer itself rather than left to the strategy's own logic, since a bug in strategy code shouldn't be the only thing standing between the account and an oversized loss.

Paper trading runs a strategy against live market data with simulated orders instead of real capital. It sits between backtesting and live trading — unlike a backtest, it's exposed to real-time data feeds, current market conditions, and the actual latency of the system generating signals.

It's most useful for catching problems a backtest can't reveal: bugs in the live signal pipeline, unexpected behavior around market open/close, or a strategy that looks fine on historical data but behaves differently when it has to make decisions in real time without hindsight.

Paper trading doesn't replicate everything about live execution — fills are still simulated, so slippage and partial fills in illiquid instruments can still look better on paper than they would with real capital at risk.

Liquidity — how much volume is available to trade at or near the current price — varies significantly through the trading session. The opening and closing periods tend to see the highest volume and volatility, while the middle of the session is often quieter.

Low liquidity widens the effective spread between buy and sell prices and increases slippage, since there's less volume available at each price level to absorb an order. Algorithmic strategies that place market orders in illiquid instruments or during thin trading windows are the most exposed to this.

Respecting actual exchange trading hours and halting or adjusting order logic outside them isn't optional for a live system — it's a basic guard against placing orders the exchange won't accept or that would fill at prices far from what the strategy intended.

Latency is the time between a strategy deciding to trade and the order actually reaching the exchange. It's made up of several stages: the time to detect a signal, the time to construct and send the order, and the network and broker processing time before it's live on the exchange.

For most retail algo strategies trading on minute-level or slower signals, latency in the range of hundreds of milliseconds to a few seconds rarely changes the outcome meaningfully. It matters far more for strategies that trade on very short timeframes or rely on being first to react to a fast-moving price level.

Reducing latency usually means simplifying the path between signal and order — fewer network hops, less processing between decision and execution, and infrastructure placed close to the broker's own systems where it materially matters.