discretionary has lots of dangers, main missing a trade. Algo never misses a trade, no emotions. We are 100 automated.
Advice for aspiring algo-traders
- Thread starter ValeryN
- Start date
discretionary has lots of dangers, main missing a trade. Algo never misses a trade, no emotions. We are 100 automated.
what happens when tech issue takes place and you rock climbing? Example, you place a trade and stop does not get submitted. My motto is fully automated does not mean unattended.
That depends a bit on where you place the boundary between attended and unattended. In my case the software handles all trading by itself (thus is unattended), but I do receive overviews of the trades done and whether those filled or not. Of course do I read those overviews. Does that mean that my system is attended? I don't think so, as reading this doesn't even take one minute.
unattended means you set and forget. What happens when you loose market data, stop loss does not get set, stop loss gets set in incorrect spot, you get overfilled on exit, cable to data center gets cut (my favourite one) and etc???? This is what I mean. I coded for all of the above, it did take some time
My background was in real-time distributed systems, so I applied the same general ideas to trading systems. You always code pessimistically (assume any external resource is potentially not available or has the potential to become a random number generator), you orthogonalize all your state and if anything unexpected happens you fail as fast as possible. Even after running these systems for years, new stuff pops up.
You can do a lot of valuable debugging by having the ability to 'replay' a days data though your system, which is why I mentioned the importance of transparency between live & back-testing. All this stuff does take time, and some amount of programming talent.
I'm asleep when the market opens, so I don't have much choice but to be 'unattended' in that period. I wake up about midday EST. If anything fails I get an alarm on my phone. Which is always a joy as I know I'll be hand closing 10s of positions which are probably in the red.
You can do a lot of valuable debugging by having the ability to 'replay' a days data though your system, which is why I mentioned the importance of transparency between live & back-testing. All this stuff does take time, and some amount of programming talent.
I'm asleep when the market opens, so I don't have much choice but to be 'unattended' in that period. I wake up about midday EST. If anything fails I get an alarm on my phone. Which is always a joy as I know I'll be hand closing 10s of positions which are probably in the red.
So did I: made an overview of all possible things that (likely) could go wrong. Corrective measures are taken and/or I receive a warning message by email. Over the years some events popped up which I had not considered in advance. Those were taken care of after the fact. By now I hardly ever have to touch the software code.
Same here.
Email might be too late. I coded sms. Same here we rarely get involved.
Just debating. If you never miss a trade and win rate is not sooper dooper, then you have higher transaction fees also.
This has been an interesting thread, albeit it seems to have got a bit sidetracked down the alley of robust trading system design (still interesting!).
Your list is excellent, although personally I'd include more of an emphasis on avoiding too much leverage and too much fitting.
Let me deal with #7 first. I think the easiest win in systematic trading is basically capturing risk premia that a discretionary trader is uncomfortable with. And although it's true that there are probably a little more premia in illiquid markets, there's still plenty of juice across liquid markets. In fact it's probably safer, until you are very comfortable with your execution, to stick to highly liquid markets. Indeed in my own system I deliberately avoid markets which are highly illiquid.
It depends on the time of trading you are doing; if you are trying to capture a liquidity premium through some kind of mean reversion or market making strategy, arguably illiquidity is a major source of income as well as giving you plenty of downside risk. If you are trading at the sort of time scale I am trading at, then illiquidity is just a pain as it makes the execution riskier without any clear benefit (the distinction is that the execution for me is a way to get into the trade, but for a shorter term / market maker type it is the trade). That also means I place less emphasis on #23 live executions matching the model: I don't even look at this.
For #2 I think there are a number of issues with the 'off the shelf' systems. The main ones that come to mind are a lack of flexibility (although the scripting languages they provide might be theoretically Turing complete, it is tortorous to do certain things, like for example continous rather than binary trading if the system thinks only in terms of discrete trades; or they lack data to do things like calculate a futures carry signal), and making it far too easy to overfit a model.
I'd say an off the shelf system would be fine for someone who is happy using a fairly simple discrete system that fits into the neat box provided by the scripting language; something like a simple weighted average of momentum rules for example, which hasn't been fitted beyond the bare minimum. Of course such a system could equally be run in Excel, but that wouldn't give you the automated execution.
GAT