If you actively trade, you probably spend your days and nights researching, staring at the past candle charts, and coming up with the strategies to apply in the coming days.
Next day market opens, and now it’s time for mechanical work to monitor the market and react to the best of the human ability in free time during your day-time job.
If the research work can be justified to require human intelligence and creativity, I am fully convinced that at least the mechanical part is not worth putting so much effort into.
So where do we start with automating?
The first implementation can be as simple as a script in your favorite programming language running on your laptop, connected to your broker via API and submitting orders.
In a fortunate case it may pass a smoke test and execute a few orders.
Now it comes to hardening the solution. In this article I will try to focus on something less obvious I have discovered on the algo trading implementation journey.
#1 Data is king
Some brokers provide basic data feed for algo trading, but more often than not the limitations steer you towards specialized data provider(s).
The features you would be looking for:
- Decent amount of historical data of decent quality for backtesting.
- Real time market data. Not the end of the day, and not 15 minutes delayed. As close to real time as possible, with possibility to subscribe for data push notifications.
- Data aggregated from multiple exchanges. If you want to make decisions (you do) based on pre- or after- market hours data, this is a must have.
- No or reasonable limit on the number of tickers you can get data for concurrently.
- Data on market index constituents. And ideally historical data, as constituents change, and you want to backtest our algos without “cheating” (survival bias).
- Corporate and fundamentals data. Historical data is quite useful here as well.
Even to satisfy this short list, you need a specialized data provider or a few. For personal use it comes to a couple of hundred dollars of fees a month. It might be under one hundred if you sacrifice some requirements and data quality.
#2 Orders can be over-executed
Ever encountered a situation when your limit order and stop-loss order were executed simultaneously?
Well, it does happen. It’s much more rare when trading manually, but when a program is able to submit orders so much faster, and generate higher order flow, probability of it naturally increases.
A trading engine must be able to recognize such situations and react accordingly. I.e. calmly close the resulting short position (or long position if you are exiting a short trade).
#3 Not all brokers let you set order validity
Quite typical for brokers is to allow an order validity of 1 day, but not shorter.
A common situation is that you submit a buy limit order, the market goes up, our order remains pending, and never executes expiring at the end of the day. A good trading engine would be able to handle such cases and provide configurable validity.
E.g. submit a limit order and if it does not execute after 5 minutes — cancel the order and try something else, adjust the price or try a different ticker altogether.
#4 Circuit breakers is the new reality
Remember when the SEC halted trading on meme stocks or the stocks would not trade during the covid news? Halts happen for various reasons, so a trading engine needs to react accordingly. I.e. not go frenzy during the pause, and continue trading as soon as trading reopens.
#5 Stock splits, ticker renames, mergers and acquisitions are a lot more challenging for an algo
Apple, Tesla, anyone who decides to do a stock split, you need to handle that properly as well: take it into account when exiting the trade, calculating profits and benchmarks. Same with reverse split, which is quite common for the stock trading under $1. As well as another subtle but similar in nature event of issuing stock dividends by a company.
Facebook renames to Meta and changes the ticker. Hertz files for bankruptcy and emerges back on the market under a new ticker. Cloudera gets acquired and becomes private.
All these and many more need to be smoothly handled by the engine, data needs sourced to be linked back to action.
#6 Penny stocks need a special treatment
Stocks under 1$ are quite special indeed. Besides the risk being delisted if a stock trades for under $1 for a period of time, such stock has also a privilege, it can be traded for sub-penny amounts, i.e. for multiples of $.0001. You should carefully handle that in the trading engine, so you can benefit from more precise order placement and stop losses.
#7 Index constituents are harder than it should be to
Ever found a profitable pattern to use for trading, which indicates a rather rare market even for an individual ticker? For example, trading the double bottom pattern may be profitable, but rarely beats buy-and-hold if applied to a single ticker, as most of the time you are waiting for it to happen, and missing out on opportunities for your money to work.
For a good trading engine you need an ability to continuously screen a set of securities for desired market patterns. Probably you don’t want to manually enter a bunch of tickers, but use well recognized “buckets” such as market indexes, S&P 500, DJIA, and others. And of course you need to monitor how the constituents of these buckets change over time. Get the historical data and index updates in a reliable way is a project on it’s own.
#8 Unattended execution is costly
You don’t want the algo to stop trading when you close a laptop, or don’t have internet connectivity. To achieve unattended execution, you need the right infrastructure, monitoring, backups, disaster recovery and many other fun things. It’s an extra buck but definitely worth the spend.
#9 Speed of execution matters a lot
Working with the arrays of data, monitoring and trading multiple tickers soon starts taking quite a bit of time, minutes or even hours. Performance optimization, parallel execution and scaling are soon to come as a requirement. Even for a retail trader delays longer than a few seconds may noticeably impact the gains.
