Exchange Architecture

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. - Example: Limit Buy, quantity 200, limit 100.00, can_rest = true, TIF = IOC.

2. Define acceptance rules before you define matching - Decide what happens if the order would execute immediately but your semantics forbid it (post-only). - Example: Post-only limit buy at the current best ask: either reject it or cancel it. You must pick one and test it.

3. Pin down the matching sweep for each TIF - For IOC: does the matcher keep sweeping all eligible price levels until the order is fully filled or until it exhausts price-crossing liquidity? - For FOK: does it check full-fill availability by scanning book depth before executing anything, or does it try to match and roll back?

4. Define timer and session cutoffs with exact timestamps - For DAY: does the order expire at a wall-clock time, or at the end-of-session market event? - Example: expire at 16:00:00.000 exchange time. If you use microsecond clocks, log the resolution.

5. Create test vectors that isolate one semantic at a time - Use the smallest book that still exercises partial fills and expiration. - Example book (per side): bids at 99.00 for 50 shares; asks at 100.00 for 80 shares; asks at 101.00 for 100 shares.

6. Record matcher traces and assert expected outcomes - For IOC limit buy at 100 with quantity 120: you should see fills against asks at 100 (up to 80) and then either stop and cancel remainder (40) or continue into 101 if your crossing rule includes it (it shouldn’t, because 101 is above the limit). - Expected outcome: fill 80 at 100, cancel remaining 40.

Here’s a realistic scenario you can run in a staging environment. Assume a single instrument, continuous trading, price increment 0.01, and the following visible book at time T0:

• Best ask: 100.00 for 80 shares - Next ask: 101.00 for 100 shares - Best bid: 99.00 for 50 shares

Now Nadia wants to validate IOC and DAY for a limit order. She sends two orders at T0 with an exchange timestamp of 12:30:00.500:

1. Send Order A: Buy limit 100.00, quantity 120, TIF = IOC. 2. Send Order B: Buy limit 100.00, quantity 120, TIF = DAY. 3. Wait for the matching cycle to complete and pull the execution report for both orders. 4. At T0 + 2 seconds, send a cancel request for any remaining quantity of Order B. 5. At T0 + 10 seconds, confirm Order B status if it still rests (and confirm whether DAY expiration happens later in the session cutoff event).

Expected outcomes (assuming standard semantics):

• Order A (IOC): fills 80 at 100.00, cancels the remaining 40 immediately after the IOC matching attempt. - You should not see any execution at 101.00 because the limit blocks price crossing above 100.00.

• Order B (DAY): fills 80 at 100.00, rests the remaining 40 at 100.00 (since it can rest and the limit allows it). - At T0 + 2 seconds, the cancel should remove the resting remainder and prevent any future fills at 100.00 unless you allow “cancel-on-arrival” semantics that race with matching.

Quick checklist: - Confirm your engine logs the exact moment it marks IOC remainder as canceled. - Confirm your engine never matches a buy limit above its limit price. - Confirm your DAY orders expire at the defined session cutoff time, not on a coarse timer tick. - Confirm cancel removes resting liquidity immediately enough that it does not trade in the next matching sweep.

What to watch for: failure modes in semantics + TIF implementations

Most bugs show up as “impossible” executions or as mysteriously missing fills. You can usually trace them to one of a few edge cases where semantics and TIF interact with queueing, partial fills, or event ordering.

Race at the matching boundary If you process timer expiration and cancel requests out of order relative to matching events, you can invalidate queue position unexpectedly. For example, a DAY order expires “just after” a match eligible event but “before” the engine generates the match, so the engine cancels the order instead of letting it fill. - Do this: serialize events per instrument (arrival, cancel, timer tick) into a single ordered stream, and apply them in that order inside the matcher loop. - Not this: handle expiration in a separate worker without a strict ordering barrier; it will occasionally win the race and you’ll get nondeterministic fills.

IOC scope ambiguity Different engines implement “IOC matching attempt scope” differently: some sweep all eligible price levels in one go; others stop early after a partial fill at the best price. That changes fill quantity and the post-trade state of the order. - Do this: define the sweep explicitly: “IOC performs price-crossing matching until either (a) the order quantity completes or (b) the order becomes unmatchable due to limit/price rules.” Then test with a book that has at least two price levels on the opposite side. - Not this: implement IOC as “match once at top-of-book then cancel remainder.” Traders will see systematic underfills whenever top-of-book liquidity runs out.

Queue position drift from replace semantics Cancel/replace and amend flows often interact with TIF in subtle ways. If your engine treats a replace as a fresh order (new time priority) but the trader expects it to preserve time priority, you create worse execution timing and higher slippage. - Do this: document and enforce your replace rule: cancel+new resets priority; amend-in-place preserves priority only for fields you explicitly allow to change. Then ensure TIF resets or does not reset based on the exact rule you publish. - Not this: reset priority on any amend event “because it’s simpler” and also keep the original TIF horizon, which produces behavior that looks inconsistent: the order keeps a long life but loses its queue position.

These failure modes matter because they change what traders can rely on when they build execution logic. A trader’s model often assumes deterministic semantics: “IOC means no resting remainder” and “DAY means it stays live until cutoff.” If your matcher violates those assumptions, you force everyone to adapt by adding heuristics around your engine, which increases message traffic and reduces market quality.

Order semantics and TIF rules are not UI labels; they are core matching inputs. When you specify them precisely, test them with small deterministic books, and log the exact state transitions, you turn “it filled” and “it didn’t” from a debate into an engineering property. That discipline carries forward into how you design the order book, matching engine throughput, and recovery behavior under load.

End of chapter one. 7 more chapters and about 15,855 words in the full book.