Every one of this module's algorithms exists because trading has a cost that scales with your own size, and that cost has a shape worth knowing precisely rather than guessing at. The practitioner's workhorse is the square-root law: impact (in bps) = k × σ × sqrt(Q / ADV), where Q / ADV is your order's size as a fraction of average daily volume (the participation rate), σ is the instrument's daily volatility (also expressed in bps), and k is a calibration constant a real desk fits from its own historical fills, typically somewhere in the neighborhood of 0.5–1 (code-pack Exercise 6, market_impact_model, takes k as a parameter rather than hardcoding one, precisely because it genuinely differs by instrument, venue, and era). The single most important consequence of the square root (not a straight line) is that impact cost is sub-linear in size: quadrupling your participation rate only doubles your impact (sqrt(4) = 2), which is exactly why a large order broken into smaller pieces over time costs less, in total, than the same size dumped in one shot, the mathematical justification for every scheduling algorithm in this module existing at all. A calibrated impact estimate is also usefully split into two pieces with very different lifespans: permanent impact, the piece that reflects genuine information leaking into the price (the market correctly inferring that someone with a view is buying) and that never reverts, and temporary impact, pure supply/demand pressure from your own order consuming the available book, which decays back toward the pre-trade price once you stop trading. This module's model takes a permanent_fraction parameter (a simplification of the full Almgren-Chriss stochastic-control framework, which properly derives an optimal trading trajectory trading off impact cost against the timing risk of spreading out too slowly, worth knowing the name and the trade-off it formalizes, out of scope to derive here) and splits a total impact estimate accordingly.
Advertisement
What is the largest participation rate you can afford?
The square-root law also answers a genuinely practical question every desk eventually asks: given a maximum acceptable impact budget, what's the largest participation rate I can afford? Invert the law algebraically, solve budget = k × σ × sqrt(p) for p by isolating sqrt(p) first (divide both sides by k × σ) and then squaring both sides, giving p = (budget / (k × σ))², clipped to at most 1.0 (code-pack Exercise 7, max_participation_for_budget). This is exactly the algebra behind a real "capacity" conversation: how large a position can a strategy actually hold before its own trading cost eats the edge that justified holding it in the first place, the same capacity concept QD1.02 and QD1.04 gesture at from the signal and portfolio-construction side; this module supplies the execution-cost half of that ceiling.
{
"skill": "Drafting a small transaction-cost-analysis (TCA) report once you already know the four benchmarks it compares",
"use": "Once you can compute arrival slippage, VWAP slippage, and fill rate by hand for a small example, have a coding assistant draft the reporting function that packages all three together — pure composition of formulas you already own, a good fit for acceleration.",
"tools": ["A coding-focused chat assistant or IDE copilot (Claude, GitHub Copilot, Cursor)", "This module's own hidden-test harness, run locally, as the ground truth"],
"prompt": "Write execution_quality_report(arrival_price, vwap_benchmark, exec_avg_price, exec_qty, total_qty) for a BUY order. Return arrival_slippage_bps and vwap_slippage_bps using the standard (execution - benchmark)/benchmark * 10000 shape, fill_rate as exec_qty/total_qty, and beat_vwap as True when vwap_slippage_bps <= 0. Do not invent any additional metrics or import any pricing/broker library — this uses only arithmetic on the numbers I've given you.",
"verify": "Coding assistants asked for a 'TCA report' will sometimes confidently reach for a named library or API that sounds plausible for finance work but does not exist in this program's runtime (no live broker connection, no pricing service, no pandas requirement here) — read every import before running anything, and if one appears that you did not ask for, treat it as a hallucination until you've confirmed it is real AND available. Then hand-check the sign convention specifically: for a BUY, paying MORE than the benchmark must produce a POSITIVE slippage number (a cost), never negative — a generated draft that silently flips this sign will still run without error and will still look plausible in a demo.",
"diy": "You must already be able to state, from memory, why a buy that executes above arrival price is a cost (positive bps) and why 'beating VWAP' means executing BELOW it — Common Mistake #2 and this Core section are exactly that gate. A copilot assembles the report; it must never be the one deciding what the sign convention means.",
"market": "IN"
}