r/algorithmictrading

I'm a student at NYU studying to get into quant. Last year I started a project that I thought would be small, building a router that picks the best strategy for a given market in DeFi and sizes it with Fractional Kelly Criterion. 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 wrote 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 do not 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 in the studio, it separates performance by regime. It crushed in Crisis (+1440 bps) but bled out in High Vol (-1398 bps), ending at -245 bps net. It gets flagged as Noise.

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 overfit models 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.
The router captures about 86% of the perfect-foresight ceiling (95% lower bound ≈ 39%) and this is on the same volume of trading, around 7-12 trades per day on both the oracle and my router on a very diversified roster of bots. I also found that best available edge scales with roster size at r=0.986 against extreme-value theory (the √(2·ln N) scaling).

This mechanism could technically make money, but the allocator wasn't the bottleneck, the roster quality was.
The network effect (this is the part I'm most excited about):
I wanted to know does adding more strategies actually help or am I just diluting? I subsampled my 93-bot roster down to smaller sizes (10, 20, 35, 50, 70, 93 bots) and re-ran the entire pipeline from scratch on each one.
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 (the √(2·ln N) scaling 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. 

But here's the catch: 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 because the percentile just re-centers on whatever population is there. 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 I want creators :) Every good strategy added raises the ceiling for everyone.
How it expanded into a creator studio:

\"The web IDE where you can write standard Python strategies with declared SL/TP and pull from a feature catalog like orderbook imbalance or cross-asset momentum.\"

The router dynamically updates its own parameters as the roster changes but it does this via offline re-tuning on a cadence, 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 data feeds with historical data as well. These became obvious next steps:

• 6 active domains: ETH, BTC, SOL direction + scalp (6 more registered but dormant, yield, tail hedge, liquidation arb, memcoins (This one might be insanely hard to get right tbh), etc, waiting for strategies)
• 5-stage validation pipeline: static check, in-sample, out-of-sample, walk-forward, cost-adjusted
• Creator IDE: write Python strategies with custom stop-loss, take-profit, and trailing stops directly in the browser or via API/MCP
• Arena & Leaderboard: strategies that pass validation compete on live paper data for capital allocation
• Non-custodial: API keys stay encrypted in user vaults

\"Live portfolio dashboard routing capital across active domains. Also I made a Dummy \"Hedge Fund\" called DaBronjame2 which was meant to be a fund of a collection of only bad bots which traded only during Neutral markets and scalp in them. Shouldn't have played with 20x leverage before :)\"

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.

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 a volume of 7-12 trades per 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. Oh, and importantly nobody can see any strategy code, it runs in a confidential VM! Happy to share more details 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 live paper data, most have no edge after costs (shocking!! I know). The router captures ~86% of a perfect-foresight ceiling at matched volume. 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. It snowballed into a full creator platform (5-stage validation, arena, non-custodial, confidential VMs for strategy privacy and more). Would love feedback from people who actually know what they're doing. Does the approach make sense, is 86% of ceiling decent, what would you need in a Python strategy sandbox?

Everyone's comments are welcome, but I'm mainly hoping to hear from people who've actually worked in quant research, at a prop shop or trading firm, or independent traders who've built something that's actually been profitable in live markets — not just in a backtest.

If you reply, mentioning what you've worked on or where helps me weigh the answer properly — that's the only reason I'm asking, not to see anyone flex.

I'm not asking anyone to hand over an edge or a strategy. I'm just curious about the actual process — how does an idea go from nothing to something testable?

Questions:

How does a hypothesis actually form in practice? Is it usually "pick a market/asset, ask 'what if X happens, then what follows?', and go look for evidence" — or does it more often start from something else, like a live anomaly you noticed, a macro/economic question, or a flow/structural observation?

How much do academic papers actually drive idea generation versus being used afterward to formalize or validate something you already suspected from watching markets?

Is there any kind of structured workflow for the "ideation" stage — sources you go to, questions you habitually ask — or is it mostly unstructured reading plus intuition plus trial and error?

Is there real methodology that basically never gets discussed outside funds and prop shops, or is the actual edge more about execution, risk management, and data/infrastructure rather than some hidden idea-generation framework?

Once you have a raw idea, what's the first thing you do to sanity-check it before ever touching a backtest?

* Long story short - been fucking around with a leveraged-ETF rotation strategy for the last few days.*

The strategy holds one leveraged ETF at a time, flipping between positions when RSI hits hard thresholds - for example:

RSI_SPY > 80 → rotate into UVXY.

The strategy produced 186 trades in my standalone Python replica.

QuantConnect?

136 trades.

Both Cloud and local LEAN.

Same strategy.

Same period.

Same data.

So I started digging.

It wasn't the data.

It wasn't the margin model.

It wasn't the strategy logic.

It was RSI.

More specifically, a subtle difference in how QuantConnect seeds Wilder's RSI compared with the formula used in my Python implementation.

And because the strategy uses hard thresholds, that tiny difference was enough to fuck everything up.

A day where my RSI was 80.1 could be 79.8 in QuantConnect.

That's enough to miss the rotation.

Then the next position is different.

Then the next signal is different.

And suddenly the entire trade sequence is out of sync.

What made this especially annoying was that the numbers weren't wildly wrong. They were close enough to look completely normal.

The final way I isolated it was to calculate the RSI by hand using QuantConnect's own stored price data, then compare that against the RSI QuantConnect was reporting.

That's where the difference finally showed up.

The fix was to stop using QuantConnect's built-in RSI and implement the Wilder calculation manually.

After that:

>!TADA - (=^ェ^=)!<

Python: 186

QuantConnect: 186

Debugging took around 16 hours across the data audit, margin investigation and asking AI wHaT the Shit is this - and bam ----> indicator forensics.

>All that because *“Wilder's RSI”* apparently doesn't necessarily mean the same fucking thing everywhere.

Lesson learned:

If you're trying to get multiple backtesting engines to produce the same result, don't just compare the strategy logic. Compare the actual numbers coming out of every indicator.

#

**TL;DR:** A dead-simple rule — 60% SSO / 40% QLD when the S&P is 3% above its 200-day SMA, 0.5× S&P exposure when it's 3% below — did **16.2% CAGR over 27 years (1999–2026)** against 8.7% for SPY and 11.7% for always-on 2× leverage, with a −56% max drawdown versus always-on's −94%. I then spent five phases optimising it, found four configs that beat it, and every one of them fell apart out-of-sample. Shipping the original, unchanged.

# The strategy

SPX > SMA200 + 3% → 60% SSO / 40% QLD (2× leverage)
SPX < SMA200 − 3% → 50% SPY / 50% cash (0.5× exposure)
Inside the ±3% band → do nothing, hold current regime
Rebalance: quarterly + immediately on a regime switch. Signal at close, trade next close.

That's it. No crash guard, no vol filter, no RSI, no sector rotation. 28 regime switches in 27 years — about one a year, risk-on 72% of days.

# Results, 1999–2026

SSO and QLD only launched in 2006, so to cover the dot-com bust I synthesised both back to 1999 from SPY/QQQ total returns: daily-reset model, prospectus expense ratios (0.89% / 0.95%), 40bp financing spread over 3-month T-bills. **Zero parameters fitted to the real ETFs.** Over 2006–2026 the synthetic series tracks the real ones within 0.3pp of CAGR at 0.996 daily correlation.

27.4 years, $20k start + $500/month ($184,500 deposited):

Metric	Strategy	SPY	Always-on 60/40 SSO/QLD
CAGR	**16.16%**	8.65%	11.73%
Max drawdown	−56.1%	−55.2%	**−94.0%**
Sharpe	**0.58**	0.45	0.27
Calmar	**0.29**	0.16	0.12
Ending value (DCA)	**$5.27M**	$1.23M	$4.78M

Two things worth pulling out.

**The "always-on wins on dollars anyway" argument dies over a long enough window.** On 2006–2026 alone, always-on ends ahead ($3.11M vs $2.48M) because DCA contributions during the −84% hole bought in cheap — that's the standard rebuttal to any timing overlay. Extend back through the dot-com bust and it reverses: $4.78M vs $5.27M, and always-on got there via a **−94% drawdown**. Nobody holds through −94%.

**The window you start in changes everything.** Same rule, 2006–2026 only: **20.3% CAGR, −44.8% DD**. From 1999: 16.2% and −56%. If a leveraged strategy's track record starts after the dot-com bust, you don't know what it does in a lost decade. For what it's worth, in the 1999–2006 stretch alone the strategy did +3.9%/yr while always-on did −9.4% and SPY did +1.0%.

# Then I tried to improve it

All on 2006–2026, the window they were tuned on:

Config	CAGR	Max DD	Verdict
Original ±3%	19.90%	−45.0%	baseline
Exit −3% / re-enter +1% / 21-day min-off	20.53%	−42.4%	More return AND less drawdown
SMA-150 with −4% exit	**21.57%**	−42.8%	Best of 213 configs
100% SPY in bear markets instead of 50%	20.34%	**−61.0%**	Rejected — deeper hole than SPY itself
EMA instead of SMA	median 12 whipsaws vs SMA's 7		Rejected — EMA loses on every axis

The middle two looked like free lunches. So before deploying, four tests.

# The four tests

**1. Out-of-sample history.** Test the dot-com bust, which no tuning had seen:

Config	1999–2006 CAGR	Max DD
**Original ±3%**	**+3.55%**	−56.6%
−3%/+1%/21d	\+0.79%	−64.3%
SMA-150 −4%	**−1.70%**	−68.5%
Always-on 60/40	−9.75%	−91.6%

The ranking inverted completely. The untouched original came out best; my top config lost money. A shorter MA with a wider exit whipsaws horribly in a long grinding bear — 11 switches vs the original's 6.

**2. Walk-forward.** Every 2 years, pick the best of 160 configs on trailing data only, apply blind to the next 2 years. Chained: **5.06× for the retuning process vs 5.58× for the fixed original rule.** Selection won 4 of 11 windows. Retuning has negative skill.

**3. Monte Carlo.** 1,000 stationary block bootstraps (mean block 40 days), signal recomputed on every path. My "improvements" beat the baseline on 55–57% of paths. That's a coin flip.

**4. Permutation.** 2,000 circular rotations of the regime sequence — same switch count, same time in market, wrong dates. The real signal beat 97% of rotations (p = 0.031). **So the 200-day filter itself is real. The tuning on top of it wasn't.**

# The one thing that did survive

Volatility targeting: scale the risk-on sleeve by `35% ÷ 60-day realized vol`, capped at 1.0. Over 1999–2026 it moves Calmar 0.29 → 0.34 and drawdown −56% → −45%, for 0.8pp of CAGR.

It passed the test that killed everything else. Average exposure is 0.96×, barely a de-lever, so I pinned exposure at a flat 0.96× as a control — same average, same rebalance schedule. That reproduced **none** of the benefit (Calmar 0.29, DD −54%). Rotating the exposure schedule to the wrong dates also killed it (0.26). So the gain is genuinely in *when* it de-levers, not in holding less. It won 74% of Monte Carlo paths, and every target from 20% to 60% beat the baseline — a plateau, not a lucky cell.

I still passed on it, because it only helps in slow grinding bears (dot-com −56%→−45%, 2022 −41%→−37%, and literally zero effect on COVID, 2018 Q4 or the GFC — realized vol spikes *after* price falls). I'm optimising for CAGR; if you're optimising for sleep, take it.

# Lessons

1. **In-sample improvement is free. Out-of-sample improvement is nearly impossible.** 250+ configs, four winners, zero survivors.
2. **Walk-forward is the cheapest honesty check that exists.** One number (5.06× vs 5.58×) invalidated my entire optimisation phase, including configs I never individually tested.
3. **Always build a static control.** "Same average exposure, held constant" is what separated a real signal from a de-lever in disguise.
4. **Trust plateaus, not peaks.** Prefer the parameter you could misestimate by 30% and still be fine.
5. **Parameters don't transfer between your own strategies.** I ported a −13%/15-day crash guard from another live strategy of mine. Audit: it fires 51 times over 1999–2026, and the ±3% rule is *already* defensive on all 51. It never once forces an exit. It works over there because that strategy uses a slower EMA with a 30-day hold — copying a parameter without the mechanism it compensates for adds risk, not safety.
6. **Drawdown budgets have cliffs, not slopes.** Risk-off exposure could go 0%→50% SPY essentially free, then cost 16 points of drawdown between 50% and 100%.
7. **Check your moving average is warmed up.** I hit this twice. Slicing prices to a backtest window *then* computing a 200-day MA leaves the first 200 days undefined and silently parks the book in cash. It cost me 1.7pp of CAGR on the full-history run before I caught it by noticing two phases disagreed about the same number.

# Final config

signal = "^GSPC" # S&P 500 close
ma_kind = "sma" # NOT ema
ma_length = 200
exit_buffer = -3.0 # % below SMA → risk-off
entry_buffer = +3.0 # % above SMA → risk-on
risk_on = {"SSO": 60, "QLD": 40}
risk_off = {"SPY": 50, "CASH": 50}
rebalance = "quarter_end + on_switch"
execution_lag = 1 # T+1
# explicitly NOT included: crash guard, recovery rally, vol target,
# min-hold, asymmetric re-entry. All tested, all rejected.

**Risk number to actually plan around: −56%, not −45%.** The friendlier figure comes from a window with no slow bear in it before 2022.

Happy to answer questions on the synthetic LETF construction or the stress-test setup — that's the part worth copying if you're building something similar.

*Windows: 1999–2026 with synthetic SSO/QLD pre-2006, 2006–2026 on real ETFs | $20k + $500/mo DCA | Data: Yahoo Finance | T+1 execution, \~10bp of traded notional in costs* *Not financial advice. Leveraged ETFs can lose 90%+ in a severe bear market — always-on 60/40 SSO/QLD did exactly that in 2000–02.*

I want to backtest a daytrading strategy using the walk forward method, I want to know what you guys usually do:

I track the following result metrics for each parameter configuration:
Total_Net, Total_Trades, Win_Days_Pct, Profit_Factor, Max_Drawdown,  and Daily_Sharpe.

1-How many configurations you carry from IS to OOS?
2-How do you choose the IS metrics to determine what configurations to be OOS tested ? Im inclined to use the sharp ratio, Total_Net ...
3-And if you are looking for the parameter configuration to go live, what metrics you would look for?

Is there good resources about this topic?
Thanks!

All algo traders, what kind of metrics would you consider looking at in the backtesting results, and why? For example, in the backtesting results, we see metrics like:

• Sharpe ratio
• Sortino ratio
• Calmar ratio
• Drawdown
• Expectancy
• Profit factor

There are so many such metrics. What will you prefer looking at and ignore others, and why? What is the rationale behind preferring those metrics?

Hey guys,

I know this sub is mostly HFT interview stuff, PPOs and package discussions lol, but I wanted to ask something different. I'm pretty new to this and honestly stuck.

I'm trying to build some MFT/LFT strategies but I keep coming back to square one, like I build something, it looks fine, then falls apart and I don't really know why. So basic questions but genuinely don't have anyone to ask:

how do you even start, like where do you look for a strategy idea in the first place

once you have an idea how do you know if it's actually something or just noise

any papers or resources you'd actually recommend for someone starting out (not the generic ML for trading stuff, more practical)

how do you set parameters/hyperparameters without just overfitting to the backtest

how do you go from idea to actually coding it properly

how do you figure out which risk management setup is actually helping vs just looking good in backtest

how do you know a strategy's results are "real" and not just luck

once something shows a bit of an edge how do you improve on it without ruining it

I know most people here are genuinely some of the top minds.. so if anyone's willing to help a beginner out even a little bit I'd really appreciate it. This community seems solid so thought I'd just ask honestly instead of pretending I know more than I do.

(Note: this post was written with help from AI, just used it to organize my thoughts/questions properly)

Thanks 🙏

Hi everyone! I've been building my bot for four months now, and during that time I've been exploring the world of HFT trading. But I've hit a dead end at the validation stage (my bot is a scalper). It simply responds 50/50, meaning losses and profits are equal. I'll lose my account due to the exchange's commission. I'd like to ask a couple of questions for experienced HFT traders.

1. What loss function do you use? (I'm using MSELoss, is that suitable?)
2. Should I look for patterns not only in the order book and trade history, but also in candlesticks?
3. What happens if I add EMA to the neural network's responses? Will that help smooth out the neural network's noise?

Thanks in advance for your reply, and sorry for my English; I can't write as well as you. (I used a translator.)

&#x200B;

I am a 19-year-old student pursuing a B.Tech in AI & Data Science. I have also been trading forex manually for the past two years. Currently, I am at the breakeven stage, so I am planning to explore algorithmic trading full-time.

I have a good understanding of coding, AI/ML, and software development.

I recently started exploring algorithmic trading, building my own strategies, implementing them, and backtesting them using Indian market data. I have also backtested strategies in the forex market using MQL5. However, I mainly used AI-assisted ("vibe") coding for the MQL5 strategies.

I tested several strategies in MQL5, and most of them were indicator-based strategies. Most of these strategies ended up around breakeven, with relatively low drawdowns and win rates of around 30–50%.

I also tested around seven strategies in the Indian equity market, and I got similar results — most were around breakeven. I have tested only equity assets so far, not F&O.

So, if you are an algo trader, I would really appreciate some advice on things like:

What types of strategies do you use — indicator-based, pair trading, time-based, price action, mathematical/statistical, etc.?

Which timeframes do you usually trade when doing algorithmic trading?

Is algorithmic trading actually profitable for an individual trader in the long run?

Is it better to focus on one asset/class, or should I build strategies across different asset classes such as equities, futures, forex, etc.?

What would you recommend to someone trying to build their own algorithmic trading strategies from scratch?

What are some common mistakes beginners make when developing and backtesting algos?

I would especially appreciate advice from people who have been doing algorithmic trading for a few years and have experience with live trading, not just backtesting.

Thanks in advance!

Note: i used ai for grammatical mistakes.

Been running a multi-strategy trading system on IG Markets for about 6 weeks — sharing the real numbers, not a highlight reel.

The fleet:

V3 — regime-classifying bot (ADX/Hurst), switches between trend-following and mean-reversion

AGENT — pure deterministic rules engine, no AI in the trading decisions

SCALP+TREND — two strategies sharing infrastructure

HAIKU_GB — the interesting one: Claude Haiku makes genuinely discretionary LONG/SHORT/FLAT calls on Gold and Brent, full reasoning, Python only enforces sizing/risk. No overlay telling it what to do.

What I actually found, not just what worked:

Only ~53% of my sandbox data turned out to be genuinely clean once I dug in — a mid-price logging bug had been quietly turning a real £220 loss into a fake £237 "profit" for eight weeks before I caught it

A rules overlay was silently vetoing ~half of Haiku's directional calls, which meant I was accidentally measuring "Haiku's judgment filtered through a rulebook" instead of Haiku's actual judgment

Found and fixed a fleet-crash bug that had been intermittently taking down the whole system for weeks — root cause was a Go binary (GitHub CLI) segfaulting under Android's sandboxed ptrace emulation

The most interesting pattern so far: my best entry-quality bot (61% win rate) is my worst performer overall, and my worst entry-quality bots (26-28% win rate) are flat-to-positive — exit management seems to matter more than entries, testing that hypothesis now with counterfactual logging

Current phase: spent the last month making the existing system honest before adding anything new — real broker reconciliation, fixed data integrity bugs, no new strategies. Targeting a clean data run through the end of the year, live money decision in January based on what the data actually shows, not vibes.

Happy to go deeper on any piece of this — the Haiku experiment, the bug-hunting, the architecture, whatever's interesting to people.