Crypto execution methods: matching the method to the order

A brokerage that executes every customer order the same way is paying for it somewhere: spread on orders that could have been worked passively, delay on orders the customer needed filled now, or impact from sweeping books with size that should have been paced. The cost shows up as slippage, complaints, and a best execution file that is harder to defend than it should be.

Crypto execution methods exist because orders differ. A retail app buying a small ETH clip on a quiet afternoon has nothing in common with a treasury rotating a nine-figure stablecoin balance or a market maker rebalancing during a liquidation cascade. The method should follow from what the order needs, rather than from whatever the trading stack shipped with.

Start with what the order needs to achieve

Four questions sort most orders.

Does the customer need certainty of fill and price right now, or can the order be worked? Someone pressing "buy" in an app expects the price they were shown. A fund accumulating over the session does not.

How large is the order relative to visible liquidity? A 50 BTC order is small against aggregated depth on major venues in normal conditions and enormous in a thin altcoin pair at 3am on a Sunday.

What are market conditions doing? Volatility widens spreads and thins books, so the same order can justify a different method on a calm day and a volatile one.

How much control does the trading team want? Some desks want the book and their own orders. Others prefer to delegate the mechanics and hold the provider to a benchmark.

Streamed prices with Fill or Kill orders

For small and mid-sized orders where the customer needs an immediate answer, an indicative streamed price paired with a Fill or Kill (FOK) order is usually the cleanest method. The brokerage shows its customer a price derived from a continuously updated stream and, if the customer accepts it, submits a FOK order to the broker. The order is then either accepted and filled in full or rejected. Unlike an RFQ, the streamed price itself is not a firm, contractually guaranteed quote.

This suits retail flow well. The brokerage can quote its customer from the stream, add its margin, and, if the customer accepts, submit the FOK order in one automated loop. If accepted, the order fills in full; if not, it is rejected, with no partial fill or residual position to reconcile.

The trade-off is size. Streamed prices are designed around the amounts being quoted, and pushing well beyond them can result in rejection. FOK removes partial-fill uncertainty, not execution uncertainty: the order can still be rejected if the streamed price is no longer available. The gap between what a customer saw and what is executable a moment later remains a problem of quote latency and margin design.

Smart Order Routing across venues

When the order is too large for a single stream, or when the brokerage wants to source across several venues rather than one, Smart Order Routing (SOR) does the sweep automatically. The router reads available liquidity across connected venues, splits the order, and sends child orders where the marginal price is most favourable, net of fees where the logic is configured for it.

This matters because crypto liquidity remains fragmented across venues. Depth in the same pair varies by venue, time of day, and who is quoting.

Two caveats. SOR is still an immediacy method: it reduces the cost of taking liquidity without removing it, and an order large relative to aggregated depth will still walk the books. And connecting to more venues does not by itself produce better fills. What counts is whether those venues hold real depth in the pairs the brokerage trades, and whether routing decisions can be evidenced afterwards.

That last point has a regulatory edge. Under MiCA Article 78, a CASP executing client orders must take all necessary steps to obtain the best possible result, weighing price, costs, speed, likelihood of execution and settlement, size, and the nature of the asset, and must maintain and monitor an execution policy. Venue-level fills on routed orders are what a compliance team needs to show where an order went and why, and a provider should be able to return them. The method alone does not satisfy the obligation; there is more on what to ask a provider in best execution in crypto: what institutions should ask.

Direct Market Access for desks that want the book

Some trading teams do not want a routing engine deciding for them. Direct Market Access (DMA) gives the desk a venue's order book and lets it place, amend, and cancel orders directly, including passive limit orders that earn the spread rather than pay it.

It makes sense when the desk has a short-term price view, wants to post liquidity, or runs its own strategies and needs control over placement and timing. Market makers, quantitative desks, and larger brokerages with in-house trading capability tend to sit here.

The cost is that the outcome becomes the trader's responsibility, including the bid that never fills while the market runs away. A brokerage should be honest about whether it has the people to use DMA well in a volatile session.

Algorithms for large orders: TWAP, VWAP, and VIO

Large orders that do not need immediate completion are usually better paced than swept. The common crypto execution algorithms differ mainly in what they pace against.

TWAP (time-weighted average price) slices the order evenly across a chosen window. It is predictable and easy to explain. Its weakness is the same predictability: evenly spaced child orders can be detected, and TWAP ignores whether the market is busy or quiet.

VWAP (volume-weighted average price) weights the slices to an expected volume profile so that more of the order executes when the market is typically more active. It suits orders benchmarked to the session's VWAP. The dependency is the profile, and crypto volume shifts with news, liquidations, and regional sessions in ways historical curves miss.

VIO participates at a target percentage of actual traded volume as it occurs, rather than a forecast. It adapts when volume spikes or dries up, which suits fast markets and orders where footprint matters more than completion time. If the market goes quiet, so does the algorithm.

None of these removes market impact. They spread it, trading certainty of completion for a lower average cost. Choosing between them comes down to the benchmark the desk will be judged on, which is also why the benchmark comparison on the post-trade report matters more than the algorithm name; it is how a desk finds out whether the method it picked was the right one.

High-touch for the orders that do not fit

Some orders are too large, too illiquid, or too sensitive for any automated method. A block in a thin pair, a treasury conversion timed around a funding event, or an order where information leakage would be costly all benefit from a trader working it by hand and reporting back with the reasoning. There is more on executing larger crypto orders without signalling to the market.

High-touch costs more in commission and time, and for most brokerage flow that is not justified. For the few orders where the alternative is a visible footprint and a poor fill, it is often the cheaper outcome. A good desk will also say when an algorithm would have done the job.

Where the provider model matters

Whichever methods a brokerage uses, the commercial arrangement behind them shapes the result. A provider trading against its clients from its own book has a different incentive on every fill from one acting as agent.

Under an agency model with no proprietary trading book, and with fees agreed and stated separately from the execution price, the cost of the service and the cost of the market appear as two numbers. This is the model Aplo runs. Where qualified custody sits alongside execution, that also bears on capital efficiency in digital-asset execution because assets supporting trading need not be pre-positioned across a dozen venue accounts.

None of that makes any method perform better. It changes what a brokerage can see and verify afterwards.

Deciding, and writing the decision down

The practical question for a head of trading is not which of these methods is best, because that question has no answer. It is where the thresholds sit. At what size does customer flow stop going through the price stream and start being routed? At what point does a routed order become one that should be worked over the session instead, and which benchmark decides between TWAP, VWAP, and VIO once it does? When does the desk pick up the phone?

Most brokerages already have answers. Fewer have them written down, so they live in the heads of two or three people and quietly change when the market does. An execution policy that states the thresholds, names the method for each band of order, and records why the desk departed from it on a given day is worth more than any single algorithm, and it is most of what a regulator will ask to see.

The thresholds will drift. A routable size in a calm quarter is a worked order in a volatile one, and the post-trade benchmark data will show it before anyone on the desk notices. Reviewing the mapping against that data every few months is a small task with a large payoff.

If you are reviewing how your customer and institutional flow is executed today, speak to us.