Some trading systems may not work in the time it takes to execute trades manually and system designers may wonder why actual performance does not match their testing results. The problem may not be with the strategy, they simply may have designed/optimized a strategy too complex and fast to execute without greater automation.
At that point they can scrap their system or go all in by automating their trade execution. The key is first to create a solid design that anticipates potential issues or problems and then to create a testing plan that covers anything you can anticipate.
One of the major benefits of good trade execution software is the ability to act on signals 24 hours a day without having a human involved to pick up the phone or go online to input the trade information. The trade execution software generates the trade instruction to the futures commission merchant (FCM) and then handles the resulting responses appropriately, only alerting the trader if there are issues with the trades or unexpected results.
This frees up the trader to work on optimization, creating additional strategies or other business responsibilities. The trader would get involved only if an alert was generated by the trade execution software. It is a lot of work to develop good trade execution software, but in the long run the automation of this process should free up time for the trader. The question really comes down to, can you generate a return on your investment? In this case, time is invested in creating the trade execution software and then free time is generated by not requiring human intervention in the trading process.
An additional benefit to automating this process is a reduction in errors. Because the trade execution instructions are transmitted electronically to the FCM there is no chance of an error because of a miscommunication on the phone with your broker, someone making a fat fingered error or reversing a buy vs. sell order. However, the potential for bugs in the system can create bigger problems (see "Bugs happen, have back-up systems," last page).
Automating the trade execution process can be a very big step and will require careful design and planning. Start out with a conversation with your FCM. Get their published specifications. Ask them for references of other traders who are using their automated trade execution platform. How reliable and responsive is the FCM’s platform? What happens in the event that their platform is down or inaccessible? What are their disaster recovery procedures? Do they have a separate disaster recovery site that can be used in the event that the main production site is inaccessible?
Next, take a look at your hardware infrastructure. To properly monitor the trade execution software, you may need to purchase additional hardware, software and monitoring tools. By setting up the proper hardware infrastructure, you can minimize the risk that the automated trader would be down and no one would know about it. "Getting on the same page," (below) shows how the automated trader would be responsible for checking on the connection to the FCM and reporting a "heartbeat" to the database.
Monitoring your vital signs
The monitoring/alerting hardware would then check on the heartbeat in the database to ensure that the automated trader is active and functioning. The monitoring/alerting hardware also would write a heartbeat to the database and the automated trader would similarly check on this heartbeat to make sure the monitoring hardware was running. If either the monitoring/alerting hardware or the automated trader hardware does not detect the proper heartbeat then an alert would be sent to the human trader that something was wrong. Both the automated trader and the monitoring/alerting hardware generate a positive alert or heartbeat to the database saying "Hey, I am up and running and this is the last date/time I checked in."
Also, both machines check the heartbeat of the other machine to make sure the last time the other machine checked in was less than a user-defined number of seconds or minutes. This triangular monitoring will reduce the risk that the automated trader is not functioning without an alert
being generated.
To complete the hardware infrastructure, several environments may be needed. In addition to the production environment, there also should be a quality assurance environment for user testing and implementation of code changes. A disaster recovery environment also should be set up in a separate location with separate connections to the FCM in the event of a disaster that disables the primary production environment.
Building the system
Now it is time to start planning what functions the automated trading software will perform. Is the automated trader going to generate market or limit orders? How will the software handle partial fills? How long should the software wait for execution before the order is cancelled or a human trader is alerted? The easy part is to design software that can send an instruction to the FCM and then receive a response for the full trade. The hard part is to design software that can handle the variety of responses or non-responses that can happen. Every step of the process should be recorded in the database so that if there are issues, the trade instructions and execution can be reconstructed to see what happened.
During the design phase of the software, policies should be established on how to control the source code. How often is the code going to be backed up? Where is it going to be stored? Once a version is put into production, a complete copy of the source code for that version should be saved permanently. How are versions going to be numbered and controlled? How is the software going to be documented? A full-blown user manual is probably not necessary, but some documentation will be essential in understanding the evolution of the software and help with resolving design issues once you get into production. Some thought should be given to the release process as well. Once the code is in a production environment, how are future versions going to be implemented?
The coding phase of the software development is fairly straightforward. During the coding phase, the users should work to develop a comprehensive testing plan. Testing should include basic straightforward tests of the functionality as well as testing corner cases even if there is a very low probability of the corner case actually happening in production. Discovering how the software handles the corner cases often can lead to fixes and improvements that help even the most straightforward of processes. The software should be able to trap communication and network errors to provide alerts when things go bump.
Software bugs or errors are preventable with a good testing plan, but even the best testing plan may miss unanticipated events. Manually monitoring the software, particularly in the early stages of production, is essential for the user to get comfortable that the software is working as expected. Also, manual monitoring can lead to process improvements or enhancements that take care of the unanticipated events. If possible, run in production against the FCM’s test or demo system for a period of time to get comfortable with the process. Once comfortable with the test or demo system, switch to live trading with a small account to make sure the live system behaves like the test system. Once live, a combination of manual monitoring and a good alert process should enable a smooth operating environment freeing the trader up for more important tasks.
Now that a production version of the system is running, there needs to be a process for implementing changes and enhancements. Changes and enhancements to the software should be released first to the quality assurance environment, thoroughly tested by the users and then formally "accepted" by the users prior to being placed into production. Users should create a document of their testing scenarios and screen print or otherwise document the results of their testing. If possible, the quality assurance environment should be linked to the FCM’s demo system so that a complete production-like test can be undertaken by the users. The developer and users should work together to come up with "release notes" that are additions to the documentation and contain information on what is being updated or changed with each release. The testing plan should be modified with each release to make sure the new versions of the software are tested completely.
This entire process will take careful planning, quite a bit of time and a dedication to making the software work. But, in the end, the entire organization will be stronger because of this ability to automatically execute trades without human intervention. The traders can focus more energy on creating systems that produce profits and less time worrying about the task of executing trades with the FCM. Also, if designed properly, additional FCMs could easily be supported giving the organization a greater ability to service their clients.
Bugs happen, have back-up systems
Even the best design, coding, testing and implementation can have issues. For example, the authors’ automated trading program experienced a bug in its trading process that affected its risk management exits after running successfully with no glitches for nearly a year of live trading. Fortunately only one account was impacted, but over a four-day period this account lost about $30,000, more than half of its equity. The bug in the program was corrected, and additional alerting was put in place to notify the trader should similar issues arise.
It is important to be creative and thorough when designing the software and particularly the alerting/monitoring process. While the specific bug was corrected, it is important to have additional safeguards. If your automated system limits risk to a specific percent per trade and has an overall exposure limit (as was the case here), a separate alert should be set to alert the trader immediately to a breach in any of these parameters.
Also, while automating your system frees up time, you still need to monitor your trading daily to make sure nothing unusual has happened.
Brad Kuhlin and Bob Clancy are principals of CTA Adantia LLC, which was featured in our October "Hot New CTA" story. They can be reached at www.adantia-llc.com.
