Matching engine or venue: a 30-day implementation plan

Picture two otherwise similar trading operators making opposite calls. One routes orders to an established venue, accepting its rules and connectivity costs in return for available liquidity.

The other builds a matching engine to control execution, product rules and the trading experience, then takes on the engineering and operational burden. Neither choice is automatically cheaper or faster. The right answer depends on who supplies liquidity, what the product requires and what the firm can reliably operate.

A 30-day implementation plan should not promise a production-grade engine from scratch. It should produce evidence for a decision, test the critical path and set conditions for a bounded launch. A useful starting point is to map the full order journey, from client gateway and pre-trade risk through matching or venue routing, acknowledgements, market data and post-trade records. Industry coverage at Trading Technology can help teams track the vendors and infrastructure choices around that stack.

Compare control with the full operating cost

A venue route means integrating to its protocol, managing sessions and handling its order, market-data and throttling rules. It does not remove the need for your own risk checks, order state, client reporting or incident response. The venue controls its matching priority, supported order types, trading phases and market protection rules. You control which clients and orders reach it, subject to your agreements and obligations.

An in-house matching engine gives you more direct control over price-time or pro-rata priority, self-trade prevention, order types and instrument behaviour. It also makes your firm responsible for deterministic sequencing, recovery, surveillance hooks, market data distribution and operational controls. Building the matching loop is only one part of the work. A broker or prop firm still needs a clear answer for liquidity, clearing or settlement, and what happens when a component fails.

Use these typical market planning ranges as a first comparison, not as vendor commitments or audited results. Latency depends on geography, hardware, protocol, load and what each measurement includes. Build effort varies sharply with asset class, regulatory scope and existing components.

Compare total cost over at least three years. Include venue, market-data, connectivity and transaction charges, plus certification and failover links. For an own engine, count development, test environments, monitoring, on-call rotations, hardware and the cost of sourcing or supporting liquidity. A low-latency benchmark that omits risk checks or recovery can mislead the investment case.

Days 1-5: define the boundary and decision test

First choose the exact flow under review. Is the firm matching client orders internally, operating a venue for third parties, or choosing between an internal book and routing to an external market?

These are different operating and regulatory models. Set the boundary before comparing code or latency.

Write down the instruments, trading hours, expected peak order and cancel rates, client types, jurisdictions and liquidity source. Estimate average and peak message rates separately.

A strategy that cancels heavily may put more pressure on gateways and venue limits than its trade count suggests. Define the required behaviour for reject, cancel, replace, partial fill, auction and trading halt.

• Specify order priority, time-in-force, self-trade prevention and permitted order types.
• Record target latency at p50, p99 and p99.9, with measurement points and load conditions.
• Set recovery objectives: maximum lost state, acceptable restart time and how sequence numbers resume.
• Identify liquidity, market-data, clearing and regulatory dependencies before estimating build scope.
• Set a decision threshold for cost, control and operational risk, including a reason to stop the project.

By day five, produce a one-page architecture and a decision worksheet with named owners. Put an engineer, operations lead, product owner and compliance representative in the same review. If an own engine is only being considered to improve execution on an external venue, test whether smarter routing or connectivity changes address the actual bottleneck first.

Days 6-20: prove the order path under stress

Build a thin vertical test rather than a broad prototype. For a venue route, connect a certification or test environment, establish and recover sessions, submit and amend orders, reconcile acknowledgements and consume market data.

Inject disconnects, delayed responses, duplicate messages and throttle errors. Verify that retries cannot create unintended duplicate orders and that local order state converges with the venue's state.

For an own engine, test the same client-facing path with a small instrument set. Use deterministic event sequencing and retain an append-only event log so the book can be replayed.

Test simultaneous orders at the same price, cancel-versus-fill races, self-trade controls, partial fills and restart from a checkpoint. A matching decision should not depend on thread scheduling or wall-clock differences between machines.

Run load tests with realistic order-to-trade and cancel-to-new ratios, not just a high rate of simple inserts. Measure gateway, risk, matching or venue, market-data fan-out and persistence separately. Test at expected peak and a higher burst, often 1.5-2 times the forecast peak as a planning case. Track p99 and p99.9 latency, rejects, queue depth, CPU saturation and recovery time. Keep the test configuration and results repeatable.

At day 20, review failure modes alongside the performance numbers. A fast path that loses order state during failover is not a viable execution path. Record what remains outside the prototype, including production monitoring, access controls, change approvals, disaster recovery and support coverage.

Days 21-30: make the decision and stage the release

Use the final ten days to compare the evidence against the thresholds set in week one. A venue route is usually the stronger choice when external liquidity, certification and established market operations matter more than control over matching rules. An in-house engine is more plausible when the firm has a specific product or workflow the venue cannot support, a credible liquidity plan and enough staff to own continuous operations.

Do not treat the choice as irreversible. A hybrid design may route some instruments to venues while matching a tightly defined internal flow, provided the legal model, client disclosures, conflict controls and surveillance support it.

Keep order identifiers and execution records traceable across the boundary. Define which system is authoritative for each state transition, and reconcile fills, fees and positions.

1. Days 21-23: compare three-year operating costs, latency distributions, failure tests and unresolved dependencies.
2. Days 24-26: review the design with operations, security, compliance and the teams responsible for liquidity and post-trade processing.
3. Days 27-28: document the decision, owners, launch limits, rollback trigger and service objectives.
4. Days 29-30: approve the next phase. If evidence is incomplete, extend the test or keep the existing route rather than disguising uncertainty as a go-live date.

A first release should limit instruments, clients, order types and exposure. Use shadow traffic where it is safe and meaningful, then a controlled cohort with clear kill switches and staffed support. Monitor rejects, stale market data, unmatched executions, queue depth and reconciliation breaks. The plan succeeds when the team can explain why the chosen model fits, what it will cost to run and how it will fail safely.

FAQ

How long does it take to build a matching engine?

A production-grade build commonly takes 12-30 engineer-months, depending on product scope, resilience, risk controls and existing components. That estimate does not guarantee regulatory approval, liquidity or a production launch within 30 days.

Is an in-house matching engine faster than a venue?

The matching path inside an engine can be tens to hundreds of microseconds, but that excludes other parts of the order journey. A venue route adds connectivity and venue processing, while colocation and protocol choices can materially change the result. Compare like-for-like p99 measurements under load.

What should a venue integration test cover?

Test session recovery, order entry and amendments, throttling, duplicate or delayed messages, market-data gaps and reconciliation. Include cancel-versus-fill races and verify that local order state recovers after disconnects.

How many engineers are needed to operate an own matching engine?

Typical planning ranges are about 3-8 FTE across software engineering, SRE and on-call coverage. Trading hours, instrument count, resilience requirements and existing support teams can move the figure substantially.

What should the team ask before approving an engine build?

Ask which measurable constraint a new engine removes, and whether routing or connectivity changes could address it at lower cost. Then identify who owns liquidity, recovery, surveillance and 24-hour incident response if the engine goes live.

Which measurable constraint would justify owning the matching engine, and who in the team would own its failure at 03:00?

#latencia de ejecución #infraestructura de trading #conectividad con centros de negociación #matching engine implementation #venue execution #order matching system #order book design #trading system testing