High-Frequency Trading Consulting
We take one market and one horizon at a time. A line has four parts: the forecast, the rules that trade on it, the risk layer around them and the path from a market event to an order at the venue. Teams running a high-frequency line reach us at one of two moments. Either nothing is built yet and the line has to be defined before any of it is written. Or a line already runs, and the question is whether a short-horizon forecast still adds anything to the rules behind it.
Four parts of one line, and any one of them on its own
- Alpha research
- A short-horizon forecast of the next mid-price move, fitted to your market and your horizon, then tested for whether it says anything your current rules do not. The model itself never travels. What travels is the process that builds it (order-book reconstruction, leakage controls, embargoed walk-forward validation, measurement out of sample).
- Strategy design
- When to act, in which direction, at what size and when to do nothing. Fees, queue position, fill assumptions, latency and failure scenarios sit inside the evaluation from the first version onwards.
- Risk controls
- Position and inventory limits, drawdown, markout on fills, trade-level statistics, explicit stop conditions. These get designed together with the trading logic. A risk layer fitted afterwards bounds whatever is easiest to measure.
- Production systems
- Two paths, kept apart: the hot path from a market event to an order, measured; and the slow path beside it carrying control, oversight, replay and dashboards. The slow path watches the hot one and has no say in what it does.
Any one of the four can be commissioned on its own. A new line still gets defined whole first (the market, the trading capital and how it is meant to grow, the technical and legal limits of the venue and the jurisdiction). Those constraints decide the parts, and the parts do not decide them. An existing system is opened at whichever part is holding it back today; the rest stays where it is.
The first week goes on finding out what is there
The first week is an inventory. What data exists and in what state; what the running code already does; what the request means once you take it apart.
- The data
- Where it comes from, what it records and where the record has holes in it. Gaps, resets and fields that quietly stopped being written are ordinary findings at this stage (they are also why a result can come out clean and mean nothing). Most of the questions worth asking later are settled here.
- The code you already run
- If a system exists: what it does today, and the point at which it constrains research or execution. If nothing exists yet: what the venue and the market permit, read off the venue’s own documentation.
- The question behind the request
- What you want to change is usually a different sentence from the one the request arrived in. Those two come apart more often than they meet, and building against the wording spends the engagement on the wrong problem.
That week ends in writing: the problem as we understand it by then, the measurement that would settle it and what we would do first. If the measurement says the work is not worth doing, that sentence goes into the same document, and you get it at that point rather than later.
A worked case: on Coinbase BTC-USD the spread is one tick more than half the time
Public exchange data, which is why every step of it can be set out here.
There is an assumption in order-book work that tends to get used without checking. On a venue where the spread is quantised to a single tick, spread-normalised features degenerate; on a venue where the spread moves, they do not. A research plan built on it picks the second venue and gets on with the work. We wanted the distribution in front of us before relying on that, so we measured it: Coinbase BTC-USD, three days, 29,263,059 book states reconstructed to depth five. The tick is $0.01.
- exactly 1 tick
- 55.60% of book states
- 2–3 ticks
- 1.62%
- 4–20 ticks
- 3.93%
- 21–100 ticks
- 16.15%
- 101–500 ticks
- 20.90%
- over 500 ticks
- 1.81%
The median spread is the smallest value the venue allows. The band just above it is close to empty, and the next populated region sits about a hundred times further out (p75 = 83 ticks, p90 = 205, p99 = 633). On Binance futures BTCUSDT over the same days the spread is exactly one tick in 99.7% of states, so the two venues differ by degree and not by kind. What that costs a research plan is specific. On this data a spread-normalised feature works as a switch. Almost none of its variation sits on the body of the distribution and almost all of it on the tail.
Two cheaper explanations went first, in the same pass. Reconstruction gaps cover about 13 seconds of one day, which cannot produce a fifth of all states. Nor are the wide states bunched into episodes. The quietest hour of the day still holds 18–26% of them and the busiest holds 45–56%, so they sit across the whole session.
Where this result stops. The measurement cannot tell “the top of this book is really shaped this way” apart from “this is what a depth-five reconstruction makes of it.” Both readings survive the data, and nothing above chooses between them. What we have is a property of the data as we hold it (three days, one instrument, one venue, one reconstruction depth) and not an established property of the market. The number travels only with that sentence attached to it.
What we do not do
- No ready-made signals, bots or subscriptions
- Every engagement is defined for a market, a horizon and a system.
- No performance guarantees
- No promised return, no Sharpe ratio, no latency figure. A latency target can be written down only once the venue, network, hardware, workload and measurement method are known, and it stays a target even then.
- No capital under management
- We do not take money under management and we do not trade a client’s money.
- No retail products and no courses
- The work is for professional market participants.
- No published research methods
- The work gets explained; the method stays between the client and us.
Request a technical assessment
Write what you run today and where it is stuck: the market, the strategy or the system you run, and the point in research or execution that is holding it up. Two paragraphs are enough. One named bottleneck is worth more here than a full description of the stack.