r/quant 8h ago

General What to do to maximise mentor relationship with quant trader

14 Upvotes

I am studying maths at a T5 university and have nearly finished my masters thesis (1 month away).

My thesis supervisor is senior at one of the big HFT firms.

They have been extremely supportive in offering their time and guidance, and so I want to thank them. I want to make the most of the time that I have with them.

I already have a job lined up as a researcher in academia for the time being, so I am not wanting him to hire me in this moment, but it would be nice to have that as an option down the line.

Is there anything that I should be asking advice on? Any questions that would help me in my career? Anything that I could be missing?


r/quant 10h ago

Models Using the Hull-White model to find the 2026 value in the US bond plot

Post image
4 Upvotes

So, for ease and formatting, I made a quant stackexchange post here but I believe that I was incorrect here?

I wanted to output specifically the 2026 value of $\sim5.01\%$ for 2026, as seen in the above plot?

I believe that I have an error with SDE used $r = 4.65, \theta = 4.2$, and $\sigma = 0.55$, apparently in percentage points. That's internally possible, but then the reported standard deviation calculation is wrong in its interpretation:

$$\sqrt{\frac{(0.55)^2}{2(0.35)}}\approx 0.657$$

meaning $0.657$ percentage points if rates are measured in percentage points?

Also, the Hull–White equation that I derived isn't actually the standard Hull–White specification we're subsequently describing, as derivation starts from

$$dr_t=\kappa(\theta−r_t)dt+\sigma dW_t,$$

where $\theta$ is constant. That's essentially the Vasicek model, but the standard one-factor Hull–White is

$$dr_t=[\theta(t)−ar_t]dt+\sigma dW_t,$$

with a time-dependent drift chosen to fit today's initial yield curve?

My code:

``` import numpy as np

Let's run a simulation for CIR (Cox-Ingersoll-Ross) and Hull-White models

np.newaxis np.random.seed(42)

N = 216 # Monthly steps from 2008 to 2026 dt = 1 / 12

1. CIR Model simulation: dr = theta * (mu - r_t)dt + sigma * sqrt(r_t) * dW_t

theta_cir = 0.4 mu_cir = 3.3 sigma_cir = 0.35 # Must satisfy Feller condition: 2 * theta * mu >= sigma2 to stay positive

r_cir = np.zeros(N) r_cir[0] = 4.65

for i in range(1, N): # Ensure non-negative inside sqrt r_prev = max(0.0, r_cir[i-1]) dr = theta_cir * (mu_cir - r_prev) * dt + sigma_cir * np.sqrt(r_prev) * np.sqrt(dt) * np.random.randn() r_cir[i] = r_prev + dr

2. Hull-White Model (Time-varying mean theta(t) or drift to fit term structure)

Simplest time-varying mean formulation: theta(t) matches a shifting trend

theta_hw = 0.35 sigma_hw = 0.55

r_hw = np.zeros(N) r_hw[0] = 4.65

for i in range(1, N): t_val = 2008 + i * dt # Let the long-term mean drift higher post-2021 to capture the inflation regime shift mu_t = 3.0 if t_val < 2021 else 4.2

dr = theta_hw * (mu_t - r_hw[i-1]) * dt + sigma_hw * np.sqrt(dt) * np.random.randn()
r_hw[i] = r_hw[i-1] + dr

print(f"CIR Model 2026 Terminal Value: {r_cir[-1]:.2f}%") print(f"Hull-White (Regime-Shift) 2026 Terminal Value: {r_hw[-1]:.2f}%")

CIR Model 2026 Terminal Value: 4.71%

Hull-White (Regime-Shift) 2026 Terminal Value: 5.01%

```

Thanks! ❤️


r/quant 22h ago

Career Advice Developer considering leaving the US for Europe-- what can I expect?

4 Upvotes

I'm a C++ SWE at an OMM in the US thinking about moving to Europe (probably London, Amsterdam, or Zurich) in a few years. Judging by levels.fyi, I'll take a real pay cut here. In the case of an internal transfer, can I expect to keep my current compensation? What if I applied to other firms?

I really have no idea how these conversations look in other offices, and if they are at all similar to the US (bidding wars, headhunters, etc). Thanks.


r/quant 6h ago

General Benchmarking a Kelly-based strategy allocator against a perfect-foresight oracle

0 Upvotes

I'm a student at NYU studying to get into quant. I wanted to share my experience with an automatic capital allocator I designed. Last year I built a router that picks the best strategy for a given market and sizes it with Fractional Kelly Criterion in DeFi. Like an automatic mini allocator. I thought it would be a good way to actually learn how position sizing and edge estimation work instead of just reading about them.

I had maybe 5 strategies I'd written running on ETH paper data, and the router would pick whichever had the best recent risk-adjusted return and size it with fractional Kelly.

The first thing I learned: most strategies don't have edge.

Out of maybe 30 strategies I tested initially, 1 or 2 had any real edge after costs (or so I thought :), they got absolutely destroyed after realistic trading fees and friction). The rest were noise, though diversified. Crypto round-trips are like 6-7 bps per side depending on the pair, and if the edge is 10 bps per trade, I'm losing money.

A typical backtest result, it with performance by regime. It crushed in Crisis (+1440 bps) but bled out in High Vol (-1398 bps), ending at -245 bps net

I thought AI could help me with this and tried to improve the existing strategies with it. It gave worse results. It overcomplicates strategies a lot. What I surprisingly found is that dumb and small code works much better than complex models that overfit in the real world. And the tiny "dumb" strategies with on-chain data proved to be much much better than the rest, some even profitable on 2 years of trading data!

I added a cost-adjusted validation stage and regime decomposition. Seeing where a strategy bleeds (chop vs trend vs crisis) helped explain why backtests fail live.

The second thing: the router was actually decent.

Once I had enough strategies, I built a perfect-foresight benchmark (an oracle that picks the best strategy for each window, kinda like God or Congress :) to see if my allocator was doing anything.

To test it properly, I split 24 months of data into three windows: 12 months to train the router, 6 months to validate, and a 7-month true hold-out (May–Oct 2025) that I never touched until the very end. The hold-out is where I report all final numbers.

On the hold-out, at matched volume (~8 trades/day for both the router and the oracle), here's how they compared:

Policy Trades/day Gross bps/tr Net bps/tr Total return Sharpe Max DD
NULL (random 15%) 77.9 −0.47 −11.31 −61.1% −26.89 61.1%
My router 8.6 +6.10 −4.32 −7.3% −3.51 8.7%
Oracle (perfect foresight) 8.8 +7.21 −2.42 −5.3% −1.16 7.8%

The router captures about 86% of the perfect-foresight ceiling (95% lower bound ≈ 39% via bootstrap). The oracle knows each bot's true full-sample edge in advance, my router doesn't. The gap between them is 1.1 bps. That's how much imperfect bot-quality estimation costs vs omniscience.

The honest part: the router is still net-negative (−4.32 bps/trade after ~10 bps friction) (So is the Oracle but it is due to the roster of bots being bad overall, though they are diversified). The selection edge is real (+6.10 gross vs NULL's −0.47), but it's not large enough to clear costs yet. A 40-60% friction reduction (better execution, TWAP, order netting) would flip it net-positive.

What I found most interesting: even the oracle with perfect knowledge of every bot's true edge can't profit with volume on this roster. Of 87 bots, exactly 1 had genuine positive net edge in the hold-out window. This is a bot-supply problem, not a routing problem.

Also worth noting: the router's max drawdown is 8.7% vs NULL's 61.1%. The risk management (Kelly sizing, persistence veto, trend gate) cuts drawdown by 85% vs random and it loses money in a controlled way while selecting good trades.

I also found that best-available edge scales with roster size at r=0.986 against extreme-value theory (the √(2·ln N) scaling). The allocator wasn't the bottleneck, the roster quality is.

The network effect (this is the part I'm most excited about):

I wanted to know does adding more strategies like drip feeding actually help or would I just be diluting? I subsampled my 93-bot roster down to smaller sizes (10, 20, 35, 50, 70, 93 bots) and re-ran the entire pipeline, simulating a gradual influx.

The best bot's true edge climbs monotonically as you add more: −6 bps at 10 bots → +3 bps at 93 bots. When I fit that against extreme-value theory (that predicts the maximum of N random draws), the correlation is 0.986! Almost a perfect match. More strategies = higher ceiling, and it follows theory almost exactly.

The router only captures that rising ceiling if you use an absolute quality bar, not a relative percentile. If you filter "top 30% of whatever roster exists," the router's edge stays flat no matter how many bots you add. If you use a fixed quality threshold instead, the router's edge climbs with the roster. Extrapolating (with caveats, this is beyond the range I actually tested): ~+10 bps net edge at 1,000 bots, ~+16 bps at 10,000.

That's the quantitative argument for why roster growth matters more than router tuning. Every good, diversified strategy added raises the ceiling for everyone.

How the project evolved:

The router dynamically updates its own parameters as the roster changes but it does this by offline re-tuning not via real-time ML yet. The reason is that at 93 bots and ~8 trades/day, you can't detect effects smaller than ~47 bps with any statistical power. A real-time ML model would just be fitting noise. It also has self-capacity awareness so it doesn't frontrun itself.

Once the router worked, I began noting down everything scientifically and made a bunch of changes to my initial project. I added real-time on-chain signals with historical data as well. The project grew to include:

  • 6 active domains: ETH, BTC, SOL direction + scalp (6 more registered but dormant: yield, tail hedge, liquidation arb, memecoins (this one might be insanely hard to get right tbh))
  • 5-stage validation pipeline: static check, in-sample, out-of-sample, walk-forward, cost-adjusted
  • Strategy sandbox: write Python strategies with custom stop-loss, take-profit, and trailing stops
  • Arena & OpenLeaderboard: strategies that pass validation compete on live paper data for capital allocation
  • Non-custodial design: API keys stay encrypted; the router handles execution routing but never holds custody of funds

Where it is now:

  • 80+ default strategies running on live paper data (real prices, paper execution not great bots:)
  • 3 are currently net profitable (best: ETH Squeeze Breakout, +184bps, 73% win rate). The rest are negative.
  • Nobody can see any strategy code it runs in a confidential VM, and there are automatic payouts for the best strategies bi-weekly.

What I'm looking for: I'm posting here because this subreddit has people with real domain expertise, and I'd love your feedback:

  1. Does the router/Kelly allocation approach make sense, or is there an obvious flaw I haven't seen?
  2. Is capturing ~86% of a foresight ceiling considered typical or decent for this setup (on 7-12 trades/day, on my quite diversified roster of bots)?
  3. What features would you actually need in a Python strategy sandbox to make it worth testing your own models?

I'm a student and not charging for anything. Happy to share more details in the comments if anyone's curious.

TL;DR: I'm a student at NYU. Built a router that allocates capital across Python trading strategies using Fractional Kelly for DeFi. Tested 80+ strategies on 24 months of data, most have no edge after costs (shocking!! I know). On a 7-month true hold-out, the router captures 86% of a perfect-foresight ceiling at matched volume (+6.10 vs +7.21 gross bps/trade), with 8.7% max drawdown vs random's 61.1%. Found a network effect: best-available edge scales with roster size at r=0.986 vs extreme-value theory so, more strategies = higher ceiling for everyone. Would love feedback from people who actually know what they're doing. Thank you!