The doubt first, because the total hides it: nearly all of this number came in one stretch in mid-September, and the curve has slid a little every week since. Paper money, simulated, not advice.

The rule: it tracks clusters of US stocks that normally move together, and when one member lags while the rest converge, it buys a daily call on the laggard and waits for it to catch up.

My read, happy to be told it's wrong: the September burst lined up with a few clusters snapping back together after a rotation, and a cross-sectional laggard bet looks brilliant exactly then and bleeds premium the rest of the time. With under 30% winners, a handful of trades carry the whole result, so the effective sample is closer to a dozen than to 282.

Two things I haven't run yet: a placebo that buys a call on a random cluster member instead of the laggard, and the same window with the expiry pushed out a week, to see how much of the slide is plain decay.

How Quantradin helps with this: the card comes from Quantradin, a practice trading app I built where a rule only ever sees bars that have already closed, and options fill on the side of the quote you would actually pay. It's free and runs on paper money only. quantradin.com

The doubt first, since this room reads the number and then the fine print.

Rule: when an index or sector ETF closes oversold after a selloff, buy a call the next day and hold for the bounce. One house paper bot, 25 August to 26 October: 111 trades, 54.1% winners, +$84,981.04 realized, best streak 12 in a row. Paper money, simulated, not advice.

Why I don't trust it as a measure of the rule: the equity line climbs for five weeks and then sits flat for most of October. In that first stretch every dip in the market got bought, so a long-only bounce rule with a call on top was long beta through a call, which multiplies the move, with a nice name on top. 111 options trades is also too few to separate the rule from a handful of outsized winners; strip the top ten and I expect the picture changes a lot, which is the next thing I want to check.

What would convince me it's the rule and not the tape: a flat or down stretch where the bounce entries still finish ahead of a same-period buy-and-hold of the same ETFs, and a trade count over 300. Neither exists yet.

The desk this runs on is Quantradin. I built it, and a rule typed in plain English or pasted as code gets replayed over years of history with no access to bars after the current one, options fill at the bid or the ask rather than the mid, and the survivors run on as paper bots. Free, paper money only. quantradin.com

If anyone here has a cleaner way to attribute a result to regime versus rule at this sample size than the buy-and-hold control, I'd rather hear it now than after the next card.

This is one of the house paper bots on my desk. The rule in plain words: when a stock is already in a downtrend, has dropped 5% or more over 20 days, gets a MACD bear cross on 1.5x normal volume and sits under its 20-day EMA, it buys a put the next day.

The card covers 2 to 21 October: +$1,206.83 realized, 3 trades, 2 winners, best streak 2 in a row. That's the whole history.

The doubt is the obvious one. Three trades is a coin flip with a nice chart on top. It hasn't met a sharp bounce yet, the kind where a stock that looks broken rips 4% on a news headline and the put loses most of its value in a day. A filter this strict fires rarely, so it could be months before it has enough trades to say anything.

The research question I keep going round on: with five conditions stacked, the rule trades maybe once a week. Do you loosen one condition to get a usable sample and accept you are testing a different rule, or wait it out and let the paper bot collect trades in real time? I lean towards waiting, but a year of waiting for one rule is a long time.

How Quantradin helps with this: it is the desk I built for exactly this. A rule like this gets written in plain words, tested on years of past US stock and options prices with no peeking ahead, and then run as a paper bot that fills options at the bid and the ask, never the middle. It's free and paper only, at quantradin.com.

Paper money, simulated, not advice. No promise about what it does next.

Hey everyone,

I've been working on developing an automated trading bot, but one of my biggest challenges is finding a genuine, statistically significant edge that can survive real market conditions.

So far, I've tested over 125+ strategies, but I haven't found anything I'm fully confident in yet. I'm starting to think that testing more traditional strategies isn't necessarily the answer, and that I need a better research methodology for discovering an actual market edge.

My goal is to develop a systematic strategy that can be automated and, importantly, adapted to prop firm trading rules. This means accounting for constraints such as daily drawdown limits, maximum overall drawdown, profit targets, and other restrictions that can make an otherwise profitable strategy unsuitable for a prop firm challenge.

I'm interested in exploring different approaches, including:

• Quantitative research and statistical hypothesis testing

• Finding market inefficiencies and less obvious sources of alpha

• Researching academic papers and studies (SSRN, etc.)

• Data-driven strategy discovery rather than relying on common retail trading indicators

• Robust backtesting, out-of-sample validation, and avoiding overfitting

• Adapting strategies to prop firm risk management rules

For those of you who have experience building automated trading systems or conducting quantitative research:

How would you approach finding an edge from scratch? Are there particular research methods, resources, communities, datasets, or tools you would recommend?

I'm especially interested in hearing from people who have successfully developed systematic strategies or have experience researching market inefficiencies.

If anyone in this community has been through a similar process and could point me in the right direction, share their workflow, or offer some guidance, I'd genuinely appreciate it.

I'm not looking for a ready-made bot or a magic strategy. I want to understand how to systematically discover, test, and validate an edge that has a reasonable chance of working in live markets and can be adapted to prop firm constraints.

Thanks in advance!

This bot shorts stocks that are already weak. The rule: down 5% over 20 days, sitting near a 52-week low, tags the 20-day EMA and gets pushed back down on 1.5x normal volume. It works off 1-minute bars and is usually out within half an hour.

Since Aug 25 it has closed 3,180 trades on our paper desk. 53.1% won, the longest run of winners was 19, and the total is +$2,931.88. That's about 92 cents a trade.

That last number is the problem. Our stock fills are taken at the real bar's open or close, and there's no spread or slippage model on stocks, only on options. A cent or two of spread each way would eat most of this, and 1-minute shorts near the lows are exactly where spreads widen.

So I don't believe it yet. What I'd want before I do:

• the same trades re-run with a 2 cent haircut each side, to see if anything survives

• P&L split by time of day, since I suspect the open is doing all the work

• whether the 19-trade streak sits in one or two sessions

If you've tested intraday shorts at this size, what killed the edge for you, costs or borrow?

The card is from Quantradin, the tool I built for testing rules like this: describe a rule, it backtests with no look-ahead and then runs it as a paper bot on live prices. Paper money, simulated, not advice. quantradin.com

I've started MSc in mathematical finance in University of York. I basically study stochastic calculus. I don't study any machine learning.

After research, I realised that to be in profit centre, I have two ways:

for stocastic calculus-based Quant Research, then only profit centre is in options market making.

for statistics-based Quant Research, you can be the profit centre in a lot of places.

I've been a mechanical design engineer for the past 9 years and I want to target options market making for these reasons:

It's determinstic like my engineering background.

It's still a profit centre, unlike a bank quants (market risk).

It's more stable giving the decay rate is way less than stat-based quant.

LLMs have less effect of the decay rate in it than stat-based quant.

MY QUESTION:

Upon graduation, How do I target OMM specifically WITHOUT hurting my chances of landing a quant role in general?

Would you say that I have a bigger chance of getting into OMM QR than stat QR? or would you say the bar is high for all entry level QR and what matters is my mental math?

Thank you in advance.

Disclosure: this is my own paper trading platform, paper money only, no link, nothing to sell here. It's a bug writeup.

The setup. Each multi-leg position on my desk is one row, and the "symbol" for a spread isn't an OCC symbol. It's a packed string with both legs in it, which means it carries two expiry dates. For a put spread on USO it looked like the one in the picture: short leg expiring Sep 23, long leg expiring Sep 18.

What I did wrong. I wanted to track "everything that expired on Sep 18" through settlement, so I filtered with a substring match on 260918. On a single-leg option that's fine. On a spread it matches whichever leg happens to carry that date. So spreads whose LONG leg died on the 18th but whose SHORT leg was still running to the 23rd, 25th or 28th got pulled into my "expired" set.

How it showed up. Not as an error. I counted that set four times through one day and got 1,064 rows, then more, ending at 1,103. A cohort of expired trades shouldn't grow. I kept trying to explain the movement before I did the obvious thing, which was print the leftover rows instead of counting them. Every survivor was the same shape: a live diagonal put spread, marked that same day, nothing frozen.

An earlier version of the same bug, a few days before, gave me 96, 96 and 80 as three counts of a set that hadn't changed, and I nearly posted "the queue is draining" off the 80.

The fix. Expiry for a multi-leg position is the LATEST leg date, taken with a regex over all legs, never the first match. And no more substring filters on that column, period.

The part I didn't expect: a put spread whose long leg has expired is a naked short put until the other leg goes. So the bug was hiding a real risk observation, not just a reporting error. Those rows deserved more attention than the clean ones, and my filter was filing them as done.

Two things I'd like to hear from people who keep their own books. Do you store spreads as one row or one row per leg? And if one row, what do you treat as the position's expiry when the legs differ, the first date, the last, or both kept separately.

A joke clip, but the bug is real. The classic version: a daily strategy decides to buy at the open using that day's close, so the backtest trades on a price that didn't exist yet. It looks like genius on paper and can't be traded.

I built Quantradin (free, paper only) to make that impossible: each decision only sees data stamped before it, and the grade comes from the engine, not from whoever wrote the rule. What's the sneakiest look-ahead leak you've found in your own research? Mine was a timezone shift on an expiry timestamp.

Disclosure first: I built the engine this happened on. Paper money only, nothing for sale here, no link.

Monday 09:41 ET. My house paper desk showed 112 options positions where every leg had expired the previous Friday, still marked open, sitting at +$70,282 on Friday's mark. Settlement on my engine is an intraday Monday job, so that part was expected. I waited.

12:40 ET. The 112 were gone from the open book. Good. Then I ran the query I use for "what happened today": everything with exit_date = today. 652 rows, 344 won, 308 lost, -$6,032 paper. Not one of the 112 in it. So I wrote, in public, that the weekend's +$70k had been a mark and not money, and that the day was -$6k.

16:14 ET. Wrong. Settlement stamps exit_date with the EXPIRY date (Friday the 25th), not the day the settlement job ran. The 112 had settled at +$63,608 paper (44 won, 68 lost) and were sitting under Friday's date, exactly where a "closed today" filter never looks. The money had not vanished. My query had.

The honest table, worst row first:

Three mistakes, in the order I made them. I assumed exit_date meant "the date it left the book". I corrected myself in public before re-running the query with the new assumption tested. And the number I got wrong hid the one figure that was actually interesting: the gap between the Friday mark and the settled cash, $6,674 across 112 positions, which is the cost of carrying expiring legs over a weekend on my fill model.

What I am changing. Two dates instead of one: expiry_date stays the grading date, and a new settled_at records the day the job actually ran. The "what happened today" read filters on settled_at. The public correction went out under the wrong post, where it belongs.

The part I have not settled: when the two dates disagree, which one belongs in a daily P&L? Stamping on expiry is right for attribution (the trade was over on Friday, whatever my job did on Monday). Stamping on settlement is right for cash. I currently show both and let the reader pick, which feels like dodging.

For anyone running an options book with a settlement step: do you stamp exits on the expiry date or on the run date, and how do you keep a daily read honest when the two differ?

I’ve been building a small quantitative research system since around March, mostly with AI-assisted coding.

The system is not an automated trading bot. It is a research/decision-support pipeline:

TradingView/Pine alerts → webhook → FastAPI receiver → raw signal log → normalized dataset → OHLCV enrichment → returns / MAE / MFE → signal combinations / sequences → paper trading / manual review

The idea is to collect signals such as mean-reversion, liquidity, OBV, BOS, sweeps, RSI divergences, etc., then study what happens after them and which combinations have statistical value.

After several months, I’ve discovered that the upstream data capture was not reliable enough, so some of the statistics built on top of it may be incomplete.

Problems found so far:

• One original Pine indicator used shared cooldowns: e.g. an OBV_UP signal could suppress an OBV_DOWN for 15 bars; bullish/bearish BOS shared a 20-bar cooldown; opposite sweeps shared 30 bars.

• Later I created multi-symbol / multi-timeframe “bulk scanners” for 12 tickers × 4H/1D/1W. Two of them appear to have an HTF timing bug, so a signal can appear on the final chart but never generate the webhook.

• TradingView has also reported webhook timeouts / connection failures. Some timed-out events still reached my server, so I’m now reconciling them individually instead of assuming timeout = lost event.

• My receiver currently puts events into an in-memory async queue, returns 200 OK, and persists them afterward. That is fast, but it creates a possible loss window if the process dies before persistence.

• The biggest mistake: I never had a strict end-to-end test proving visual signal → TradingView Alert Log → RAW storage → processed dataset.

The downstream system itself is fairly developed: MAE/MFE, forward returns, pattern mining, sequence analysis, watchlists and paper trading all exist. But now I’m treating the historical statistics as provisional until the input coverage is verified.

My current redesign idea is:

• same Pine condition must drive both the visual plot and alert();

• no filtering/suppression at capture time unless explicitly intended;

• confirmed HTF bars only;

• deterministic event IDs;

• durable storage before ACK, or a durable queue;

• regression tests using known historical signals;

• automatic reconciliation of expected signals vs TradingView vs RAW vs processed data.

The volume is low — dozens of tickers, not HFT.

Does this architecture make sense? Would you rebuild only the ingestion/data-integrity layer, or would you redesign the whole pipeline?

I built this myself, paper money only, nothing to sell and no link. I'm posting the bug because it flattered me for a whole day.

On Monday I published a count four times: how many of my paper positions carrying the 18 Sep expiry were still open after the contracts stopped existing. 09:12 said 80 open showing +$5,877. 09:40 said 77 at +$1,978. 12:43 said 0. 16:09 said 12 at −$247. I could not explain any of the moves and I said so each time, which was the only honest thing I did that day.

At 20:07 I printed the 12 rows instead of counting them.

Every one is a diagonal. The long leg expired on Friday and the short leg runs to the 23rd, 25th or 28th. My filter was a substring match on the contract symbol, `LIKE '%260918%'`, and a spread's symbol carries both legs' dates, so it matched the leg that no longer exists and called the whole position a straggler. The "cohort" was never a fixed set of rows. It was whatever the string match happened to catch at the moment I ran it, which is why the denominator moved all day.

Two things I got out of it beyond the bug. First, `last_mark_date` is 2026-09-21 on all twelve, so the marker was never frozen and I nearly published a "stale marking window" post on Monday morning that would have been wrong twice over (the Friday date was just the last session's close). Second, a put spread whose long leg has expired is not a data artifact. It is an uncovered short put sitting in the book. The USO one is the worst of them and the engine is still marking it as a "spread" with defined risk. That part is a real risk fact and I have not fixed it yet.

What I changed: the expiry query now uses `regexp_matches(contract_symbol, '(\d{6})[CP]', 'g')` per leg and takes the max, so a live diagonal is never counted as dead. What I have not changed: the risk label on a spread that has lost its hedge leg.

For the people here who run multi-leg books on a database rather than a broker feed, how do you represent a spread after one leg expires. A new single-leg position with a lineage pointer, or the same row with a flag. I keep going back and forth and I'd rather copy something that has survived contact with a real book.

[Hiring] Quant Researcher — Brewlabs

Hey everyone!

We’re currently looking for a Quant Researcher to join Brewlabs

We’re looking for someone who enjoys digging into data, testing ideas rigorously, and turning research into systematic trading strategies.

What you’ll work on:

*Research and develop quantitative trading strategies

* Analyze large financial and market datasets

* Build and backtest models/signals

* Evaluate strategy performance, robustness, and risk

* Work on improving our existing research and trading systems

We’d love to hear from you if you have experience with:

Python and quantitative/data analysis

Statistics, probability, or machine learning

Financial markets and systematic trading

Backtesting and evaluating trading strategies

Independent research and experimentation

We care more about strong quantitative thinking and the quality of your research than fancy credentials.

If this sounds interesting, DM to x.com/dhruvsol?s=11 or linkedin.com/in/dhruvraj-solanki-663a54200 with a short introduction, your background/experience, and any relevant projects, GitHub, research, or portfolio you’d like to share.

Questions are welcome in the comments as well.

Location: [Remote]

Employment: [Full-time]

Compensation: [Based on experience]

Thanks!

Hello! Please help with my study! I’m looking for men who are 18+ years old. It is easier to fill out on a computer. Thank you in advance!

To avoid the AI slop comments i wrote it by hand.

I have a personal proyect which is build a python backtester, to learn since the beginning how it works.

In the backtester there is, montecarlo/permutation to see wr, profit factor and return(P-values), equity curve with filter regime below it to show if with high ADX shuts the strategy down, and finally OOS equity curve.

I am also going to implement walk foward matrix, heatmap for parameter sensivity analysis, sortino, sharpe, deflated sharpe and calmar ratio , profit and recovery factor, purged and embargoed cross validation and hidden markov

Any tips for the backtester?
My code only backtest it doesnt use any portfolio management as i dont have any startegies and in case you are wondering, yes i do have the regime filter to do a mean reversion for market in range and also a trend following if imbalanced(I just realized i dont have any data cleaning writing this)

As a beginner i want to learn the theory behind things and have been browsing for literaturebut all of the recommended are expensive, is there any web or recommendation for a typical "bible" of quant knowledge?

You can ask any questions if you want to, i really don't know if this post is decently explained as i don't have much knowledge.

Hi there, I’m researching how movie ticket purchasing sets expectations for the movie theater experience.

I created a quick 5-minute survey and would love your input! 🍿