Best execution in crypto: what institutions should ask before onboarding a provider
Best execution in crypto is one of those phrases that can sound reassuring while telling you very little. In Europe, the more precise reference point is best execution under MiCA for crypto-asset service providers executing orders on behalf of clients. The underlying principle is familiar from MiFID II: a provider should take sufficient steps to obtain the best possible result for the client. The important distinction is maturity and precision. MiFID II sets out a highly structured framework, with defined execution factors, monitoring obligations and public disclosures. MiCA is more principle-based at this stage, so the assessment depends heavily on the provider’s execution model, execution policy and governance framework.
A provider can show a decent price on screen, but that does not explain how the order moved through the market, which venues or liquidity routes were considered, what fees were included, how much spread was paid, whether the trade created market impact, or whether the final result could have been better through another route.
For institutions, that gap matters. Onboarding an execution provider means choosing the system that sits between your order and a fragmented market. That system decides where the order goes, how it is split, what liquidity it touches, how quickly it fills, what gets reported back, and how easily your team can explain the result internally.
Crypto market structure makes this harder because liquidity sits across centralised exchanges, OTC desks, liquidity providers, and, in some cases, decentralised venues. Depth changes quickly. Asset coverage is uneven. Venue quality varies. A provider may advertise broad access, but the real question is whether that access produces better execution for the size, urgency, and assets the institution actually trades.
For institutions operating in a MiCA context, the useful question is not whether a provider uses familiar best execution language. It is whether the provider can explain how its execution arrangements work for crypto-assets, how different execution routes are selected, and how the outcome can be evidenced against its execution policy. Best execution should be read as an obligation of means rather than a guarantee of a particular trade result. A provider is not promising that every order will achieve the single best possible outcome in hindsight. It should be able to show that it has designed, implemented, monitored and followed sufficient execution arrangements for the orders it handles.
If a provider claims best execution in crypto, can they show the process behind the claim?
Where execution cost actually appears
Headline price gets the most attention because it is visible. It is also the part of the trade that can give buyers false comfort. A quote can look attractive at the point of execution while the real cost appears through spread, fees, market impact, poor routing, partial fills, failed settlement, or the opportunity cost of waiting too long to complete the trade.
This is where institutions need to push past “best price” language. A provider should be able to explain what it is optimising for on a given trade. Sometimes price matters most. Sometimes speed matters more. Sometimes the priority is reducing market impact. In other cases, the client may exclude a venue even when it shows the best visible price, because the operational, counterparty, or policy risk is not acceptable.
Those trade-offs are normal. The issue is whether they are visible.
A useful conversation about execution quality under MiCA can still draw on familiar MiFID-style factors: price, costs, speed, likelihood of execution and settlement, size, nature of the order, custody conditions, client restrictions and any other factor relevant to the outcome. The point is not that MiCA copies MiFID II line by line. It is that these factors give institutions a practical way to test whether the provider’s arrangements are proportionate to its model and to the orders it executes. In practice, that also means asking about depth, market impact, spread, operational constraints, and whether the client gave any specific instruction that affected the route.
If the answer keeps returning to “we have strong liquidity”, the buyer has not learnt enough.
How the order actually moves
Smart order routing is only useful language when the buyer understands what the router actually sees and how it makes decisions. Venue coverage is the obvious starting point, but it needs to be unpacked properly. Which exchanges are connected? Which are actively used? Which are technically available but rarely selected? Is the order being worked through a central limit order book, an OTC quote, RFQ liquidity, a liquidity provider, a principal model, a riskless principal model, or another aggregation layer?
Aplo’s execution setup includes capabilities such as Direct Market Access, Smart Order Routing, algorithmic strategies, high-touch execution, synthetic pairs, and GUI or API access. The important point is not the feature list on its own. It is whether those routes sit inside a clear execution process, with governance around venue selection, routing logic, client instructions, conflicts, post-trade evidence and the way different routes are used for different order types, asset pairs, sizes and urgency levels.
The next layer is routing logic. Does the system account for depth, fees, balances, latency, fill probability, and venue quality? Can the client exclude venues? Are those exclusions built into the route selection, or handled manually? If an order is split, can the provider show where it went and why?
Synthetic pairs are worth asking about as well. A long list of supported assets can look impressive in a deck, but the useful question is whether the provider can find workable liquidity when the obvious direct pair is weak. In crypto, coverage without intelligent routing can still leave the client paying more than necessary.
A route that cannot be explained is hard to govern. That is where a product feature becomes an operational question.
Slippage needs a benchmark
Slippage is often presented as if it explains execution quality on its own, but the number depends on the benchmark. Expected price against what? The price shown when the order was submitted? The arrival price? A composite market price? VWAP over a defined period? A snapshot from one venue? A benchmark built from the venues the provider could actually access?
Without that context, slippage can look precise while doing very little useful work.
Institutions should ask how execution quality is measured by order type, asset, trade size, and execution method. A market order needs one kind of analysis. An algorithmic order needs another. A high-touch execution may need notes on trader intervention, timing, discretion, and market conditions.
The cleaner provider conversations separate the components. What was the explicit fee? What was the spread? What moved because of the wider market? What moved because of routing? Was there partial execution? Did anything fail? How long did completion take?
This does not need to become a forensic exercise after every trade. It does need to be available when the buyer asks, especially for larger orders, recurring flow, or assets where liquidity is thinner.
This is also why best execution should not be reduced to slippage alone. Slippage is a useful metric, but only as one input within a wider execution review that includes policy, controls, evidence, exceptions and governance.
What to ask for before signing
The best time to test execution transparency is during onboarding, before the provider becomes part of the institution’s trading workflow. Ask for a sample execution report that shows what your trading, operations, risk, and finance teams would actually receive after a trade.
A useful report should include order timestamps, execution timestamps or execution windows, asset pair, order type, requested size, executed size, average price, venue-level fills, fees, slippage against a stated benchmark, rejected or partially filled amounts, settlement status, and any manual intervention.
The execution policy matters too. Buyers should ask who owns it, how it is approved, how often it is reviewed, how venues and liquidity sources are selected, what triggers a routing change, what monitoring takes place, how exceptions are handled, and how conflicts are managed if the provider can act in more than one capacity. In a MiCA context, the policy should help evidence the sufficient steps the provider takes, rather than imply that every trade outcome can be guaranteed.
Under MiCA, buyers should also understand whether orders may be executed outside a MiCA-authorised trading platform. That can include OTC venues, third-country trading platforms, or decentralised venues. If those routes are part of the execution policy, the client should know how consent is handled, how those routes are assessed, and how the provider evidences that the outcome remains consistent with its execution obligations.
Aplo’s guide on choosing the right crypto prime brokerage is useful background here because provider selection rarely comes down to execution alone. Custody, liquidity access, security, operational fit, reporting, and platform usability all sit close to the trading workflow.
That is especially true in crypto, where execution and custody are connected. Assets need to be available in the right place at the right time. Prefunding, exchange exposure, custody setup, settlement timing, and withdrawal processes can all affect the result. If a provider treats execution as a completely separate conversation from operations, the buyer should press harder.
Where provider claims get loose
Most weak execution claims do not sound obviously weak at first. They usually sit inside familiar phrases: deep liquidity, broad venue access, smart routing, competitive pricing, institutional-grade execution. Some of those claims may be true, but they need testing.
Venue count is a good example. More venues can help, but the number itself does not prove better execution. Some venues may have shallow depth, unreliable connectivity, operational restrictions, or risk characteristics that make them poor choices for a specific client.
Smart routing needs the same scrutiny. A router that looks mainly at top-of-book price can still make poor decisions. A stronger system should account for available size, fees, fill likelihood, latency, settlement risk, and client restrictions.
OTC certainty also needs context. A fixed quote can be valuable when the client wants speed, discretion, or operational simplicity. The buyer still needs to understand the cost of that certainty, particularly when it appears as spread rather than an explicit fee.
The same distinction applies to prime brokerage models. Some prime brokers focus on direct exchange execution, using routing technology and execution algorithms to access liquidity across venues. Others are closer to OTC quote aggregators, comparing prices from dealers and routing the client towards the quote that best fits the instruction. Both models can be useful, but they create different questions around cost, transparency, credit, routing logic, and value added.
Role clarity is just as important. A provider may act as agent in one context and principal or riskless principal in another. It may route orders to trading platforms, quote bilaterally, source liquidity from OTC relationships, use RFQ workflows, or support several execution models depending on the order. That can work perfectly well, provided the client knows which model applies, how incentives are managed, and what evidence is available afterwards.
Aplo’s explainer on how crypto prime brokers compare to market makers and OTC desks is a useful way to frame those differences, because the execution model shapes transparency, pricing, alignment, and the client’s ability to assess outcomes.
The useful question is blunt: can the provider explain how it makes money, how it routes orders, and how the client can check the result?
What a better provider conversation sounds like
A strong execution conversation gets specific quickly. If you ask how a £2 million BTC order would be handled, the provider should be able to walk through it. If you ask what changes at £20 million, the answer should change. If you ask about a thinner asset, the discussion should move into depth, timing, routing, market impact, and whether an algorithmic or high-touch approach would make more sense.
Good providers are also comfortable naming the limits of their model. That matters more than a polished answer. Institutions do not need perfect claims or guaranteed outcomes. They need arrangements that are proportionate to the provider’s model, a policy that can be explained, governance that shows how decisions are controlled, data they can review, and incentives they can live with.
For Aplo, the execution conversation sits in that practical space: fragmented liquidity, Direct Market Access, Smart Order Routing, algorithmic execution, synthetic pairs, broad asset coverage, and workflows that can be used through API, GUI, or high-touch support. The commercial value comes from how those routes are selected, governed, evidenced, and made usable for institutional trading teams.
Before onboarding a crypto execution provider, ask the same question from several angles: can you show us how execution quality is produced?
That means routing, venue selection, cost treatment, benchmark logic, reporting, settlement, custody conditions, exception handling, consent for relevant execution routes, and governance. Best execution under MiCA becomes meaningful when a provider can evidence the sufficient steps it takes before, during and after execution. The buyer does not need a slogan. It needs an execution process that survives a proper review.