Home / System Architecture / The Execution Engine
ComponentAdvanced

The Execution Engine

The execution engine is the component that turns approved target orders into actual broker orders, decides how to work them (order type, slicing, timing), and processes fills back into confirmed positions.

Quick answer: The execution engine is the component that turns approved target orders into actual broker orders, decides how to work them (order type, slicing, timing), and processes fills back into confirmed positions.

In simple words

Once the system knows what it wants to hold and the risk engine approves, the execution engine makes it happen. It talks to the broker, chooses how to place the order, watches the fills come back, and keeps going until the target is reached. It is where clean intentions meet a messy market.

Purpose

A target position is abstract; a filled position is real. The execution engine owns the gap between them, minimising slippage and handling the market's refusal to fill cleanly, so the rest of the system can think in targets rather than order mechanics.

Visual explanation

The Execution Engine

Approved target to order strategy to broker; fills feed back and the engine works the residual until the target is met.

Execution EngineTarget OrderRisk CheckOrder SlicingBroker APIFillsReconcile

Professional explanation

Single responsibility

The execution engine's job is to move the actual position toward the target the strategy and risk engine agreed on, as cheaply and reliably as the market allows. It computes the delta (target minus current), decides how to execute it (order type, size, timing, slicing), sends orders through the broker API, and reconciles the fills that come back. It should not decide direction or size (upstream) nor own the durable order state machine (that is the OMS's job in a mature system), though in small systems execution and OMS blur together. Its guiding metric is execution quality: how close the realised price is to the decision price.

Inputs, outputs and the delta model

Input is an approved target position (and constraints such as a limit price or urgency); output is a stream of broker orders and, ultimately, a reconciled fill state. Working in deltas is what makes execution robust: the engine repeatedly asks how far am I from target and works the remaining quantity, so a partial fill simply leaves a smaller residual to complete rather than corrupting state. This is naturally idempotent with respect to the target: if execution is interrupted and restarted, recomputing the delta from the actual filled position resumes correctly instead of double-sending.

Order type choice and slicing

Execution chooses how to work an order. A market order guarantees a fill but pays the spread and risks slippage; a limit order controls price but may not fill; a marketable limit caps slippage while behaving like a market order. For size large relative to available liquidity, the engine slices the parent order into child orders spread over time or price (a simple TWAP-style schedule, or participation-rate logic) to reduce market impact. It must respect the instrument's tick size and lot size, and adapt: if a passive limit is not filling, it may need to cross the spread before the opportunity is gone. Every slicing decision trades impact against timing risk.

Fill handling and partial fills

Fills arrive asynchronously and partially. The engine must consume fill events, update the filled quantity and average price, and recompute the residual. Partial fills are the norm in thin option strikes: an order for 3 lots may fill 1, then 1, then rest. The engine tracks each child order's state, cancels and replaces stale limits, and knows when the parent is complete. A crucial subtlety is that a fill message and an order acknowledgement can arrive out of order or be missed on a disconnect, so the engine must reconcile against the broker's authoritative order and position report rather than trusting only its own event stream.

Concurrency and race conditions

Execution is intensely concurrent: outbound order requests, inbound fill and reject events, cancellations, and the strategy possibly changing the target mid-execution all interleave. Race conditions cause the worst execution bugs, such as cancelling an order that has already filled, or acting on a target that has since changed. The robust pattern is a single-threaded event loop (or a per-instrument actor) that serialises all state changes for a given instrument, so order state transitions happen one at a time in a defined order. External confirmations, not local optimism, drive state: an order is only working when the broker acknowledges it, and only filled when a fill confirms it.

How it fails

Execution fails by chasing a runaway price (repeatedly crossing the spread and paying ever-worse fills), by double-sending on a retry after an ambiguous timeout, by leaving orphan orders resting after the strategy has moved on, by over-filling when it miscounts partials, and by acting on stale targets. Slippage and latency turn a profitable-on-paper strategy into a losing one if execution is naive. Defences: cap the number of aggressive re-tries and the total slippage per order, make order submission idempotent with a client order id so a retry cannot duplicate, reconcile positions against the broker regularly, and time-out and cancel working orders that the strategy no longer wants.

Observability

Measure execution, do not assume it. Log every child order with its intended and filled price and compute slippage against the decision price and the arrival price. Emit metrics for fill rate, average slippage, time-to-fill, cancel/replace counts, and rejected orders. An execution-quality dashboard surfaces when a strategy is quietly bleeding to slippage even while its signals are fine. Reconciliation logs (system position versus broker position) should be a first-class alert, because a divergence there means the engine's picture of reality is wrong, which is among the most dangerous states a trading system can be in.

Market vs limit execution

AspectMarket orderLimit order
Fill certaintyGuaranteedNot guaranteed
Price certaintyNo (slippage risk)Yes (at limit or better)
CostPays the spreadMay earn the spread
Best whenFill urgency is highPrice control matters more
Failure modeSlippage in thin marketsUnfilled, misses the move

Practical example

Illustrative example (Indian market)

A Nifty options bot needs to move from flat to short 3 lots of the at-the-money call. The execution engine computes the delta of 3 lots and, seeing the strike is only moderately liquid, slices it into three 1-lot child orders using marketable limit orders capped one tick through the bid. The first fills immediately, the second fills after a reprice, the third rests; after a 5-second timeout without a fill the engine crosses the spread to complete it, but a maximum-slippage guard would have paused rather than chase if the price had run 10 points away. Each child carries a unique client order id, so when a network blip forces a resend, the broker rejects the duplicate rather than double-selling. After completion the engine reconciles: broker shows short 3 lots, matching the target, and logs realised slippage of 1.2 points versus the decision price.

On NSE, far-from-the-money option strikes and the back-month contracts are often thin, so a market order there can slip badly through a wide spread; execution engines commonly prefer marketable limits with a slippage cap on illiquid strikes, and slice larger orders, because a single aggressive market order into a thin book can move the price against the whole order.

Advantages

  • Lets the rest of the system reason in targets while it handles order mechanics
  • Delta-based working is naturally idempotent and robust to partial fills
  • Slicing and order-type choice reduce market impact and control slippage
  • Reconciliation against the broker keeps the system's position picture truthful

Limitations

  • Cannot eliminate slippage or guarantee a fill in a thin or fast market
  • Aggressive fill-chasing can worsen the very slippage it tries to avoid
  • Correctly handling out-of-order and missed fill events is genuinely hard
  • Optimal execution logic adds complexity and its own failure modes

Why it matters in practice

  • Poor execution can erase an otherwise real edge through slippage and missed fills
  • A divergence between assumed and actual position is one of the most dangerous states

Common mistakes

  • Assuming backtest-style perfect fills at the decision price, ignoring the spread and slippage
  • Retrying an order after an ambiguous timeout without an idempotency key, causing a double-send
  • Cancelling an order that has already filled due to a fill-versus-cancel race condition
  • Chasing a runaway price by repeatedly crossing the spread with no slippage cap
  • Trusting the local fill event stream instead of reconciling against the broker's authoritative report
  • Leaving orphan resting orders after the strategy target has changed

Professional usage

Serious execution desks treat execution as a measured, optimised discipline: they benchmark realised fills against arrival price and other references, choose or build execution algorithms (TWAP, VWAP, participation, implementation shortfall) to match order size to liquidity, and serialise order state per instrument to avoid races. Every order carries a client order id for idempotency, positions are continuously reconciled against the broker and clearer, and execution quality is reported as its own P&L line so slippage cannot hide inside strategy returns.

Key takeaways

  • Work in deltas (target minus actual) so execution is idempotent and partial-fill safe
  • Choose order type and slice to balance slippage, impact and fill certainty
  • Serialise order-state changes per instrument and drive them from broker confirmations, not optimism
  • Cap slippage and re-tries, use idempotency keys, and reconcile positions against the broker

Frequently asked questions

What is an execution engine in algorithmic trading?
It is the component that turns an approved target position into actual broker orders, chooses how to work them (order type, slicing, timing), and processes the resulting fills back into a confirmed position.
How does an execution engine handle partial fills?
It works in deltas: it tracks the filled quantity, recomputes the remaining residual after each fill, and continues placing or repricing child orders until the target is reached, so a partial fill just leaves a smaller amount to complete.
What is order slicing?
Order slicing breaks a large parent order into smaller child orders spread over time or price to reduce market impact, since sending the full size at once into limited liquidity can move the price against you.
How does an execution engine avoid double-sending orders?
By attaching a unique client order id to each order so that a retry after an ambiguous timeout is recognised as a duplicate and rejected by the broker rather than executed twice.
Why is working in target positions useful for execution?
Because recomputing the delta from the actual filled position makes execution idempotent: if it is interrupted and restarts, it resumes toward the target without double-trading, since it always works the difference.
What order type should an execution engine use?
It depends on the trade-off: market orders guarantee a fill but risk slippage, limit orders control price but may not fill, and marketable limits cap slippage while behaving aggressively. Thin instruments usually favour limits with a slippage cap.
How does the engine handle a missed or out-of-order fill message?
It reconciles against the broker's authoritative order and position report rather than trusting only its own event stream, so a message lost during a disconnect is corrected by comparing to the broker's record.
What is a race condition in execution and how is it avoided?
It is when concurrent events, such as a cancel and a fill, interleave badly, for example cancelling an order that has just filled. It is avoided by serialising all state changes for an instrument through a single event loop or actor.
What is slippage and how does the engine limit it?
Slippage is the gap between the expected and the realised price. The engine limits it with marketable limits, slicing, and a maximum-slippage guard that pauses rather than chases a price that has run too far from the decision level.
Should the execution engine trust its own fill events or the broker?
The broker's report is authoritative. Local optimism, treating an order as filled before confirmation, causes over- and under-counting, so state should transition only on broker acknowledgements and reconciled positions.
What happens to resting orders when the target changes?
The engine must cancel orders the strategy no longer wants, otherwise orphan orders can fill unexpectedly and push the position past the new target. Working orders are tied to the current target and cancelled when it changes.
How is the execution engine different from the OMS?
The execution engine decides how to work an order and interacts with the market; the order-management system owns the durable order state machine, idempotency and dedupe. In small systems they overlap; in larger ones they are separate for clarity and safety.
How do I measure execution quality?
Compare realised fill prices against a benchmark such as the decision price or the arrival price, and track fill rate, average slippage, time-to-fill and reject rate. Reporting these separately keeps slippage from hiding inside strategy returns.
Does latency matter for a retail execution engine?
For strategies holding minutes to days, correct handling of fills, slippage caps and reconciliation matter far more than milliseconds. Latency becomes critical only for high-frequency strategies with specialised infrastructure.

Voice search & related questions

Natural-language questions people ask about The Execution Engine.

What does the execution engine do in a trading bot?
It takes the position you want and actually places the orders to get there, watching the fills and finishing the job even if it only fills a bit at a time.
How does a bot handle an order that only fills part way?
It keeps track of how much is left and places more orders for just the remaining amount until it reaches the target.
Why does my bot sometimes send the same order twice?
Usually a retry after a timeout with no unique order id. Giving each order a client order id lets the broker reject the duplicate.
Should my bot use market orders or limit orders?
Market orders fill for sure but can slip, and limit orders control price but might not fill. On thin option strikes, a limit with a slippage cap is often safer.
How do I stop my bot from chasing a runaway price?
Set a maximum slippage. If the price runs past that from your decision level, the bot pauses instead of crossing the spread again and again.
Why does my live P&L differ from my backtest?
Often slippage and partial fills. A backtest assumes perfect fills at the decision price, but the real market makes you pay the spread and may not fill cleanly.

Sources & references

    Last reviewed 11 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.

    ← Previous
    The Risk Engine
    Educational content only — not investment advice. Examples use illustrative numbers and simplified models. Algorithmic trading and derivatives involve substantial risk. See our Risk Disclosure and SEBI Disclaimer.