Services
Matching engine development: what gets built around the engine, and what to ask
Updated Sep 25, 2026
Facts 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 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 the parts a venue needs around that core, because that is where most of a project's time goes.
| Component | Responsibility | Decide early |
|---|---|---|
| Member gateway | Sessions over FIX, binary or WebSocket protocols; authentication; message throttles | Which protocols members get on day one, and what happens to their orders on disconnect |
| Sequencer | Puts every inbound command in one total order and stamps it | Timestamps are input data, never read by the engine itself |
| Pre-trade and credit checks | Member limits, price collars, maximum order size | Which checks sit before the sequencer and which after it |
| Matching engine | Applies commands to the book under the venue's priority rule | Price-time or another priority rule, order types, self-trade prevention |
| Market data publisher | Top of book, depth, order-by-order feeds; snapshots and incrementals with sequence numbers | Whether a retransmission service exists for members who miss packets |
| Drop copy | A copy of every execution to members' risk and back-office systems | Per member or per trader, and what happens during a reconnect |
| Market phases | Pre-open, opening auction, continuous trading, closing auction, halts | The auction uncrossing algorithm and who can trigger a halt |
| Post-trade interface | Trades to clearing and settlement, or to a wallet ledger for crypto | Whether fees are computed in the engine or after it |
| Surveillance feed | Every order event, in sequence, for market abuse monitoring | Retention period and who can query it |
| Administration | Instrument listing, tick and lot tables, fee schedules, expiries | What can change intraday and what only between sessions |
| Resilience | Primary and standby with a replicated journal | Recovery 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?
| Stage | Output | Evidence it is done |
|---|---|---|
| 1. Rulebook | Written market rules with worked examples | Test vectors: input sequences with expected output events |
| 2. Reference model | A slow, obviously correct implementation of the rules | Passes every test vector |
| 3. Engine, journal, replay | The production engine and its append-only journal | Replaying a session reproduces the event stream byte for byte; engine and reference model agree on generated sequences |
| 4. Gateway, market data, drop copy | Member-facing interfaces | A member conformance test suite, run by someone who did not write the gateway |
| 5. Failover drills | Standby takeover under load | Measured recovery time and zero lost acknowledged orders across repeated drills |
| 6. Load at the burst profile | Latency distribution per path | p99 and p99.9 from gateway in to acknowledgement out, under load sent at a fixed rate |
| 7. Member certification and launch | Members connected and certified | Mock 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.
| Option | What the vendor publishes | Deployment | Price |
|---|---|---|---|
| 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] |
| Exberry | An "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 Eqlipse | Sold 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 build | Your rulebook, your priority rule, your order types | Where your members and your regulator need it | Build 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?
- Show a venue you built that is in production, and explain who operates it today.
- How do you prove determinism: what does a replay test compare, and how often does it run?
- What is the latency distribution from member socket to acknowledgement, at which percentile, under what load shape?
- How long does standby takeover take, and has it been drilled under load?
- How are auctions, halts and trade corrections reflected in market data and drop copy?
- 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 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.
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]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]Exberry, SaaS and cloud deployment page (dedicated and shared models, deployment targets; no price). Vendor's own page · checked Sep 23, 2026
- [3]Nasdaq, Inc., Nasdaq Reports Second Quarter 2025 Results (Nasdaq Eqlipse delivery models), Jul 24, 2025. Press · checked Sep 23, 2026
- [4]GitHub (Openware), openware/opendax repository metadata (description, licence and date of the last push). Official documentation · checked Sep 23, 2026
- [5]FIX Trading Community, FIX Session Layer, Technical Standard, June 2020 (ResendRequest handling and gap fill), Jun 1, 2020. Specification · checked Sep 23, 2026
Building this system with an outside team?
Send us what you have: a design, a vendor quote or a list of requirements.
Free project intro call, 30 minutes.
We reply within 24 hours.