How An Order Entry Gateway Works

A trading firm never sends an order straight to an exchange's matching engine. It sends it to a gateway: a dedicated server, run by the exchange, whose entire job is to sit between every client's systems and the matching engine, checking and forwarding messages before they're allowed anywhere near the actual order book. Understanding what the gateway does — and doesn't do — is the starting point for understanding how an order actually gets from a trading desk to a fill.

What the gateway checks before an order goes any further

• Session validity. Is this connection logged in, authenticated, and using a sequence number the exchange expects next? A malformed or out-of-sequence message gets rejected before it's even parsed as an order.
• Message format. Does the order conform to the expected protocol — correct fields, correct data types, required tags present? See The FIX Session Layer: Logon, Heartbeat, Logout for how this works over FIX, and Binary Order Entry: Why Exchanges Left FIX for the faster, more compact formats many exchanges use instead.
• Risk and sanity limits. Is the order size and price within the firm's pre-set risk limits, and does it pass basic sanity checks — the fat-finger and price-collar checks covered in Fat-Finger Limits And Price Collars — designed to catch a typo before it becomes a multi-million-dollar mistake?
• Entitlements. Is this firm even allowed to trade this particular instrument, and has it posted the margin or credit required?

Only after all of these pass does the gateway forward the order into the matching engine's input queue.

Walking an order through

A trading firm's system sends a buy order for 500 shares at $50.10. The order hits the exchange's gateway, which:

1. Confirms the session is logged in and the sequence number is next in line.
2. Parses the message and confirms all required fields (symbol, side, price, quantity, order type) are present and valid.
3. Checks the order against the firm's pre-trade risk limits — say a $2 million notional cap per order. $50.10 × 500 = $25,050, well under the limit, so it passes.
4. Checks the price against a reference collar — is $50.10 within, say, 5% of the last reference price? If the stock last traded at $50.00, yes, it passes; an order at $5.00 by comparison, plausibly a fat-fingered decimal error, would be rejected right here, before ever reaching the book.
5. Forwards the now-validated order to the matching engine, which timestamps it and places it in the book.

Every one of these steps happens in well under a millisecond on a modern exchange gateway — the checks are real, but they're built to add negligible latency for orders that pass.

Why this architecture matters

Because every order from every client passes through a gateway before the matching engine ever sees it, the gateway is also where an exchange enforces fairness and consistency: every order gets the same validation, in the same order it arrived, regardless of which firm sent it. It's also usually where the exchange assigns the definitive, exchange-side timestamp used for priority — which is why gateway architecture, and how close a firm's servers sit to it, matters enormously for latency-sensitive trading.

What a gateway is deliberately not

It's worth being precise about what a gateway does not do. It does not decide whether an order matches against another order — that's exclusively the matching engine's job, working from its own separate order book. It does not hold any trading logic, pricing intelligence, or strategy of its own; it is purely a validation and routing layer. And it does not typically retain state about an order beyond confirming it was accepted or rejected — once an order clears the gateway, responsibility for tracking its life cycle (new, partially filled, filled, cancelled) shifts to the matching engine and the execution-report messages it generates, covered in The Execution Report State Machine.

This separation of concerns is deliberate: keeping the gateway's logic simple and fast means validation adds minimal latency, while keeping all matching logic centralized in one engine means every participant, regardless of which gateway instance they connect through (large exchanges run many gateway servers in parallel for capacity), sees a single, consistent order book rather than a fragmented view assembled from multiple entry points.