High-Frequency Trading (HFT) Consulting
HFT Architecture provides high-frequency trading consulting for electronic trading teams—from short-horizon alpha research and strategy design to risk controls and production systems. We work on one market and one horizon at a time.
Building a new trading line, or testing whether a forecast adds anything to the rules you already run? Start with the data, the existing system and the decision you need to make.
Your first deliverable. A written assessment: the problem, the measurement that would settle it and what to do first—including a recommendation to stop if the evidence does not justify the work.
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).
- Starting point. Order-book data and the market and horizon to be modelled.
- What you get. A market-specific forecast with out-of-sample measurements and documented data and leakage checks.
- 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.
- Starting point. The forecast or current rules, trading costs and execution assumptions.
- What you get. Trading rules evaluated with fees, queue position, latency and failure scenarios stated alongside the result.
- 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.
- Starting point. The strategy, position constraints and scenarios it must survive.
- What you get. Explicit limits and stop conditions, checked against the trading logic and its failure scenarios.
- 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.
- Starting point. Venue connectivity, the current stack and the workload to be measured.
- What you get. A measured event-to-order path, with replay, oversight and controls separated from execution.
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 an assessment conclusion looks like
An illustrative note based on the public-data case above. This is a research example, not a client result or a claim about live returns.
The note connects the decision to the evidence still needed to make it.
- The decision
- Do not choose a venue on the assumption that its spread gives a continuously varying normalisation scale. In this sample, the feature behaves mostly as a switch between the body and the tail of the distribution.
- What remains unresolved
- The measurement does not separate the shape of the market from the effect of reconstructing only five levels. It cannot yet justify a venue-wide conclusion or a trading decision.
- The recommended next check
- Compare against a deeper reconstruction over the same period before relying on the feature. This is the proposed next measurement, not a completed validation.
A project assessment follows the same shape: a decision, its evidence, the uncertainty and the next check. The scope is set by your market, horizon and system.
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.
Goes to our inbox as one email.