u/SpinachRegular3907

Are quants right to dismiss retail trading concepts?

Are quants right to dismiss retail trading concepts?

TL;DR: Quants are right about intraday: it's a brutal competitive game, you won't win by drawing resistance lines or using ICT concepts. But at low frequency, you can't statistically prove an edge for years, returns mostly come from factor exposure, and the real risk is quitting during a drawdown. That's where "retail" stuff like having a plan and position sizing actually matters and you can even find good strategies.

1. Why quants are right about intraday

First question: where does intraday profit come from? My answer: statistical arbitrage. If you make money intraday, it's because your trades make the market a bit more efficient, and you get paid for that.

Which means retail intraday traders compete directly with quant firms that have better data, better infrastructure and lower costs. Nice chart drawings don't win that fight. Yes, some retail intraday traders make money, and people call it survivorship bias.

A lot of retail content is about "perfect execution" and "the mindset to follow your plan". My question for them: why don't you automate your plan? You'd get perfect execution, and you could run it on multiple assets. But if your plan is bad, you'll have to face it.

Intraday trading is really hard, for retail and pro firms alike. You get paid for the value your trades bring to the market, and the competition is huge.

2. At low frequency, it's less clear

A) You can't prove an edge in a reasonable time

Simple t-test on your annual returns: the t-stat is just your Sharpe times the square root of the number of years. To be significant at 5%, you need T > (1.96 / Sharpe)² years of data.

https://preview.redd.it/e8gcnwkamnuh1.png?width=2400&format=png&auto=webp&s=adb058e724b6a0e30501e3d1e9747aa8ac1a2dc7

So with a low-frequency strategy, you'll basically never know statistically whether you have an edge.

B) So where does the money come from, and why does psychology matter?

At low frequency, most returns come from factor exposure (beta, momentum, etc.), not from a statistical edge. Example: my Ichimoku strategy on BTC (classic 9/26/52 settings, long or cash, 0.1% fees) vs buy and hold. I've been running it live since May 2023.

https://preview.redd.it/wibeg2vuhnuh1.png?width=2600&format=png&auto=webp&s=577166fa55bb258c355f42cb5d6c1d3c44bba848

Metric Ichimoku Buy & Hold BTC
CAGR (2015 → 2026) 69% 60%
Max drawdown -47% -84%
Longest drawdown 785 days 1,079 days
Time in market 47% 100%
Sharpe backtest (2015 → Apr 2023) 1.52 (t = 4.4) 1.10 (t = 3.2)
Sharpe live (May 2023 → Oct 2026) 1.05 (t = 1.94) 0.89 (t = 1.64)

Funny thing: the live Sharpe is 1.05 over 3.45 years, so t = 1.94. Just below 1.96. That's exactly what the chart in part A says: with a Sharpe of 1, you need ~4 years.

And even a significant Sharpe doesn't mean you have an edge: buy and hold is significant too and looks great on a chart.

But would you have kept holding at -84%, and stayed underwater for almost 3 years? Easy to say yes looking back. Much harder when you're living it. Ichimoku's worst drawdown was -47%, and it sat in cash more than half the time.

Do I have an edge with Ichimoku on BTC? I don't fucking know. But I can explain the bet I'm making. Ichimoku is a trend-following tool, so it's basically exposure to time-series momentum, a well-documented factor (Moskowitz, Ooi & Pedersen, 2012). Crypto is a FOMO-driven market that trends hard, and that's where Ichimoku shines. It fails when the market goes nowhere, or on pump and dumps.

So my bet is simple: "Bitcoin will keep trending."

Conclusion

Here's the difference. In intraday, the psychological risk is execution, and automation fixes it. At low frequency, the risk is giving up on the strategy during a year-long drawdown, and even an automated system gets switched off by a human who panics.

That's why retail concepts like having a plan, money management and position sizing can actually save people who aren't full quants. A properly systematic strategy is still better. But at low frequency, the money comes from factor exposure, and what makes the difference is choosing the right one at the right time. I'm not sure the classical quant approach is the only way to do that well.

Momentum reference: Moskowitz, Ooi & Pedersen (2012), Time Series Momentum: https://papers.ssrn.com/abstract=2089463

Data: angolin.com, a crypto data provider I'm building. The daily BTC history used here is available there if you want to rerun the backtest yourself.

reddit.com
u/SpinachRegular3907 — 5 days ago

Built a crypto OHLCV API for backtesting (one exchange live, multi-exchange coming) — looking for feedback

Hi,

I'm building an API for crypto OHLCV, aimed at backtesting. Multi-exchange aggregation is the actual goal. Starting narrow with a single exchange to get the core right first.

I'm trying to document the sourcing and aggregation methodology as thoroughly as I can: handling survivorship bias properly, being transparent about where the data actually comes from. The goal is a data provider that's fully transparent on data provenance, easy to integrate, built with algo traders and for algo traders.

What's live right now:
- OHLCV from one major exchange, hourly and daily granularity
- Two endpoints: raw per-exchange, and an aggregation endpoint (single-source for now, the aggregation logic is built, just needs more exchanges wired in)
- Plain REST API — no data dashboard, no builder, just JSON in, JSON out (there's a basic usage dashboard to track your API quota, that's it)

Not there yet (being upfront, since half of this sub will ask):
- Multi-exchange — that's the actual differentiator, coming next
- No delisted-pair historical universe yet
- No minute granularity yet
- No websocket / real-time

There isn't much yet, on purpose. I'd rather ship the boring plumbing first and grow it from real feedback than launch with everything half-baked.

Opening 25 free spots for interested devs, every feature it gets, free for as long as the account's active.

What would move the needle most for you?
- More exchanges (tell me which ones you need)
- Minute-level data
- CSV/Parquet export via a dashboard, instead of hitting the API
- A Python SDK (client library) instead of raw requests
- Something else? Tell me!

If you want to help build a fully transparent crypto data provider, DM me.

reddit.com
u/SpinachRegular3907 — 19 days ago

How do you validate an OHLCV series for a crypto database?

I'm trying to centralize data from multiple exchanges to build a clean, aggregated, representative historical dataset with good granularity, without going through the usual data providers that are basically black boxes where you never really know what's inside.

Now that my database is up and running, I'm hitting my first real quant/stats problem: how do I know my OHLCV prices are actually correct? The exchange hands me data, but nothing tells me it isn't corrupted, or that two different histories haven't been silently stitched together under the same ticker (classic issue on equities markets, I'd assume it happens on crypto too).

Checks I currently have in place:

- Timestep consistency : Less trivial than it sounds — on Binance alone I've already found dozens of candles with a shift.

- Outliers : This is where I'm least confident. A crypto doing +50%/-50% in a day genuinely happens. I've been considering a 3-4x recent standard deviation threshold, but I'm not fully convinced it's the right approach.

- Gaps : There are often holes in the data. Should they be filled? If I'm aggregating across exchanges it evens out, but if I want to keep a single exchange's history for pure backtesting, missing data becomes a real problem.

And then there's a case that's more of a genuine methodological dilemma than a bug to fix: illiquid pairs. Someone dumping a large order on a thin pair can produce a High or Low that's completely unhinged and doesn't even show up on other exchanges. Concrete example: CRV/EUR on OKX, May 22 2024.

The dilemma: for backtesting on that specific exchange, this data point is almost useful : it shows a real risk of getting stopped out due to illiquidity in live conditions. But it also biases the backtest : I can't just model it as a normal price move, I need to know that pair was illiquid at that point and probably treat it separately (maybe as a stress test) rather than feeding it straight into the normal backtest.

Anyway, I get the feeling my validation process still has gaps. What am I missing?

reddit.com
u/SpinachRegular3907 — 1 month ago

How do you deal with survivorship bias in your backtests?

Trying to build a proper backtesting universe and running into survivorship bias everywhere.

If I just take today's top 100 crypto by market cap/volume as my universe, that's a massive survivorship bias, obviously. I've been trying to reconstruct what the top 100 actually looked like at each point in the past, but I can't do it from volume data alone. I'd need historical prices for basically every coin that ever existed, including the ones that crashed or got delisted, which is exactly the data that's hardest to get.

Even at the single-exchange level it's just as bad: the moment a pair gets delisted, ccxt (and the exchange APIs directly) just stop returning any history for it... so even reconstructing "what was actually tradable on Binance at time T" is broken by default.

Anyone found a decent way around either of these? Data source, methodology, anything. Trying to avoid fooling myself with backtest results that only look good because they're built on survivors.

reddit.com
u/SpinachRegular3907 — 1 month ago