Hey everyone!
I’ve been running my own algorithmic trading strategy for approximately 1 year, and I’d love some feedback from experienced algo traders, quant developers, and people who have scaled automated trading systems.

Over the past year, the algo has generated approximately 2.5 million cents in trading profit on a cent-denominated account with Vantage Markets. I’ve attached a screenshot of the MT5 account history.

My current setup
● Broker: Vantage Markets
● Account: Cent account
● Instrument: XAUUSD (Gold)
● Execution: MT5 Expert Advisor (EA)
● Infrastructure: VPS
● Trading period: 1 year
● Reported trading profit: 2.5M account cents

The system is already running live, and I’m now exploring what it would take to scale it substantially potentially 100x the current trading size.
I’m trying to understand what actually needs to change when moving from a retail algo setup to something capable of handling significantly more capital. Is the current architecture sufficient, or would I eventually need a completely different execution infrastructure?
Questions for those who have experience scaling algos

1. Strategy scalability
   How do you determine whether a profitable strategy can maintain its edge at 10x or 100x the position size? What tests would you run before committing more capital?

2. Infrastructure and architecture
   I’m currently running an MT5 EA on a VPS. Can this setup handle substantially larger trading sizes if the broker and execution conditions allow it? At what point would you consider a separate execution engine, Python/C++ services, or a dedicated risk-management and order-management system?

3. Broker and execution limits
   For XAUUSD, how would you evaluate Vantage’s execution quality, liquidity, slippage, order limits, and spread widening as position sizes increase? Are there specific things I should test with the broker before scaling?

4. Risk management
   What safeguards would you add before scaling significantly? For example, independent exposure limits, maximum drawdown controls, daily loss limits, execution monitoring, and automatic shutdown mechanisms.

5. How would you scale it?
   If you had a working MT5 EA with a year of live trading history, what would your next steps be? Would you gradually increase position sizes, conduct forward tests at each stage, or build additional infrastructure first?

6. What becomes the bottleneck at scale?
   For those who have actually scaled automated strategies, what tends to break first: the strategy’s edge, execution quality, broker limitations, infrastructure, or risk management?

I’m not looking for a shortcut to multiply profits overnight. I want to understand how to scale this properly without destroying the existing edge or taking on risks I haven’t accounted for.
I’d especially appreciate advice from people who have moved beyond small retail setups and have experience operating automated strategies with meaningful capital.

Happy to share additional details about the strategy, drawdowns, trade frequency, and performance statistics if that would help.

Thanks!

instead of finding a algorithm which works why not copy someone who already figured it out?

curious to hear why this is a bad idea, hard to execute?

for example the hyperliquid leaderboards are their for anyone to view and analyze

I have been working on the ORB strategy EA for XAUUSD to win prop firm challenges, need opinion does the strategy and ea will work or should I give up as far now the backtest are not promising. Anyone build successful ORB profitable EA

Out of curiosity, Has anyone successfully turned a profitable strategy on the strategy tester into a profitable bot system?
I don't tend to use it but I see a a lot of hate on it and was just curious if anyone has been able to closely replicate its results in a live hands free setting. it does seem like it could be useful for certain things.
Slippage and commission can be factored into this tester which can help make results more realistic. And I know it can be easy to overfit with this tester but genuinely just curious on peoples experiences when attempting this.

Most of us trade with some version of the same rule: take the 15-min setup only if the bigger picture agrees. The 60-min trend is up, or the stock’s sector index is above its 20 SMA, or NIFTY closed green yesterday.

It’s a sensible filter. But it’s surprisingly easy to backtest it wrong.

The trap: peeking at an unfinished bar

Say your chart is 15 min and your filter is “60-min close above its 20 SMA”. At 10:15, the 60-min bar covering 09:15–10:15 is just finishing. At 09:45, it’s only half done.

Many backtests quietly use that bar’s final close at 09:45, which you couldn’t have known at 09:45. The result is a strategy that looks great on paper and falls apart live, because in the backtest it was reading the future.

How it should work

• Data1 = your trading chart (e.g. 15 min)
• Data2 = same stock on a higher timeframe (60 min), or an index/sector index
• Data3 = a third layer (e.g. NIFTY Daily as a market filter)
• Rule: at any Data1 bar, the strategy only sees Data2/Data3 bars that have finished. The daily bar becomes available on the day’s last intraday bar, not at the open.

It also helps to label bars by their close time (like TradeStation). The 09:15–09:30 bar reads 09:30, and the last bar of every timeframe reads 15:30. Then Data1, Data2 and Data3 line up visually, and you can check exactly what your strategy “knew” at each bar.

A simple example to test yourself

• BUY when EMA 9 crosses above EMA 21 on the 15-min chart
• …AND the 60-min close is above its 20 SMA (finished bars only)
• SELL is the mirror image

Compare it with the plain EMA crossover. Sometimes the filter cuts the losers, sometimes it just cuts trades. That’s exactly what backtesting is for.

Where I’m going with this

I’ve been building this into RN TradeLab, the backtesting tool I work on. v0.24 is coming soon with:

• Data2/Data3 panels on the chart: same symbol on a higher timeframe, or any index/stock
• Strategies that can use Data2/Data3 directly, with a built-in check that they only see finished bars
• Close-time bar labels, so everything aligns across timeframes
• New candle styles (hollow, OHLC bars, Heikin Ashi, volume candles)

Not financial advice. This is about testing ideas properly before risking money on them. Happy to answer questions about multi-timeframe backtesting in the comments, even if you use a different tool.

I’ll keep posting what I learn while building this. Follow me if you’d like the updates and the v0.24 release.

I’m trying to optimize my algorithm but for using options, not shares. with options, there’s just so many choices and variablea. DTE, Strike are the obviously two, but how do you algorithmically choose that?

im particularly asking for day trading. For example, if im trading on the 5 minute candles, I wouldn’t choose 0 DTE, obviously. But do I pick 1 week out? monthly contracts? Do I go OTM, ITM, or ATM? If ITM, then how deep ITM?

can someone give me some guidance or at least some pointers to research about?

Does anyone have clean, high-quality historical daily QQQ constituent weighting data covering at least the last 12 months that they'd be willing to share?

I haven't found a high-quality dataset at an affordable price. Getting NDX weightings directly from Nasdaq comes with a nosebleed price tag. Thanks!

I took 156 markets listed on both Kalshi and Polymarket with the same settlement rules, and priced a 1,000-contract buy three ways against the live order books, fees included.

Extra cost per $1,000, compared with routing across both:

• Kalshi only: +$24.51
• Polymarket only: +$6.80
• Always the cheaper venue: +$0.69

Where routing really pays is size on thin books. 10,000 YES on Inter Miami to win the MLS Cup cost $2,173.52 routed, vs $3,297.77 on Kalshi alone and $3,310.31 on Polymarket alone. On its own, each venue’s book runs out and the price climbs. Split across both, it stays low.

So I built a smart order router that does this automatically. It reads both order books, adds each venue’s fee to every price level, and fills your order from the cheapest price first, whichever venue it’s on.

The smart order router is available here: github.com/Synpath-ai/synpath

Disclaimer: Not financial advice. Educational purposes only.

Lots of people go ahead and point out 'as much as possible' 'as much as you can really' 'at least (some amount of years that is gigantic)'. But what does the answer turn to when you consider an algorithm that trades across much shorter distances and scalping algorithms that go in and out of trades after 5 minutes? Depending on frequency, too. I would assume its important to test out all possible markets, crashes, etc... If youre trading so quickly and at such a small length of time, market conditions that show results after a full day essentially wont impact you at all, or so i think? Im not too experienced so any advice is much appreciated.

(and no i dont mind downloading years of data i just want to know if at some point it becomes redundant)

Every retail trader I know has been told not to hold over the weekend. I ran the same rules twice across 26 years of SPY to see what that instruction actually costs, and the gap is far bigger than I expected it to be.

The rules are deliberately boring, because the only thing being measured here is the exit. Buy SPY at the close after two down closes in a row, hold five sessions, exit at the close. $10k account, January 2000 to March 2026, commission and slippage charged on both sides of every fill.

Held through the weekend: 605 trades, 56.9% wins, profit factor 1.42, +282.9%, max drawdown 34.6%

Flat at every Friday close: 727 trades, 53.1% wins, profit factor 1.05, +20.6%, max drawdown 49.3%

Same entries on the same days, and the only difference is that the second version goes home flat on Friday and buys back in when the signal returns. It handed back 93% of the return and the profit factor came in at 1.05, which is close enough to 1.00 that youre working for your broker.

The part I did not expect at all is the drawdown. Going flat for the weekend is supposed to be the cautious choice, and it finished with a worse peak to trough, 49.3% against 34.6%, because selling Friday repeatedly took it out of the bounce and had it buying back higher on the Monday.

____

Theres an obvious objection here and id raise it myself if this was somebody elses post. Flattening on Friday also means holding for fewer sessions on average, so the shorter hold could be doing the work here rather than the weekend.

So I ran a control with the exit moved to the Wednesday close, same entries and same costs: 739 trades, 55.1% wins, profit factor 1.29, +170.7%, drawdown 28.7%. Chopping the hold short midweek costs about a third of the return, and chopping it short on Friday costs nearly all of it, so the weekend itself is where the money goes.

Two things worth being honest about. This is one mean reversion entry on one index ETF and its long only, so a good chunk of what the Friday exit gives up is simply SPY drifting upward, and a lot of that drift lands between the Friday close and the Monday open. A short strategy, or a single name carrying real weekend headline risk, could very plausibly come out the other way. The SPY history in Agenticks runs from 2000, so i used the whole thing instead of choosing a window that suited the answer.

The cheapest version of this test for anybody holding swings is to take your own last two years of trades, cut every one of them at the Friday close, and total it up again.

Mother Superior has been running live for roughly two weeks. It is a short-term XAUUSD scalper/intraday EA built from eight separate modules, with an integrated recovery layer. The first nine traded days are currently at +12.22%.

It has already traded through a few red-folder news events and behaved well so far. Still, two weeks is two weeks. The first genuinely ugly market regime will tell me far more

than a green opening run, so we’ll see what happens.

I’ve spent roughly three months building the system. Each module has its own entry logic, Magic Number and basket management. The shared risk layer lets me limit simultaneous positions and includes optional equity protection.

Only 2022–2024 was used for development and parameter selection. The final system was also challenged on the history outside that window:

• 2017–2021: earlier untouched survival/stress history

• 2022–2024: development and parameter selection

• 2025–2026: formal frozen-parameter OOS

That gives seven calendar years outside the development window. I keep the older survival/stress years separate from the formally declared OOS period, but the same final structure survived both sides of the development sample.

The main continuous 2021–2026 real-tick report used a fixed 0.01 first lot with no compounding. Starting from $1,000, realised balance finished at $3,903.12 across 1,511 closed trades. Profit factor was 2.93 and every tested calendar year was positive. The number I care about most is the observed MT5 maximum relative equity drawdown: 12.82%.

For the Monte Carlo check I resampled the complete deal history 10,000 times in 50-deal blocks. This keeps some local clustering instead of pretending every trade is independent. Median ending balance was $3,896; the 5th–95th percentile range was $3,504–$4,318. Median maximum realised-balance drawdown was 4.1%, with an 8.0% 95th percentile.

The Monte Carlo only rearranges realised trades. It cannot reconstruct every floating basket or invent a gold regime that never appeared in the source data. That is why I still treat the observed 12.82% MT5 equity drawdown as the more relevant risk figure.

How much live history would you personally require before giving meaningful weight to the untouched tests and bootstrap results?

I work alone and rarely get to share the mini achievements that each day's dev brings, I find this a real shame.

So I am curious what are you building today? Or what was the latest thing you built which you're proud of that no one got to hear about?

For me, today im working on improving my display/GUI for certain features to make live monitoring easier.

Do you think it's okay using Metatrader's api for fetching historic data? Has anyone noticed discrepancies? Isn't it supposed to be the actual numbers you'd get trading with that specific broker?

Wsp guys, I just want to thank this sub first because the first time I ever seen what algo trading is, was in this sub when i joined in january this year, after 10 months of 1000 different algos created, backtested and modified I trusted one and made 4.6k this month since i switched from prop firms to personal account.

Im not selling anything but just wanted to show u guys its possible, willing to answer any questions but im not a pro still, also attached the backtest of this year. And before u say its only a year of backtesting the strategy its based around works always because its similar to scalping, also backtested last 3 years and it works

I have come to realize that trading is always going to be hybrid and never fully automated, after fantasizing that I can pass on to my family a program that they can use well after I am gone. Each intervention in the program pushes you further into discretionary trading land, as does each manual execution, tweak and so on.

As such, this will be my last post on here as I retire this account and ride off into the sunset.

I wish everyone happy trading and lots of profits.

Good luck and farewell, cheers!

I know backtesting does not imply future profits, but I am very excited

Hi folks, am putting together my specs for a new home build PC. I am reading conflicting info RE the best CPU for the task. Top contenders are: A. AMD 9950X , B. AMD 9950X3D and C. Intel 270K Plus. Any recommendations?

I’m a software developer working with trading/OMS concepts, and I’m trying to understand how mature trading systems handle order lifecycles and state consistency.
Consider a hypothetical scenario:
A parent order has a quantity of 2,000, with a child order of 500.
A modification requests changes to both the parent and child.
The child replacement is sent to the broker but gets rejected.
The original child remains valid, while the internal parent may already have been updated.
I’m curious how production OMSs typically approach this:
How are parent-child associations and order-version histories maintained across replacements and rejections?
How do systems handle consistency when a parent modification succeeds internally but the child replacement fails externally?
Are these workflows generally handled through state machines, event-driven reconciliation, operation-level coordination, or another approach?
Are there any public architecture documents, open-source projects, or books worth studying?
I’m particularly interested in hearing from engineers who have worked on institutional trading systems, FIX integrations, or OMS/EMS platforms.
Beyond this specific problem, I’m also trying to become better at independently reasoning about complex system architectures rather than jumping straight into code or relying on AI-generated solutions.
Would appreciate any practical insights or learning resources!

Hello everyone,

I’m interested in finding high-frequency data (timestamps at one-second intervals) for about 10 stocks on the New York Stock Exchange. A few years ago, I wrote a thesis investigating a correlation between trading times and stock prices based on a test I developed. Out of sheer curiosity, I want to see if this correlation still exists, but I can’t seem to find official high-frequency data for the New York Stock Exchange, for example.

Is there a way to find high-frequency data for free?

Say you have a dataset. It says X event happened at time Y. There is a very good chance it did not happen at time Y.

This is due to:

1. Measurement error
2. The timestamp does not mean what you think it means

For example, say you are using the SEC Corpus. Claude and other LLMs will advise you to use acceptance datetime.

This is a bad idea.

Acceptance datetime is not when the filing has been released to the public. It actually may be days prior. For example, a filing accepted on a Friday, may be released to the public on Monday.

Also, the SEC misreports acceptance datetime on most of its endpoints. There is an issue where it assigns either the exact timestamp, +4, -4 or +5,-5 (depending on DST). The correct timestamp is found (generally) within the SEC filing's SGML file.

Additionally, SEC data is often published first via newswire. So, markets may have already reacted to the news.

This extrapolates to other datasets. One way to improve backtesting performance is to create features that assume that timestamp may not be quite correct. If this works, it is a sign that there may be something off with your datasets timestamps.

Links (can remove, not sure if falls afoul of self promotion):

• SEC filing detected time dataset: GitHub
• Bad timezone timestamps: GitHub

So I'm struggling with getting a proper data source. I was running a few strategies fine with IBKR's realtime feeds till recently a strategy popped up that requires futures/CME MBP-1 for building certain indicators.

I need to test this strategy on paper and for 2 weeks now, I realized that IBKR is not able to maintain a continuous realtime feed. I get quotes with timestamps that are off or huge delays. There's no delay on processing as these get logged immediately. The code is running on a server in a datacenter and I've ruled out processing/network lags.

The timestamps that come with the quotes will be 10+ seconds old.

Before I spend $400/month on data from databento/massive for paper testing a strategy, I would like to know if there's a cheaper alternative.

I can maintain a funded account on some brokerage if it gives access to websocket and proper data streams or have a subscription that's significantly cheaper than $400.

I've looked at

FMP: no futures stream

moomoo: futures is only quotes; no best bid/ask

tradier: futures requires CQG, other vendors involvement.

kinetick: I've reached out to them, still waiting.

Update: subscribed to tickstream for $79 .. will try them out.

A broad profitable parameter surface can coexist with almost no persistence in which settings win. I tested that distinction with 700 configurations of a monthly momentum and correlation allocation rule.

The base rule ranks 14 global asset classes on average 3, 6 and 12-month momentum, keeps the top 5, then holds the least-correlated 3 using the previous 252 trading days, with equal weights and a cash filter. I varied momentum lookbacks, shortlist size, holdings count and correlation window. Each configuration ran over 1987 to 2026.

I split the comparison into 1987 to 2018 and 2019 to 2026, ranked the configurations by CAGR within each window, and compared their ranks. The correlation was 0.048. The published settings moved from 3rd to 58th among the 700.

The return improved while the relative rank deteriorated. I can't use the higher later CAGR as evidence that choosing those settings worked. All 700 configurations exceeded 10% CAGR after 2019. The later period favoured the family broadly.

I also inspected the 19 neighbours that differ from the published settings on exactly one axis. Their full-period CAGRs ranged from 10.6% to 15.0%. The median neighbour gave up 1.51 percentage points of annual compound return; the worst gave up 4.07. Those are losses relative to the published configuration, not negative portfolio returns.

My interpretation is narrower than "the parameters don't matter". I didn't find a collapse from moving a setting, but the split also didn't show that the best fitting-window rank carried forward. Ranking noise can select a winner even when the surrounding rules all benefit from the same market behaviour.

There are material limits. The grid is centred on the published values, so I chose the neighbourhood. Universe choice remains outside this parameter sweep. The claimed 2019 design date has no public timestamp; I can't establish a genuine holdout from that assertion. This split is a retrospective diagnostic, and a friendly later regime doesn't establish an edge.

When you tune a systematic rule, what do you hold back as a genuine out-of-sample window, and how do you stop yourself from looking at it early?

looks like the LLM "goldrush" is cooling off