A familiar story: you build a machine learning model, run backtests, and the numbers look great. Stable profits, clean equity curve, reasonable drawdowns. You deploy it to production, and within days, it starts losing money. When this happens, the first suspects are usually the same. Overfitting. Data leakage. A market regime shift. Sometimes those are real problems. Very often, they are not. In practice, many “profitable” models fail for a much more mundane reason: they never learned how their predictions would be executed. Backtests operate in a world where prices are clean and instantly accessible. A model predicts a price move, the trade is assumed to happen at that price, and profit is calculated accordingly. Real markets work differently. Between a prediction and actual profit lies execution — and it is here that hidden costs accumulate. A model predicts prices. A trading system executes orders. The gap between the two is where most strategies quietly die. Execution is not just an engineering detail. It changes outcomes in systematic ways. Latency, queue position, market impact, and adverse selection all distort the theoretical edge a model appears to have. Ignore these effects, and even the best predictive signal becomes untradable. This disconnect shows up especially clearly during interviews. I often ask candidates a simple question: “You have a model that performs pretty well in backtests. You deploy it, and it starts losing money. What did you forget?” Most answers revolve around modeling mistakes. Very few mention execution. “You have a model that performs pretty well in backtests. You deploy it, and it starts losing money. What did you forget?” In this article, I want to focus on exactly that missing piece — the hidden costs that appear when a model meets a real order book. We’ll look at two fundamental execution modes. The first is taker execution, where trades are executed aggressively using market orders. The second is maker execution, where strategies rely on limit orders and liquidity provision. Both look simple on paper. Both introduce subtle but powerful failure modes once money is on the line. Understanding these effects is not optional. If execution is not part of your modeling assumptions, your backtest is not a simulation — it’s a fantasy. Two Ways to Lose Money: Taker and Maker Execution Two Ways to Lose Money: Taker and Maker Execution Execution problems usually show up in two fundamentally different ways, depending on how a strategy trades. The first case is taker execution — market orders, aggressive liquidity taking. The second is maker execution — limit orders, liquidity provision, market making. On the surface, these approaches look like opposites. In practice, both introduce hidden costs that are rarely visible in backtests and painfully obvious in production. Taker Execution: When Speed Becomes a Price Let’s start with the simpler case — taker execution. A market order feels straightforward: you want to trade now, you accept the current price, and you’re done. In reality, even “now” has a cost. now Execution Delay and Slippage Imagine two participants receive the same signal: the market is about to move up. Both send a market order to buy 100 BTC into the same order book. the market is about to move up One order arrives first. The other arrives a moment later. The second trader buys at a noticeably worse price. Nothing mysterious happened — this is just how markets work. That difference is called slippage. The root cause is execution delay: the time between sending an order and getting it filled. Even tiny delays change outcomes, because markets are competitive systems. Seeing information earlier — and acting earlier — is an advantage. This has always been true, long before milliseconds mattered. In The Ascent of Money, Niall Ferguson describes how Rothschild profited from learning the outcome of the Battle of Waterloo hours before the rest of the market. The delay wasn’t technical, but informational. The effect was the same. The Ascent of Money The Ascent of Money Latency is not a detail. It is one of the oldest edges in trading. Why naive delay modeling fails When people try to account for latency in backtests, they often reach for a simple fix: assume a constant execution delay. That almost never works. First, network delays are not constant (on a scale of milliseconds, not to mention nanoseconds!) . Second, during volatility spikes, latency tends to increase — sometimes dramatically. Exchanges slow down, queues grow, internal systems struggle. Third, a trading strategy must be robust. If it only works under ideal latency, it doesn’t really work. A fragile strategy that collapses when conditions deteriorate is not a strategy — it’s a bet on perfect infrastructure. A more realistic way to think about delays A more practical approach is to treat execution delay as a stochastic process rather than a fixed number. In practice, this can look like the following: You collect real execution latency statistics during live trading and treat them as a time series. In backtests, every simulated order is assigned a delay sampled from a latency distribution relevant to the current market conditions — not copied verbatim from history, but drawn probabilistically. Even a rough distribution is better than a constant. And deliberately injecting a small probability of very bad delays forces the strategy to face reality. If it can’t survive those cases, production will eventually teach that lesson anyway — at a higher cost. very bad This is not quite the same as "predicting black swans", it is exactly about Taleb’s “antifragility”. Taleb’s “antifragility” Taleb’s “antifragility” Market Impact: When the Market Reacts to You Even if latency were magically eliminated, taker strategies face another, deeper problem: market impact. Suppose you need to buy $100 million worth of an asset. You don’t send one giant order — you slice it. The first slice fills. Other participants see aggressive buying. Prices move. Subsequent slices execute at worst levels. You end up paying more than your model ever assumed. Market impact is difficult because it is reflexive. The market doesn’t just reveal prices — it responds to your actions. Your backtest implicitly assumes a world where you trade without influencing it. In reality, your orders change the very distribution you are trying to exploit. This is why market impact modeling is such a large research area — and why it remains fundamentally unsolved. We don’t know how the market would have behaved if we hadn’t traded. Running experiments on live markets is expensive, slow, and unreliable. would have behaved Many ML backtests quietly assume zero market impact. That assumption is almost always wrong. A real backtest should be “interactive” – i.e. reacts to the actions of your strategy. Maker Execution: Getting Paid — and Then Paying It Back At first glance, maker execution looks safer. No slippage. Better prices. Sometimes, even rebates. But the risks don’t disappear — they change shape. Queue Priority and Signaling With limit orders, latency still matters. If two participants place an order at the same price, the one who arrives first gets priority. The other may never be filled. Market impact also doesn’t vanish. Posting a massive visible limit order is often worse than slicing aggressive orders. A huge “wall” in the order book becomes a signal. Other participants react. Price moves away. The order stops being liquidity and starts being information. This naturally leads to a tempting thought: can’t we manipulate the market this way? can’t we manipulate the market this way? And yes — that’s exactly why such behavior is illegal. illegal illegal but sometimes it’s just fun. Toxic Execution and Adverse Selection The most subtle — and most dangerous — risk of maker strategies is toxic execution. If your limit order gets filled, it often means that someone else knew something you didn’t. An informed participant decided it was profitable to trade against you. After the fill, price frequently continues moving — and now it moves against your position. against you In other words, execution itself becomes a negative signal. This probability depends on the instrument and the level of competition. Paradoxically, orders placed very deep in the book can be more dangerous. If such an order fills, it often means the market has already moved far enough that something unexpected happened — and you are already late. more In a sense, this is the mirror image of market impact. Instead of you moving the market, the market moves through you. Living in the ecosystem Markets are not fair systems. They are ecosystems. Some participants are faster, better informed, or better capitalized. Interacting with them indiscriminately is dangerous. A practical maker strategy tries to avoid “feeding the sharks”. That usually means: avoiding interaction with clearly informed flow, monitoring order behavior that looks algorithmic or coordinated, watching activity across multiple venues — simultaneous aggressive trades often signal a large informed participant, and being ready to exit quickly when execution itself becomes a warning sign. avoiding interaction with clearly informed flow, monitoring order behavior that looks algorithmic or coordinated, watching activity across multiple venues — simultaneous aggressive trades often signal a large informed participant, and being ready to exit quickly when execution itself becomes a warning sign. Ultimately, this pushes you back toward prediction — but now you are not predicting prices. You are predicting who you are trading against. And as discussed in the previous article, that is not an easy problem. Conclusion: Execution Is Not an Afterthought A trading model doesn’t fail because it predicted the wrong price. It fails because it ignores how that prediction would be executed. Backtests live in a simplified world where prices are executable, latency is invisible, and the market doesn’t react. Production lives in a competitive, adversarial environment where every order leaves a footprint. Execution is not an implementation detail. It is part of the model. If execution costs are not embedded into your assumptions, your backtest is not a simulation of reality. It is a simulation of a market that does not exist. And markets are very good at punishing fantasies.
