Concept
Cost-model Realism
Cost-model Realism is a Performance, Backtesting & Validation concept. The Library holds 1 implementation, a working definition you can pull into Quant.
Top Cost-model Realism indicator
The top custom implementation, built on the original standard Cost-model Realism formula.
1 total
This Cost-model Realism implementation is strategy-ready: open it in Quant, set your rules, and it backtests automatically.
What is cost-model realism?
Cost-model realism is the discipline of making a backtest's assumed trading costs match what execution would actually have cost: commissions and exchange fees, bid-ask spread, slippage between signal price and fill price, market impact for size, plus the carry items many tests forget, such as funding rates on perpetuals, borrow fees on shorts, and overnight financing. A backtest run at zero or token costs is not a conservative simplification; it is a systematic upward bias, because costs are paid on every trade while edge arrives only on some.
The issue exists because most strategy edges are small relative to round-trip costs, and the relationship is multiplicative with turnover. A signal worth 0.15% per trade is genuinely profitable at 0.05% round-trip cost and a steady loser at 0.25%. Many published anomalies and most high-frequency-looking retail backtests live entirely inside this gap: profitable on paper, negative after honest costs. Realistic modeling means using the spread and fee schedule of the actual venue and account tier, filling market orders at the touch or worse rather than at mid, and recognizing that limit orders avoid spread but introduce non-fill risk that the backtest must also model.
Traders care because cost assumptions are the single easiest place for a backtest to lie, and the lie is invisible on an equity-curve chart. Serious validation therefore pairs a realistic base case with cost sensitivity analysis, re-running the test at multiples of assumed costs to see where profitability dies, and treats a strategy that only works at optimistic costs as unproven. A Sharpe ratio quoted without its cost assumptions is close to meaningless for high-turnover systems.
How traders use it
- As a backtest configuration standard: set commissions from the real fee schedule, model spread by filling at bid or ask rather than mid, and add a per-trade slippage allowance calibrated to the instrument's typical depth and the order size traded.
- As a turnover audit: multiply round-trip cost by annual trade count to get the yearly cost hurdle, then check that gross backtest returns clear it with a margin, since strategies that barely clear it often disappoint live.
- As a stress test via cost sensitivity: re-run the backtest at 1.5x, 2x, and 3x assumed costs and record where expectancy turns negative; a robust strategy degrades gradually rather than flipping sign at a small cost bump.
- As a live calibration loop: once trading begins, compare realized fills to modeled fills and feed the measured slippage back into the cost model, tightening the estimate with real data over time.
- Its main limitation is honest uncertainty about impact: costs for size, stressed markets, and thin sessions are hard to model from historical quotes, so cost models tend to be most reliable for small orders in liquid instruments.
Cost-model realism vs related concepts
Execution Cost Modeling: Closely related but aimed at execution tactics: it models how order type, timing, and slicing change the cost of a given trade. Cost-model realism is the validation-side counterpart, asking whether the backtest's assumed costs are honest at all.
Cost Sensitivity: The stress-testing extension. Realism sets the best-estimate base case; sensitivity analysis perturbs that estimate to find the cost level at which the strategy breaks, which matters because the true future cost is never known exactly.
Concept family
Performance, Backtesting & Validation
30 concepts mapped · 30 in the Library
Cost-model Realism FAQ
Turn Cost-model Realism into a trading strategy.
Take the implementation from this page into Quant, then build on it, backtest it on real data, and keep refining it in conversation.
