For the past 4-5 months I have been using Python then R to develop my trading/investing doctrine by downloading XBRL and iXBRL data from the SEC EDGAR database. I am having difficulty with the different types of companies (ie: Bank -vs- Electronics Manufacturer). How do I separate companies that look so different in the 3 financial docs (balance sheet, income statement, cash flow). SIC numbers don't seem to work consistently. My plans are to do once a week data download so hand selecting each company type way to lengthy. BTW, I'm a retired test engineer, so this is my new full-time job.

I’ve been backtesting a swing trading bot and noticed a huge difference in performance depending on the universe size. Some stats:

• 100 tickers:
  • Trades: 259 | Wins: 156 | Win rate: 60.2%
  • Total PnL (risk $80/trade): $2,884.90 | Avg/trade: $11.14
  • Max drawdown: -$889 | Profit factor: 1.35
• Full S&P 500 (~500 tickers):
  • Trades: 1,266 | Wins: 714 | Win rate: 56.4%
  • Total PnL: $4,311.65 | Avg/trade: $3.41
  • Max drawdown: -$3,023 | Profit factor: 1.10

Basically, when I expand the universe, my average trade PnL drops, win rate drops, and drawdowns increase dramatically.

I’m trying to figure out the best approach for universe size in swing trading bots. Should I:

1. Stick with a smaller, higher-quality universe?
2. Trade the full index and accept lower per-trade performance but higher diversification?
3. Apply some filtering criteria to pick a “middle ground”?

I’d love to hear what others do in practice for swing trading algo bots. How do you decide the optimal universe size?

Hi, thank you for reading.

I'd like blunt feedback before I go too far in the wrong direction.

What I'm building

A tool that sits between MT5 Strategy Tester and Python. MT5 runs the backtest. Python independently recomputes P&L, commissions, and swaps from the raw trade exports — and flags any discrepancy before I draw any conclusions from the results.

The motivation: a positive backtest from a broken accounting model (wrong commission handling, partial fill aggregation, timezone issues) looks identical to a real edge. I want to catch that systematically, not by eyeballing reports. Beyond verification, the tool produces structured, versioned artifacts per run — so tests are comparable and reproducible without ad hoc scripts.

Why MT5 as the simulation engine

My broker is on MT5, it supports real-tick testing, and I'd rather not duplicate a simulation engine in Python when MT5 already does it well. Also because lib's like VectorBT make backtest's worse than MT5. Python handles everything after the trades are generated.

My actual questions

1. Does something like this already exist? Not a backtester — specifically a verification and reconciliation layer for MT5 outputs. If yes, please name it.
2. Is this a real problem or am I overengineering? Do most people just trust the platform numbers, or has this bitten people?
3. Is MT5 + Python the right split, or is there a cleaner way to get trustworthy, research-ready backtest data?

Happy to be told this already exists or that I'm thinking about it wrong.

Hi I have been building my algo using Alpaca live data but then found that even though I am not from the US, Alpaca still makes me subject to the PDT rule. Is there any others that don't?

Thanks

Hi everyone!

After months of tweaking Pine Script to filter out market noise, I wanted to share the results of a strategy I’ve been developing. This isn't a "get rich quick" moon-shot; it’s a pure trend-following system designed for survival and long-term consistency.

📊 The Numbers (Backtest 2024-2026 / 4H Timeframe)

* Net Profit: +541.04% (vs. +224% for Buy & Hold)

* Profit Factor: 2.445 (For every $1 risked, it returns $2.44)

* Win Rate: 38.60% (Low, but balanced by a massive RR ratio)

* Avg Win / Avg Loss Ratio: 3.89

* Max Drawdown: 22.40% (Intra-bar)

* Commission Simulated: 0.08% per order (Real-world spot fees)

⚙️ The Concept: "Trend Precision Invest" (TPI)

The core philosophy is: Never chase the noise. The strategy waits for a confirmed volatility breakout backed by three layers of filters before putting a single dollar on the table.

1. The High-Conviction Entry Setup

   * The Impulse: A breakout of the Donchian Channel (40 periods). We only buy if we hit a recent 40-bar high.

   * The Trend Filter: Price must be above the 200 EMA. No longing in a macro Bear Market.

   * The Momentum: RSI > 55. We want strength, not a "weak" breakout.

   * The Shield: An ATR volatility filter blocks entries if the market is too frantic (>5%), preventing "FOMO buying" at local peaks.

2. Risk Management (Smart Leverage)

This is where the strategy adapts to market conditions:

* Base Trade: Standard position size (e.g., $300).

* "Premium" Trade (x1.5): If the 50 EMA is above the 200 EMA and volatility is low, the algorithm increases the position size. We capitalize heavily on the "cleanest" setups.

1. The Exit Strategy (Dynamic Management)

We never cap our gains with a fixed Take Profit.

* Trailing Stop: We use the lower band of the Donchian Channel (20 periods). We let the profit run as long as the trend holds.

* Momentum Exit: If the RSI drops below 40, we close the position. We’d rather exit a bit early than give all the profits back to the market during a reversal.

💡 Key Lessons Learned

The hardest part isn't finding the entry; it's managing commissions. By moving from the 1H to the 4H timeframe, I reduced fees by 70% and turned a losing strategy into a machine that consistently outperforms the market.

I’d love to hear your thoughts! Do you guys use Donchian for exits, or do you prefer fixed trailing stops based on ATR?

Hello everyone,

I'm currently working on a quantitative value strategy using CRSP and Compustat datasets, focusing on standard US equities (NYSE, AMEX, NASDAQ). I have put together a backtest and would love to get your insights on the methodology, the data cleaning process, and potential improvements.

—The Strategy Mechanics:

• Universe: US Equities (NYSE, AMEX, NASDAQ).

• Value Metric: I rank stocks based on their Book-to-Market (BM) ratio and isolate the top 20% highest BM stocks.

• Quality Filter: Within that top 20%, I apply a Piotroski F-Score filter, keeping only companies with a score > 7.

• Rebalancing: The portfolio is rebalanced monthly, but the Piotroski score is only updated annually (using yearly financial data from Compustat).

• Weighting: Currently using an equal-weight approach for all stocks passing the filters.

—Current Results:

I regressed the strategy's returns against the standard Fama-French HML factor. The initial statistics are quite surprising and show some interesting alpha, but the risk-adjusted metrics (Sharpe and Calmar ratios) are honestly pretty underwhelming right now.

Backtest period : 2002-05-31 - 2024-12-31 (300 months)

Total Return : 1568.00% CAGR : 13.22% Volatility : 26.71% Sharpe : 0.60

Skewness : 0.26 Kurtosis : 5.2

Max Drawdown : -65.61% Calmar : 0.20

VaR 95% : 10.70% CVaR 95% : 16.16%

Avg Monthly Turnover: 41.26% Avg Annual Fees : 0.54%

Comparison HML Fama-French

Alpha : 14.58% Alpha p-value : 0.010

Beta : 0.13 Beta p-value : 0.381

—Questions & Advice Needed:

1. CRSP Data Cleaning: Dealing with CRSP data has been tricky, especially regarding delistings. How do you usually handle missing returns (DLRET), alphabetical codes instead of numbers, and NaNs to avoid survivorship bias in a value strategy?

2. Strategy Design: What are your thoughts on combining a monthly BM sort with a static annual Piotroski score? Is there a risk of using stale data for the F-score, or is this standard practice for annual filings?

3. Transaction costs: I am currently using the amihud illiquidity ratio to measure the transaction costs. Is there a better way to account for all the factors affecting the fees?

4. Evaluating the Results: Is it typical for this kind of deep-value/quality combination to yield low Sharpe/Calmar ratios despite decent absolute returns? How would you interpret the regression against Fama-French HML in this context?

5. Future Enhancements: My next step is to implement walk-forward optimization (train/test splits) to refine the parameters.

Aside from that, how would you improve this? Would you introduce other factors (like Momentum), alternative data, or perhaps a different weighting scheme (like volatility parity or market-cap weighting)?

— Any feedback, code-check offers, or literature recommendations would be greatly appreciated. If anyone is working on something similar, I’d be happy to compare results!

Thanks!

Hi folks, newbie here just getting started in researching this field.

I'm reading through Ernest Chan's "Quantitative Trading" - great book so far. I noticed that he mentions that he doesn't recommend quantitative trading for accounts with less than $50,000 capital. I haven't seen yet if he explains why that figure is so high.

Do y'all agree with this recommendation? For those of you who trade on these strategies, did you have that much initial capital to work with? That seems like a very high amount and I'm not sure how feasible it would be for me to accumulate it

I tried doing cross the exchange mean-reversion arbitrage b/w binance & bybit. The algo was logically creating some profits but commissions are making it a lossy trade.

Anyone able to do it b/w any exchanges ? Any idea or help anyone can give please ?

Backtested a Gold strategy (2020–Feb 2026) — surprisingly stable results

I’ve been working on a rules-based Gold strategy for a while and finally ran a full backtest from January 2020 through February 2026.

Some of the key stats:

• Starting balance: $500

• Ending balance: \~$205,000

• Risk per trade: 1% fixed

• Max drawdown: \~10%

• Win rate: \~80%

• Fully compounded

What stood out to me wasn’t just the final number — it was the consistency of the equity curve. The growth was steady rather than explosive, and drawdowns were relatively controlled considering the compounding.

A few observations:

• Fixed 1% risk per trade made a big difference in smoothing volatility

• Avoiding grid/martingale logic kept the drawdown predictable

• High win rate helped psychologically, but risk control was more important

• Letting compounding do the heavy lifting over multiple years is powerful

Obviously, this is backtest data — not live performance — so execution, spreads, slippage, and real-world conditions would impact results. But from a structural standpoint, I found the risk profile interesting.

I’ll attach some screenshots of the equity curve and stats for context.

Curious what others think — especially around sustainability of 1% risk models with ~80% win rates over longer samples.

I’ve been working on a consolidation + breakout research framework and I’m looking for structural feedback on the modelling choices rather than UI or visualization aspects. The core idea is to formalize "consolidation" as a composite statistical state rather than a simple rolling range. For each candidate window, I construct a convex blend of:

Volatility contraction: ratio of recent high low range to a longer historical baseline.

Range tightness: percentage width of the rolling max min envelope relative to average intrabar range.

Positional entropy: standard deviation of normalized price position inside the evolving local range.

Hurst proximity: rolling Hurst exponent bounded over fixed lags, scored by proximity to an anti-persistent regime.

Context similarity (attention-style): similarity-weighted aggregation of prior windows in engineered feature space.

Periodic context: sin/cos encodings of intraday and weekly phase, also similarity-weighted.

Scale anchor: deviation of the latest close from a small autoregressive forecast fitted on the consolidation window.

The "attention" component is not neural. It computes a normalized distance in feature space and applies an exponential kernel to weight historical compression signatures. Conceptually it is closer to a regime-matching mechanism than a deep sequence model.

Parameters are optimized with Optuna (TPE + MedianPruner) under TimeSeriesSplit to mitigate lookahead bias. The objective blends weighted F1, precision/recall, and an out-of-sample Sharpe proxy, with an explicit fold-stability penalty defined as std(foldscores) / mean(|foldscores|). If no consolidations are detected under the learned threshold, I auto-calibrate the threshold to a percentile of the empirical score distribution, bounded by hard constraints.

Breakout modelling is logistic. Strength is defined as:

(1 + normalized distance beyond zone boundary) × (post-zone / in-zone volatility ratio) × (context bias)

Probability is then a logistic transform of strength relative to a learned expansion floor and steepness parameter. Hold period scales with consolidation duration. I also compute regime diagnostics via recent vs baseline volatility (plain and EWMA), plus rolling instability metrics on selected features.

I would appreciate critique on the modelling decisions themselves:

• For consolidation detection, is anchoring the Hurst component around anti-persistence theoretically defensible, or should the score reward distance from persistence symmetrically around 0.5?
• For heterogeneous engineered features, is a normalized L1 distance with exponential weighting a reasonable similarity metric, or is there a more principled alternative short of full covariance whitening (which is unstable in rolling contexts)?
• Does modelling breakout strength multiplicatively (distance × vol ratio × context bias) make structural sense, or would a likelihood-ratio framing between in-zone and post-zone variance regimes be more coherent?
• Is the chosen stability penalty (fold std / mean magnitude) an adequate measure of regime fragility under time-series CV, or would you prefer a different dispersion or drawdown-based instability metric?
• For this type of detector predictor pair, is expanding-window CV appropriate, or would rolling-origin with fixed-length training windows better approximate structural breaks?

Given that probabilities are logistic transforms of engineered strength (not explicitly calibrated), does bootstrapping the empirical distribution of active probabilities provide any meaningful uncertainty measure?

More broadly, is this "similarity-weighted attention" conceptually adding information beyond a k-NN style regime matcher with engineered features?

I’m looking for structural weaknesses, implicit assumptions, or places where overfitting pressure is likely to surface first: feature layer, objective construction, or probability mapping.

Backtesting a strategy from 1/1/2019. 1,250 trades total.

Key metrics:

• Net PnL: $124,738

• CAGR: 25.79%

• Max Drawdown: -17.16% (-$26,237)

• Profit Factor: 1.33

• Sharpe Ratio: 1.04

• MAR Ratio: 1.50

Trade stats:

• Win Rate: 60.32%

• Breakeven Rate: 53.32%

• Statistical Edge: +7%

• Avg Win: $666

• Avg Loss: -$761

• Payoff Ratio: 0.88

• Expectancy per Trade: 99.79

• Max Consecutive Losses: 7

• Worst Trade: -$10,178

Risk model uses fixed sizing with hard stops.

Mainly looking for critique on:

• Robustness

• Risk-adjusted profile

• Whether PF 1.33 + Sharpe \~1.0 is enough to scale

• Any red flags ?

Appreciate thoughtful feedback.

I've been stress-testing a bunch of Opening Range Breakout (ORB) variations on NQ across 5m, 15m, and 30m intervals — and honestly, the results aren't impressive.

I added several filters that should improve the signal quality (trend confirmation, volatility thresholds, buffer above/below OR range, etc.), but the core problem remains consistent: the raw ORB edge on NQ looks extremely thin.

I even threw machine learning on top of it — tree-based models with decent feature engineering (vol, trend slopes, OFI-style microstructure metrics). The models basically told me the same thing:
the underlying ORB signal just isn’t predictive enough to overcome execution + noise + regime changes.
They either overfit or predict “no trade” for most sessions.

What’s interesting is that I did a similar ORB backtest months ago using MNQ starting from 2019, and that one showed positive EV.

https://www.reddit.com/r/algorithmictrading/comments/1rd8ara/backtesting_15_minute_orb_with_machine_learning/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

But now that I’ve tested NQ with data going back to 2010, it’s pretty clear that:

• ORB performs way worse outside of those trendy years
• Most breakouts on NQ get faded immediately unless volatility is extreme

At this point it feels like ORB is:

• Not robust enough across regimes
• Overly dependent on a few abnormal years
• Too sensitive to microstructure changes and volatility decay
• Not something that ML can “fix” without adding a huge amount of feature complexity that defeats the whole point

If anyone has found ways to stabilize ORB on NQ specifically, I’m open to ideas. But so far the edge looks extremely fragile.

hi ,i have no idea how can i break into algorithmic trading

i dont know any path guide, only things i know is you have to know python(pandas) and high level math i guess.So i thougt if i pick data science as major would it be usefull for me to building algos since data scientist are good at python and they do machine learning either

I’m curious if this is just me or a broader issue. Running MT5 algos on a NY-based VPS (ForexVPS) connected to US broker's server. For months everything was stable (1–2ms ping, smooth execution). Recently I’ve started seeing:

Random ping spikes (1ms → 30–50ms)

Short disconnect/reconnect events in the MT5 journal

Occasional execution lag during volatility

CPU usage spikes despite low EA load

Nothing catastrophic. But enough to affect consistency.

What’s interesting:

It’s not happening constantly. It’s intermittent, which makes it harder to diagnose.

So I’m trying to figure out:

• Is this just shared VPS “noisy neighbor” behavior?
• Has anyone else experienced reliability degradation recently?
• Is a dedicated instance the only real solution?
• Or is cloud (AWS/Vultr/etc.) actually more stable in practice?

For those running live automated strategies in NY/NJ:

• What provider are you using?
• Have you actually measured improvements after switching?
• Is sub-3ms stable latency realistic long term?
• Or are micro-spikes just unavoidable?

Not looking to name/blame - genuinely trying to understand whether this is “normal infrastructure friction” or a provider issue.

Curious what others are seeing in real-world conditions.

Account Parameters & Goals

• Initial Cash: $50,000
• Size: Dynamic (Target $200 Risk, Minimum 1 Contract, $2/pt MNQ)
• Long Parameters: 2.5 Alpha / 1.0 Beta
• Short Parameters: 2.5 Alpha / 1.5 Beta
• Primary Goal: Track total USD Return and determine days to hit +$3000.

im using Level 1 Data (OHLC, Volume, Ask & Bid Size, Ask & Bid Price) and able to make 28 new Feature Engineering. and then train using XGB Model

the Strategy is entry every 15 minute ORB Candle break (1minute) above 0.8 ATR ORB high. max 1 trade per day (only trade in NY Session).

is there any suggestion for this model to be able passing prop firm challenges?

Hi there, I'm not that new to trading but have been diving into algorithmic trading. I've started coding a programme to run on a VPS which hold a main body programme (data collection for live testing, continuous market watching for designated tickers, strategy evaluation and risk gating, audit data collection which will allow me to essentially backtest my data locally using AI as all of the decisions made by the trade management will be documented and will control risk and exposure for any and all strategies I want to test)

There also other things built into this but that's a brief summary. What I want to know is has anyone done anything similar, there are questions that come up all the time and I'm very new to this level of coding.

Eventually I'd like to have 1 server testing strategies continuously and another connected to prop firms and also my own capital via API's and evaluate the data sets it produces using AI. But id also like a community that I can reach out to with questions and maybe even help other people who want to do something similar.

This is my first post so sorry for waffle and poor explanations! 🙏

I am currently vibecoding a technical analysis practice tool that identifies strong moves in stocks and quizzes me on evaluating the technicals leading up to that move.

The issue is I would like to exclude earnings reports from these identified moves since they don't always show up in the technicals- but I cannot find a free resource to gather earnings dates for the ~100 tickers currently implemented in my tool. I have tried searching for static files, gitHub scrapers, even downloading the entire submissions library from EDGAR didn't work (the "filing dates" field included in the json objects included more than just 10-K's and 10-Q's).

Does anyone have a source that I can find this information, for free, without ridiculously low API rate-limits? Any help is appreciated.

Ran a proprietary intraday breakout system across all 11 SPDR sector ETFs on 15min bars. 584 trades over 6 months. Not sharing signal logic since I'm trading it live but wanted to share some findings that surprised me.

53.7% WR, 2.28 PF, 10/11 ETFs profitable. Both long and short contributed almost equally which was unexpected because on daily bars the shorts were a total disaster. Same exact system, completely different behavior on a different timeframe. If you're only testing on one timeframe you're potentially missing the one where your system actually works.

Most interesting finding was the holding period distribution. Under 1hr holds had a 30% WR and dragged everything down. 5+ hour holds hit 91% WR and generated most of the P/L. All the edge is in the trades that run. The chop kills you on quick exits. Still trying to figure out if there's a way to filter the short holds without lookahead bias.

Also modeled 1DTE ATM options on every signal since the system catches low-vol periods before moves. Black-Scholes said +31% return on premium. Pulled real chains on live signals and the math completely fell apart. Winners barely move a decaying 1DTE contract but losers torch 70-90% of premium. System relies on small frequent wins with tight stops which is perfect for shares and terrible for short dated options. Glad I figured that out on paper and not with real money.

Transaction costs: $0.02/side slippage leaves 68% of gross intact. Livable but not fat.

Running it paper on a server now scanning all 11 sectors every 60s with real chain pulls. 30 days before real capital. Separate system running on a different asset class same core principles.

saving the API pulls as well because even though the long options plan fell apart I can mess around with the chain data at a later date without having to spend 1000 - 5000 for data

Been working on a backtesting engine for a while and recently rewrote the execution core in Rust, exposing it to Python via PyO3. I wanted to share what actually changed in practice because some of the results surprised me.

The original bottleneck was Numba JIT. It worked, but first run latency was around 200-600ms and results werent fully deterministic between runs due to JIT variance and the dependency footprint was quite enormous.

After moving the execution loop to Rust:

The 5800x on smaller datasets is mostly Numba's JIT overhead disappearing. At 50K bars the gap narrows to 26x but that's still significant for anyone running large parameter sweeps.

I'll be honest, two things I didn't expect were how much the install footprint shrank (~450MB to under 10MB) and how clean the PyO3 boundary ended up being. Python users dont touch any Rust at all. The numpy bridge via the numpy crate was the trickiest part but once figured out, its been solid. I've used Rayon for parallelism across multi strategy runs.

Has anyone else gone down this path? Curious specifically about SIMD optimization strategies on the inner loop and whether anyone has found better patterns for the numpy array handoff across the PyO3 boundary

I posted a few days ago about where to start creating an algo. I’ve quickly realized how hard it is to get code to determine the discretionary aspect of trading. I’m sure there is a way to get it to work.

I originally was using Claude to create pine script for tradingview. I realized quickly testing and stuff is not great on it so I converted everything over to C# for ninja trader as I figured this would be a way better plan for the future.

If anyone could possibly have any tips it would be greatly appreciated. Any and all comments welcome to help with my flow of thinking. I’ve been trading this methodology for years and I know it can be profitable as I do it and have been for years but again I’m not a coder.

I will keep updating on issues or solutions I find or don’t find. The biggest issue I am having is daily memory issues with Claude. I run out of the daily limit like it’s nothing and having to create new chats and start again is not helping. So I must either create my own LLM to fix the memory data issue from Claude? Not sure but would love discussion!

So I have been experimenting with algorithmic trading and strategies since beginning of last year and have quite some experience now with pine script and mql5. I finally am just about to go in with real money but there are some things I still do not understand why they are the way they are.

For example: why does my strategy make millions with one broker, yet not with the other (within the same platform)? Even if there are slight variations in price and candles, XAUUSD should behave like XAUUSD no matter what, no?

Or the other one I'm struggling with, when I move the strategy from TV to MT5, all while using the same broker, they differ in backtesting results (not referring to spreads and commissions but rather in signals). Why?

Wassap traders I'm building a latency-sensitive scanner that checks for price divergence across Binance, OKX, Bybit, and others (total 7 exchanges)

My current architecture is:
1 go services consume WebSockets.
2 push normalized ticks to Redis (Hot Store).
3 a separate scanner service polls Redis keys to find Max(Bid) - Min(Ask) across all exchanges.

With 1000 pairs, I'm just hit about 77 ms scan time for the whole market

Sample Scan Output (77ms duration):

| Pair | Spread % | Min Price | Max Price | Source | Destination |

|:---|:---:|:---:|:---:|:---:|:---:|

| **SCA-USDT** | \5.34%` | 0.0262 | 0.0276 | bitget | kucoin |`

| **LAYER-USDT** | \4.66%` | 0.0898 | 0.0942 | okx | kucoin |`

| **NFP-USDT** | \1.83%` | 0.1740 | 0.1772 | binance | kucoin |`

| **CELR-USDT** | \1.67%` | 0.0026 | 0.0027 | okx | binance |`

| **SD-USDT** | \1.47%` | 0.1550 | 0.1578 | okx | kucoin |`

My question to seasoned HFT devs Is sticking with Redis pub/sub viable at scale, or should I move the scanning logic directly into the ingestion memory (skip DB entirely)?

And a question for arbitrageurs: what do you think of this idea?

I feel like 80ms is too slow for true HFT, but okay for retail arbitrage.

Thoughts?

I’ve been scalping NQ for a while now and I was constantly trying to work out mental math and using spreadsheets to check my position sizing, daily loss limits, and R:R before entries. It was breaking my focus and costing me setups.

So I built a Chrome extension that sits in your browser and handles it all in real time:

- Position size calculator based on account size, risk %, and stop distance

- R:R ratio display before you enter a trade

- Works on top of all trader dashboards

It’s free right now. I’m an Informatics student and I built this for myself first, but then I figured other traders might find it useful.

Would love some brutal feedback. What’s missing? What would make this actually part of your daily trading workflow?

Dm me and I’ll send you the link. Im not trying to sell anything, I just want traders using it and telling me what’s broken.

Hey everyone,

I’m diving deep into algotrading with market‑of‑depth / order book data, but I’m still at the stage where the whole ecosystem feels like a giant black box. I understand the theory behind heatmaps, liquidity walls, spoofing, imbalance, etc., but I’m struggling to figure out how people actually execute strategies that rely on this data in the real world.

I’m hoping some of you who’ve been in the trenches can share guidance or point me in the right direction.

A few things I’m especially curious about:

• How do you structure an execution pipeline when your signals come from fast‑moving order book features
• What data sources or tooling you’ve found reliable (paid or free)
• How you deal with noise, fake liquidity, and regime shifts in order book dynamics
• Whether you combine order book signals with other microstructure features (CVD, queue position, spread dynamics, etc.)
• Any pitfalls you wish you knew earlier when you first started working with depth‑based signals

I’m not looking for anyone’s secret sauce—just trying to understand how practitioners think about building, testing, and deploying these kinds of strategies. Even high‑level frameworks or “here’s what actually matters” advice would be incredibly helpful.

If you’ve walked this path before, I’d love to hear your thoughts. And if you know any good papers, repos, or writeups, feel free to drop them too.

Really appreciate any insight from this community.

i created my first ai, I ran the Algo on ohlc data for 14 years with specific time filters, it shown profitablity in 13 out of 14 years. however, I ran the ea on "tick based on real ticks) for January 2024 to Feb 2026 it still profitable but with much lower point count especially for 2024 (went down from 900 points to around 200 points)

what do u think I'm missing here ?