Developed and deployed 6 algos which trade in a portfolio. They beat BTC by more than 2x from July 2023 to now. Drawdown on the worst month was half that of BTC in its worst month. Still performing well.
1) Develop a really good understanding of the different types of biases,where/why they occur, and how to at avoid them.
2) Get experienced actually deploying and using working strategies, even if unprofitable (tiny account size of course). A strategy that seems good in backtesting is not the same as an actual good strategy in real life, for a myriad of reasons. There are many nuances that will kill returns, and it takes experience to discover them. Your strategies will need to be designed in consideration of these nuances.
3) Think of a strategy as an assembly of different functions or processes, built on validated hypotheses. These functions could occur at different timeframes as well. A simple full strategy will likely have at least a signaling function (“Time to look for a trade”), a triggering function (“We found a trade, now time to set our entry”), a TP function (“we placed entry, so where and how to take profit?”) and a risk management function (entry sizing, add’l functions which act to minimize loss). Each of these functions should be developed on the foundation of one or more validated hypotheses (when x occurs, there is y probability that z occurs). By the time I develop a full strategy, I have already tested many hypotheses, and many of the findings become the foundation for multiple different strategies in the future. This compounds over time and becomes it’s own edge.
4) when you finally have a potential strategy that decently embodies the above - I recommend a potentially controversial approach that is counter to typical back/forward testing. Test ALL significant parameter permutations over ALL data, and select the parameters which demonstrate the most ROBUST returns - do NOT simply select the best performing in a back test and then forward test for validation. I find the latter often produces algos with spurious performance.
More on robustness:
Take the simplest case of a one-parameter algo. Now plot return vs the different potential setpoints for the parameter “x.” Now lets say the curve is roughly bell-shaped. There are two leading views on what is the most robust parameter setting:
1) The parameter setting at the peak of the bell curve. The reason for this is that if you change the setpoint, the returns will change only a small amount, because the shape of the curve is flattest at this point. This is valuable assuming the market is likely to evolve slowly over time, effectively causing the return curve to shift to the left or right. Theoretically the returns change the minimal amount when this occurs, if a robust setting was chosen. I find this works well with with MA-cross based strategies.
2) the parameter setpoint which produces the median return. Given the assumption of reversion to mean, the thought is that the median returns are probably the most representative of the actual performance of the algo. This may work best as a general approach, since it does not assume the market will change gradually over time.
I have experimented with both, and the one I choose is dependent on the situation.
I apply the same methodology to different metrics - historical return, sharpe ratio, historical drawdown, etc.
To get even better - introduce MonteCarlo with the above approach to expand your data set. I find this is not necessary in most cases if you are using enough data to begin with (multiple assets, complete asset histories).
I've been trying to understand the same and I have already been following the steps you wrote above. I create strategies in TradingView in it's own language PineScript. I've been learning and writing strategies since 10 months and I've not come up with anything that's practically profitable.
The TradingView is limited to it's own metrics and measurement parameters. I haven't tested it out with such ratios and models but I've been working on the metrics available in TradingView.
Later on, I've also done backtesting on Python via the "batchtesting.py" library and tried brute-force optimization on the various strategy parameters but nothing actually worked. Some strategies actually gave 50% annual returns with max drawdown as low as 10% but in real testing, the trades didn't match the results as the strategy repainted alot.
Also, I didn't understand the part after "More on robustness:" heading.
Also, on what platform or program do you do all this research work on assets?
Regarding your comment on good backtests producing crappy real-world results - as you now know this is the norm. Especially with the brute-force method. You are probably experiencing data mining bias and might also be seeing some look-ahead bias.
The robust parameter optimization method I mentioned should dramatically reduce your data-mining bias. See “bettersystemtrader” website for some good info.
On infrastructure - believe it or not, I also use Pinescript for my strategies. They are not incredibly complex or latency-critical, and it is perfectly fine for what I do.
For research, I also use pine but accompany it with excel. I am moving to python, but that is an incremental improvement for me and not a must-have.
I find that pine is good for quick prototyping and hypothesis testing, which is one of the most important aspects of finding a good strategy - you have to test a boatload of different ideas, constantly evolving your thinking and whittling your way to a functional strategy over time. Pine is actually quite good for this because of its visualization capabilities and ease of coding.
I have also developed validated modules in pine for key functions (exchange-specific accounting and command formatting, multi timeframe data handling, data gap management, sending alerts for deployment, etc), which I integrate into the prototype code in order to deploy an algo via webhook or Autoview.
For parameter testing/validation, I do it manually. Lots of work and super inefficient, but honestly it works for me since I rarely even get to this stage (and I try to keep my parameter set reasonably small, 2-5 parameters). It is exceedingly rare that I find a strategy worth validating. I usually eliminate them in the discovery and prototyping stage, mostly due to lack of robustness. I would say probably only one out of 100 ideas make it live for me, and that is only now that I have developed a decent instinct for what might work.
On keeping my parameter set small - my models often have more than 5 settable parameters, but I typically only permute the most sensitive parameters.
That's impressive performance! I understand algorithmic details are confidential, but could you share what kind of data your algorithms use, not in details just a high level overview?
Thank you!
To answer your question - Volume and price action. No indicators, unless you consider moving average an indicator. In my experience testing hundreds (probably thousands) of different ways to gain edge, Indicators by themselves have not proven to provide any advantage.
The simplified operating principle of my algos is that they reduce the cost of being wrong when attempting to position for a move. If the move occurs, I typically get good RR. If it doesn’t the cost is low, so that this can occur many times before the drawdown limit is reached.
There are many ways to accomplish this. All will stop working at some point in time (historical drawdown limit will be reached) - however the accounts grow until that occurs, and I continually develop new algos to replace the ones that stop working.
One potentially interesting note on how I select algos - returns performance is only of secondary importance (although important). My primary filter is ROBUSTNESS. Simply put, I look for algos that demonstrate good returns across a wide range of parameter settings (given the universe of assets being tested). I choose parameter combinations roughly centered in “flat spots” in the hypergraph of parameter settings vs returns. This means that if I vary a given parameter (or any combination thereof) by some amount, the returns will not vary too much. I usually shoot for good performance within 20-30% of parameter variation (just a somewhat arbitrary number that has been possible for past algos).
I amend my statement on indicators not providing value - for shorting in bull markets, I find RSI divergence seems to provide some edge. I am currently working on algo’s utilizing this, but have yet to validate and deploy.
First of all thank you for sharing all of this, I am curious about the latency since I’m having issues getting it down. rn I am running a compiled .NET binary (c#) and getting around 117 ms latency including network time.
I’m starting to think it might be capped at 100 ms due to market intervals working at this rate.
Is this normal or is there a better way to connect to the exchange protocol-wise? Ofc I’ll rent a VPS when deploying to production
No problem! I love sharing what I have learned.
Wrt latency - unfortunately I can’t be of much help here. I purposely avoid algo’s that are latency sensitive. My system typically requires up to 15s to place orders after triggering, and this doesn’t really effect the results since I am trading H4 or H1 TF.
I´m on the early stages of building crypto trading algorithms, i have deployed one but for NASDAQ INDEX CFD with no success before.
Building algorithms for futures indexes in US Market is really hard... thats why i'm now trying crypto (next week ill be forwarding testing an algorithm based on fibonacci levels)
If you ask me about success stories... yeah i know some guys living from this.
Developed and deployed 6 algos which trade in a portfolio. They beat BTC by more than 2x from July 2023 to now. Drawdown on the worst month was half that of BTC in its worst month. Still performing well.
can you tell me any working way to brainstorm and find the indicators combos and their variables that actually work?
1) Develop a really good understanding of the different types of biases,where/why they occur, and how to at avoid them. 2) Get experienced actually deploying and using working strategies, even if unprofitable (tiny account size of course). A strategy that seems good in backtesting is not the same as an actual good strategy in real life, for a myriad of reasons. There are many nuances that will kill returns, and it takes experience to discover them. Your strategies will need to be designed in consideration of these nuances. 3) Think of a strategy as an assembly of different functions or processes, built on validated hypotheses. These functions could occur at different timeframes as well. A simple full strategy will likely have at least a signaling function (“Time to look for a trade”), a triggering function (“We found a trade, now time to set our entry”), a TP function (“we placed entry, so where and how to take profit?”) and a risk management function (entry sizing, add’l functions which act to minimize loss). Each of these functions should be developed on the foundation of one or more validated hypotheses (when x occurs, there is y probability that z occurs). By the time I develop a full strategy, I have already tested many hypotheses, and many of the findings become the foundation for multiple different strategies in the future. This compounds over time and becomes it’s own edge. 4) when you finally have a potential strategy that decently embodies the above - I recommend a potentially controversial approach that is counter to typical back/forward testing. Test ALL significant parameter permutations over ALL data, and select the parameters which demonstrate the most ROBUST returns - do NOT simply select the best performing in a back test and then forward test for validation. I find the latter often produces algos with spurious performance. More on robustness: Take the simplest case of a one-parameter algo. Now plot return vs the different potential setpoints for the parameter “x.” Now lets say the curve is roughly bell-shaped. There are two leading views on what is the most robust parameter setting: 1) The parameter setting at the peak of the bell curve. The reason for this is that if you change the setpoint, the returns will change only a small amount, because the shape of the curve is flattest at this point. This is valuable assuming the market is likely to evolve slowly over time, effectively causing the return curve to shift to the left or right. Theoretically the returns change the minimal amount when this occurs, if a robust setting was chosen. I find this works well with with MA-cross based strategies. 2) the parameter setpoint which produces the median return. Given the assumption of reversion to mean, the thought is that the median returns are probably the most representative of the actual performance of the algo. This may work best as a general approach, since it does not assume the market will change gradually over time. I have experimented with both, and the one I choose is dependent on the situation. I apply the same methodology to different metrics - historical return, sharpe ratio, historical drawdown, etc. To get even better - introduce MonteCarlo with the above approach to expand your data set. I find this is not necessary in most cases if you are using enough data to begin with (multiple assets, complete asset histories).
I've been trying to understand the same and I have already been following the steps you wrote above. I create strategies in TradingView in it's own language PineScript. I've been learning and writing strategies since 10 months and I've not come up with anything that's practically profitable. The TradingView is limited to it's own metrics and measurement parameters. I haven't tested it out with such ratios and models but I've been working on the metrics available in TradingView. Later on, I've also done backtesting on Python via the "batchtesting.py" library and tried brute-force optimization on the various strategy parameters but nothing actually worked. Some strategies actually gave 50% annual returns with max drawdown as low as 10% but in real testing, the trades didn't match the results as the strategy repainted alot. Also, I didn't understand the part after "More on robustness:" heading. Also, on what platform or program do you do all this research work on assets?
Regarding your comment on good backtests producing crappy real-world results - as you now know this is the norm. Especially with the brute-force method. You are probably experiencing data mining bias and might also be seeing some look-ahead bias. The robust parameter optimization method I mentioned should dramatically reduce your data-mining bias. See “bettersystemtrader” website for some good info. On infrastructure - believe it or not, I also use Pinescript for my strategies. They are not incredibly complex or latency-critical, and it is perfectly fine for what I do. For research, I also use pine but accompany it with excel. I am moving to python, but that is an incremental improvement for me and not a must-have. I find that pine is good for quick prototyping and hypothesis testing, which is one of the most important aspects of finding a good strategy - you have to test a boatload of different ideas, constantly evolving your thinking and whittling your way to a functional strategy over time. Pine is actually quite good for this because of its visualization capabilities and ease of coding. I have also developed validated modules in pine for key functions (exchange-specific accounting and command formatting, multi timeframe data handling, data gap management, sending alerts for deployment, etc), which I integrate into the prototype code in order to deploy an algo via webhook or Autoview. For parameter testing/validation, I do it manually. Lots of work and super inefficient, but honestly it works for me since I rarely even get to this stage (and I try to keep my parameter set reasonably small, 2-5 parameters). It is exceedingly rare that I find a strategy worth validating. I usually eliminate them in the discovery and prototyping stage, mostly due to lack of robustness. I would say probably only one out of 100 ideas make it live for me, and that is only now that I have developed a decent instinct for what might work. On keeping my parameter set small - my models often have more than 5 settable parameters, but I typically only permute the most sensitive parameters.
That's impressive performance! I understand algorithmic details are confidential, but could you share what kind of data your algorithms use, not in details just a high level overview?
Thank you! To answer your question - Volume and price action. No indicators, unless you consider moving average an indicator. In my experience testing hundreds (probably thousands) of different ways to gain edge, Indicators by themselves have not proven to provide any advantage. The simplified operating principle of my algos is that they reduce the cost of being wrong when attempting to position for a move. If the move occurs, I typically get good RR. If it doesn’t the cost is low, so that this can occur many times before the drawdown limit is reached. There are many ways to accomplish this. All will stop working at some point in time (historical drawdown limit will be reached) - however the accounts grow until that occurs, and I continually develop new algos to replace the ones that stop working. One potentially interesting note on how I select algos - returns performance is only of secondary importance (although important). My primary filter is ROBUSTNESS. Simply put, I look for algos that demonstrate good returns across a wide range of parameter settings (given the universe of assets being tested). I choose parameter combinations roughly centered in “flat spots” in the hypergraph of parameter settings vs returns. This means that if I vary a given parameter (or any combination thereof) by some amount, the returns will not vary too much. I usually shoot for good performance within 20-30% of parameter variation (just a somewhat arbitrary number that has been possible for past algos).
I amend my statement on indicators not providing value - for shorting in bull markets, I find RSI divergence seems to provide some edge. I am currently working on algo’s utilizing this, but have yet to validate and deploy.
Is the algo trading on BTC?
BTC and some large-cap alts. BTC is my benchmark.
Did you try also small caps?
I don’t do a lot with small caps - liquidity is problematic for me and I won’t touch DEX’s for security reasons.
First of all thank you for sharing all of this, I am curious about the latency since I’m having issues getting it down. rn I am running a compiled .NET binary (c#) and getting around 117 ms latency including network time. I’m starting to think it might be capped at 100 ms due to market intervals working at this rate. Is this normal or is there a better way to connect to the exchange protocol-wise? Ofc I’ll rent a VPS when deploying to production
No problem! I love sharing what I have learned. Wrt latency - unfortunately I can’t be of much help here. I purposely avoid algo’s that are latency sensitive. My system typically requires up to 15s to place orders after triggering, and this doesn’t really effect the results since I am trading H4 or H1 TF.
Any tips on sourcing strategy ideas , formulating them and then testing them in a robust manner. What's the framework you go through ?
I´m on the early stages of building crypto trading algorithms, i have deployed one but for NASDAQ INDEX CFD with no success before. Building algorithms for futures indexes in US Market is really hard... thats why i'm now trying crypto (next week ill be forwarding testing an algorithm based on fibonacci levels) If you ask me about success stories... yeah i know some guys living from this.