I have always been developing systems that generate the entry and exit points without human intervention but never have I allowed the execution process to be automated. Now that the new semester is coming around and given the success of my new system (thusfar), I have decided to go automated using eSignal in conjunction with NinjaTrader as the bridge to my broker. Before this continues, it must be said that I am extremely analytical when it comes to undertaking any major action. Allowing a computer to manage my finances falls into that category for me. In constructing my automated system, I came up with a ton of potentially harmful problems that could arise. Therefore, before going live with this, I would like to know if any of you have any lessons which experience has taught you when it comes to this matter. For instance, coding/logic errors you have made, software problems, inefficient order handling methods in your code, hardware issues, and so forth. To sum it up, I would like to know some of the mistakes new automated traders make in the hopes that they can be avoided. So please, feel free to post away with your stories and suggestions. Some of the potential issues I came up with are: A) If an order is sent for multiple contracts to the market, then immediately a bracket order is sent for the same quantity of contracts without confirming how many contracts have actually been filled, one may end up taking a new position when they are actually supposed to be going flat. B) If the bridge between your broker and your system goes down resulting in your order not being sent, the results can be catastrophic (IE: trading without a stop loss). Therefore, the status of all orders should be confirmed. C) The internet connection for the computer can go down or the power can go out. A properly laid out fail-safe system consisting of a back-up internet connection and a UPS should always be in place.
One suggestion - try to design your order management as a finite state machine http://en.wikipedia.org/wiki/Finite_state_machine http://www.generation5.org/content/2003/FSM_Tutorial.asp An impressive name, but simple in concept. Many communications protocols use finite state machines(s) in their formal specification. If you do this, it is much easier to ensure you have covered all bases in terms of states the code may be in and what happens when it receives external events (such as partial fill, order confirmation or timer expiration). It is a lot better than getting lost in a morass of if ... then .... else logic. Also consider the use of one cancels all order groups so that in the event of connectivity failure you are not left with unwanted orders resting in the market. (eg place limit and stop trade exit orders in an OCA group so that the broker will automatically cancel one if the other is triggered).
Hi, im considering this too, but im still only thinking about it. Here are some thoughts: Its probably better to design it so, that multiple strategies can run simulatnously, so that you dont have to rewrite the whole thing of you want to add another strategy. With the limited ressources of a private trader, its probably not realistic to assume 100% uptime. There needs to be a reliable way that the software, after a software/hardware-restart for whatever reason, can determine which positions and pending orders belong to which strategy. What if a pending order executes during the downtime? The situation may have changed completly after reconnect, and the software must be capeable of reacting to it. Needs to be able to handle partial fills Needs to make sure quotes are sane/unlagged and filter bad ticks Needs to be able to react to all sorts of special circumstances (i.e. broker/exchange acting up) I will probably assume human supervision when i start to write my software, its probably not possible to handle each and every possible hickup without an IT-department at my hands (altho that partially defeats the purpose of autotrading).
These are the two "biggies" IMHO....especially the first one. And then the issue becomes: HOW TO HANDLE PARTIAL FILLS. What is the strategy ? Cancel the remaining order quantity ? Enter the remaining quantity as a market order ? Perform these actions conditionally based on the position's open profit/loss or unconditionally ?
I am working on what I believe to be a fairly effective solution for handling partial fills but the bad ticks thing is a different story. How could your system spot a bad tick unless your data vendor itself points it out?
naifwonder, can i ask why you chose esignal as your data provider? is there any particular reason to choose one data provider over another (assuming cost is not the issue)? amnon
I am using Genesis Laser and had to deal with plenty of bad ticks. A simple filter that (ask - bid) < 1%, and last price is reasonably near the bid/ask prices, has actually been working fine (for stock L1 quotes). Now filtering stuck quotes in L2 is a little more difficult ....
I have been using eSignal since I first started daytrading. I have no particular reason to keep it other then me being used to the platform. As for selecting a data provider, one should look at reliability, speed and amount of data. In reference to reliability, certain data vendors are notorious for bad performance during high volume times which may pose a problem depending on your trading style. Some are also known for running "unscheduled maintenance" on their networks which means downtime for the trader. In fact, when I first started trading, I was going to use TradeStation until I read that their data stalls when volume gets too high which is a problem that I seldom face with eSignal. It should be noted that I am uncertain as to whether or not eSignal is any better in this department since I have only used TradeStation once. Looking back, I wish I had used TradeStation instead since the platform is superior to eSignal and they give a lot more data (eSignal only gives a few days worth of tick data for e-mini futures whereas TradeStation gives the user access to several years worth of tick data). As for speed, certain data vendors are faster then others. Trading Technologies for instance is renowned for their high speed data which is much faster and much more expensive than something like eSignal or TradeStation.
Partial fills - Depends on the model. Let's say you're dealing with outlyers like trend following.... In general terms, you'll be wanting to fill the rest of order to avoid missing the opportunity. In reverse, if you're dealing with higher # of opportunity but lower reward... you'll be better off cancelling the remaining unfilled portion to avoid liquidity risk. Black swan, operational shock... etc.. - Operational risk. The whole trading operation is structured to deal with this. Trading is not only about when and what to buy and sell. Hardware setup, software, data services, legal and internal compliance, audit, accounting and etc. are part of the trading business. Things to watch out for? 1. Trading models requires more technical skills than a discretionary trader. Quant. Risk analysis/management, econometrics, programming, market IT infrastructure, optimization theories, computer science, game theory, math, Financial Engineering, etc. etc. etc. 2. Discretionary trading is a rational process. Systematic trading is a logical process. "Now" and "Current" Though, the mentality and the objective is both the same. 3. Learn to respect Quant. analysis. Learn to respect Infrastructural ITs. Learn to respect Market structure. 4. Most won't make it. This becomes much more obvious in systematic trading. The most popular reason is because they don't acquire the required skills to become one. Sole reason being laziness and compromise. 5. Systematic trading is a mixture of all 3: a. Quantitative Analysis. Risk. b. Programming. IT Infrastructure. c. Market Knowledge. Edge. 6. When you have a system, ask "How vulnerable is this model?" If the specific "reason it has worked" can break down at any moment in the future, all the backtesting you've done is worthless. Typical one... Candlestick pattern based models, it can do the opposite anytime. Final. TEST EVERYTHING. From models to the way you make, assess, mine, identify, expose, understand, implement, etc., etc.... If there is any kind of decision to be made... TEST IT.