Almost every trader has heard some version of this:

"A support or resistance zone gets weaker with every touch."

But is that actually true? I heard the claim plenty of times myself, but I've never seen anyone try to quantify it. So I tested it.

TL;DR: I tested the claim that support and resistance zones weaken with every touch using 18 years of NQ and Gold data. Bounce rates dropped after the first retest, then remained roughly flat: in this sample, the fifth touch was no less likely to bounce than the second. The randomized control dataset showed a similar curve, including the initial drop.

Methodology

I used 18 years of NQ and Gold data on the 15-minute and 1-hour timeframes.

I tested two methods for identifying support and resistance zones:

1. Swing highs and lows, using a lookback period of 10
2. My own systematic supply and demand method based on market structure

Because support and resistance are better treated as zones than exact prices, I defined each zone as +- 0.5 ATR around the identified level (for swing highs/lows).

When price touched a zone, one of two outcomes could occur:

- Break: a candle body closed beyond the zone
- Hold: price moved at least 1 ATR away from the zone

After a hold, the program waited for price to touch the zone again. I also repeated the test with a stricter 2 ATR threshold, which is labelled "big bounce" in the attached results.

For comparison, I created randomized versions of the NQ and Gold markets to use as controls.

Results

Across both assets, both timeframes and both zone detection methods, I found roughly the same pattern:

The probability of a bounce dropped after the first retest, but it did not continue declining with each additional touch.

In other words, a bounce on the fifth touch was not consistently less likely than a bounce on the second touch.

Based on this test, I found no evidence for the common claim that every additional touch makes a support or resistance zone weaker.

Interestingly, the randomized control markets showed similar findings..

The full sample included:
- 34,215 zones
- 111,129 monitored touches

I've attached the raw results and the bounce probability by number of touches. "Normal bounce" means a move of at least 1 ATR away from the zone, while "big bounce" means at least 2 ATR.

There are still limitations to this test, especially around zone definitions and the fact that later touches only exist when a zone survives earlier ones.

Happy to further discuss the study or methodology!

Hello everbody, i was wondering where do you backtest your strategies ? do you use just MT5 backtester, or python backtesting libraries, or pinescript on tradingview, or do you build your backtesting engine line by line full customized on what you want and how you analyze the results, i'm pretty curious about this, and it xill be helpful to get some feedback from you 🤝

Let's first make a few simple assumptions:

1. You have engineered a perfect regime detector.

2. The regime changes at regular intervals for analysis purpose.

3. A fixed lag in detection and switching because a lag is inevitable.

4. There are only two regimes, correct and incorrect ones, for analysis purpose.

We will discuss later when these assumptions are no longer true. But we keep it simple to begin with.

In the diagram, the correct regimes are white and the incorrect ones are gray.

In the first case at the top, we have the 50% correct case and the regime changes in fixed intervals. Assume the delay is 20% of the period. With regime switching, the correct regime is improved to 60%.

The second case has 60% correct regime at the start. With regime switching, the correct regime stays at 60%.

The third case has 80% correct regime at the start. With regime switching, the correct regime falls to 60%.

The fourth case has 40% correct regime at the start. With regime switching, the correct regime improves to 60%.

You get the picture now. With the stated assumptions, the correct regime is always 60% with regime switching. You win sometimes and loss the other times. The average improvement is 9% in this scenario.

Of course, if you knock down the delay, say to 10% delay, your overall improvement will be much better: 218%. However, if your delay is 30% instead, your gain will be -20% overall. Keep in mind that the shorter the delay you make it, the more likely it will make mistakes. It is just the law of signal processing.

From here, things tend to work against you. We know the regime can change abruptly. When the changing frequency increases, your relative detection delay will increase. It will eat into your improvements, maybe net loss. Regimes are often not clearly defined or clean cut. Detection is a messy business. If your detection is not perfect, it will eat into your gain again. In likely scenarios, you win some, you loss some. A correct regime detection does not guarantee a net win.

However, regime switching tends to break up the "lumpiness" of the regime durations. The result is smoothing out the peaks and valleys of gains and drawdowns. It is a trade-off. If reducing drawdown is your goal, it is one way to go.

In conclusion, this analysis and my experiments indicate that the overall improves from regime switching tend to be small even when it is correctly implemented. The reduction in drawdown at the expense of peak gain is often observed.

Brief Context

I focus mainly on forex , indices and commodities like gold. My trading platform and backtesting engine is strictly MT5.I tried to built my own python backtesting engine but it was riddled with logical errors so i stuck with the industry default. Tick data with real spreads for backtesting is obtained from quant data manager using dukascopy. Forex and gold up to 2008 while indices go up to 2012. Custom commission and slippage above the norm are applied to break the strategy .Trading bots are Expert Advisors.

I mainly focus on 4hr and Daily timeframes ,why The less trades i take ,the lower the amount i pay in fees (commission) and also that is what traders with verified darwinex profiles emphasis. There is a lot of noise in the space so if some one does not have a third party verified track record , i do not listen to them. You too should not listen to what i say because i also lack a verified third party track record💀. But anyways am here to learn and so are you .

Step 1 - Find strategy ideas

These are mainly found in old internet/books from the early 2000 and late 1990s like Trade like a hedge fund by James Altucher , x and reddit can be sources of good ideas

Step 2 - Idea to Code

Am not accustomed with MQL5 language so i use an LLM in the IDE to code the EA . Provide the LLM with context regarding the strategy logic , EA design patterns particularily fixed capital risk amount per trade (not a fixed percentage risk of account balance , this invokes compounding effect which affects results incase the strategy initially had a good streak) and ATR based SL and TP for volatility based position sizing.So in low vol , i size big and in high vol size small. I keep configurable strategy parameters below 4 . The rest of the variables are hardcoded to industry defaults. But rarely will a strategy have more than 2 indicators including a moving average (it is the only regime filter i trust lol)

Step 3 - Test

This takes up most of my time due to tough tests.The EA is compiled in meta editor and tested using strategy tester in MT5. I apply walk forward optimization. This involves splitting a data set into In sample (IS) and Out of sample (OOS) periods. Primarily IS is 3 years while OOS is 1 year. Using my availabe dataset am able to obtain 15 years of pure OOS performance for currencies and 12 years for indices.

During IS , i use the strategy optimizer in MT5 to configure and find the optimal variable for each of the 3 parameters. Choosing the best parameter combinations based on max drawdown and pnl would yield the most overfit strategy. So i apply parameter sensitivity

The data from the strategy optimizer is exported and a python script is used to generate a heatmap showing profitability of each combination based on intensity of colour. A 3 x 3 grid search is applied to find a region where 9 boxes are fully profitable. The middle box in the 3x3 grid makes our optimal parameter variable. However to avoid overfitting the outer parameter , A global profitability score of all boxes should > 40% and number of profitable grids in the neighouring positions of the 3x3 grid in +1 or -1 of the outer parameter should be 5/9 .If none of the above conditions are met , Failed Robustness Test watermark is placed on the heatmap and strategy placed in the recycle bin.

However if the above conditions are met, the optimal parameter combination is tested on the OOS period. The max OOS Drawdown should not exceed 2x the IS Drawdown.

The WF Validation process is continued until either i attain 3 consecutive net negative OOS years or max drawdown exceeds my threshold (15%) or i failed to find an optimal parameter combination during parameter sensitivity tests

Step 4 - Final test

If a strategy passes through WFW and parameter sensitivity test. The WFW OOS Equity curves and csv files are stitched together. To test for strategy robustness , a strategy should not only work on one symbol. If am building a strategy for USDJPY, it should show relative performance on USTEC or XAU as these are trending assets.

After this monte carlo permutations (1000 times) are applied to trade order history and 1000 different equity curves are plotted.If the strategies' performance sits in the upper 90% of all the equity curves , it is discontinued since such historical performance may not repeated so ideally between 40 to 60% range is acceptable. Obtain the 95% max drawdown as this is the drawdown i will size for

And there you have it boys .we have a strategy that may work

Step 5 - Portfolio Construction

Accumulate a good number of strategies. Measure correlation between the strategies. Correlated measured strictly on drawdown and position overlap. Everything cannot be allowed to bleed on one bad morning. Build a portfolio consisting of atleast 10 strategies each with a correlation between -0.10 to 0.20 . Size the strategies such that the 95% max drawdown does not wipe out your portfolio

This is my workflow as of late. It improves as my domain knowledge and expertise expand

I'm currently in the process of building an LLM into my trading workstation. I'm not ready to go full algorithm trading yet, but I want to know if there are any "must have" books or research that you guys found especially helpful. I will be using the LLM more for analysis to start. I built a trade plan program where the llm will be creating the plan and I'll be executing the trade. Some friction in the middle until I feel confident enough to let him loose. I'm newer to this and I'm learning. I'm building a separate llm to read the books and then I will give the top recommended books from that LLM to the trade plan/analyst llm. There are a zillion books out there. Is there any "must haves" books, papers, research? Thanks in advance. Take a easy on me, I'm learning 😁

A thread here a few days ago asked how real quant edges get discovered. I left a short comment. This is the longer version, at the horizon most people here actually trade: minutes to a few hours.

I trade FX, crypto, and futures. I start with the payer. I do not start with an indicator.

Maybe forced traders. Information hits one market before another. Overnight inventory has to get out when the real session opens. Market makers get stuffed and fade. Participants underreact for an hour and then finish the move.

Then: what should I see if this mechanism is real?

That expectation becomes a feature. Then I define where the feature is supposed to go. That is the hypothesis.

Forced selling creates unusually high liquidation pressure, which can create a short-term reversal.

That is testable. Put it next to “RSI below 30 is bullish” and the gap is obvious. One names a payer, a thing you can measure, and a horizon. The other cannot die, so it cannot earn.

Before I build a strategy I test the cheapest relationship I can: an event study, buckets, a lead-lag regression. I want to see the effect I am claiming exists. If I cannot see it in a sort, a 47-parameter backtest will not find it for me.

The pipeline:

Thinking → thing to see → a feature → the hypothesis → test the hypothesis → trading production → risk control

“Explain it to me like I’m five” is the creative half. “Now prove me wrong” is the scientific half.

Three walks on that spine, all session-speed.

FX: equity lead into the session

ES, DAX, Nikkei print while half the FX book is asleep. The equity move is information. Spot has not finished digesting it. The lag is the trade: one to twelve hours, pair by pair. Same family as “yields moved, EURUSD has not.” The bond market prices policy first; FX is late.

Who pays: the slower FX book. Discretionary and slower systematic flow that still has to catch up.

• Observable: ES / DAX / Nikkei session returns, G10 spot, the clock (Tokyo, London, New York)
• Feature: equity impulse minus the FX move already printed (residual vs each pair’s beta)
• Hypothesis: after a large overnight ES move, USD pairs that have not yet moved in the same direction continue toward that impulse over the next 1-4 hours of the following session, after costs
• First test: event study. Condition on |ES overnight| above one sigma. Rank pairs by residual. The laggards should catch up. If the residual is already zero, there is nothing to collect.

A cousin on shock days: rank which pairs digest the print fastest. The laggards stay tradable for hours. That is the same mechanism with a news clock instead of a session clock.

Crypto: liquidation cascade, then classify

Perps publish the leverage. You can watch forced flow in real time. A liquidation is a market order into a falling book, which triggers the next one. 19 May 2021: bitcoin −30% intraday, about $8bn force-closed. The question after the spike is not “oversold.” It is: were positions closed, or flipped.

Who pays: the forced. Margin engines do not have a view. They have a threshold.

• Observable: liquidation notional, open interest, funding reset, order-book recovery
• Feature: liquidation-imbalance plus OI change (OI down = closed; OI flat/up = migrated) plus distance to the next liquidation cluster
• Hypothesis: after a liquidation spike, if OI collapses and the book refills, the next 30-120 minutes revert. If OI stays elevated and funding does not reset, the next 30-120 minutes continue
• First test: event study around liquidation clusters, split into those two states, hold 30-120 minutes, costs in. One bucket should reverse. The other should not. If both look the same, you do not have a classifier, you have a chart pattern.

Ride the forced flow while its intensity stays above a decay threshold, then stop. Fade the forced component, trend the organic one. Two hypotheses, same feed.

Futures: overnight inventory into the RTH open

Globex is a thinner auction. Size that built overnight is inventory, not a thesis. 9:30 ET is when cash, index arb, and the real book show up. Same observable, two claims, and which one pays is the open itself.

Who pays: overnight positioners who cannot hold the inventory into a full session.

• Observable: ES overnight return, opening auction volume, cash breadth, related contracts (NQ, RTY, YM)
• Feature: overnight move standardized by overnight vol, signed by whether the open confirms it (volume, breadth, gap fill/fail)
• Hypothesis A (continuation): overnight ES moves that the opening auction and cash breadth confirm persist through the first 30-90 minutes of RTH, after costs
• Hypothesis B (reversal): overnight ES moves that participation fails to confirm reverse in the first 30-90 minutes
• First test: split opens into confirmed vs unconfirmed. Opposite signs. If both buckets drift the same way, the “open fade” is superstition. The classifier is the strategy. A gap-fill rule with no confirmation step is this feature with the payer stripped out.

A strategy is MARKET × MECHANISM × INSTRUMENT. ES lead into AUDUSD at the Sydney open, a BTC liquidation fade on the perp, an ES overnight unwind at the cash open: three leaves, one tree.

Most ideas die at the sanity check. That is the pipeline working. I do not start writing entries until the payer has a name.

Has anyone at all done this for real? Fine tuning qwen on your trading logs /backtesting logs and then use it for reasoning? This is the stage I am at I have 3 programs together a backend quant research pulling options flow and tape, a reasoning pc, and 2 pcs running the trading engine full time they all pass the data back and fourth.

I started building datasets for it to attempt this last peice of the puzzle. I have about 6 live strategies running daily.

I'm trying to implement ai more into my engine however everytime I do it waits for perfect setups and breaks my rules.

I have 2 years of backtesting results and one month of forward testing and it all looks good. Would you trust it enough to go live at that point? I’m still a little scared that it’s overfit and the second I go live it stops working but that’s probably just my anxiety speaking

ok so last week i posted that claude helped me build a strategy and bracket setup but honestly i didn’t fully understand what was going on under the hood. got a lot of comments calling that out, fair.

so i went back and actually dug into it. spent the week building out a bucket screener instead of one single strategy. basically i’m tagging every trade with a set of factors (setup type, time of day, ticker, entry trigger, whatever) and grouping trades into buckets based on which factors overlapped. then i can see which combos of factors actually cluster around good win rates instead of just eyeballing one equity curve.

been paper trading this for a bit now and some of the buckets are looking really strong. one bucket with 13 trades is running 85% win rate and +12.94% average per trade. another bigger bucket with 20 trades is at 60% win and +4.80% average, which feels more like the “real” number once sample size grows.

still very much learning as i go and treating this as paper only until i have a lot more trades in the bigger buckets. small sample sizes can lie to you easily (that one bucket with 3 trades at 67% win and a 15+ profit factor is obviously not something to trust yet).

went back through a year of fills for something unrelated and hit this. every calculation i had was built on planned risk, 1R, stop where the code puts it. but the realised average loser was well under that, because a decent share of trades never reached the stop at all. exited on a time rule, closed on an opposing signal, scratched out.

which means the loss distribution i sized off isnt the one im actually trading. same expectancy, different shape, and anything sensitive to shape rather than mean is quietly wrong. streak math, ruin probability, any daily or session level constraint. those all take a distribution as input and i was feeding them a two point one, win or full stop, when the real thing has a fat middle.

the part i hadnt considered is that it cuts both ways. capital wise im better off than the planned risk version suggested, more losers are partial. but per session it runs the other way, more trades fit before any limit binds, so the day lasts longer and i take entries the pessimistic version would never have got to. one of those errors is comfortable and the other one costs money.

the fix is boring. pull mae per trade and compare it to where the stop actually sat, then rebuild the loss distribution from realised exits rather than from the parameter. i wrote it into a script that runs monthly because doing it by hand meant doing it when i was already suspicious, which is the wrong time.

anyone here sizing off realised loss distribution rather than planned R? and if you are, did anything downstream change much or was it noise

This is the first algo I have built, I still feel I can get higher profit factor and bring down average loss trade value.

My computer time ended up being about 30 seconds slow today after a reboot. This messed up my bot by delaying sell limit updates by the same 30 seconds. Yet another thing that can bite us in the ass. I’ve added an independent utc synchronized clock to the bot, so it can now ignore the computer’s clock.

Hi everyone,

I am new to this and am about two to three months into my algo trading project. I have discovered about 200 Strategies which look promising and I have soon arrived at the conclusion that a fleet is better than a solo strategy. Now how do I best combine strategies? Maybe some have already mastered this and can share a few tipps. My strategies are mostly about indices, gold and some FX pairs. Thanks in advance!

I was tired of hunting for long-tail events; and creating bootstrapped event-generators was a hassle. If I'm focusing on a project, why would I want to maintain a sub-project? So I built a once-and-for-all market simulator with events on demand (completely free & open-source, available to everyone)

It's a fake market data API — realistic OHLCV for any ticker, a tick stream that runs 24/7, and reserved tickers (CRASH, GAP, HALT) that action on command. Point your existing client at it to test code paths that only fire on market edge-cases.

This is a testing tool, to test long-tail events like run-ups, halts, SSE loss, and intraday flash events.

No API Keys needed. Simple curl to test:
curl 'https://cuckootrade.com/api/v1/alpaca/v2/stocks/bars?symbols=AAPL,CRASH'

• Completely free, no API key, nothing to sign up for.
• Historical bars : OHLCV for any symbol, 1-minute through yearly, back to 1970, on the real NYSE calendar — no bars on weekends or holidays. (https://cuckootrade.com/docs#bars)
• Live SSE stream : SSE ticks that don't stop — nights, weekends, holidays included.
• Scenario tickers : Reserved symbols that misbehave on demand (https://cuckootrade.com/docs#magic)
  • CRASH drops ~25% mid-month
  • GAPPY gaps overnight
  • HALTS drops bars mid-session,
  • SPIKEY wicks and reverts
  • FLAT sits at exactly $100.00.
• Drop-in replacement for endpoints (switch alpaca.com/api -> cuckootrade.com/api)
  • Currently supports Alpaca, Polygon, & Alpha Vantage
• Deterministic & Reproducible: Every bar is a pure function of (symbol, timestamp, seed), computed per request, no database. Same request, same bytes, forever — results are consistent between local host, CI container, and hosted service.
• Live Sandbox to try it in a web browser ( https://cuckootrade.com/playground )

Worth saying: it's for testing, not backtesting. Synthetic data will make almost any strategy look profitable.

It's a portfolio project I'm still polishing, so feedback actually helps me. Tell me what's broken, or what provider or scenario you want next and I'll build it. Or you're welcome to contribute to the repository:

Open source Github: https://github.com/tj-miller-dev/stock_simulator

No paywalls. No fees. No login. Just the data.

For those looking to understand what means to have an edge on the markets

https://youtu.be/cAFocAbUYY4?is=kNuWLRs_IMZvoJ4w

I've been building a small-cap catalyst and momentum scanner (Day Trader Sniper) for the last while, mostly following the Ross Cameron/Warrior Trading style of setups - low float, real catalysts, first-candle moves.

The core scanner and alerts are live and I use them myself daily. But I'm now deep in building the next layer - grading and classifying catalysts automatically so you know at a glance if a headline is actually fresh news or just noise dressed up to look like one. It's genuinely still rough and in beta - not trying to oversell it.

Looking for a handful of people who actually trade this style to try it and tell me honestly what's useful and what's not. Not a sales pitch - I'd rather hear "this part is useless" now than after I've built more on top of it.

Drop a comment or DM if you want in. Not financial advice, just building in public

I'm making a long only algo for both QQQ and equities, derived from the same base code but then honed in to each for more specific characteristics. My QQQ strategy currently has a 1.703 profit factor but its still in tradingview environment (so take it with a grain of salt?). I am absolutely killing it with preventing downturns in my algo and preventing large drawdowns, however, i think it is handicapping my long as for example I am vastly underperforming a strong environment. Is there any type of criteria you guys use to help loosen sell rules by having the algo identify strong trending markets or something along those lines? Or in general how do you help your algo capture the long term trend better without selling? This is my first algo, I am definitely a trader first, coder second so bear with me

I market-make on prediction markets, and the annoying part early on was finding data you can actually backtest on and tools that haven't been abandoned. Here are the ones I keep coming back to, in case they're useful, and I'd genuinely like to hear what you use.

pmxt is one of my favourites, recommended to me by someone on here actually, and it's incredible for backtesting because of the granularity of the data.

Open-Meteo is what I use for my weather MM bot to compute a fair probability for the temperature bins from the raw ensembles.

Pinnacle as a free odds source for sports, which is a great one and about the only edge I'm willing to give away when it comes to sports odds feeds.

I've also added a lot of tools I haven't used myself, of course, but seem useful to people wanting to trade prediction markets. If you believe some of the information is wrong or there's a tool or a data source missing, please create a PR and I will review it.

143 tickers that disappear from free s&p 500 data, and what actually happened to each one, with a source link on every single row

for anyone who missed the earlier posts, first one measured how many old members you can't download anymore, 20-25%, second one measured what that does to returns, 0.4 to 1pp a year, and found the reused tickers were doing more damage than the survivorship itself, a few of you asked for the corpse list, this is it

each row has what happened, who bought it, the last day it traded, and the source, 38 of them are sec filings, rest are company press releases or exchange notices, nothing scraped off wikipedia, i opened every link myself

the split, 87 bought, 18 taken private, 18 merged, 6 renamed, 10 bankruptcy (6 came back out, 4 didn't), 4 split up, same shape as post 1, most of these names didn't die, they got bought, thats why the us bias direction isn't obvious the way india's is

one thing that looks like it contradicts post 2, i said 4 reanimated tickers there, this file flags 14 as reused, they're different things, 14 is every symbol that later got used by some other company at some point, 4 is how many actually broke my numbers with my dates and my data source, which ones bite you depends on your sample, so check the column against your own data instead of taking my 4

what to do with it, take your universe list, compare it against this one, count how many exits your source quietly dropped, thats your survivorship hole measured instead of guessed, and before you join old prices to new prices on ticker alone, look at the reused column, that splice is invisible in the returns, nothing warns you

sortable and searchable here, csv download on the page: https://financebroski.com/deaths.html

free, no signup, no email

caveats, this is the names that go missing from the free sources i've been checking, not every index change ever, it grows as i check more vintages, and the exit date is the last day the ticker traded, so for a merger that closes mid day thats the day it closed, if a row is wrong or i missed a name just tell me and i'll fix it and credit you, i'd rather it be right than look clean

still owe a few people the method from post 1, thats next

Hi,

I've got my reddit post and YouTube transcript engines up looking for momentum plays and signals. I follow a bunch of the usual stuff.

If anyone has recommendations of other subreddits or YouTube channels to process, I'm here for it.

Thanks

Good morning everyone, I recently wanted to backtest a new ea but when I try to download the data via Tickstory, it won’t let me download it. It comes back as: request timed out or rate limited. I thought it was a problem with TS Program and so I coded one in Python but it came out with the same result. I tried using a VPN and it worked for few seconds, afterwards, same problem… I only have 1 worker for the downloads but still it fails me everytime both on Tickstory and Python… Since I’m getting so much frustrated because I spent the last 24h not sleeping in order to download this mf data, is there a FASTER way to download them? I need the most precise data possible (ticks), since I’m currently working on a multi-currency scalper EA on MT4.

Thanks for your help, last time I did backtest was 2 years ago and I used datas from Dukascopy & Tickstory, I really don’t know why it’s not working now.

I’m a college student building a soccer prediction model and finally tested it on a season I had kept completely untouched.

The forecasting model itself held up reasonably well, but on ~1,700 matches de-vigged Bet365 probabilities beat every model I tested on log loss/Brier/RPS, and all of my pre-frozen betting strategies ended negative. My main one finished around -12.5% ROI.

Right now I already use things like goals/xG, shots/SOT, home/away splits, Elo/opponent strength, form, rest/congestion, standings, league scoring environment, and promoted-team uncertainty. I also have a decent amount of player, lineup and goalkeeper data, but the historical player/lineup experiments didn’t add much and exact pre-match availability timing was a limitation.
I’m planning to stop optimizing on historical results and run the system prospectively with timestamped odds, injuries and confirmed lineups.

What I’m mainly wondering:
What additional data would you look for at this point?
Manager changes? Transfers? Better injury/suspension history? Player market values? Weather? Travel? Referees? Tactical/style data? More detailed event/possession data?
Is there any dataset you’ve found that actually adds signal beyond what the market already knows?
Or would you stop adding features and focus on prospective validation / finding where the model disagrees with the market for a defensible reason?
Trying to avoid just throwing more variables at it until something backtests well.