Order execution: what happens to your order from click to fill

In the article Why backtests lie we said an honest test has to account for fees, spread, the queue and slippage — and we promised to look at order mechanics up close. Here it is. Because behind that innocent click on "buy" sits a surprisingly rich world: your order has a type, a time-in-force and a life of its own, during which it passes through the venue, a risk layer and a matching engine.

You may have felt it yourself: you place a buy for ten units and three fill. The rest hangs there. Or you send an order and the venue rejects it outright, because it doesn't match some rule. An order isn't a "make-it-so" button — it's a request with rules, and the sooner you understand them, the less the live market surprises you. A naive backtest doesn't know them: it sends, fills in full, at the chart price, every time. The real market is considerably less generous.

We'll go through it in order: what order types even exist and what each trades away, what lifecycle an order goes through, how price forms in a living order book, how large size gets filled in pieces so it doesn't push the price, and what safeguards keep an impossible trade from going through. At each step we'll show how our engine handles it — because it's precisely where this mechanism is modelled honestly that a backtest stops lying.

The order zoo: more than "market" and "limit"

In the last article, market and limit were enough — take the price now, or wait for yours. The real palette is wider, and every order type is a different deal about the same thing: what you give up — certainty of price, or certainty of fill.

• Market. Certainty of fill, not of price. You take liquidity, you pay the spread and slippage.
• Limit. Certainty of price, not of fill. You stand in the queue, and price can sweep past without ever reaching you.
• Stop (market or limit). A dormant order that wakes up once price hits a trigger. It then behaves either as a market order (fill certain, at the market price) or a limit (at your price, but with no guarantee). A classic for stop-losses and for buying a breakout.
• "If touched" variants. A stop mirrored to the other side — triggered when price touches a level from above. Handy for buying at a pre-chosen level.
• Trailing stop. A trigger that moves with the market. It locks in profit and tightens as price runs your way; if it turns, it takes you out.
• Market-to-limit. Enters as a market order, but the part that doesn't fill immediately is parked as a limit — instead of blindly eating deeper into the order book.

The vast majority of backtests ignore these specific order types entirely — yet the choice of order type is part of the strategy in its own right. Every strategy also has its execution strategy: exactly how to open and close positions. Sometimes you're playing for time and certainty — you want the asset bought right now, whatever it costs; other times you're playing for price and can afford to wait. Which mode you choose is designed around the broker and its fee tiers: for large-size strategies where limits apply, cheaper maker fills help you — but where the risk of price turning against you is unbearable, we don't even weigh maker versus taker; we take the certainty of fill and the fee is secondary.

In good strategies the fill methods are also combined — and because they're full-fledged parameters, they belong in the tests too. One of the final testing phases is exactly the question of which order type and which execution strategy suits a given strategy best. A trend-following system, say, is worth trying on trailing limits: once momentum is running, we ride it and don't want to close early. Other times we reach for fixed limits that can be adjusted as the market develops. And sometimes we're sitting in a limit order and the market breaks — so we cancel it and close the position with an immediate market order.

There's a kind of restraint to it: we usually enter calmly, with good odds and the option to wait for our price — whereas the exit often has to be decisive, fast and "more expensive" when it's preventing an even larger loss. Entry and exit simply aren't symmetric.

That's exactly why it's a huge advantage that our engine reproduces every commonly used order type very faithfully — so you test the execution strategy just as honestly as the entries and exits themselves.

An order type also comes with its time-in-force — how long it should live in the book before the venue discards it. Good-till-cancel (GTC) stays until you pull it; immediate-or-cancel (IOC) fills whatever it can right away and kills the rest; fill-or-kill (FOK) fills the whole order at once or nothing; good-till-date (GTD) expires at a set time; and there are day-only and at-the-open / at-the-close variants too. It's no formality — in a fast market, the difference between "fill what you can" and "all or nothing" is the difference between a trade and nothing at all. And even these details have a deeper point: if you want the same code to run in the backtest and live — one executable file for both — it has to account for them from the start. And because the engine handles them for you, the strategy itself stays as lean, readable and efficient as possible.

And then there are the instructions that fine-tune an order: maker-only (post-only — if the order would turn into a taker, don't send it, so you don't pay the higher fee), reduce-only (this order may only shrink the position, never accidentally open the opposite one) and iceberg (show only the tip of the size, keep the rest hidden, so a large order doesn't spook the market). The strategy then reaches for exactly the tool its intent calls for.

An order's lifecycle: not "sent → filled"

In our heads we easily reduce an order to two states: I sent it, and it either filled or it didn't. Reality is finer — an order moves through a whole lifecycle, and the strategy gets a message about every change to it.

First it's created, on your side. Before it leaves for the venue it passes a risk check — and it can end here before it began: if it doesn't match something, it's denied (more on those safeguards shortly). If it passes, it's submitted, and the venue either accepts or rejects it. An accepted order waits in the book; a stop also waits for its trigger. Then comes the fill — and it need not be all at once: an order can be partially filled, piece by piece, before it's filled in full. Along the way it can be canceled or expire.

Why isn't this nitpicking? Because a naive backtest knows only two of those states — sent and filled — and skips everything in between. It doesn't see denials, rejections, partial fills (which can be modelled statistically, to a degree) or expiry. And those are exactly what decide the outcome: an order a live venue would have rejected, or filled only halfway, gets filled in full in such a test — and the equity curve banks trades that would never have happened in reality. Our engine walks the whole lifecycle and the strategy reacts to each step just as it would live — it's the very same code, which is the subject of The backtest that behaves like a live market.

Order-book mechanics: price is a crossing point, not a number

Before we get to large orders, we have to admit one thing about the order book: it's alive. How the order book looks now says almost nothing about how it will look ten milliseconds from now — especially around the spread and the levels nearest to it. Asks and bids at the various levels appear, vanish and jump every instant — so the book is treated not as a photo but as a stream: a snapshot of the state, then an endless series of incremental changes at the levels. Anyone who reduces the market to a single number, "price", misses all of this. And if you're sourcing order-book data for your backtests: snapshots on their own are, in our view, useless — without the stream of incremental changes they don't capture what actually happened in the book between them.

In the last article we said a backtest likes to simplify the market to the best bid and ask — the spread between the highest bid and the lowest ask. But even if it takes exactly that price, it's missing the crucial question: how much of it actually rests at that best level? There might be five units at the best ask, or five thousand — and whether your order fits decides the price you fill at. When the order is larger than the available size, you eat deeper into the book, level by level, at ever-worse prices. It's not "what is the price" that matters, but "how deep is the book relative to my order size". A small order in a liquid market barely has this worry; a large one — or one in a thin market — has it in full.

It's worth squaring the very idea of price while we're here. When price jumps to double, the market cap doubles too — but the money that actually flows into the market can be a fraction of that increase. Price isn't an accounting sum, but a marginal crossing point: the offer to sell meets the immediate need to buy, and vice versa. It's set by that next touch at the edge of the book — and a handful of determined buyers against thin supply move price more than huge but idle capital that merely watches. The jump in market cap is then largely a paper revaluation, not a mountain of money that flowed in somewhere.

That's also why a market can move seemingly out of nowhere. If liquidity vanishes from one side of the book — say, when sell limits above the market are pulled — a thin band is left behind and price shoots through it in a jump. And that jump tends to chain and amplify: the first move wakes the algorithms reacting to it, and they feed it further. Position liquidations pile on, scalping bots, other participants — and the purely human element, FOMO during a fast rally. In such a move many people also cancel their sell orders instead, so as not to exit too early, thinning supply even more. The loop feeds itself and repeats — until momentum starts to fade. We'll dissect this dynamic, backed by numbers and backtests, in a separate article; here it's enough to see that it all plays out inside the order book.

For our fill mechanics this yields one simple but crucial conclusion: the price you fill at — and whether you fill at all — is set by the depth and movement of the book, not by a number on a chart. An honest simulation therefore works with that depth (snapshot and changes) and continually compares its fills against what actually traded in the market. Otherwise it believes even what the book merely "shows" — as with iceberg orders, which display only the tip of the total size and keep the rest hidden below the surface. How much really sits behind the best price is revealed only by actual trades — and that's exactly what we verify our fills against.

Filling in pieces: when the strategy isn't in a hurry

Back to the order book and its levels. When a strategy has to trade a large size, it runs into what we just saw: you can't drop it into the market all at once without worsening your own price. A large market order eats through the levels and the higher it climbs, the dearer it buys. A large limit, in turn, "shines" in the book and reveals your intent to others, who position around it.

The solution professionals — and our engine — use is simple: a large order is spread into a series of smaller child orders laid out over time. Instead of one blow, the strategy sends the size in tranches — at regular intervals, across a chosen horizon. The point is single: don't concentrate the size into one instant, and so don't push the price. It's institutional thinking in miniature — and exactly the fill method a naive backtest, which settles the whole position at one price, doesn't see at all.

It has its price, though, and that price is time. Spreading it out makes sense only when the strategy isn't in a hurry — when it doesn't mind filling gradually in exchange for a better average price and a smaller footprint in the market. Where the intent is to catch a fast move, that luxury is gone and you pay the full cost of immediate execution. It's a choice, not an automatism: speed, or cost. A strategy with us steers it itself — it sets the horizon and pace, and the engine handles the split; and if a tranche would be smaller than the smallest size the market accepts, it sends the order whole rather than complicating things needlessly.

Conditional orders: entry, target and stop as one whole

You rarely want to just "buy". Usually you want to buy and at the same time know in advance where you'll take profit and where you'll cut the loss. That's what conditional (bracket) orders are for — linked groups where the orders watch one another.

Two links are enough to know. One cancels the other: a target and a stop-loss hang on the position at once, and as soon as one fills, the other cancels itself — no orphaned order left to pull you back into the market a second time. One triggers the other: only once the entry fills does the attached target and stop get released. Combine both and you get the classic bracket: an entry that automatically lights up both profit and loss protection behind it.

Why mention it under fill mechanics? Because this too is part of how orders behave — and how they must behave in the test. A backtest that doesn't know linked orders can leave a stop hanging even after the exit, or conversely release the target before the entry even happened — and then counts trades that wouldn't have existed in linked reality. Our engine holds these links, including what happens on a partial fill of the entry: protection is released only for the part of the position that actually opened.

A bracket, though, isn't "set and forget". It's more of an initial premise: depending on how the market develops — and on what the strategy, the risk level and fresh data say about it — the planned exit can move, change or be reconsidered entirely. And even when the stop or target is placed straight at the venue (which is certainty — the venue reacts to a sudden change even without us, faster than our system), you can still keep working with that order: tighten it, move it, cancel and replace it. Placed protection is a starting point, not a final stop.

Built-in safeguards: why a test can't cheat with us

One layer remains, which we've brushed against a few times: the safeguards that stand between your order and the market. A naive backtest doesn't have them — and so, in it, a strategy does with impunity things the live market would never allow. An honest simulation holds the same guardrails as the venue and the risk layer in front of it:

• You can't buy with money you don't have. Before it's sent, an order passes a check of balance, precision and size limits; anything that fails is denied outright — with a stated reason, not silently.
• A runaway loop won't get through. A rate limit cuts off a strategy that would spew orders beyond a sensible bound — a safeguard against a bug that live would burn the account on fees.
• An exit won't flip the position. A closing order marked "reduce-only" never accidentally opens the opposite trade — the end of one common and costly mix-up.
• One position, not a hidden second. In netting mode, opposing orders meet the open position instead of quietly creating a second one against it.
• An emergency brake. The whole operation can be switched to "reduce exposure only", or stopped entirely — a kill-switch for the moment something goes wrong.

Each of those safeguards sounds obvious — until a test doesn't have it. Then a strategy buys on paper with no money, spews orders with no consequences and accidentally flips positions, and the result looks better than anything that would survive live. A backtest that ignores these guardrails starts lying again — just more quietly than with fees. So we let them hold in the test too: what wouldn't pass live doesn't pass with us either.

In truth, most such bugs we catch and iron out long before production; these safeguards are the last, deepest layer. And that's exactly the principle of defence in depth: alongside robustness, the second pillar we build our approach and our engine on, so that no single error makes it all the way to the account. We'll devote a separate article to this idea — in trading and in the security of the whole platform.

Conclusion: an order has a life

Behind that innocuous "buy" sits a whole mechanism: an order has its type, its time-in-force, its lifecycle and its place in a living order book that changes faster than you can blink. Large size fills in pieces, protection hangs in linked groups, and over it all watch the safeguards that won't let the impossible through. None of it is a detail — all of it decides the price you get, and whether your trade happens at all.

And that's exactly why it matters so much in a test. A backtest that reduces an order to a "make-it-so" button measures a different market than the one you then trade on — a more comfortable, non-existent one, precisely as we described in Why backtests lie. Our engine goes the opposite way: it walks this whole mechanism event by event, as we cover in The backtest that behaves like a live market — because a test you're meant to trust with your money has to take an order as seriously as the venue does.

Want to see how your strategy behaves once execution stops flattering it? Get in touch →