Matching engine vs venue: what trading firms should model

Nearly every setup of this kind starts with the same picture: a broker or prop firm has a gateway, a risk check and a route to an external venue. The question is whether to keep sending orders out, or add an engine that matches some or all of them in-house.

A matching engine and a venue are not interchangeable. The engine applies rules to orders and creates executions; a venue supplies a market, counterparties, or both.

Consider a mid-sized multi-asset broker with 8,000 active accounts, a peak burst of 1,000 order messages a second and a small proprietary desk. It sends most orders to external liquidity providers and is considering an internal order book for a limited set of instruments. Those figures are illustrative planning assumptions, not audited performance from a named firm. They are enough to expose the real question: will control over matching improve the product or economics enough to justify owning the operational and regulatory burden?

First separate the use cases. A broker can operate an internal matching engine to cross eligible customer orders, route unmatched quantity to a venue, or support a proprietary market. A prop firm may use its own engine to coordinate strategies or match participants in a distinct product. Each model has different obligations. Internalisation does not remove best-execution, conduct, record-keeping or conflict-management duties where they apply. A venue connection does not guarantee deep liquidity or a good fill.

That distinction is central to the architecture. A venue can provide price discovery and external counterparties.

An in-house engine gives the firm control over matching rules, sequencing and some execution costs, but the firm must provide the market integrity and resilience that a venue or liquidity provider would otherwise supply. Trading Technology's coverage of trading infrastructure can help frame the provider landscape, but the decision needs to be made against the firm's own order data.

Start with the flow, not the engine

Build a replay from at least four to eight weeks of order and execution records. Include quiet sessions, news spikes, market opens and the largest operational incident in the period. Measure by instrument and account segment, not just across the whole book. Averages conceal the bursts and thin markets that dictate capacity and risk.

For the illustrative broker, the first cut might show 1,000 messages a second at peak, with 150 to 250 new orders, 500 to 700 cancels or replaces, and the balance split among acknowledgements and fills. These are different workloads. A design sized only for new orders can fall behind during rapid repricing, when cancel traffic surges and stale quotes become a risk. Record the peak one-second and one-minute rates, not only daily totals.

Track these measures for each product and route:

• Marketable and resting order shares, average order size, partial-fill rate and fill ratio.
• Rejects, timeouts, cancels after submission and the age of a quote when it fills.
• Effective spread, slippage against a defined reference, and fees or rebates per filled unit.
• Order-to-acknowledgement and order-to-fill latency at median, p99 and p99.9, including network time.
• Concentration by instrument, session, account and counterparty, plus behaviour during volatile periods.

Then classify flow by whether it can realistically be crossed internally. Customer orders may be opposite in direction but differ in price, size, time and permissions. A 10,000-unit buy does not automatically match a 6,000-unit sell. Price-time priority, minimum quantity, time-in-force, self-trade prevention and account restrictions all affect eligibility. The engine also needs a policy for residual quantity: hold it, route it, or reject it.

Use an order-level replay to compare three paths: route every eligible order externally; cross eligible flow first and route the balance; or operate a separate book for a defined participant group. Compare fill quality after fees, not headline spread alone. Internal crossing may reduce external fees, but a poor internal price or a slower residual route can cost more than the fee saving.

Model the economics at the order level

Use a full-cost model with typical market ranges as planning bands, not quotes or guarantees. Scope, asset class, jurisdiction, redundancy and existing infrastructure can move the numbers materially. In particular, the cost of a regulated multilateral venue is not comparable with a broker's internal order-matching service.

These ranges are broad because ownership boundaries vary. Some firms already have colocation, market data entitlements, monitoring and 24-hour support. Others need to buy them. Venue transaction fees, rebates, clearing, membership and market-data charges can dominate the connector bill. Get line-item schedules for the actual instruments and expected message rates before treating the table as a budget.

For the example broker, calculate the break-even point from executions that would genuinely cross, not all submitted orders. Suppose 5 to 15 per cent of eligible volume can cross after price, size and account rules. The model should test that range, then subtract the cost of maintaining the engine, market data, surveillance, controls and additional staff. Include adverse selection: counterparties may be more likely to trade against the broker when its quote is stale or its pricing is weak.

Keep a sensitivity sheet for three variables: eligible cross rate, average external fee avoided, and incremental execution cost from delay or worse pricing. A modest saving per million units can look large at daily volume, then disappear when fill rates fall in volatile sessions. Document whether the engine improves customer outcomes, reduces a measurable cost, or supports a product that cannot be delivered through existing venues. If none of those is demonstrable, the case is probably not ready.

Build or connect: the operational boundary

An external venue connection still requires serious engineering. The firm owns session management, sequence recovery, order state, throttles, drop copies, clock synchronisation, reconciliation and failover behaviour.

Venue rules differ. A syntactically valid order can be rejected for a product-specific reason, and a reconnect can leave uncertainty about whether an order is live. That uncertainty needs a deterministic recovery procedure, not a manual guess.

An internal engine adds a larger responsibility. The firm owns the matching algorithm and its observable behaviour, including how it handles simultaneous orders, partial execution, price changes and system recovery.

It also needs controls against self-trading, erroneous prices, duplicate messages and account-limit breaches. The design should make the sequence of events reconstructable from durable logs, with order and execution identifiers that survive restarts and feed downstream risk, reporting and statements.

Before choosing either path, work through these steps:

1. Define the matching boundary. Specify instruments, participants, order types, priority rules, price sources and the treatment of residual quantity. Keep the first scope narrow.
2. Replay real traffic. Use production-shaped message bursts and market data, including cancels, disconnects and stale-price events. Test p99.9 behaviour and backlog recovery, not just an average-load benchmark.
3. Specify failure outcomes. Decide what happens on a risk-service timeout, lost market data, a venue disconnect, a split-brain condition or a failed recovery node. Fail closed where an uncertain state could create exposure.
4. Prove reconciliation. Compare gateway, engine, venue, risk and client records. Set tolerances and alerts for orphan orders, duplicate fills and sequence gaps, then rehearse the repair process.
5. Approve controls and ownership. Assign named teams for release, surveillance, incident command and client communication. Obtain legal and compliance review for the proposed execution model and jurisdictions.
6. Run in shadow mode. Compute hypothetical internal matches beside the live route without executing them. Compare prices, fills, latency and would-be exceptions for several market conditions.

For a first internal engine, a single active matching shard with a tested standby can be simpler than active-active matching, where sequencing and duplicate prevention become harder. If the strategy requires horizontal scale, partition by instrument or another deterministic key and document how cross-partition orders behave. Typical engineering targets might include sub-millisecond internal matching under normal load and recovery within seconds, but targets should follow the product's risk and latency needs, not a vendor benchmark.

Operationally, watch queue depth, reject rate, stale market-data age, sequence gaps, cancel latency and risk-check time alongside CPU and network metrics. Set thresholds that lead to action: pause new orders, cancel quotes, switch routes or move to a controlled recovery state. A dashboard that reports an engine as healthy while orders are queued or prices are stale is not an adequate control.

For teams comparing architectures and vendors, Trading Technology's platform coverage provides useful market context. The implementation decision still depends on protocol behaviour, support terms, recovery design and how cleanly the system integrates with the firm's risk and books-and-records stack.

Make the decision with a controlled rollout

The illustrative broker should not move its whole flow at once. It can start with a product that has predictable liquidity, low cross-account complexity and a clear external fallback.

Define a small cohort, cap order sizes and exposure, and route only when market data is fresh and all risk checks pass. Set an automatic kill condition for elevated reject rates, reconciliation breaks, latency breaches or unexplained execution differences.

Compare the shadow and live results against a pre-agreed baseline. Review by instrument, order type, account class and market condition.

A favourable average can conceal poor fills in fast markets or an uneven outcome for a particular client segment. Include external fees, internal operating cost and execution quality in the same report. Require independent review of the pricing and allocation rules if the firm is crossing customer flow.

Keep the rollback path available. For a broker, that usually means routing eligible orders back to the existing venue or liquidity-provider stack, with clear handling for live internal orders during the switch.

Test the switch under load and reconcile positions afterwards. A fallback that has never been exercised is a diagram, not a recovery plan.

On the stated assumptions, an internal engine is justified only if replay shows material eligible flow, a defensible execution or cost benefit, and a team able to support matching, surveillance and recovery continuously. Otherwise, improve the venue connector, routing logic and risk controls first. This advice does not apply where the firm is legally required to operate a venue, where its product depends on a proprietary matching model, or where external venues cannot supply the liquidity or execution behaviour the business needs.

#qualidade de execução #custos de matching engine #sistema de matching de ordens #trading venue connectivity #broker execution infrastructure #venue liquidity #trading platform architecture #order book operations