Block Orders and Slippage: Where the Result Goes
A large order is rarely executed at a single price. Order book liquidity is finite: to fill the volume, execution of a block order passes through several levels, and each subsequent trade closes worse than the previous one.
The difference between the calculated and actual price is slippage, and in a thin market it outweighs commissions many times over.
Then the second mechanism kicks in — market impact. As soon as part of the volume hits the trade tape, market makers move quotes, arbitrageurs pull the price to the new level, and observers see the footprint of a large buyer.
Book liquidity at the levels passed through thins out within seconds, and the remaining volume is executed even more expensively — the market prices in the order in advance.
Therefore, the execution price does not equal the quote price at the moment of the decision. The algorithm solves the inverse problem: split the volume so that the average price is closer to the calculated one and the footprint in the book is minimal.
The TWAP profile stretches the entry over time, VWAP ties the pace to volume distribution, and IS logic seeks a balance between waiting risk and impact cost.
This is exactly where the result goes: fractions of a percent per trade over the long run turn into the main cost item.
Below we break down what makes up slippage of a large order and which execution parameters are configured for a specific order book liquidity and instrument profile.
What Algorithmic Execution Delivers: Effect in Measurable Values
A large block order as a single order consumes several levels of the book at once: the first trade moves the price, and the remaining volume goes through worse levels.
Slippage grows nonlinearly — the larger the order relative to the instrument's daily volume, the more expensive each subsequent share of volume.
Algorithmic execution removes this dependency: volume is cut into child orders and distributed over time.
The share of slippage removed is measured relative to the average benchmark for the period — comparison with VWAP shows how much closer the average execution price is to the market than with a single market order for the entire volume.
The footprint in the book is also controllable: each child order is smaller than the visible density at its level and is placed as a limit order, so the book does not move apart and copy strategies do not follow us.
Stability of the execution price is set in advance by a corridor of acceptable deviation — the spread between the best and worst child trade narrows, and the result is reproducible across a series of orders rather than depending on a lucky moment.
A separate class of failures during sharp movements is eliminated.
Primitive slicing keeps filling volume at any price; execution with a pause and recalculation does not trade during such an interval and returns to the market later, when the spread and density have returned to normal.
This is visible in the metrics report: the share of replaced and canceled child orders, deviation of the average price from the target, distribution of executed volume over time.
Block Orders: TWAP, VWAP, or IS — What to Choose
All three modes solve one task — split a large block order so that the market does not see it in full. The key difference is the benchmark to which the pace is tied: time, volume profile, or decision price.
Slicing parameters — interval step, volume participation limit, price boundaries, randomization — are selected for the specific book and horizon.
| Mode | When it fits | Where it breaks |
|---|---|---|
| TWAP | Even liquidity, no news background, horizon more important than entry price | Volatility spike: equal portions fall into a thin book, average price drifts |
| VWAP | Liquid instrument with a stable intraday volume profile | The day's profile diverges from historical — news, abnormal volume; the order lags the market |
| IS | There is a decision price and a time-sensitive signal; aggressive pace is acceptable | Thin book: market impact eats the gain, average price ends up worse than the decision price |
| POV | Need to be invisible, participation limited to a share of actual volume | Volume in the book falls — the order stretches out and does not fit the horizon |
What We Clarify Before Choosing
In practice, the mode is not fixed for the entire order: it is split into phases — start with IS on available liquidity, main volume with VWAP, and fill the remainder with TWAP in a calm window.
Switching by deviation from the benchmark and by remaining volume is built into the execution configuration rather than decided manually.
How We Implement Execution Algorithms: Work Stages
We start implementing execution algorithms with an audit of trading logic, not with code.
We look at how block orders are formed, what limits volume, and how the reference price is calculated, and we record the gap between expected and actual execution — that is what shows which algorithm will have an effect.
- Trading logic audit. We analyze the order flow, price sources, lot rounding, and venue rules. The output is a map of places where execution loses to slippage and where volume participation control is needed.
- Execution scheme. We choose where TWAP is appropriate, where VWAP is, and where IS with priority on minimum deviation from the decision price. We agree on the horizon, block boundaries, and behavior when trading stops.
- Parameter setup. We select the size of child orders, time step, allowable participation share, and price deviation limits. Parameters live in configuration, not in code — they are changed without rebuilding.
- Historical data testing. We run scenarios on order book and trade records, including thin markets and sharp movements. We compare with baseline execution and look at result stability, not the best single run.
- Risk control. We add limits, a ban on execution outside permitted hours, and logging of every child order so that the decision logic can be reconstructed.
- Handover. We provide configurations, the scheme, a report on runs, and the parameter change procedure, and remain in contact during the first live executions.
Policies, Configurations, and Execution Procedures
A block order is not one order but a sequence of actions over time, so the result depends on set limits, execution windows, and behavior rules when the market deviates.
Along with the code, we hand over to the client the algorithm control loop — from access rights to the procedure for the on-duty engineer. Everything listed remains in your environment and does not require our involvement in day-to-day work.
- Execution configuration: volume splitting parameters, time window, allowable deviation from target price, passive share limit, and behavior when liquidity is insufficient — as editable files, not values inside code.
- Access policies: roles for launching, pausing, and editing parameters, separation of rights between trader, risk control, and on-duty engineer, action log with initiator attribution.
- Interaction schemes: order and report flow between your systems and the execution module, failure points, and procedures for communication loss.
- Operating procedure: procedure for starting and stopping a campaign, risk limits, thresholds for automatic pause on abnormal price deviation or execution drawdown.
- Documentation: parameter descriptions with allowable value boundaries, instructions for the on-duty shift, checklist of checks for typical deviations.
- Team handover: code and configuration walkthrough, joint practice of the pause scenario, access to the repository and test environment.
Case: How Slippage Decreased on Large Orders
A market maker approached us who executed block orders on several venues, including Binance: the volume of a single order moved the price itself, and every minute of delay made the entry more expensive.
Before algorithmic execution, volume was split manually — the trader placed limit orders, watched the order book, and moved them as needed.
Measurements on a series of large executions gave an unpleasant picture: the price spread between the first and last trade reached 60–80 bps, in roughly four out of ten cases manual intervention was required, and filling the full volume stretched to 5–6 hours and did not always finish within the window.
What We Changed
We built slicing on TWAP with an adaptive step: the portion size is recalculated from actual volume at the best levels, not by a fixed timer.
We build the VWAP profile from the historical liquidity distribution within the trading window so that the bulk is executed where the book is deeper.
The control benchmark is implementation shortfall: we calculate deviation from the decision price, not from the first quote, so the algorithm does not "chase" a market that has already moved.
Passive limit orders inside the spread are limited by acceptable non-execution risk, and the remainder is taken aggressively if little time remains until the end of the window.
What Happened
Based on repeated measurements on comparable volumes, the execution price spread narrowed to 18–25 bps, the share of manual interventions fell from 40% to isolated cases, and the volume execution time decreased from 5–6 hours to 80–90 minutes. The unfilled volume on average does not exceed 2%.
Each order is written to a log with a timestamp and deviation from the benchmark — after execution, the client receives a breakdown showing how much slippage came from the market and how much from the slicing logic.
What to Do If Part of the Volume Has Already Been Executed Manually
The algorithm does not execute an order "from scratch" — on restart it reconciles the target volume with what has actually been executed on the exchange and works only with the remainder.
The source of truth is not our internal database but the position state in the order book and trade history: it is pulled by the parent order ID at startup.
Therefore, manual intervention does not cause double execution: if part of the volume has already been closed manually, the order remainder is recalculated, and placed child orders are canceled before the first new one.
The second step is schedule recalculation. For partially executed volume, not only the size changes but also the horizon: the remaining portions are redistributed over the unexpired time, otherwise the remainder will spill into the market in one chunk and move the price.
Volume and deviation limits from the reference price are recalculated — we take the reference from the Chainlink oracle — and are checked against the actual spread in the book before each portion.
The average price is the most fragile point.
So that manual trades and the algorithm's work do not "eat" each other, the volume-weighted average price is calculated for the entire order, including manual executions, and is maintained as a constraint: if the current average is worse than plan, the algorithm slows down rather than catching up on volume with aggression.
The threshold is set in advance: how much deviation is acceptable in the moment and how much overall.
Restart is safe because accounting is based on executed trades, not intention. Each cycle writes to the log the volume before and after manual adjustment, the price, and the reason for stopping — from it one can see where the divergence from plan came from.
If the volume is closed entirely outside the algorithm, it does not open new portions and completes work as a fact.
Technical Doubts Before Implementation: Common Questions
Before launching block execution, they check not "whether the algorithm will work" but how it behaves at the boundaries: thin book, venue limits, sharp price reversal. Below are common questions that come up in technical discussions and our substantive answers.
What happens if liquidity in the order book drops?
TWAP cuts volume into equal portions over time, so in a thin book each portion starts consuming more price. We set a participation threshold in total volume: if it is exceeded, the algorithm does not place the next part but waits for density to recover. Execution risk is shifted to the schedule rather than to slippage.
How are venue limits and rules taken into account?
Limits on volume, request rate, and minimum price step are built into the configuration before launch: portions are calculated taking into account already sent and confirmed orders.
A rejected order is analyzed rather than blindly repeated — otherwise a series of rejections shifts the entire execution schedule.
How is execution quality controlled?
Each portion is logged: decision time, target and actual price, volume participation. Then deviation from the benchmark is calculated — the VWAP profile or the launch price for IS. This gives an objective trade breakdown instead of a "we executed normally" assessment.
Can execution be stopped and remaining orders be canceled?
Yes. Manual stop, cancellation of active orders, and cancellation of unfilled remainders are provided. Unfinished volume is recorded in the report with the reason for stopping, so that the decision to continue is made based on data rather than guesses.
Let's Discuss the Task: What Is Needed to Evaluate Execution
To come back with an estimate and implementation plan, we need not a general idea but input data on the instrument and execution mode. The more precisely the trade perimeter is described, the fewer assumptions in the scope of work and the more realistic the timelines.
- Instrument, venues, and trading mode: spot or derivatives, one exchange or several with order routing between them.
- List of pairs and typical block order sizes — the choice between TWAP, VWAP, and a strategy minimizing deviation from the decision price depends on the one-time volume.
- Execution horizon: within a day, a working week, or until the target price is reached.
- Benchmark for VWAP: calculate by venue volume profile, by aggregated market, or by your historical profile.
- Limit on share of volume participation: what part of the market may be occupied so as not to move the price with your own orders.
- Allowable deviation from the benchmark price and behavior rules when it is exceeded: pause, slow down, or exit the remainder.
- Access: programmatic access to the account with read and order placement rights, test environment, limit restrictions.
- Current execution metrics, if the process already exists: share of unfilled volume, average deviation from the benchmark, time to fully close the position.
Based on this data, we assemble an execution map, estimate the scope of work on strategies, risk controls, and reporting, and come back with an estimate and staged implementation plan. Describe the task in this scope — then the conversation is already to the point.