Best Execution and Order Handling for a CASP: The Evidence a Regulator Will Ask to See

Best execution is not a policy you write once and file. Under MiCA it is a claim you have to be able to prove, order by order, from data you captured at the moment of routing — and most crypto firms are not capturing it.

Since the crypto-asset service provider rules in Title V of MiCA (Regulation (EU) 2023/1114) became applicable on 30 December 2024, order execution has moved from a commercial matter to a supervisory one. Article 78 requires a CASP executing orders on behalf of clients to take all necessary steps to obtain the best possible result. That sounds like a principle. In practice it is an evidentiary obligation, and the difference is the whole point of this post. When a supervisor asks why a particular order routed to a particular venue at a particular price, a firm that cannot reconstruct that decision from its own records has failed the obligation regardless of whether the routing was, in fact, good.

What Article 78 actually asks you to demonstrate

Read Article 78 as a technologist rather than a lawyer and it resolves into a short list of things your systems must be able to produce on demand:

• The best possible result, weighed across price, costs, speed, likelihood of execution and settlement, size and nature of the order — not price alone, and not the same weighting for every order.
• An order execution policy and effective execution arrangements that deliver prompt, fair and expeditious execution and stop staff misusing knowledge of pending orders.
• Clear information to clients about that policy, and their prior consent to it.
• Proof, to a client on request and to the competent authority on request, that a given order was executed in line with the policy.
• Where you execute outside a trading platform, prior express consent from the client, general or transaction-by-transaction.
• Regular monitoring of whether the venues you use still deliver the best possible result, with clients notified of material changes.

Every one of those is a demonstration, not a declaration. The two that catch firms out are the fourth and the sixth: proving execution against policy on a specific historic order, and evidencing ongoing venue assessment. Both are data problems before they are compliance problems.

Why fragmented crypto liquidity makes this harder than MiFID

Traditional best execution has decades of market structure behind it: consolidated tapes, reference prices, well-understood venues. Crypto liquidity has none of that. The same asset trades at materially different prices across dozens of centralised venues, market makers and, increasingly, on-chain pools, with no authoritative consolidated price to benchmark against. A router that skims the top of one order book can look excellent in isolation and poor against the liquidity that was actually reachable a few hundred milliseconds earlier.

The consequence is that you cannot reconstruct a best-execution decision after the fact from market data alone, because the market you were pricing against no longer exists. You have to capture the state that informed the routing decision at the moment you made it: which venues you polled, what each quoted, what was reachable given your connectivity and balances, and why the router chose as it did. Retrofit this and you are guessing. Build it in and it is close to free.

The record that closes the gap

The unit that makes Article 78 provable is a per-order execution record, written at decision time and retained immutably. It needs the order, the candidate venues and their quotes, the chosen venue and achieved terms, and — the part firms omit — a machine-readable rationale for the choice. A minimal but honest shape looks like this.

{
  "record_id": "exec-2026-0416-8827a1",
  "order": {
    "client_ref": "cli_49f3",
    "side": "buy",
    "pair": "ETH/EUR",
    "quantity": "12.5",
    "type": "market",
    "received_utc": "2026-04-16T09:14:22.104Z",
    "specific_instruction": null
  },
  "considered_venues": [
    {"venue": "venue_a", "best_ask": "2984.10", "reachable_qty": "12.5",
     "est_fee_bps": 10, "latency_ms": 41, "settlement": "internal"},
    {"venue": "venue_b", "best_ask": "2983.55", "reachable_qty": "6.0",
     "est_fee_bps": 8,  "latency_ms": 63, "settlement": "internal"},
    {"venue": "venue_c", "best_ask": "2984.90", "reachable_qty": "12.5",
     "est_fee_bps": 6,  "latency_ms": 55, "settlement": "internal"}
  ],
  "routing_decision": {
    "chosen": ["venue_a"],
    "factor_weights": {"price": 0.6, "cost": 0.2,
                       "likelihood_of_fill": 0.2},
    "rationale": "venue_b cheaper but reachable size 6.0 < 12.5; "
      "split fill raised expected slippage above venue_a all-in price",
    "policy_version": "oep-2026-01"
  },
  "execution_result": {
    "venue": "venue_a", "avg_price": "2984.10",
    "filled_qty": "12.5", "fees_eur": "37.30",
    "executed_utc": "2026-04-16T09:14:22.612Z",
    "off_platform": false
  },
  "conflict_flags": {"internalised": false, "related_venue": false},
  "log_hash": "sha256:0b9d…", "prev_hash": "sha256:7c14…"
}

The rationale and factor_weights fields are what turn a trade blotter into best-execution evidence: they record why the cheaper headline price was not chosen. The prev_hash chain makes the log tamper-evident, so “we can produce it” is not undermined by “but you could have edited it”. Capture this per order and the fourth requirement of Article 78 answers itself.

Where conflicts of interest quietly enter the routing path

Article 72 requires a CASP to identify, prevent, manage and disclose conflicts of interest, and routing is where those conflicts hide. If the firm internalises flow, runs its own market-making book, receives rebates from a venue, or routes to an affiliated or intra-group platform, the router’s choice is no longer neutral. ESMA said as much in its opinion of 31 July 2024 on EU-authorised firms routing to non-EU, often intra-group, execution venues, flagging the risk of diminished protection and asking national authorities to look closely at best execution and conflicts together.

The engineering answer is to make any conflict a first-class, logged field in the execution record — the conflict_flags above — rather than a policy paragraph nobody can reconcile against actual routing. A supervisor comparing routing statistics against affiliation is a realistic scenario; a firm whose logs let it run that comparison first is in a far stronger position than one waiting to be shown its own pattern. The same discipline underpins MiCA operational resilience under Article 68 and the surveillance obligations behind market abuse detection on your own order book: the evidence has to come off the system, not out of a document.

Build the evidence in, not the explanation after

The pattern here is the same one that runs through the technology evidence CASP authorisation actually turns on and through assembling a technical evidence pack under the CRA: the obligation is met by data you either captured or did not, and you cannot manufacture it in the fortnight before a supervisory visit. Instrument the router now, retain the records immutably, and monitoring, client requests and authority requests all draw from the same source.

Best execution under MiCA is not a promise about how you trade. It is a standing bet that, on any order a supervisor picks at random, you can show your working — and a firm that cannot has already lost the bet, however well it actually executed.