Features for Execution Cost Prediction

An alpha model asks "will this stock go up or down." An execution cost model asks a completely different question: "given that I've decided to trade, how much will it cost me to actually get the trade done." Those two questions need different inputs. Fundamentals like earnings growth or a valuation ratio say almost nothing about execution cost; what matters instead is how big the order is relative to how much liquidity is actually available, how volatile the price is while the order is being worked, and how urgently the trade needs to finish. Picking the right features here is the difference between a cost model that actually predicts slippage and one that's guessing.

The core features, and why each one matters

• Order size relative to average daily volume (participation rate). A 10,000-share order in a stock trading 50 million shares a day is trivial; the same 10,000 shares in a stock trading 200,000 shares a day is enormous. Cost scales with relative size, not absolute size, which is why this ratio — not the raw share count — is the single most important input to most cost models.
• Bid-ask spread. The most immediate, mechanical cost of crossing the market once, before any impact from size at all; wider spreads mean a higher baseline cost regardless of order size.
• Volatility over the expected execution horizon. Higher volatility means more risk that the price moves away from you while the order is still being worked, and many cost models scale price-impact estimates directly with volatility.
• Urgency or execution horizon. The same order executed over one minute versus over the full day has very different costs — a rushed order takes more liquidity per unit time and pays more for it, so planned trading horizon is itself a feature, not just an outcome.
• Recent volume and volatility patterns (intraday seasonality). Liquidity and volatility both vary predictably through the trading day — thin at the open, thick around the close in many markets — so time-of-day features help the model anticipate how much liquidity will actually be available when the order is scheduled to trade.

Worked example: two orders, same shares, very different predicted cost

Order A: 20,000 shares of a stock with 10 million shares average daily volume (0.2% participation), a 2-basis-point spread, and moderate volatility, executed passively over a full trading day. Order B: 20,000 shares of a stock with 500,000 shares average daily volume (4% participation — twenty times higher relative size), a 15-basis-point spread, and higher volatility, needing to execute within 30 minutes. Even though both orders are for the same raw share count, a cost model using the features above would predict Order A's cost at only a few basis points — small relative size, tight spread, plenty of time to trade passively — while predicting Order B's cost at several tens of basis points, driven by its much higher participation rate, wider spread, and compressed time horizon. A model that used only raw share count as its size feature, ignoring participation rate relative to each stock's own liquidity, would badly underestimate Order B's true cost.

What this means in practice

A well-built execution cost model earns its keep by feeding a trading desk realistic pre-trade cost estimates for sizing and scheduling decisions — should this order be split up, worked passively over the day, or crossed immediately — and those estimates are only as good as the features behind them. Because these features come from live market microstructure rather than slow-moving fundamentals, they need to be refreshed far more frequently than an alpha model's inputs, and they're typically trained on a firm's own historical parent-order fills rather than public data, since realized slippage depends on the specific execution strategy and venue mix actually used.