Exchange Architecture

A trading desk can lose money without a single “bad quote” showing up on the screen. The desk just sends orders that look reasonable, while the exchange interprets them differently in the order book. The gap usually hides in order semantics (what the order means) and Time-In-Force (TIF, how long the exchange keeps it active). You can watch the matcher do exactly what you told it to do, yet the outcomes still drift from what you meant.

This chapter teaches you to map those semantics to matching outcomes you can predict. You’ll learn how TIF rules interact with partial fills, cancel/replace behavior, and price-time priority so you can reason about queue position and execution timing. After this, you should be able to take an order spec - limit vs market, post-only, pegged, reserve/iceberg style, and a TIF - and predict what the matcher will do under load, including the annoying edge cases that cause “it should have filled” post-trade disputes.

The Order Semantics Matrix: how TIF and semantics shape matching outcomes

Nadia learned this the hard way when she moved from prop trading to venue design. A simulator matched her orders correctly, then the live environment “disagreed” with her expectations. The simulator treated her TIF one way; the matcher treated it another. The result: orders vanished earlier than she assumed, queue position snapped, and her backtest filled more aggressively than production.

To stop guessing, use the Order Semantics Matrix. Treat every order as a tuple of (a) execution intent, (b) price behavior, and (c) TIF. Execution intent tells the matcher what “success” means; price behavior tells it which book prices this order can trade at; TIF tells it how long it can sit before the matcher removes it. When any one of those fields changes, the matching outcome changes - even if the order price stays the same.

A clean way to think about it is to pin down two mechanics the matcher must implement: (1) whether the order can rest in the book or must execute immediately, and (2) when the exchange removes it relative to matching events. If your system removes the order at the end of a matching cycle, you preserve more queue position; if it removes immediately on receipt of a timer event, you can lose queue position between micro-events. Traders feel that as “my order got skipped” or “my cancel didn’t stick.”

Use these items to build the matrix for a specific order type and TIF combination:

1. Resting permission (can the order enter the book?)

• Example: a limit order with a standard TIF rests; a market order cannot rest and must match on arrival. A post-only limit order must not execute immediately; it either rests or gets rejected/canceled depending on your rules.

2. Price crossing rule (when does matching become possible?)

• Example: a bid limit at 100 can match asks at 100 or lower. A sell at 100 can match bids at 100 or higher. If you add pegging or discretionary offsets, you must define the exact formula and when you recompute it.

3. TIF horizon (when the exchange stops treating it as active)

• Example: Good-Til-Canceled (GTC) stays active until canceled; Immediate-Or-Cancel (IOC) cancels any unfilled remainder right after matching; Fill-Or-Kill (FOK) requires full fill now or cancels everything; Day (DAY) expires at end-of-session.

4. Removal timing (what happens relative to matching and partial fills?)

• Example: IOC typically cancels the remainder after the matching attempt finishes. If you implement IOC removal “between” price levels, you can create partial-fill patterns that differ from trader expectations.

Concrete example: take a limit buy at 100 with IOC. If the book has 30 shares offered at 99 and 70 shares offered at 100, your intended behavior usually looks like this: the matcher fills 30 at 99, then fills another 70 at 100 only if your engine allows matching to continue within the same “IOC attempt.” If your engine stops after the first price level or caps the matching sweep, the remaining size cancels at 100 and you get 30 or 30+some smaller amount. Both engines “obey IOC,” but they interpret “attempt scope” differently. The matrix forces you to specify that scope.

Putting It into practice: specify semantics + TIF, then verify with matcher traces

A practical workflow beats a spec document. You can implement or evaluate an exchange faster if you drive everything from order-level test vectors and matcher traces. Nadia’s venue-design checklist started with one thing: treat every order as a deterministic state machine driven by explicit events (arrival, match start, match end, timer tick, cancel request). Then log the state transitions.

Run this workflow for each order type you plan to support, including your TIF variants:

1. Write the order as a minimal spec

• Fields: side, limit price (or price formula), quantity, “can rest” flag, and TIF....