Plataformas · Software · Provedores · Mercados
A matching engine is software that pairs compatible buy and sell orders under a defined allocation rule.
That definition hides the difficult part: the engine is only one component in a service that must accept orders safely, publish consistent prices, manage risk and recover without creating duplicate trades. Using a venue outsources some of those functions, but adds connectivity, commercial and dependency risks of its own.
Define the boundary before comparing latency
There are at least three different choices often compressed into "build or buy". A broker can route client orders to an exchange or liquidity provider.
It can use a vendor-hosted engine under its own brand. Or it can operate an engine that matches orders internally, potentially against the broker's own liquidity. Those models have different technical and regulatory boundaries. An engine does not, by itself, make a firm an exchange, nor does connecting to a venue transfer every obligation to the venue.
For an owned book, the matching rule must be explicit and testable. Price-time priority is common: better-priced orders execute first, then earlier orders at the same price.
Other allocation rules, such as pro-rata, change both participant expectations and the data the system must retain. Specify how the engine handles partial fills, self-trade prevention, cancel-replace priority, minimum quantities, price collars and rejected orders. If those rules live in undocumented application code, operations cannot reliably explain a fill or reconcile a dispute.
A venue connection shifts the matching decision elsewhere, but not the work around it. The broker still needs to map client identifiers, translate order types, enforce pre-trade limits, handle rejects, monitor sessions and reconcile its records against venue execution reports. Each venue can interpret fields and session recovery differently. A FIX connection that passes certification is not proof that reconnects, bursts, stale market data and partial fills behave correctly in production.
Write down the system boundary before an architecture review. Include where credit checks run, which system owns the order state, where trade records become authoritative and who can halt trading. This is the level of detail that makes platform choices comparable. Trading Technology's infrastructure coverage provides further context on the systems brokers operate around execution.
- For an owned engine, define sequencing, allocation, risk checks, market data publication, persistence and kill controls.
- For venue access, define routing policy, session ownership, reject handling, market-data quality checks and reconciliation.
- For either model, identify which team can declare a book safe to reopen after an incident.
Latency is a budget, not a product claim
Comparisons often put an engine's matching time beside a venue's round-trip time. These are different measurements. A matching decision may take tens of microseconds inside one process, while an order's full path includes gateway parsing, risk checks, network transit, venue queues and acknowledgement handling. A fast matching core does not help if a serial risk call or overloaded gateway adds milliseconds.
Measure the complete path with a monotonic clock and consistent event definitions: client ingress, risk decision, venue send, acknowledgement, execution report and client egress. Track median, p99 and p99.9, not just an average. A 200-microsecond median can coexist with multi-millisecond tails during bursts or garbage collection. For an external venue, separate your gateway and network contribution from the venue's own processing time where the protocol and timestamps allow it.
The table gives indicative typical market ranges, not audited results for any provider. They vary with asset class, order rates, hosting location, protocol, certification scope and resilience requirements. Compare like with like, including whether figures cover risk checks and network hops.
| Measure | Owned engine, typical range | Venue connection, typical range |
|---|---|---|
| Matching or venue response path | 5-100 microseconds for an optimised in-process match | 0.5-10 milliseconds for a network-inclusive order acknowledgement |
| Order acknowledgement, colocated or same-region setup | 0.1-1 millisecond within a tightly controlled stack | 1-10 milliseconds, depending on route, venue and protocol |
| Initial production delivery | 6-18 months for a production-grade engine and surrounding controls | 2-12 weeks per venue connection, excluding lengthy commercial onboarding |
| Core 24/7 technical coverage | Typically 4-8 engineers, with risk and infrastructure support beyond that | Typically 1-3 engineers for connectivity, with shared operations and dealing coverage |
Do not choose an owned engine because a benchmark beats a venue's published figure. A broker serving retail flow may care more about predictable execution, fair pricing and recoverability than shaving a fraction of a millisecond. A prop firm running latency-sensitive strategies may care more about deterministic tails, queue position and physical distance to the venue. Both need a workload replay that includes realistic bursts, cancels and market-data fan-out.
Liquidity and market integrity are the hard parts
A venue supplies access to counterparties and a rulebook. An owned book has to attract enough two-sided flow to make prices useful. A technically correct order book with sparse depth can widen spreads, produce intermittent fills and leave users trading against a stale reference price. If the firm is also the main liquidity provider, it must define how quotes are generated, when they are withdrawn and how inventory and adverse selection are controlled.
Internal matching also changes the conflict and surveillance picture. The firm must preserve an auditable sequence of events, explain allocation outcomes and monitor for abusive behaviour.
Controls commonly include price collars, fat-finger limits, message-rate limits, self-match prevention, trading halts and a clear procedure for cancelling or correcting erroneous trades. The precise obligations depend on the product, jurisdiction and business model, so involve compliance and legal teams before implementation, not after launch.
For a venue model, liquidity is not guaranteed just because a connection is live. A venue can reject orders, throttle traffic, change its schedule or lose a market-data channel while order entry remains available. The router needs policy for stale prices and venue outages. It should not blindly reroute an order if doing so could duplicate exposure or violate the client's instructions. Keep order state separate from transport-session state, and reconcile execution reports and drop-copy records against the broker's ledger.
In either model, record enough information to reconstruct the decision: the order version, relevant market data, risk checks, allocation or routing choice, timestamps and resulting fills. Retention and access controls should support investigation without allowing operators to rewrite history. A deterministic replay of the same ordered inputs should produce the same book state, or the system should clearly document which external inputs prevent that.
Price the operating model, not just the software
Vendor pricing is visible; the full cost of ownership is less so. A venue route can involve connectivity, market-data licences, certification, minimum fees and charges for order or message volume. An internal engine removes some venue fees only if the firm has a viable source of liquidity and is permitted to operate the model it intends.
It adds engineering, observability, on-call, capacity planning, security, testing and audit costs. Budget the service around the people and controls needed to run it, not the matching algorithm alone.
Staffing ranges in the table are directional. The lower end assumes a narrow product set, mature shared infrastructure and an experienced team.
A new venue, multiple asset classes, demanding uptime targets or bespoke surveillance can push the requirement higher. An owned engine also needs independent review of matching rules, resilience tests and operational procedures. Four engineers cannot provide solid 24/7 coverage if they are also responsible for every gateway, database and release.
Before committing to an owned engine, price the work that tends to arrive after the first successful match:
- Redundant gateways, sequencer recovery, durable event logs and tested failover.
- Market-data normalisation, snapshot recovery, throttling and client feed distribution.
- Risk limits, surveillance alerts, operator permissions and incident evidence.
- Load tests, fault injection, release controls, weekend maintenance and on-call cover.
A venue route also needs investment in adapters and operational tooling. A normalised internal order model can reduce application complexity, but avoid flattening venue-specific semantics that affect priority or execution. Maintain venue-specific configuration, version it, and test changes against captured messages. Certification time is only one part of delivery; production monitoring and support continue for as long as the connection is live.
Choose by failure mode, then test the hand-off
Start with what the business must control. If the requirement is access to established liquidity, routing to venues is usually the simpler operating choice. If the requirement is a proprietary market, a specialised allocation rule or complete control over internal order sequencing, an owned engine may be justified.
A hybrid is common: route externally for depth while matching eligible flow internally under explicit rules. It is also the model with the most complex state and conflict controls.
Run a failure exercise before making a build decision. Simulate a venue disconnect after order send but before acknowledgement, a duplicate execution report, a stale book, a full event log, a risk service timeout and a failover during a burst. Check whether the system can distinguish an order that was never accepted from one whose acknowledgement was lost.
Define whether it queries, cancels, waits or blocks new exposure. Never assume a reconnect means the remote and local books agree.
For an owned engine, test process restart from the event log, sequence continuity, duplicate client requests and recovery of market-data subscribers. Measure time to a consistent state, not merely time to start the process. Test the halt path independently from the normal order path, and ensure no single operator action can silently reopen a market without the required checks. For a venue model, regularly test session resets, throttling responses, sequence gaps and reconciliation against drop copy.
Use acceptance criteria that describe operating behaviour: maximum tolerated stale-data age, recovery time, un reconciled trade count, order-rate limits and who approves reopening. Tie each measure to an alert and a runbook. Engineers comparing platform architectures can use independent trading infrastructure analysis as a reference, but must validate the figures against their own traffic and venue contracts.
The mistake most readers will still make after reading this is treating the matching engine as the decision, rather than the operating model around it.
Perguntas frequentes
When should a broker build a matching engine?
Build one when the business needs control over allocation, internal liquidity or a specialised market model that venues cannot provide. Include the cost of risk controls, market data, surveillance, support and recovery in the decision. A matching algorithm alone is not a production service.
How long does it take to build a matching engine?
A production-grade engine and its surrounding controls typically take 6-18 months, depending on product scope, resilience requirements and team experience. Venue onboarding and certification can extend the timetable. A narrow prototype is not a reliable estimate of production delivery.
Is a matching engine faster than routing to a venue?
The matching decision inside an optimised engine can take 5-100 microseconds, while a venue order acknowledgement commonly includes network and processing time measured in milliseconds. These figures measure different parts of the path. Compare full order-to-acknowledgement and tail latency under realistic load.
What does a broker still need to manage when using a venue?
The broker remains responsible for order mapping, pre-trade risk, session health, reject and partial-fill handling, market-data checks and reconciliation. It must also decide how to respond when acknowledgements are lost or venue data becomes stale. Venue access does not remove the need for operational controls.
