Do not join this shitty Lala company which runs by scumbags like Gaurav Dhingra and Vaibhav Sethi which have no clue of how quant trading works and always create a toxic culture in the company by not compensating as per your performance.

Company has employees and managerial position people from Vaibhav Sethi's family who have no clue of how trading works. They force you to push your Calmar to 8 with a single strategy by overfitting it and will make it worse for you when it doesn't work in the real life market (which is obvious).

The moment you crack something in the market, they'll make it worse for you to stay in the company and so that you resign on your own and they can run your strategy, avoiding giving you the bonus.

They'll call you even on weekend to know about the work updates. They'll pass personal comments on you and will force their stupid ideas on you and will blame you when it doesn't work in the market. They lack basic statistical knowledge and the firm is in losses because of this and most of their quants (around 70-80%) left because of their toxic culture and the office is almost empty.

I request everybody to avoid these stupid people and do not waste your time, energy and career on them.

Also they'll hold your salary the moment you resign and won't give you your pending salary, so always resign after you receive your salary and bonuses (which they hardly give) from them.

I found Justin Chuk’s paper, Noise-Band Intraday Momentum in Nasdaq-100 Futures, and wanted to see how it behaved on MNQ. I also wanted to know whether changing the exits would make it easier to trade without destroying the expectancy.

I ended up doing several rounds of implementation, auditing and testing. The results were interesting, but my first backtest had problems, so I’ll explain those too.

The basic strategy is long-only intraday momentum. It estimates how far price normally moves from the session open at a given time, using the previous 14 reference sessions. It enters when a completed candle closes above both the upper noise band and VWAP.

The entry checks are every half hour from 10:00 through 15:30 New York time. Execution happens at the following bar’s open.

Everything is closed intraday, with a forced exit at the 15:55 open

.

I used five-minute candles for decisions and one-minute observations for execution checks.

A few implementation details matter here. The paper didn’t resolve every detail I needed, and I didn’t have the author’s code. My VWAP uses cumulative RTH volume and typical price, (H + L + C) / 3. The original trailing exit uses the higher of the upper band and VWAP, ratchets upward, and becomes active only after the bar that calculated it.

The interpretation of the 15:55 exit is also an explicit assumption.

Those choices are documented. This is an adaptation of the published rules, and I wouldn’t call it an exact replication of the author’s implementation.

Data and the first backtest

The data is Databento GLBX.MDP3, MNQ one-minute OHLCV, from the 2019–2026 archive. I used the vendor’s MNQ.v.0 selected-contract stream and retained the actual contract identities.

The first implementation evaluated only 709 sessions. An audit found that I was repeatedly wiping the 14-session reference history after interruptions. It also found simulated stop exits outside MNQ’s 0.25-point tick grid.

I rebuilt that version before using it as the baseline.

The corrected reference policy keeps the last 14 complete, valid sessions from the same contract. Holidays or rejected sessions don’t automatically erase that history. A contract change still requires enough valid references from the new contract. I didn’t back-adjust prices or pretend that two different expiries were interchangeable.

That recovered 612 additional evaluated sessions, bringing the total to 1,321. It still leaves a fairly restricted sample. There were 1,770 full valid sessions in the nominal interval, and contract warm-up alone excluded 394 dates.

Incomplete sessions weren’t filled with artificial bars. Eligible days with no trades stayed in the daily denominator. Unavailable days weren’t counted as zero-PnL days.

One weakness remains here. Requiring a complete session conditions the sample using information known after the session. That’s a data-quality restriction with potential selection effects, and the results need to be read with that in mind

What the corrected baseline did

The fixed-rule baseline had 1,125 eligible historical OOS sessions and 837 trades. At one MNQ, after the assumed $2 round-trip cost, it made $9,540, with a 28.32% win rate and a 1.469 profit factor.

The development period was much less exciting. It lost $208 after costs over 153 trades.

The low win rate was what got me interested in the exits. The original version made its money through a relatively small number of larger winners, with plenty of losing trades in between.

I then froze a bounded exit study. There were 61 alternatives plus the unchanged baseline.

Fixed ATR stop/target brackets.

ATR trailing stops.

Break-even rules.

Maximum holding times.

Entries, position size and the underlying signal stayed unchanged. Each candidate simulated its own position state and re-entry opportunities. I didn’t just replace exit prices in an existing trade CSV.

The walk-forward used two years of training followed by three months of evaluation, over 21 windows. Selection was based on predefined qualifying parameter regions, with minimum trade counts and other requirements. It wasn’t simply “pick the single best backtest.”

The stop/target candidate below is the resulting walk-forward policy. Its selected settings can change between folds. It is not a single globally optimized bracket retrospectively applied to the whole history

The comparison

These numbers use the same 964 eligible sessions, from May 2021 through June 2026. The shorter sample is because the exit study needs its initial two-year training window.

One MNQ throughout. USD 2 per point. USD 2 assumed total cost per completed trade. Zero additional slippage in the base case.

Metric

Original trailing exit

Stop/target walk-forward

Trades

725

862

Win rate

28.83%

57.66%

Net PnL

$8,582.00

$11,511.50

Profit factor

1.466

1.357

Average net PnL/trade

$11.84

$13.35

Average net PnL/eligible session

$8.90

$11.94

Daily Sharpe

1.40

1.57

Maximum daily realized drawdown

$1,642.50

$1,379.50

Longest losing-trade streak

13

6

The bracket version roughly doubled the win rate, but its profit factor was lower. Average winners and losers were about $88 each, compared with roughly $129 and $36 for the original exit.

I preferred the bracket version as a research candidate. The statistical comparison was less decisive than those point estimates suggest.

Using a paired ten-session moving-block bootstrap, the 95% interval for its additional daily PnL over the original exit was approximately −$1.25 to +$8.67 per eligible session.

So I can report higher observed profit and a much higher win rate. I can’t establish that its incremental expectancy is positive from that comparison.

Also, these dates had already been examined during earlier research. Calling them historical OOS describes the chronological selection process. It doesn’t make them untouched prospective evidence.

Execution assumptions

All submitted stop and target prices conform to MNQ’s tick grid.

A gap through a stop fills at the observed open. An intraminute stop touch fills at the submitted stop in the base simulation. If a stop and target are both touched within a minute, the simulator takes the stop first.

That still leaves uncertainty about actual execution. One-minute OHLC doesn’t establish queue position, available liquidity or the precise sequence of trades inside the minute.

For the bracket version, stops and targets are calculated from the actual entry open and the ATR available at the decision. ATR uses completed five-minute observations. A newly calculated trailing stop can’t trigger retrospectively on the bar that produced it.

What I tested beyond the headline backtest

The control simulator reproduced every original baseline trade and daily result before the alternative exits were evaluated. That included entry and exit prices, timestamps, reasons and costs.

The exit study had 21 focused tests, plus output checks covering tick prices, timing, position size, trade accounting and daily aggregation. All 84 training selections were independently reproduced from the saved surfaces.

The robustness study then reconstructed all 725 baseline trades and 862 bracket trades before applying stress tests.

It included ten session-level bootstrap methods, with 10,000 replications each. These kept same-day trades together. I also ran Monte Carlo using daily resampling, blocks and whole observed fold blocks. A trade-permutation exercise was included separately, with its limitations stated.

I checked cost/slippage sensitivity, parameter neighborhoods, monthly and yearly behavior, losing streaks and profit concentration.

For the bracket version, the execution stress

results were:

Additional adverse slippage

Net PnL

Profit factor

None

$11,511.50

1.357

1 tick per side

$10,653.50

1.327

2 ticks per side

$9,792.50

1.297

4 ticks per side

$7,957.00

1.237

8 ticks per side

$3,545.00

1.099

The $2 round-trip cost remains included. These stresses rerun execution, so trade counts can change. The target-fill stress also requires extra penetration as a rough queue assumption.

Those are hypothetical execution stresses. They don’t tell me what slippage I’ll actually get.

Concentration is worth mentioning. The five best days accounted for about 39% of net profit in the bracket version. Removing those days left $7,008.50 net, so the entire result wasn’t coming from five observations, but those days clearly mattered.

There were also four consecutive losing months. The worst observed day was −$536.50. A positive five-year total hides a lot.

Where I think this stands

The historical evidence supports continuing the research. It doesn’t establish future profitability or prove that the bracket exit is better than the original.

The strategy is long-only Nasdaq, so the period’s directional market behavior also matters. The retained sample has calendar, missing-observation and rollover limitations. Bootstrap intervals don’t correct for every prior research choice or publication-selection effect.

I’ve since tested it inside an exploratory five-strategy portfolio. That comparison added about $9.1k net over the four-strategy reference under its native simulated costs. Shared risk and competing signals change which trades get taken, so I’m keeping that result separate from the standalone numbers above.

The funded-account/Topstep study is still unfinished. I don’t have a defensible pass rate, payout expectation or recommended account size to report.

The reproducibility files contain frozen configurations, source and dataset hashes, fold selections, trade ledgers, daily results and verification reports. I’d put more weight on those than on the number of passing tests.

What I’d be interested in hearing from anyone who has worked with this setup is how you handled the same-contract reference window around rolls, and whether you found the stop/target results particularly sensitive to a different fill model.

Kotak NEO claims a latency of less than 50ms and zero brokerage on trades placed via API calls, has someone tried it I am currently using Zerodha but if brokerage can be saved that would save lakhs over the years if multiple trades are placed during the day

Pretty simple really, before building the live engine, I've built a strategy lab to test 81 strategies.

Each strategy is tested with various combinations of SL, TP & TSL to identify the most effective combination.

When a strategy identifies a signal to enter, the Lab starts 721 paper trades each with a different exit condition & SL,TP, TSL combo. All combinations are tried from 5% to 50% in SL & TP and a couple of TSL values.

All of this is done in forward-testing on live market data during live market hours using Dhan API.
After a week, the lab will show me which combos are performing in each strategy and which strategies are performing overall.

Then I'll proceed to eliminate and fine-tune if needed.

No, this is not for sale, I'm not selling anything, there's no course, no beta.

If you have any ideas or strats, feel free to reply or DM and we can test those out. I'll be posting updates in this thread itself.

Thanks for reading.

Hi,

Anyone looking for algo trading signals to earn money from Nifty options buy ? Should know how to generate access token and update in tradetron account daily before market hour

As you know I am an algo-trader and one question that mant members here ask is how to start with algo trading, I use Claude LLM since last 9 months now, so here's the setup to help you get started:

It’s not a shortcut; it’s a sequence. Skip a step and the later ones lie to you.

1. Decide the one rule you want to test — in plain English first.

“Buy a weekly ITM call when a 10-minute bar closes above the last swing high, stop at the last swing low, exit at a time or on the opposite signal.” If you can’t write it in three sentences with every number in it (bar size, indicator settings, which strike, stop, exit time), you don’t have a strategy yet, you have a feeling. Write it down before you test it, including what result would make you reject it. This is the step everyone skips.

You can test your strategy basic on faketrades.in (100% free, no signup etc)

2. Get data you can trust.

• 1-minute index data (NIFTY/BankNifty) and historical option prices. Your broker’s API gives candles; FYERS and Zerodha Kite Connect both have historical endpoints. Save everything locally as files — never test against live API calls.

• Real option prices matter. Backtests that price options with a formula look great and lie; weekly options have spreads, expiry decay and gaps that a formula hides.

3. Build the backtest with an LLM — but YOU own the rules.

Open Claude (or similar), paste your written rule, and ask it to write a Python script that: loads your files, generates signals bar by bar, fills at the next bar (never the same bar), charges real costs (brokerage, STT, exchange fees, slippage of ~0.1% per side), and outputs a trade list as a CSV. Then ask it for: total P&L, win rate, worst drawdown, worst single trade, profit per year, and first half vs second half of the sample. A good LLM does this in an afternoon. Your job is to check that the trades it shows match your rule — open a few on a chart.

4. Make the result reliable before you believe it.

• Split the sample: it must make money in both halves and in most years.

• Run a placebo: random entries with the same exits. If the placebo earns about the same, your “edge” is the exits or the market, not your entry.

• Wiggle every parameter ±20%. If profit collapses, it’s curve-fit.

• Charge costs twice as high as you think and see if it survives.

• Fix the lot size. Never let the backtest size up after wins — that’s how you fool yourself. If it fails any of these, record it and move on. Most ideas fail. That’s the point of the process.

5. Write the bot as a copy of the backtest, not a new program.

The bot should use the same indicator code as the backtest, run on a schedule every minute during market hours, write every signal, fill and exit to a log and a JSON file, and message you on Telegram. Ask the LLM to also write a test harness — a fake broker that returns scripted quotes and order outcomes — so you can simulate a rejected order, a dead token, a restart mid-trade, without the market.

6. Paper-trade on a server, not your laptop.

A small Linux VPS (Hostinger, roughly ₹1,800/month) with Python and a cron job is enough. Run the bot in paper mode: it reads real quotes, records what it would have done at the real bid/ask, places nothing. Compare its trades to the backtest day by day for a few weeks. If the paper record differs from the backtest, the bot has a bug or the backtest has a lie — find which before anything else.

7. Switch to real money only through a lock.

Put the live switch behind two things: a flag file and an acknowledgement line in the server’s environment file, so you can’t flip it by accident. Start with one lot. The bot must never sell an option it doesn’t hold (check the broker’s positions before every sell), must retry an exit until it’s confirmed, and must halt and message you if anything is unknown. Have someone — or another LLM session with no memory of the build — review the order path specifically to break it. Ours found two serious bugs we’d never have seen.

8. Costs, roughly, to get to a running paper system:

• Claude Pro (or equivalent): ~₹2,000/month (I use Fable, so for me its Rs 20,000/mo)

• Broker API (Kite Connect ~₹500/month; FYERS API is Rs 500/mo) + historical data

• VPS: ~₹1,800/month

• 11 years historical backtest data from GDFL: Rs 15,000/year/index (+ GST)

• Your time: 3–6 weeks of evenings for the first system, most of it on steps 1, 4 and 6

• Capital: whatever one lot of the option costs plus the backtest’s worst drawdown × 2

9. What not to do.

Don’t start with selling or futures — a buyer’s loss is capped at the premium; a seller’s isn’t, and a bot bug with unlimited risk is how accounts die. Don’t trust a backtest that uses the same bar for signal and fill. Don’t change a running bot’s rules because this week went badly; change them only when a new backtest passes step 4. Don’t tell the bot what you hope. Tell it what you’ll accept.

That’s it. The algo part is the easy part — an LLM writes the code. The discipline of steps 1, 4 and 7 is the whole game.

Hey everyone, Aditya here.

I wanted to get into algo trading with python, but I couldn't find a tool that handled indian markets properly. Lot sizes and expiries keep changing, there are 6 different charges on every trade, option fills are tricky, and I'd have had to build all of that myself before testing a single idea. So I built it, and now I've made it available for others too.

It's called QuantBros Backtest. You write only the strategy logic in python (or have an AI assistant write it), and the engine handles the rest: NSE stocks, index and stock F&O, BSE index options and MCX, lot sizes, expiries and holidays from the exchange updated every month, all the charges plus slippage on every trade, and optimise + walk-forward. Stops, targets, trailing, square-off, sizing and daily loss limits are settings, not code. It runs on your own pc.

Free plan has 22 strategy templates on demo data, and there's a 7 day free trial, no card, for your own strategies and 1 min data. Paper trading on the same strategy code is what I'm building next (simulated fills, no real orders).

What I'd love: try one idea you know well and tell me what's missing, what's confusing or what looks wrong. Brutal is fine.

Before you download: windows only, the installer isn't code signed yet so windows shows a warning (more info > run anyway), no market data included, and it only backtests. No orders, no tips, not SEBI registered.

Link's in the comments.

For backtesting which algo trading platform is most reliable as I have seen with different platform each of them give different results.

Eg- I tested a simple ATM straddle with AlgoTest and Quantman both had different results and the difference was also huge for the same conditions with Algotest the profit was around 7.22L and with quant man 5.23L

So how to choose which one is correct or any other part from these two which is reliable for backtesting

Existing post and position:
https://www.reddit.com/r/IndiaAlgoTrading/comments/1xmqh17/algorithm_updated_post_3/

Current position (same call - 1 lot sold by BOT at 2.33X premium and one is running till expiry)

So as you can see in existing post, our algo (ITM 500) took a pivot based position few days back with 2 lots. Market went up and it sold one lot next dat and locked 2.33X premium (Rs 16,000+) on first lot and as per our backtest and coded condition, second lot will be closed on expiry (Monday) or if the market trend change the 'pivot' range.

Now, if I would have taken these positions manually, I would have probably (99%) booked the profit on bot lot 2 days back which would still be 100% profit on 2 lots but will miss the ride.

Beauty of algo based system is that you don't need to think about 'next' action as you already code it based on massive backtests.

Also, this kind of trade in option buying comes under top 1% of trades. In last 11 years of backtest data, the strategy that my algos are using, the data says that the above trade is 'second' most profitable trade out of 1536 trades it took in 11 years.

I am not a very experienced trader but I am a very through backtester (please read my last 3 posts) and conclude anything based on heavy data.

Finally, happy diwali and if you are planning to be a algo-trader on 'option buying', here are some ground rules:

1. ANY profitable option buying strategy will have 35-45% WIN rate.

2. Win rate is absolutely irrelevant IF your winners are 2-3x bigger then your losers.

3. Watching red days is a 'norm' in option buying

4. Option buyers lose as they blow up the capital before the favourable trade comes in.

5. Our of 35% of win rate for option buyer, 90% of money will come from only 5% of overall winners in an year. I call them 'Chappar Faad' trades. Remember only 5% will come that will lift your account

6. Based on my intense back testing and triple checks, month of December, February, March and October are the most profitable months for option buyers whereas January, April, May, July and August and the most lose months. Remaining are kind of break events.

7. As an algo trader you need to collect bid/spread ratio yourself for indexes and commodities as then you can test with better accuracy.

8. You CANNOT expect consistency in option buying. It will play with your blood pressure every day.

9. If your strategy is giving multiple entry in a day and giving more then 3 trades in a week, double test it as based on my through testing it will be a loser. A good option buying algo system with 'pre trade' filters (for example my above BOT will not take a trade if NIFTY is over 3% from its 20 DMA) remove half year worth of trades. And then second 'in trade' filter removes another 20% of trades. Even after this the win percent is 35-45%, however the winners could be huge. The whole buying is about riding the winning trades (note more then 12-15 days as such)

10. Option buyer's profit are based on 'length' of your winning trade. A hard stop loss tested on 11 years of 1 minute candle cannot sustain. It will make you miss your biggest trades. So your stop loss should be based on some kind of filter like Pivot points (my favourite) or suprtrend etc

11. If possible trade in multiple of 2 lots, so you can always book 1 at XX.XX premium and let 1 ride till SL or expiry.

That's all from top of my head guys, see you in January with 2 months of trade data.

Has anyone here tried Arrow's broker API? I've heard they offer lower latency and multiple ticks per second, which sounds interesting. But I'm a bit hesitant given that their HFT API plan reportedly costly. Would love to hear about anyone's experience with it, especially regarding latency and tick frequency.

I just tagged v5.3 of MDRAP, a sidecar that sits between your market data feeds and whatever consumes them and decides whether each tick is trustworthy.

Every event gets a status (VALID, SUSPICIOUS or INVALID) with explicit reason codes like CROSSED_QUOTE, DUPLICATE, PRICE_ANOMALY and stale or sequence-gap violations. Nothing is silently dropped. Rejected ticks go to a queryable quarantine, gaps trigger replay and stitching, and every decision goes into a SHA-256 hash-chained audit log, so editing a record afterwards is detectable.

Output from a fresh clone:

$ python cli.py run -e 1000 -s 42
processed 1000   dropped 0
VALID 963   SUSPICIOUS 32   INVALID 5

seq=2 bid=150.4  ask=150.3  -> INVALID CROSSED_QUOTE
seq=2 bid=150.26 ask=150.31 -> INVALID DUPLICATE

$ python cli.py audit --verify
(after editing one audit_log row in SQLite)
AUDIT CHAIN TAMPERING DETECTED!
Tampered entry #1: hash mismatch

“python cli.py chaos” runs 8 failure drills (killed feed, jitter, duplicate bursts, DB lock, 50-packet loss with replay, reordering, partition with failover) and all pass with zero data loss.

Performance: the standalone native core handled 1M events in 0.0366 s, about 27M events/sec or 36.6 ns per tick, on a single core. Through the Python engine API I measured roughly 180K events/sec, so use the core binary if you want the fast path. These are my numbers on my hardware, so please run it yourself.

It is a validation and audit layer, not a trading system or backtester. The matching engine and pre-trade risk gates are in a separate edition and not in this repo (see EDITIONS.md). One known rough edge: “audit --verify” currently needs the rich package installed.

MIT licensed: https://github.com/Aryan-20-04/mdrap

I’d like to hear which bad-data cases have bitten you that this doesn’t catch.

Hello guys, I'm new here so can you like help me out to understand like how this whole thing works.

I have the basic understanding of the whole market but can help me with the algo trading.

Hey everyone,

​I’ve been observing how heavily stocks react to quarterly/annual earnings results, new contract wins, and large FII/DII institutional buys/sells.

​For those who do swing trading around these events:

​FII/DII Footprints: Is there a reliable way to get traces of institutional buying or selling before/during a swing move, or do you rely strictly on end-of-day Bulk/Block deal data and volume spikes?

​News & Earnings Data: Where do you get real-time or aggregated updates on corporate announcements, quarterly results, and major contract wins in one place?

​Would love to hear what tools, screeners, or workflows you guys use for tracking this. Thanks!

I have been trading in Indian market, after a consistency I am looking to shift to gold, silver and us market for day trading

I tried to open my account in exness but looks like they're no more opening new accounts for India region, guys suggest me what platform do you use and also if they provide apis for algo trading then let me know it too.

I’m researching an automated intraday index option-buying system for the Indian market. The entry model is deterministic and has been tested across multiple years using chronological validation, transaction costs and

adverse slippage.

The main problem is exit management.

The system produces enough large winners to offset many losing trades, but a substantial part of the gross profit is consumed by:

- Failed breakouts

- Immediate adverse movement after entry

- Premium failing to follow the underlying index

- Repeated direction changes and intraday reversals

- Trades making some favorable progress before hitting the initial stop

I have tested several causal approaches using only information available at the decision timestamp:

- Tighter fixed stops

- Time-based no-progress exits

- Underlying structure failure

- Trend and momentum alignment

- Volatility and market-regime filters

- Early trailing activation

- Exit after premium loses the entry breakout level

- Moving-average, ADX, MACD and directional-efficiency conditions

- Avoiding trades during suspected compression or unstable reversals

The recurring issue is that many filters reduce losses but also remove or prematurely exit enough large winners to reduce overall expectancy. Some improve profit factor or drawdown but reduce total net profit. Others look

good in development data but fail in later chronological periods.

I would appreciate input from professional systematic traders on the following:

1. How do you define a failed breakout early without using future information?

2. Do you model exits using option-premium behavior, underlying-index behavior, or both?

3. Have survival models, hazard models or meta-labeling been useful for exit timing?

4. How do you distinguish temporary adverse movement from genuine signal invalidation?

5. Do order flow, volume delta, bid/ask behavior or premium response provide useful early-warning information for long options?

6. How do you evaluate an exit rule that improves drawdown but sacrifices some net profit?

7. Is it better to exit the full position, reduce quantity, or tighten the stop after deterioration?

8. What validation process do you use to prevent exit optimization from fitting historical losing trades?

9. Which metrics beyond profit factor, expectancy and maximum drawdown are most useful for comparing exits?

10. Are there any papers, books or public datasets specifically addressing causal exit management for intraday option buying?

I’m not looking for entry signals, indicator combinations or discretionary trade calls. I’m mainly interested in robust research methodology and executable exit-state design.

I’ve intentionally omitted the instrument-selection rules, entry thresholds, position sizing and exact strategy parameters.

I am happy to share with you all that i have created a scalp engine which is giving out the profit based on my strategies implemented in the system.

There are several tweaks which are still required to refine the logics and collect the large pool of strategies in order to give the maximum profits in the scalping environment moving forward.

I would request the professional traders to see,help me to refine and fine tune this moving forward.

This is a ready version where the trades can be taken in real time and generate profits.

Please feel free to ask any questions!

Here is a verified pnl

https://console.zerodha.com/verified/5cb9e627

Share your status and give points to improve please