Numerai is a crowd-sourced AI hedge fund.
They paid $72,002,141 to data scientists to beat the market.
Despite these efforts, since 2019, it has underperformed the S&P500.
Why is trading the hardest problem in the world?
Feeling super generous so, somewhat reluctantly, here are 5 industry secret holy grail books that have immensely assisted me in my quantitative trading endeavours (as an ex manual HFT mm) that I highly recommend new and experienced traders pick up if they can. No specific order.
gm
Really didnt expect to run this account up to 10m+ within a month after getting rekt in January and starting over in futures with 300k
time to set some new yearly goals
Going from only knowing python / r to learning a low level language
(c/c++/rust) has made me realize so many important nuances in building production infra that I normally wouldn’t have even thought about
Noticed spikes in latency at exactly 10ms every time in a very important single threaded process on the hot path, pinned to a core. Turns out isolcpus was not set to isolate the core on this instance, so this was all due to kernel interference!
One big project > a bunch of trivial small projects imo. Market making is a good thing to focus on, it forces you to have to solve problems in systems design, math / stats, game theory etc. Build a simple system and iterate one step at a time
Making a streamlit dashboard + using flat files in aws S3 (or similar) as your db is actually pretty nice and is a fraction of the cost of a traditional cloud db / grafana
If anyone is interested in some orderbook / trade / other market data for any cex let me know.
I’ve built a scraper (works for binance, bybit, bitget, okx so far).
As long as I can keep the aws bill under a certain number I’ll make sure it’s free for now!
Feel free to dm
New infra features done:
1. WsPool:
Create N ws connections, measure latency, keep the ones w lowest latency
2. Redundant streams:
Multiple ws for a given stream (book/trade etc), first recipient processes a given message (indexed by some id field)
results to come!
@BlackSwan_ptf
Distance based metrics aren’t very robust. With pairs in general, you’ll always have some out of sample decay, try to optimize for maximal reversion and volatility, penalize for structural breaks, measure performance after in sample, then trade pairs that remain stable
Doing a rework of the infra, before I would handle ob updates on one thread, then send the entire ob to the strategy thread via a channel. Now sending the processed deltas to the strategy thread w a ring buffer, busy spinning on the recv end and applying updates there
There are definitely many ways to apply this to trading, but I’ll leave that as an exercise for the reader ;)
This article is also a great resource if you’re interested in a deeper look
(9/N)
A method for detecting breaks is the recursive CUSUM method, which defines break points recursively based on cumulative forecasting error. CUSUM is robust to heteroskedasticity and can detect multiple breakpoints.
(6/N)
I’ve been getting into poker lately, it’s so satisfying in that it feels like running a trading system, except I get to look my counterparty in the eyes when I take his money
Aligning trade and ob data for research is a bit tricky, make sure your timestamps correspond to matching engine time, not send time. The state of the book at trade time is what matters, though you can’t trade on this info until it reaches your system some time later
Data -> Hypothesis:
Starting with data and a broad research question, then developing informative features to model.
- Alpha comes from features more than models
- Overly complex models / poor features -> overfitting
- Many approaches to the problem -> more orthogonal
(4/N)
Both approaches have their pros and cons, and neither will work if data is poorly used.
Lookahead bias, survivorship bias, low degrees of freedom, over/underfitting, incorrectly modeling costs and other backtesting errors are all common mistakes that can ruin alphas.
(9/9)
Crypto exchange idea: make all takers take an iq test, left tail and right tail iq takers get their trades matched to separate degen / toxic orderbooks
Hypothesis -> Data:
Starting with a hypothesis about how markets function based on prior research, translating it into code and testing it with historical or live data.
- Fewer ideas tested -> Lower chance of spurious conclusions (multiple testing bias)
(2/N)
Rather, you need a method which can be used to detect breaks in real time with minimal delay and does not cause lookahead bias.
More on this in part 2!
(9/N)
@gumby_arc
it’ll take longer initially, but I highly recommend abstracting all the exchange logic you can so all you have to do to connect an exchange is pass args for the exchange’s unique traits like message formatting, signing requests etc
- If prior research had alpha once, some extension of it likely has alpha
- Minimally orthogonal to other researchers' work -> more competition / alpha decay
- Analytical methods often make unrealistic modeling assumptions -> needs addressing
(3/N)
In the case of a mean reverting portfolio, sudden and prolonged divergences from the local mean are often a result of structural breaks, which are a major form of tail risk in stat arb.
(2/N)
This concept is very useful in modeling lead-lag relationships between variables. An example of this is applying granger causality to test whether some time series Y can be predicted with a lagged version of another time series X.
(5/N)
This wasn’t exactly a catastrophic issue, but hopefully provides some insight into how you can run into unintended behavior with async if you’re not careful.
(here’s a cookie for reading this far 🍪)
The theory first approach might look like taking a well-established idea, such as cointegration based pairs trading, and extending it to more advanced applications.
(5/N)
@dom67191
Of course, not every hypothesis you have will be right. It’s kinda a cost / benefit analysis, where your cost is often code complexity. Things like reliability, tail latency, throughput etc. all contribute to long run pnl, even if you don’t see an impact immediately
More formally, if the variance of your prediction of Y given all information in the universe is lower than the variance of the same prediction without X, then X granger causes Y.
(4/N)
One common approach to causal inference is called Granger Causality. The core idea of granger causality is based on the ability to predict a variable, given information from other variables.
(2/N)
First start with an idea;
“Can I extend to find multivariate cointegration? Why would there be an edge in doing so?”
See if any research on the idea already exists, then implement, test and improve upon.
(6/N)
For the bivariate case, even if your pair is mean reverting, trading both assets when only one is likely to drive most of the portfolio’s reversion will be inefficient and will likely be -EV after fees.
(7/N)
Look at the data. Is there an effect?
Create features that capture this effect, i.e difference in rolling % change in some sentiment score between the pair’s assets, then model and test.
(8/N)
If the inclusion of a variable X helps predict a variable Y better than the same prediction without X, then it is said X contains some unique information regarding Y, and therefore X granger causes Y.
(3/N)
The data first approach can look like starting with price/volume, fundamentals, alt data, and looking to answer a broader research question such as “How do changes in relative news/sentiment with cointegrated assets affect pair tradability?”
(7/N)
In testing for stationarity when forming mean reverting portfolios, with an ADF test for example, structural breaks inflate the p value of the test and cause a non rejection of the NH, implying non stationarity.
(3/N)
Determining which asset is a granger leader and which is a granger follower can help determine which is likely to drive an expected mean reversion. I.e: if X lags Y by 1 minute, then X only trade X since it is likely the one driving most mean reversion.
(8/N)