LiquidityWell have built an industry leading fully featured Matching Engine applicable across multiple asset classes. The following paper outlines this product, its features and how we are able to process more than 1 million Orders Per Second (OPS)
About LIQUIDITYWELL
LiquidityWell Ltd supplies technology solutions to organizations operating within the Financial Electronic Trading domain. Our clients’ demand includes high data throughput with low deterministic latency and smart data analytics. Our software delivers these attributes for companies operating central exchange venues or as clients of those venues. 100% of the code and intellectual property belong to LiquidityWell, which is offered to clients on a lease or copy purchase basis.
The Matching Engine (ME)
The matching engine is the heart of the exchange technology, the point where the interests of buyers and sellers find each other, and trades occur because of order matching. The matching engine holds a limit order book, one for each instrument, with the set of orders that haven’t matched yet.
The matching process for each discreet instrument is strictly sequential. Order requests can be processed concurrently before they reach the matching engine, hence the matching engine is often the bottleneck for the throughput of the exchange. The number of requests an exchange can process per second is limited to the number of requests the matching engine can process per second. The LiquidityWell matching engine helps overcome these constraints
ME Performance
The LIQUIDITYWELL Matching Engine (ME) is designed and developed in a fundamentally different way to any other engine we have seen, making it the most performant available on the market.
Critically and most different from all other engines we have examined, our ME exhibits a “big-O” of 1 (for the data sets sizes under consideration within Exchange Matching. Every ME we have previously been exposed to exhibits a big-O of log (n).
Simply put, with our ME, we can process at a constant, ultra-low latency, order books with 1 order or 1,000,000 orders in the resting order book. The key stand out is that other MEs have significant speed and throughput degradation as the number of resting orders increase – we do not. The ultra-low latency performance of the LIQUIDITYWELL Matching Engine is maintained as scale increases. Put another way, when the market events cause a spike in activity, the very time the exchange needs consistency, the LiquidityWell ME will retain its underlying latency profile.
Basic Testing Example (average nanoseconds per order)
Follow test were designed to measure the speed of the order book, a “real world” order message was used but no business logic was added (see below for available business logic). All conducted on a machine with just an i5 intel processor.
Test: To populate and then delete orders from a book
| Description | Number of Orders | Order Book | Time in nanoseconds per operation – 3 test runs per scenario and the average recorded across all three tests |
| Insert bid orders into the order book. | 100,000,000 | randomly distributed over 1,000 price points | 14.960 14.769 15.158 Average 14.963 |
| Insert ask orders into the order book | 100,000,000 | randomly distributed over 1,000 price points | 15.007 15.421 14.492 Average 14.974 |
| Randomly delete bid orders resting in the order book | 100,000,000 | randomly distributed over 1,000 price points | 6.724 6.950 6.736 Average 6.804 |
| Randomly delete bid orders resting in the order book | 100,000,000 | randomly distributed over 1,000 price points | 6.740 6.850 6.775 Average 6.790 |
Conclusion
The insertion and deletion timings for 100,000,000 orders, shown here, and the similar results for partials of this order size, not displayed, demonstrates O(1) performance and not O(log n) as would be the case if a tree indexing structure were used.
If latency or processing bottlenecks are in anyway a consideration or fear, then this factor is of critical importance. It is not uncommon for developers to show insert and deletion timings for smaller order books, for example 1, 10 or 100 orders. We run our numbers over 1,000,000+ orders, and this can equally be demonstrated.
Here’s an external explanation of big-O in simple terms:
http://stackoverflow.com/questions/487258/plain-english-explanation-of-big-o
Matching Engine Business Layer
The business logic layer of the matching engine covers multiple scenarios and trade types. It has been written to cover the functionality in both Spot and Derivatives products, it is flexible enough to support both Auction and CLOB execution. The final feature set to be included with the ME would depend on the business requirement. The following summarizes the features that can be included. The caveat being that business functionality and order profile impact latency and throughput. Therefore, any final latency and throughput discussions must be tested with real life order messages and flow.
| Category | Feature | Description |
| Matching Engine | Central limit Order Book – price | Standard bid offer order book, with bid at a lower value than the offer – suitable for price order books |
| Central limit Order Book – yield | Inverted bid offer order book, with bid at a higher value than the offer – suitable for yield order books | |
| Auction Fixed Price | Auction book created on instrument that match on a pre-announced price point. | |
| Auction Variable Price | Auctions book created with a trade price calculated in order to clear the maximum buy and sell order volumes. |
| Category | Feature | Description |
| Orders | Limit | Order is entered at a user defined price and will execute on entry up until said price point and thereafter residual quantity will reside in the resting order book. |
| Market | Orders entered without a price specified that will execute with available matching quantity on the contra side of the market, any residual will be removed from the market. | |
| Market Limit | As a market order above but will execute only up to a user defined price point | |
| Stop Market | A user defined trigger price point will, when reached by the last trade price, enter a market order into the order book. | |
| Stop Limit | A user defined trigger price point will, when reached by the last trade price, enter a limit order into the order book. | |
| Stop Market Limit | A user defined trigger price point will, when reached by the last trade price, enter a market order into the order book up until a specified limit price defined by the user | |
| Trailing Stop | The ability to enter a stop order that will change as the market moves in the users’ favor | |
| Take Profit Limit | A limit order is entered into the market when the trigger price is reached by the last traded price. | |
| Take Profit Market | A market order is entered into the market when the trigger price is reached by the last traded price. | |
| Post Only | A limit order that will enter the market only if the order will not execute on entry. | |
| Hidden Order | A limit order that is not seen by the market and will sit at a price point in a priority below the shown orders. |
| Category | Feature | Description |
| Time in Force | Day | Order that will remain in the order book until the end of day |
| GTC | Orders that will be remain in the order book until the user deletes then and can carry across multiple days | |
| FAK | Fill and Kill order that will execute on entry up to the size specified and then be removed from the market | |
| FOK | An order that will either execute in full on entry into the market or not at all. |
| Category | Feature | Description |
| Others | Disclosed Quantity | Quantity shown to the market |
| Iceberg | The ability to not disclose all quantity to the market | |
| Own vs Client Orders | The ability to enter an order on behalf of a third party | |
| Self-Match Prevention | The ability to set up a rule to restrict the trading between either the same user or economic owner of the order. |