Plataformas · Software · Provedores · Mercados
Nearly every broker or prop firm setup of this kind has an order gateway, a risk check and at least one venue connection. The harder decision is where orders should meet: inside a matching engine the firm operates, or on an external venue that supplies the book and execution rules.
These are not simply software choices. An internal engine means owning order priority, market data, fairness controls and failure recovery.
A venue means accepting its access model, fees, liquidity and operational limits. Many firms use both, with routing rules deciding which flow goes where.
The right comparison starts with the product and the firm's role. A prop firm matching its own traders against a simulated or internal book has different obligations from a broker routing client orders to a regulated exchange. In OTC markets, a broker may also stream prices from liquidity providers and execute against them without operating a public central limit order book.
Choose the execution model before the software
First define what a fill represents. On an exchange, the venue runs a rule-governed book and publishes executions under its market structure. At a broker, an order may be routed to an exchange, an ECN or a liquidity provider. An internal book may match two customer orders, or may record a firm's decision to take the other side. Those cases have different legal, disclosure and best-execution implications.
Write down the order types and trading behaviour the product needs. A basic market-and-limit workflow is much simpler than supporting iceberg orders, auctions, stop triggers, pegged prices, self-trade prevention and complex time-in-force rules. Each feature adds states to test, publish and recover after a disconnect.
- Use an external venue when access to established liquidity and a known rulebook matter more than control of matching logic.
- Consider an internal engine when the product needs a distinct market structure, controlled simulation, or matching across a pool the firm can lawfully operate.
- Use a hybrid when some flow can be matched internally but residual orders, hedges or instruments need external execution.
Map the full order lifecycle before comparing vendors or estimating engineering effort: client submission, pre-trade checks, sequencing, match or route, acknowledgement, fill reporting, ledger update and downstream reconciliation. This makes missing responsibilities visible. It also gives operations a clearer basis for service-level objectives and incident ownership.
Teams reviewing platform and provider choices can use Trading Technology's infrastructure coverage as a reference point, but the final design must follow the firm's products, jurisdictions and execution obligations.
What a venue gives you, and what it withholds
A venue supplies the matching rules and, usually, access to other participants. It may also provide market data, drop copy, test environments and formal procedures for halts, auctions and technical incidents.
The firm still owns its connection, client-facing order state, risk checks and reconciliation. A venue's acknowledgement is not a substitute for an internal record of what the client submitted.
External access can shorten time to market. A relatively standard FIX or native API connection may take several weeks to integrate and certify, although onboarding, market-data agreements and cross-connects can extend the schedule.
Connectivity choices matter: a broker using a regional network path may see round trips in the low single-digit milliseconds, while colocated or direct paths can be below a millisecond. The measured result depends on venue, instrument, geography and load.
The trade-off is dependence. Venues set tick sizes, order types, throttles, session windows, fee schedules and change calendars.
A gateway must handle sequence gaps, duplicate messages, stale market data, rejects and cancel-on-disconnect behaviour. If a session drops after an order is accepted but before its acknowledgement arrives, the client system needs a recovery process that asks for order status instead of blindly resending.
Venue access also does not guarantee usable liquidity. A displayed book can be thin, fragmented across venues or unavailable at the requested size.
Routing logic may need price checks, venue health scores, exposure limits and a defined fallback. For OTC products, a liquidity provider's quote and fill policy require separate monitoring, including reject rates and slippage by symbol and time of day.
Typical external-venue operating costs include connectivity, market-data licences, certification and ongoing support. Charges vary sharply by market and access tier. A plan should model per-message or per-order fees, market-data redistribution rights, cross-connects and the engineering time required for venue rule changes, not just the initial integration.
What operating a matching engine adds
An engine gives the firm control over the book and the timing of its own matching decisions. It can support product-specific rules, controlled trading sessions and a consistent interface across client channels.
That control is useful only if the firm can explain and prove how each order was handled. Deterministic sequencing, timestamp quality, immutable event records and repeatable replay are operating requirements, not optional diagnostics.
The engine is one component in a larger system. Production design commonly includes an order-entry gateway, pre-trade risk, a sequencer, matching logic, market-data publication, drop copy, persistence and recovery tooling.
Risk checks must have a defined position in the path. A check performed before the sequencer can race with another order unless exposure is reserved atomically or checked again at the right point.
For a central limit order book, engineers must specify price-time priority or another allocation rule, partial-fill behaviour, cancel and replace priority, self-trade prevention and what happens when a participant disconnects. The book must not lose an accepted order during a process failure. Replication, write-ahead logs, snapshots and recovery tests should demonstrate how the service rebuilds state and how clients learn whether an in-flight order traded.
There is also an ongoing fairness and control burden. Monitor for crossed or locked books, abnormal order bursts, stale prices and abusive patterns.
Keep an auditable trail that links client messages to risk decisions, book events, fills and corrections. Surveillance, compliance and support teams need tools to inspect that trail without making changes to live state.
For planning, an internal engine often needs a larger team and a longer validation cycle than a venue adapter. It also creates a larger incident surface: a matching defect can affect every participant connected to the book.
Resilience testing should cover process restart, network partition, storage failure, clock drift, market-data interruption and recovery with open orders. Performance tests should include realistic bursts and cancel-heavy traffic, not only steady-state throughput.
These estimates are broad planning ranges, not audited results for any named provider or firm. Product complexity, regulatory scope, existing components and certification requirements can move them substantially.
| Approach | Typical time to first production | Typical initial engineering team | Typical ongoing engineering cover |
|---|---|---|---|
| Connect to an established venue | 6-12 weeks | 2-5 engineers | 1-3 full-time equivalents |
| Build and operate a matching engine | 9-18 months | 8-20 engineers | 5-10 full-time equivalents |
| Hybrid engine and venue routing | 4-9 months | 5-12 engineers | 3-6 full-time equivalents |
Ranges above are typical market planning estimates. They assume a defined product scope and exclude lengthy licensing, major legacy replacement or a new clearing arrangement. A small internal simulator can be built faster, but it should not be treated as equivalent to a production venue with client money, live risk and resilient recovery.
Build a route that can fail safely
A hybrid design can preserve choice, but it does not remove complexity. Each route needs an explicit owner, eligibility rules and recovery behaviour. For example, an internal book may take only defined instruments and sizes, while other orders route externally. A hedge can be sent after an internal fill, but then the firm carries exposure between the customer execution and the hedge fill. That exposure needs limits and escalation rules.
Keep order state consistent across the gateway, risk service, engine or venue adapter, and client API. Use stable client order identifiers and idempotent handling so a retry cannot create a second live order.
Track venue identifiers separately. Reconciliation should compare acknowledgements, executions, open orders, positions and cash or margin records, with a defined process for breaks. Before choosing a build or buy path, run this sequence:
- Document the market structure. State who matches, who is counterparty, which order types are supported and where execution obligations sit.
- Measure the flow. Capture peak new orders, cancels, executions, concurrent sessions, symbol count and burst duration. Include market-data fan-out and expected growth.
- Set service objectives. Define accepted-order acknowledgement latency, recovery time, data-loss tolerance and availability targets. Measure percentiles under load, not only averages.
- Price the full operating model. Include venue and data fees, network links, on-call cover, certification, surveillance, disaster recovery and the cost of rule changes.
- Test failure paths. Simulate lost acknowledgements, duplicate execution reports, sequence gaps, stale prices, venue disconnects and engine restart with working orders.
- Assign control ownership. Name the team responsible for order state, limits, incident decisions, audit records and client communication. Make escalation paths explicit before launch.
Keep the first production scope narrow. One venue, a small instrument set and a clearly bounded order workflow make certification and incident diagnosis manageable. Add routes only after the team can reconcile every state transition and demonstrate safe behaviour during disconnects. The broader trading infrastructure reference library can help frame provider comparisons, but operational acceptance should come from tests against the firm's own traffic and failure cases.
This week, ask engineering and operations to produce one end-to-end order-state diagram for the highest-volume instrument, including every timeout, retry and recovery path.
Perguntas frequentes
When should a broker build its own matching engine?
Build one when the product requires matching rules or control that available venues cannot provide, and the firm can fund the engineering, surveillance and operational responsibilities. A simulator or internal book also suits some prop-firm workflows, but it is not automatically appropriate for client execution.
How long does venue integration usually take?
A relatively standard venue connection often takes about 6-12 weeks to reach production. Certification, market-data permissions, network setup and complex order workflows can extend that schedule.
Can a firm use an internal engine and an external venue?
Yes. A hybrid can match eligible flow internally and route other orders or hedges externally. It needs explicit routing rules, consistent order state, exposure limits and recovery procedures across both paths.
