Tapping Buy feels like one action. To a trading system, it begins a chain of separate decisions: Which market did you mean? Is the quote still current? How much may the account buy? Should the order wait or trade immediately? Did the venue accept it? How much actually filled? Does the account now agree with the exchange?
That chain is the subject of Inside the Trade, our ten-part guide to the machinery behind crypto markets. We begin with one hypothetical order and follow it from observation to confirmed position.
Series map: 1. Anatomy of a trade · 2. The order book · 3. Maker, taker and arbitrageur · 4. Book pressure · 5. Market-data traps · 6. Direction versus price · 7. The validation ladder · 8. The production system · 9. Exchange differences · 10. Latency
Our hypothetical order
Suppose a trader wants to buy no more than 0.01 BTC on a spot exchange. The displayed market is:
- best bid: $99,990;
- best ask: $100,000;
- amount offered at $100,000: 0.006 BTC; and
- the next offer: 0.010 BTC at $100,010.
These are invented figures for teaching. They are not a current quote or trade recommendation.
The trader submits a limit buy for 0.01 BTC at $100,010. That limit says, “buy at $100,010 or lower.” It does not say the complete order will fill at one price.
1. The interface turns intent into an instruction
Before anything reaches an exchange, the client has to form an order containing the venue, market, side, type, quantity, limit price and usually a time-in-force instruction. A professional system may also attach a client order ID so the request and later venue messages can be reconciled.
Small ambiguities matter. BTC/USD spot is not the same instrument as a BTC perpetual contract. “Market buy $1,000” is not the same instruction as “buy 0.01 BTC with a protected limit.” A reduce-only order has a different purpose from one allowed to open new exposure.
2. Market data supplies the system’s current world
An electronic strategy does not see a chart. It receives events or snapshots describing orders and trades. A feed handler parses the venue’s format; a normalizer converts that format into an internal representation; and an order-book builder reconstructs the currently visible bids and asks.
Headlands Technologies’ educational Quantitative Trading Summary describes the high-level production chain as market-data parser, trading strategy and order gateway, supported by monitoring, captured data, simulation and reconciliation. The post dates from 2017 and explicitly says it is not exhaustive or necessarily current, but that separation of responsibilities remains a useful mental model.
A trustworthy market view needs more than price. It needs the venue, instrument, event time, receive time, sequence or update relationship, and known connection state. A quote without freshness is an attractive-looking unknown.
3. Risk checks can stop the order
The strategy—or the human—proposes an instruction. A separate policy layer should decide whether the account is allowed to send it.
Checks may include:
- allowed venue and instrument;
- maximum order and position size;
- available balance and current exposure;
- daily loss or turnover limits;
- limit-price distance from a trusted reference;
- quote age and spread;
- duplicate client order IDs; and
- venue or account status.
If the account already holds its maximum BTC allocation, the correct outcome may be rejection. That is not a system failure. It is the system doing its job.
AI does not remove this boundary. Our guide to AI trading agents explains why a model should propose actions while deterministic software enforces authority and risk.
4. The gateway speaks the venue’s language
After approval, an order gateway converts the internal instruction into the exchange’s required fields and authentication scheme. It sends the request and waits for a response.
“Sent” is not an order state. The request can time out while the venue accepts it, or the response can be lost on the way back. Blindly retrying can create a duplicate. Robust clients therefore use unique IDs and query authoritative venue state after uncertainty.
5. Matching creates fills, not promises
Our 0.01 BTC limit crosses the displayed offers. In the simplified book, it can fill:
| Fill | Quantity | Price | Notional |
|---|---|---|---|
| First level | 0.006 BTC | $100,000 | $600.00 |
| Second level | 0.004 BTC | $100,010 | $400.04 |
| Total | 0.010 BTC | $100,004 average | $1,000.04 |
Fees would be added separately. If another participant removes liquidity first, the outcome can differ. The order might partially fill, remain open, or be cancelled depending on its time-in-force and the live book.
This is why a displayed midpoint or last price is not automatically an executable price. Our article on spread, slippage and partial fills develops that distinction.
6. The account must reconcile what happened
The exchange’s fill messages are the authoritative execution record. The internal system should update orders, fills, balances, fees and positions, then compare its state with the venue’s account records.
Imagine the client recorded 0.006 BTC filled but missed the second fill after a disconnect. Its screen would understate both BTC exposure and cash spent. A reconciliation process should detect that mismatch before the system trades again.
Professional systems often keep a secondary stream of order confirmations, commonly called a drop copy, and a captured copy of market data for later replay. The names and implementations vary by venue, but the principle is stable: do not let the strategy’s memory become the only history of what happened.
What can go wrong?
- The quote is stale before the order leaves the device.
- The market symbol maps to the wrong instrument.
- The risk service is using an old position.
- The order times out but is accepted by the venue.
- A partial fill is mistaken for a complete fill.
- A cancellation races with an incoming fill.
- Fees, funding or gas are omitted from the ledger.
- The local account disagrees with the venue after reconnecting.
The useful question is not “did the API call succeed?” It is “can we prove the final order, fill and position state?”
What this does not prove
Understanding order flow does not produce a profitable strategy. It only removes some expensive misconceptions. Our example assumes a simple price-time order book; onchain automated market makers, request-for-quote systems and auction designs follow different mechanics.
Next, we open the matching chamber itself: The Order Book Is Not the Market.
Crypto trade execution FAQ
What happens after I submit a crypto buy order?
The client creates an instruction, risk checks it, a gateway sends it, the venue accepts or rejects it, matching creates fills and account state is reconciled.
What information defines a crypto order?
An order identifies venue, instrument, side, type, quantity, price where applicable and time-in-force, often with a unique client order ID.
Why does quote freshness matter?
Markets can move while data travels and software runs. A price without a reliable timestamp and valid connection state may no longer be executable.
What should a pre-trade risk check verify?
It can verify venue, instrument, size, balance, exposure, loss limits, price distance, quote age, duplicate IDs and account status before submission.
Does sent mean an exchange accepted my order?
No. A request can time out or its response can be lost. Query authoritative venue state by a unique identifier before retrying an uncertain order.
Can one order fill at multiple prices?
Yes. A marketable order can consume several order-book levels, producing multiple fills and an average execution price different from the best displayed quote.
What is a partial fill?
A partial fill occurs when only part of the requested quantity executes. The remainder may rest or cancel depending on price, liquidity and time-in-force.
Why can an order timeout create duplicates?
The venue may accept the first request even when the client misses its response. Blindly resending without checking order state can submit a second order.
What is trade reconciliation?
Reconciliation compares internal orders, fills, balances, fees and positions with the exchange's authoritative account records to find missing or conflicting state.
Does understanding order execution make trading profitable?
No. It reduces operational misconceptions but does not create a trading edge or remove market, liquidity, venue, protocol and custody risk.
Risk disclosure: Crypto trading can result in rapid and complete loss. Order controls reduce operational errors; they do not remove market, liquidity, counterparty, protocol or custody risk. This article is educational and is not investment, legal or financial advice.
Share
Found this useful?
Share it with someone who'd want to read it.
Related

Book Pressure and Trade Impulse: Signal or Backtest Bait?
Rebuild two classic microstructure teaching signals, then stress-test the assumptions that make an attractive formula fail in real crypto markets.

The Order Book Is Not the Market: How Bids, Asks and Trades Become a Price
Learn how order events create bids, asks, spreads, depth and trades—and why the visible book is only a conditional snapshot of liquidity.

How Fast Is Fast Enough? Latency in Crypto Trading
Latency matters only relative to a strategy, venue and market event. Map the full path before paying to optimize the wrong bottleneck.
