TWAP execution algorithm: time-sliced order scheduling
A TWAP execution algorithm divides a parent order across a fixed time horizon. Its target quantity advances with elapsed time, not market volume. The schedule is simple to inspect, but it still needs price limits, fill feedback, and a rule for any balance left at the end.
- Schedule input
- Start time, end time, parent quantity
- Target path
- Quantity follows elapsed time
- Main limit
- The schedule does not measure available liquidity
Key Takeaways
- TWAP sets a time-based target path and compares actual fills with that path.
- Equal time slices do not require an intraday volume forecast.
- Limit prices and missed fills can leave the order behind schedule.
- A hard end time creates a choice between canceling the balance and trading more aggressively.
How a TWAP schedule is built
Choose the parent quantity, start time, end time, and number of decision intervals. A basic schedule assigns equal quantity to every interval. A live implementation measures cumulative fills rather than assuming each child order completed.
Schedule rule
targetFilled(t) = parentQuantity × elapsedTime / totalHorizon
deficit(t) = max(0, targetFilled(t) - actualFilled(t))Inputs beyond the clock
The time path is only one part of order handling. A usable specification also defines the child-order type, limit-price rule, maximum child size, minimum delay, cancel and replace behavior, and whether the strategy may continue after its planned end time.
- Use actual fill reports to update remaining quantity
- Cap child size and participation when displayed liquidity is small
- Define whether missed slices are carried forward or abandoned
- Stop when market data, timestamps, or order acknowledgements are stale
Where TWAP can fail
A fixed clock can send the same target size into very different liquidity conditions. The algorithm may trade too much during a quiet interval or too little during a liquid one. Repeated timing and size can also make the pattern easier to infer. Randomization may reduce regularity, but it changes the simple schedule and does not remove market impact.
A code prototype is not an execution venue
Pineify can translate a detailed schedule into editable cTrader, MQL5, NinjaScript, or Pine Script code. Platform compilation, market-data permissions, broker order types, simulation, live credentials, and position reconciliation remain separate. Pine Script can model a schedule or create alerts, but it does not by itself supply a broker execution engine.
Turn a TWAP specification into a cBot prototype
Define the parent quantity, time window, child-order rules, price limits, catch-up behavior, and shutdown conditions. Pineify can convert those rules into editable cTrader C# code and return compiler diagnostics. Review and backtest the result in cTrader before any broker use.
Sources and verification
This page is educational and does not provide investment advice or an execution recommendation. Order handling, market data, fees, venue rules, and fills vary by broker and market. Pineify does not route or execute live orders, and no method guarantees lower costs or better prices.