Building A Smart Order Router In Code: Scanning Venues, Splitting Orders And Routing For Best Execution

Fragmented - Modern markets are split across many venues - so every order faces a real-time routing decision  ·  Price + fees + latency + fill - The router chooses the best venue(s) after accounting for all four, not price alone  ·  Split - A large order can be broken into smaller child orders spread across venues and over time  ·  Co-located - At execution-focused firms, routers run on servers beside the exchange matching engines, in C++ or FPGA

In a modern equity or crypto market, liquidity for the same instrument is spread across many different trading venues - exchanges, alternative venues, dark pools - each with its own prices, fees and characteristics at any given moment. That fragmentation creates a deceptively hard problem that has to be solved in real time every time someone trades: for this particular order, right now, which venue (or venues) will actually give the best outcome? Sending it blindly to one exchange can mean a worse price, higher fees, or failing to fill. The system that answers this question is the Smart Order Router (SOR): it monitors all the venues it is connected to, works out where each order should go to get the best available execution after accounting for price, fees, latency and the likelihood of getting filled, and can break a large order into smaller pieces distributed across venues and traded over time until it is filled. It is one of the most important systems in electronic trading, and this playbook is a developer-and-enterprise tour of how it actually works in code.

What A Smart Order Router Actually Does

At its core, an SOR turns 'I want to buy or sell this' into 'here is exactly where and how to send it for the best result'. It does this continuously and automatically. First, it maintains a real-time picture of the venues it is connected to - the current prices and available liquidity at each, updated constantly from market data. When an order arrives, it applies its routing logic: which venue or venues offer the best execution once you account for not just the headline price but the fees each charges, the latency to reach it, and the probability that an order sent there will actually fill. For a large order that no single venue can absorb well, it does something more sophisticated - it splits the order into smaller child orders and distributes them across multiple venues, and often across time, to work the order without moving the market against itself. And as fills come back, it adapts - re-routing the remaining quantity as venues and conditions change. The SOR is, in essence, a real-time optimisation engine for the question 'where does this order go?', answered order by order, in a fragmented market that never stops moving.

The Building Blocks In Code

Built in code, an SOR is a pipeline of connected components, each a real engineering task. Venue connectivity is the foundation: reliable, low-latency connections to every trading venue, handling each one's protocol and quirks, so the router can both see prices and send orders everywhere it needs to. Market-data aggregation builds the consolidated real-time view - taking the price and liquidity feeds from all venues and assembling them into a single, current picture of where the best prices and available size actually are, which is what the routing decision reads from. The routing decision itself is the brain: given an order and the aggregated market picture, it computes the best venue(s) and how to split, applying the logic that weighs price, fees, latency and fill probability. Order management then sends the resulting child orders, tracks them, handles fills, cancels and re-routes as needed, and works the parent order to completion. And underlying all of it is a feedback loop with transaction-cost analysis - measuring how well the routing actually executed, so the logic can be assessed and improved. Each block is demanding, and together they form the system that answers the routing question well, at speed, order after order.

• Venue connectivity - reliable, low-latency connections to every venue, handling each one's protocol, to see prices and send orders everywhere.
• Market-data aggregation - consolidating all venues' price and liquidity feeds into one real-time picture the router decides from.
• Routing decision - the logic that picks the best venue(s) and split, weighing price, fees, latency and fill probability, not price alone.
• Order management - sending child orders, tracking them, handling fills, cancelling and re-routing, and working the parent order to completion.
• TCA feedback - measuring execution quality so the routing logic can be evaluated and improved over time.

Where Latency And Hardware Enter

How fast an SOR needs to be depends on the kind of trading it serves, and at the fast end the engineering becomes extreme. For execution-focused and high-frequency firms, the routing decision has to happen in a tiny fraction of a second, because prices and liquidity across venues change continuously and a stale decision routes to a venue that is no longer best. This is why such firms run their SORs on co-located servers - physically placed in the same data centres as the exchange matching engines, to minimise the network latency of both seeing prices and sending orders - and why the routing logic is often implemented in C++ or even on FPGAs (field-programmable gate arrays, hardware that can execute the routing logic in nanoseconds rather than the milliseconds a conventional software path takes). Not every SOR needs this - a router for less latency-sensitive trading can be built in software without co-location - but understanding that the extreme end exists, and why (co-location and hardware acceleration to make the routing decision fast enough to be accurate in a market moving at machine speed), is part of understanding the system. The latency requirements are set by the trading, and at the top end they push SOR engineering into co-located, hardware-accelerated territory.

The Bottom Line

The Smart Order Router is the system that answers, in real time and order by order, the deceptively hard question a fragmented market forces on every trade: where should this order go? It monitors all connected venues, routes each order to the best execution after accounting for price, fees, latency and fill probability, splits large orders across venues and time, and adapts as fills come back - built in code as a pipeline of venue connectivity, market-data aggregation, routing decisioning, order management and TCA feedback. At the execution-focused end it runs on co-located servers with routing logic in C++ or on FPGAs to make the decision fast enough to be accurate; elsewhere it can be built in software. And throughout, it is tied to the regulatory obligation of best execution, which the TCA feedback loop lets you measure and evidence. It is one of the most important and demanding systems in electronic trading, and exactly the kind of trading infrastructure BraivIQ builds. Educational engineering guidance only - not financial advice.

References & Further Reading

• FOW Learning - smart order routing systems: what they are: https://www.fow.com/insights/smart-order-routing-systems
• Quantt - smart order routing: how it works and why it matters in 2026: https://www.quantt.co.uk/resources/smart-order-routing-guide
• Velvetech - FPGA in high-frequency trading guide: https://velvetech.com/blog/fpga-in-high-frequency-trading/
• Wikipedia - smart order routing: https://en.wikipedia.org/wiki/Smart_order_routing
• Medium (Shailesh Nair) - FPGA acceleration in HFT: architecture and implementation: https://medium.com/@shailamie/fpga-acceleration-in-hft-architecture-and-implementation-68adab59f7af