A quant with their own book: a story of a trading team at BHFT

Why one BHFT team gives every quant a book, and how cheaper testing made it possible.

A quant with their own book: a story of a trading team at BHFT
Figure 1. Where the loop closes: research queue vs. your own book

Who gets to run a book? Most firms respond to this question the same way: you get one after you have proved you can run one somewhere else. The multi-manager platforms have industrialised that answer. They buy track records, give each manager an allocation, and cap the cost of error with hard drawdown thresholds.

At Millennium, as Marc Rubinstein has described, a 5% drawdown halves the team's risk and 7.5% winds the portfolio down completely. The seat is temporary by design. Median tenure for a portfolio manager is 1.8 years at Point72 and Balyasny, 2.3 at Millennium and 3.0 at Citadel, so the platform has to keep buying: regulatory filings show Millennium adding 260 net new investment staff in a single year, roughly five a week, on top of the 330-plus investment teams it already runs. 

The design answers a real problem: finding out whether someone can trade takes years, so the platforms let someone else pay for the finding out and hire the result. The cost is that the model cannot produce a trader, only hire one.

We sit at the other end of the same problem. Let's look into a specific team at BHFT. There are 11 people: three have a profile closer to a quant than a trader. Every one of them runs a book.

Three years ago this would have been a bad idea, for reasons that have nothing to do with culture. Handing a book to someone new only makes sense if you can find out quickly whether their ideas work. Back then you could not.

A backtest on a new market meant six to eight weeks of waiting for data, then three or four months of writing and debugging. At that price you cannot afford to be wrong about a person, so you hire people who have already been right elsewhere. Today, with AI tools available, making an idea UAT / prod-ready is no longer the expensive part.

Why nobody hands out research tasks

At most firms a quant works through a list. Someone senior decides what gets researched, the quant does the work, and a trader takes it from there. The quant rarely finds out what happened to it.

At this specific BHFT team, there is no list. Historically, there was nobody to write one: producing and distributing tasks would have taken the team lead's whole week, so each quant got a small book instead.

Where the loop closes

A person forms a hypothesis, tests it, puts it on the market and sees the response. In HFT you can see the difference the same day (see Figure 1 above). The market's answer turns into a change, and the change turns into the next action.

Working through a task list, two things are missing: what gets tried next and whether the last thing worked. Both come back the moment a person trades their own ideas.

This approach speeds up how fast someone learns and shows whether they can carry responsibility for their own decisions. Allocation stays with the team lead and risk limits are in place, but the decision to open and close is theirs.

The weight of P&L lands on their shoulders, and that is part of the design. The starting limit is set so that a person feels the pain of a mistake without being frightened by it.

What a book costs you

Depth. At a large firm a quant can spend years on one market and know it down to the last detail. That kind of knowledge stacks up, but breadth does not.

Our approach is different. In a new market the person who knows a little about how five exchanges behave is worth more than the person who knows everything about one.

That is a trade we make on purpose, yet we make exceptions to it when the work demands them. Narrow specialists still get hired, for the jobs where depth is the whole job.

What a book involves

A book is not a licence to trade whatever you like. It is a defined size, a set of limits, and a list of things that have to match before the size goes up.

Getting approved and sized

Approval used to work in two stages. A candidate strategy was scored by an internal tool against a set of risk mandates, and only then could it go live. The tool has fallen out of use, so the judgement call now sits with the team lead. The mandates and limits themselves have not changed: brokers and trading accounts require them, and they apply to everyone.

We look at the backtest and at VaR, then pick the minimum size at which the strategy can be tested. If the test horizon assumes 100 entries and the minimum clip is 1, the minimum size is a hundred. From there the ramp is decided case by case, because a strategy that trades often earns its size faster than one that trades rarely. A typical shape, as an example: start five to ten times below the target size, then add 1 or 2% a day or 25% a week.

Figure 2. Two example ramp rules from the same starting point. The ramp is a second test: each step raises the cost of the strategy being wrong, so each step has to be earned.

What we watch besides P&L

Live P&L is the headline number and, on its own, the least diagnostic. The standard set goes further: Sharpe, drawdown and its length, hit rate, average win against average loss, turnover, capacity. All of it is still the P&L seen from different angles; it tells you how a strategy performed, but not whether it’s running the way it was modelled. For that you have to look at the execution detail underneath.

What we reconcile

What a mismatch is telling you

Maker/taker split

The robot is crossing where the backtest assumed it queued

Fill rate

The queue model is wrong, or you are being adversely selected

Order replacements

Production latency and shared rate limits are biting

Slippage

Sizing or timing assumptions do not survive contact

Markouts

The edge decays faster in the wild than on paper

How long it takes to know

Between two weeks and two months, depending on frequency. That dependence is arithmetic.

The standard error on an annualised Sharpe estimate is roughly one over the square root of the number of years of data. Separating a true Sharpe of 1.0 from zero at 95% confidence therefore takes close to four years of daily returns.

Figure 3. The confidence band on an estimated Sharpe of 1.0, collapsing as the track record lengthens. It straddles zero until around 3.8 years.

What matters in that formula is the number of independent observations. A strategy that trades a thousand times a day reaches the same statistical ground in days that a once-a-day strategy reaches in years. Frequency sets the validation horizon. If someone does one trade a day, judging them on five trades is not serious.

How teams accumulate

Here is an example of how a team shapes up. The idea began with the team lead. This one was about calendar spreads. Someone else picked it up and reworked it, and it ran that way until he no longer had the bandwidth to watch it alongside his own book.

Rather than shelve it, we looked for someone who already knew this class of strategy from the outside, and found a trader who had run it by hand. He brought the thing the original version lacked: a view on which products it actually worked on. Within a few months he had strategies of his own built on the same idea, and an algo trader joined after that to automate what the two of them were doing manually.

Nobody designed that sequence. Each person arrived because the previous one had run out of capacity, and each of them changed the strategy instead of simply taking it over.

The result is a team of three covering twenty-three hours of trading. There are plenty of volatile periods in a day, and each of them watches more closely at the hours that suit them.

Who pairs with whom

Three is not a target. Plenty of books stay with one person, and a pair is just as common as a trio. It all depends on the strategy: how many hours it has to be watched, and whether the work splits cleanly into parts one person can hand to another.

Where a pair forms, one brings the creative part, the other runs the day-to-day, because the first finds it harder to sit through a losing streak without interfering.

Combinations like that are not arranged in advance. They emerge as you go, and the lead's job is to notice when someone's personal capacity stops covering the work and add the missing function.

The technical mix varies too. Two of that team are closer to pure traders: they generate approaches and algorithms, and they pick up the engineering side gradually. We keep off-the-shelf robot solutions for exactly this, so nobody is blocked on building their own setup.

Two kinds of "drilling" at BHFT

"Drilling" is our own shorthand for how a piece of work relates to the ground already covered.

Horizontal drilling means you go sideways into a market nobody here has traded before. It is tunnelling for a metro line: slow, expensive, and you cannot tell in advance what you will hit.

Vertical drilling means you go deeper into one that is already open, a track that is already laid. Driving trains is easier, there is nowhere much to turn, and the result shows up fast. People on the vertical side become heroes quickly.

Figure 4. The same effort, two shapes of payoff. Horizontal work produces nothing for months and then produces a market.

Both are needed. But you cannot measure them with the same ruler. Someone who spent six months digging a tunnel looks worse on the numbers than the person who drove the first train over finished rails. Promote based on the numbers alone and you stop having tunnels.

The cost of checking

The data we could not use

Three years ago a broker in one of our markets offered us PCAPs, raw captures of the exchange's network traffic. We could not use them. We had no library for that market. We asked the broker to rebuild the data into BBO or into minute bars and got a strange look, because on their side this was routine work with tools they already had. The data was as clean as data gets, and it went unused.

Turning PCAPs into L3 ourselves would have pulled IT resources away for two or three sprints, so realistically a month and a half of waiting. Then someone would still have to write the backtest: a few thousand fairly trivial lines that would need debugging and checking like any other.

Figure 5. The same work, before and after. The bar on the right is not a rounding error in the chart.

We now welcome PCAP feeds, because we can convert them into whatever format we need ourselves.

Checking the machine that checks

The obvious objection is that AI-assisted development trades one kind of error for another, and the objection is fair. In METR's randomised trial, experienced developers were given tasks in codebases they knew well, half with AI tools and half without.

The ones using the tools took 19% longer, and afterwards reported that the tools had made them about 20% faster. METR now treats that result as historical, but the gap between how fast people feel and how fast they are is still there.

So we measure rather than trust the feeling. Peer review is gradually being replaced by review with a model, where one agent's code is checked by another. Alongside that we reconcile L3 backtests against production, and in 98% of cases we land in the right place in the right queue.

The robot in the wild

The remaining 2% come from the difference between a backtest and a live server. In a backtest, especially a Python one, a robot runs alone with the whole machine to itself. In production it shares that machine with 70 other instances, a data relay and 8 gateways, all of them writing somewhere, under shared RPS limits. Its orders queue behind traffic that does not exist in the test.

What improved

The approach to backtesting has become less selective. We test more hypotheses, including weaker ones. Laziness used to work as a filter, because testing was expensive. Now, as long as an idea looks reasonable, we test it.

The main gain is response time. We are losing the situation where so much time passes between hypothesis and result that the result is no longer interesting. The cost of switching your own internal context has come down.

Why teams grow their own

Cheap testing changes who you can afford to hire. When it took four months to find out whether an idea worked, a wrong hire cost a year. When it takes a session, the same mistake costs a quarter.

What does not transfer

A Formula 1 driver moves to another team and stops delivering at the same level of skill, because the car is set up for someone else. The same thing happens with traders. There is no way to test it at an interview: references do not exist in a closed environment, the product is non-standard, and everyone's opportunities and ethics are different. A track record tells you what a person did inside a machine you cannot inspect.

What motorsport worked out first

Red Bull founded its junior team in 2001 and states its purpose in six words: "We don't buy stars, we make stars." Mercedes followed in 2014 and signed Kimi Antonelli at the age of 11.

Money is not the reason teams do this. Finding and developing a junior does not come much cheaper than signing a star, and a team with Mercedes' budget could sign almost anyone. Growing a driver inside your own system is simply more reliable, because the driver and the machine are shaped against each other from the start.

What the question became

For a long time the hard part was how. How to get the data, how to write the backtest, how to get a number worth trusting. That work still exists, but it no longer sets the pace.

Today's question is where to focus. Which market, which hypothesis, which of the secondary ideas is worth the time. Those answers come from knowing a market, reading around it and staying curious about it, which means they come from people. Give someone at least a small book early, and they will find out the answers quickly enough.

Sources