A Practical Order Matching Framework for High-Frequency Strategy Backtesting | by DolphinDB | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

A Practical Order Matching Framework for High-Frequency Strategy Backtesting

DolphinDB

10 min read·<br>3 days ago

Listen

Share

In medium- and high-frequency strategy development, the divergence between backtested and live performance is a well-known problem — and transaction costs are usually the culprit. Idealized backtests assume instantaneous, complete fills: a limit order at price P executes at price P the moment the market touches it. What this ignores is everything that actually determines execution quality: queue position, partial fills, order latency, and multi-level slippage. At HFT margins, these are not rounding errors — they determine whether a strategy is profitable.<br>Press enter or click to view image in full size

DolphinDB’s Order Matching Simulator replaces this abstraction with exchange-level matching logic. It ingests L2 snapshot or tick-by-tick data, reconstructs the order book at each point in time, and evaluates your orders against it using price-time priority consistent with SSE and SZSE trading rules. Latency, fill ratio, and order book depth are all configurable — and calibratable against observed live execution.<br>This post covers the engine’s architecture, walks through matching examples with real L2 order book data, and presents performance benchmarks at scale.<br>How the Order Matching Simulator Works<br>The simulator sits between your strategy logic and your output tables, acting as a synthetic exchange matching engine.<br>Press enter or click to view image in full size

The order matching simulator takes two inputs: the market data and the orders placed by the user. It simulates order matching according to the configured matching rules. Execution results are written to the trade details output table, including partial fills, order rejections, and order cancellations. Any unfilled portion remains pending for subsequent matching or cancellation.<br>Supports configurations such asfull ratio and latency.<br>When multiple user orders on the same side are matched simultaneously, executions follow price-time priority.<br>When the market data is tick-by-tick data, the matching engine builds the market order book in real time. When a user order arrives, it is immediately matched against the order book to generate execution information. Any unfilled portion then joins subsequent market orders and executed orders, and is matched thereafter according to price-time priority.<br>When the market data is snapshot data, a user order is immediately matched against the order book upon arrival, generating execution information. Depending on the order matching simulator configuration, any unfilled portion may continue to be matched against subsequent market snapshots.<br>Matching mode 1: Match against the latest traded price and the opposite-side order book at the configured ratio<br>Matching mode 2: Match against the list of trades within the interval and the opposite-side order book<br>Supported user order types include limit, market, and cancel orders. Different combinations of order types and market data types correspond to different matching rules; see later sections for details.<br>Key configurable parameters:

Case Study 1: Order Matching Based on Level 2 Snapshot Data<br>Using the snapshot order book at a specific time 2022.04.14T09:35:00.040 as the reference (Table 1), the latest traded price at that moment is 16.34. A user then places a sell order with a price of 16.32 and a quantity of 50,000. The order is then matched and executed under order matching mode 1 and order matching mode 2, respectively.

Matching orders using mode 1<br>In matching mode 1, a limit order is matched immediately against N levels of order book data, and for any unfilled portion of the resting order, subsequent market data is used first to match by price against the latest price within the interval, and then to match and execute sequentially against the order book at the latest point in time. In this scenario, set “matchingMode” to 1 and the interval fill ratio (matchingRatio) to 10%. The other configuration details are as follows:<br>config = dict(STRING, DOUBLE);<br>// Market data type: 0 indicates tick-by-tick, 1 indicates snapshot<br>config["dataType"] = 1;<br>// Matched order book depth, 5 - 50<br>config["depth"] = 10;<br>// Simulated latency, in milliseconds, used to simulate the delay from when a user order is submitted to when it is processed<br>config["latency"] = 0;<br>// In tick-by-tick mode, whether to output the order book: 0 = no, 1 = yes<br>config["outputOrderBook"] = 0;<br>// If order book output is enabled, the minimum interval for outputting the order book, in milliseconds<br>config["outputInterval"] = 1;<br>// Execution percentage against the order book<br>config["orderBookMatchingRatio"] = 1;<br>// In snapshot mode, two matching modes are available; set this to 1 or...