amBrain

Matching engine development: what gets built around the engine, and what to ask

Published Sep 23, 2026Facts checked: Sep 23, 2026

Short answer

Matching engine development is only partly about the matching rule, which fits on one page. Most of the work is the venue around it: a member gateway and sequencer in front, pre-trade and credit checks, market data and drop copy going out, market phases and halts, a journal that makes every session replayable, and failover that loses no acknowledged order. Scope these together with the engine, or the engine is rewritten when they arrive. License an engine when your market rules are standard; build one when the rules, the latency at the member's socket or the fee structure are what your venue sells.

On this page

What does a matching engine development company actually build?

How the order book, the matching loop, the journal and the replay harness are designed is covered in designing a matching engine in Rust. This page is about everything a venue needs around that core, because that is where most of a project's time goes.

Components of a trading venue around the matching engine
ComponentResponsibilityDecide early
Member gatewaySessions over FIX, binary or WebSocket protocols; authentication; message throttlesWhich protocols members get on day one, and what happens to their orders on disconnect
SequencerPuts every inbound command in one total order and stamps itTimestamps are input data, never read by the engine itself
Pre-trade and credit checksMember limits, price collars, maximum order sizeWhich checks sit before the sequencer and which after it
Matching engineApplies commands to the book under the venue's priority rulePrice-time or another priority rule, order types, self-trade prevention
Market data publisherTop of book, depth, order-by-order feeds; snapshots and incrementals with sequence numbersWhether a retransmission service exists for members who miss packets
Drop copyA copy of every execution to members' risk and back-office systemsPer member or per trader, and what happens during a reconnect
Market phasesPre-open, opening auction, continuous trading, closing auction, haltsThe auction uncrossing algorithm and who can trigger a halt
Post-trade interfaceTrades to clearing and settlement, or to a wallet ledger for cryptoWhether fees are computed in the engine or after it
Surveillance feedEvery order event, in sequence, for market abuse monitoringRetention period and who can query it
AdministrationInstrument listing, tick and lot tables, fee schedules, expiriesWhat can change intraday and what only between sessions
ResiliencePrimary and standby with a replicated journalRecovery point: no acknowledged order may be lost

Which market rules have to be written down before the engine exists?

The rulebook is a product decision, and every ambiguity in it becomes a bug later. Write these down with worked examples before the first line of the hot path.

  • Order types and time-in-force. Limit, market, stop, stop-limit; day, good-till-cancelled, immediate-or-cancel, fill-or-kill. DXmatch's product page lists "Limit, Market, Stop, Stop-limit" and "DAY, GTC, FOK, IOC", a reference point for what a vendor engine ships[1].
  • Priority rule. Price-time is the common default in order-driven markets; pro-rata or a hybrid changes the data structures, not only a parameter.
  • Self-trade prevention. Cancel the resting order, the incoming one, or both, and at which level: account, trader or firm.
  • Price protection. Collars around a reference price, and what happens to an order outside them.
  • Auctions. How the opening price is found, which orders participate, and how imbalance is published.
  • Disconnects. Whether a member's orders are cancelled when its session drops. The FIX session layer lets a sender skip stale orders on resend instead of replaying them[5], so members expect the venue's rule to be explicit.
  • Corrections. Who may bust or adjust a trade, and how the correction reaches market data and drop copy.

How is a matching engine build staged?

Stages of a matching engine build and the evidence each one produces
StageOutputEvidence it is done
1. RulebookWritten market rules with worked examplesTest vectors: input sequences with expected output events
2. Reference modelA slow, obviously correct implementation of the rulesPasses every test vector
3. Engine, journal, replayThe production engine and its append-only journalReplaying a session reproduces the event stream byte for byte; engine and reference model agree on generated sequences
4. Gateway, market data, drop copyMember-facing interfacesA member conformance test suite, run by someone who did not write the gateway
5. Failover drillsStandby takeover under loadMeasured recovery time and zero lost acknowledged orders across repeated drills
6. Load at the burst profileLatency distribution per pathp99 and p99.9 from gateway in to acknowledgement out, under load sent at a fixed rate
7. Member certification and launchMembers connected and certifiedMock trading sessions with real members before the first live session

What goes wrong when these parts are added late?

  • A fast engine behind a slow gateway. Decoding, validation and serialisation at the boundary often cost more than the match itself. Measure from the member's socket, not from the engine's input queue.
  • Auctions added late. An opening auction needs its own book state and its own price discovery; bolting it onto a continuous-only engine touches the core.
  • Market data without recovery. A member who misses a packet needs a snapshot or a retransmission path; without one, every gap becomes a support call. How fan-out behaves under bursts is in sequence gaps under bursts.
  • Failover proven only on paper. A standby that has never taken over during a busy session has not been tested.
  • Determinism broken by convenience. Reading the clock, iterating a hash map or depending on thread timing inside the matching path makes replay diverge.

Should you license a matching engine or build one?

Several vendors sell exchange cores. None of those below publishes a price.

Licensed and open-source matching engines next to a custom build
OptionWhat the vendor publishesDeploymentPrice
DXmatch (Devexperts)"Modular system built for launching exchanges and dark pools": price-time priority, market data, risk controls, admin UI; "FIX 5.0 Trading and Drop Copy"; "Opening auctions"; "sub-100-µs end-to-end order-processing latency at the 99th percentile"[1]"RPM packages for Linux: deploy on bare metal for lowest latency or in AWS or Google Cloud"[1]Not published[1]
ExberryAn "Exchange in a Box" for regulated, digitised, prediction and alternative markets; "We can adjust the service to run dedicated and shared models, and control the level of data segregation both from physical and logical aspects"[2]"across cloud platforms such as AWS, Google Cloud and Azure, as well as bare metal and on-premises deployments"[2]Not published[2]
Nasdaq EqlipseSold as "fully managed services mandates where Nasdaq hosts and manages the clients' entire trading environment" or as an "AWS-hosted SaaS deployment"[3]Nasdaq-hosted or AWS-hosted[3]Not published[3]
OpenDAX (Openware)"Open-Source Cloud-Native Digital Asset & Cryptocurrency Exchange Platform" under Apache-2.0[4]Self-hosted[4]Free licence; the repository's last push was 2 December 2023[4]
Custom buildYour rulebook, your priority rule, your order typesWhere your members and your regulator need itBuild cost plus operations; no licence fee or revenue share

License when your market is standard for its asset class and your advantage is membership, listings or distribution. Build when the rulebook is unusual, when latency at your members' sockets is what you compete on, or when a per-volume or managed-service fee would outgrow the cost of running your own team. The same choice for a crypto venue, with the kits priced side by side, is on white-label exchange vs own matching engine and HollaEx vs OpenDAX.

What should you ask a matching engine developer?

  1. 1.Show a venue you built that is in production, and explain who operates it today.
  2. 2.How do you prove determinism: what does a replay test compare, and how often does it run?
  3. 3.What is the latency distribution from member socket to acknowledgement, at which percentile, under what load shape?
  4. 4.How long does standby takeover take, and has it been drilled under load?
  5. 5.How are auctions, halts and trade corrections reflected in market data and drop copy?
  6. 6.What do we receive at the end: code, rulebook tests, runbooks? Does anything stay yours?

Who should not build a custom matching engine?

  • A crypto exchange launching a standard spot market to test demand. A white-label kit is faster; HollaEx alternatives and ChainUp alternative show how those are priced.
  • A broker that routes client orders to existing venues. That is an order management and connectivity project, not a matching engine; see trading platform development company.
  • A venue whose licence application has not started. Rules, capital and reporting obligations come from the regulator, and the engine follows them.

About amBrain

  • amBrain is a software development company specializing in trading platforms, matching engines, real-time bidding systems, and casino platform engineering.
  • amBrain builds crypto exchanges: matching engine, wallets, deposits and withdrawals.
  • A mini-exchange running in production on MOEX colocation.
  • Three formats: full delivery, a dedicated team, or engineers embedded in your team.
  • The client keeps full ownership of the product and the code, except our reusable components.

Frequently asked questions

A member gateway, a sequencer, pre-trade checks, market data and drop copy, market phases and auctions, a post-trade interface, a surveillance feed, administration tools, and a standby that takes over without losing acknowledged orders.

Price-time is the common rule for order-driven markets, and vendor engines such as DXmatch document a "Price-time priority algorithm"[1]. Pro-rata or hybrid rules suit some derivatives markets and change the book's data structures, so decide before the engine is written.

Yes. DXmatch ships as RPM packages for bare metal, AWS or Google Cloud[1], and Exberry runs on AWS, Google Cloud, Azure, bare metal and on-premises[2]. Venues whose members compete on latency usually run the engine and gateways in a data centre that offers colocation.

Against a written rulebook with test vectors, a slow reference model run on the same inputs, deterministic replay of recorded sessions, and failover drills under load. The design article covers the replay harness and the invariants it checks.

License when your rules are standard and time to market matters more than control; none of the vendors above publishes a price, so compare quotes on the same rulebook[1][2][3]. Build when the rulebook, the latency at the member's socket or the fee structure is your product. Where to start with your own trading platform covers the decisions that come before either.

Product and company names are trademarks of their respective owners and are used only to identify their products. No vendor named here reviewed or endorsed this page.

Sources

  1. [1]Devexperts, DXmatch matching engine product page (positioning, order types, FIX 5.0, opening auctions, latency figure, deployment packages; no price). Vendor's own page · checked Sep 23, 2026
  2. [2]Exberry, SaaS and cloud deployment page (dedicated and shared models, deployment targets; no price). Vendor's own page · checked Sep 23, 2026
  3. [3]Nasdaq, Inc., Nasdaq Reports Second Quarter 2025 Results (Nasdaq Eqlipse delivery models), Jul 24, 2025. Press · checked Sep 23, 2026
  4. [4]GitHub (Openware), openware/opendax repository metadata (description, licence and date of the last push). Official documentation · checked Sep 23, 2026
  5. [5]FIX Trading Community, FIX Session Layer, Technical Standard, June 2020 (ResendRequest handling and gap fill), Jun 1, 2020. Specification · checked Sep 23, 2026

Related

Free project intro call, 30 minutes.

We reply within 24 hours.

Book a Call