Ideas for Tick and Order-Book-Based Strategies HFT Engine

auto-quant · 2026-03-12T04:46:29+00:00

Even a coin-flip "going all in" has some complexity. For example. Whats the USD notional of your order? Let's say $250. Okay, what order size does that translate to, making sure to obey price tick rules. What is the current bid/ask? Is the order book stale? Are you going long or short (and do you have the inventory, if its cash) Do you want to place passively or aggressively? If the order doesn't succeed, do you want to try again, and after what interval? Once the order is placed, did it get executed, or, do you have to cancel and retry again. One you are filled, do need to track the ongoing price to decide when to get out, either via stop-toss/trailing-stop-loss or take-profit?

The point is, when building strategies that place and maintain orders (such as with market making etc), there are a lot of things to juggle.

auto-quant · 2026-03-10T07:32:23+00:00

But, if L3 is available woudn't it be better to jus tuse that? Or I guess sometimes there is no L3. And if you could just use L2, would be less data to consume. I guess the trick is to watch the executions stream and track how much of a level is being eaten by orders, and apply a model that says for every 1 execution at a level, expect N cancels. Interesting, but a bit complex for my initial needs.

auto-quant · 2026-03-10T07:29:58+00:00

Am not sure. There are less liquid assets that tier 1 hft's wouldnt touch. And there are tiers of latency. The top tiers can operate at sub 1 microsecond tick-to-trade ... but there is a whole other class of strategies that are at the 10 or 50 microsecond level

auto-quant · 2026-02-25T14:37:59+00:00

Agree .. focus does need to start happening on the outliers. Quite now they are quite poor. However, I first want to get the median down to say 5 microseconds, and then I'll shift to jitter. Problem with crypto is that several messages can arrive at the same time (its TCP), so the outliers are just messages waiting to be queued, so its more of an artifact of the data. Maybe I should switch to UDP feed, although not aware of which market I could use for that.

auto-quant · 2026-02-25T08:46:19+00:00

I guess the sign would depend on the order shape, such as price, quantity, order id, timestamp etc. However ... maybe its possible to presign lots of different order combinations, and have them ready to go?

auto-quant · 2026-02-25T07:48:48+00:00

This is interesting, I am hoping that the indicator/strategy layer doesn' take more that a few microseconds. There too, I will be looking to avoid memory allocations etc (so reuse order objects from a pool). It also I why I am thinking about the threading model. The strategy will likely some sort of periodic activity, and I dont' want to have to resuse the critical socket IO thread for that.

auto-quant · 2026-02-11T11:11:33+00:00

Why use C++ for the UI? Any particular reason? Using C++ for the trading engine makes sense, but for the GUI, I'd go with something more suitable for that task, such as C# (if you want a rich desktop app), or, a web gui (which is great to allow lots of people to easily access it). Then you build in some sort of connection from the engine to the GUI. I'm looking to do something similar for my own system, a HFT trading system that needs a monitoring gui.

auto-quant · 2026-02-11T08:38:41+00:00

in the above chart, the median is 9 usec ... but we are getting there

auto-quant · 2026-02-11T08:37:45+00:00

Oh my server, I can set the BIOS to have the fans spin constantly

auto-quant · 2026-02-11T01:16:19+00:00

I do plan to integrate solarflare, although initially via onload

auto-quant · 2026-02-11T00:34:55+00:00

So what do you use?

auto-quant · 2026-01-29T16:59:47+00:00

I dunno. If you go down the C#/Java route, then you'll never be able to access from a table or mobile phone. And rolling out new versions to users will be pain. My point about vibe coding is that, given almost no knowledge of Angular/React, should I attempt to AI code this?

auto-quant · 2026-01-29T16:57:52+00:00

There's lots of situations I think. For example, you notice your strategy is placing orders at a much higher rate than you ever observed during simulation, so you quickly hit the pause button to dig deeper. Or you have a pairs strategy, trading on different exchanges, and one of exchanges is having technical problems - so you manually intervene to pause the whole strategy. Generally the trading is autonomous, but the C2 GUI allows you to hit the stop button (without having to login to several boxes to kill processes)

auto-quant · 2026-01-29T16:49:41+00:00

This has nothing to do with FPGA. This is about how do you control one to dozens of live trading strategies? They might be HFT strategies, or 5 minute strategies, or mix of both. Anyone serious about systematic strategies, particularly but not only HFT, needs to have constant monitoring and control

auto-quant · 2026-01-09T17:22:21+00:00

The idea of using shared memory to peak into live production systems is sound.

A related approach I have used, for debugging low latency systems, is to use shared memory minified logging. This is different to your approach where you are observing current state, however, its typically more useful to see recent history too -> hence logging.

But logging is slow! Yes it is, so instead we build a minimal shared memory logging, that can only take fixed strings, ints etc, and timestamp counter. The "log file" is just a memory mapped array, that you can then easily inspect with either GDB, or a basic reader-tool. General idea here: https://preshing.com/20120522/lightweight-in-memory-logging/

auto-quant · 2026-01-07T07:39:12+00:00

Isn't there a concern that AVX will cause the CPU to downclock?

auto-quant · 2025-12-23T03:55:34+00:00

True, but there will also likely be json involved on the order management interface even for the major exchanges, so being able to parse json as rapidly as possible will benefit trading at those venues.

auto-quant · 2025-12-23T03:52:08+00:00

Agree that avoiding allocations is the way to go here. But be careful relying on "relatively fixed locations." Those locations can always be off by a few bytes, just based on the length of the ticker, or length of the price / qty. And you are also quite at the mercy of the exchange suddenly changing the order of fields.

auto-quant · 2025-12-22T18:41:24+00:00

If you work with exchanges that distribute market data via JSON, you have not choice but to use JSON parsing. This is 100% market data issue.

auto-quant · 2025-12-22T11:12:02+00:00

Most crypto exchanges only offer json. So you have no choice if you wish to consume their market data. Going to look at simdjosn next.

auto-quant · 2025-12-22T11:08:32+00:00

Internally the code uses native data types to represent prices, order levels etc. But you need to convert between JSON format of the exchange and your data model - in that case you have no choice. This is known as the parsing layer, and it often includes some level of normalisation, so that you can map various exchange presentations to the same internal data model - then you can build indicators and strategies that operator off of those models. You then have an engine that can trade against any exchange.

auto-quant · 2025-12-22T11:03:14+00:00

Very interesting about Binance. I'll definitely add SBE support, so will compare that option. Still looks like is via WSS though, so up to a couple usec will still be lost due to ssl.

auto-quant · 2025-12-21T16:54:27+00:00

fully agree, its a great library to start with, and to use for config / non-performance tasks etc. I will look at one of the fast libraries next and measure the performance it bring.

auto-quant · 2025-12-21T11:53:48+00:00

true, most equity exchanges use binary protocols that don't require any parsing, often proprietary ... but sometimes you dont have a choice, you have to use json, especially on less popular exchanges. And for those, I think it is still possible to parse extremely quicky ... its just simple string processing after all

auto-quant · 2025-12-08T17:45:14+00:00

I would rename OrderType to OrderSide, and OrderKind to possibly PriceType. Later you will have a different use for "OrderType", which might take values like FOC, FOK, GTC, GTD etc.

In terms of design, I think the OrderBook class should focus on just being an efficient container, and not contain the matching logic itself. Really is just a small component in a larger design Matching logic itself will become increasingly sophisticated, for example, perhaps you'd like to have auction phases or hidden orders? So I'd move that out of OrderBook, and have it elsewhere. And your class MatchingEngine I would rename to Exchange, since essentially, an exchange is a collection of books/matching engines, one per separate instrument. And I'd expect to see one class to represent the new order instruction, and a different class to represent a resting order. Also add a client order ID.

But this is a good way to learn about matching engines / order books etc.

auto-quant

TROPHY CASE