5 October 2026 · 3 min read

Matching engine development, what correct actually means

Price time priority, partial fills, self trade prevention and the millisecond nobody tests. The part of an exchange that has to be right rather than fast.

The matching engine is the smallest component in an exchange and the one with the least tolerance for being nearly right. Everything else can be fixed on Tuesday; a mismatched fill is somebody's money.

What it has to do

• Price time priority. Best price first; at the same price, earliest order first. Simple to state, easy to get subtly wrong under concurrency.
• Partial fills. A large order consumes several resting orders and leaves a remainder. Each piece is its own trade record.
• Order types. Limit and market at minimum. Stop, post only and immediate or cancel when the venue grows up.
• Cancel correctly. A cancel racing a fill must resolve one way, deterministically, with the user told the truth.
• Self trade prevention. One account should not trade with itself, by accident or by design.
• A deterministic sequence. Every event ordered and numbered, so the book can be rebuilt from the log exactly.

Fast is not the requirement

New operators ask about throughput first. Unless you are running a derivatives venue with professional flow, your bottleneck will be users, not the engine. A straightforward single threaded engine handling a few thousand orders a second is far beyond what a new venue sees, and it is much easier to prove correct.

Correct and boring beats fast and clever, every time, in the one component where an error is indistinguishable from theft.

How it gets tested

This is what separates a real engine from a demo.

• Deterministic replay. Feed a recorded sequence, rebuild the book, compare byte for byte.
• Property tests. For any random order sequence: no negative balances, no crossed book, total in equals total out.
• Concurrency tests. Cancel and fill arriving in the same instant, repeated thousands of times.
• Reconciliation. Balances derived from the trade ledger must equal the balances on record. Run it continuously, not once.

If balances are a column somebody updates rather than a ledger you can replay, none of the above is possible, which is the single most useful thing to check in any codebase. It is also the test applied when taking over somebody else's build.

Build, buy or borrow

• Open source engines are a good study and a reasonable base when someone owns them afterwards.
• A written for you engine is what a from scratch build at $999 includes, with the order types a spot venue actually needs.
• No engine at all is the right answer more often than people expect: a swap quotes rather than matches, and launches with no users.

Questions

What does a matching engine do

It pairs buy and sell orders by price and time, produces fills, maintains the order book and emits a deterministic sequence of events that the rest of the exchange depends on.

How fast does a matching engine need to be

Far slower than most people assume. A new venue is limited by users, not throughput, and a simple engine that can be proven correct beats a fast one that cannot.

What is price time priority

Best price is matched first, and among equal prices the order that arrived first is filled first. It is the fairness rule that makes a book trustworthy.

What is self trade prevention

Stopping one account from matching against its own orders, which otherwise creates fake volume and distorts your own market data.

How do you test a matching engine

Deterministic replay against recorded sequences, property tests asserting no crossed book and no negative balances, concurrency tests for cancel against fill, and continuous reconciliation of balances against the trade ledger.

Do I need an engine for a swap platform

No. A swap quotes a price and sources the other side, so there is no book to match. That is exactly why it can launch with no users.