At QuantStart we place an emphasis on fully automated systematic trading and the processes that surround it. However we should be careful to distinguish between the separate concepts of systemisation and automation. The former involves a trading strategy that can be codified into a set of rules, which can—and often is—calculated and traded in a manual fashion. The latter encompasses the case where the calculation and execution is fully automated in code.
Many experienced traders are well aware of the benefits of systemisation and have refined their trading rules over a long period of time. They may make use of systematic signal generation, portfolio construction and risk management techniques. They may even wish to fully automate their strategy, freeing up more time to carry out research and further refine their systematic process. However, for those with no experience of coding it can be a daunting prospect.
While a plethora of resources now exist to get started with coding, there is still a reasonable learning curve before a trading strategy can be fully automated from signal generation to automated execution. Hence experienced traders often consider turning to experienced software developers to code up their strategy, mitigating the need to learn how to code themselves.
In fact this is a common query on both the Quantcademy forums and via the QuantStart support mailbox. Hence we decided to put together a guide for those traders who wish to hire a software developer or larger firm to code up their strategy, which provides some insight into the various factors that need to be considered throughout the hiring process.
Prior to the hiring process it will be necessary to consider the frequency of trading, the asset classes being traded as well as which brokerage will be utilised.
Higher frequency strategies generally require more software and hardware infrastructure than lower frequency strategies. Hence the cost of implementing an intraday code will likely be higher than that of a low frequency codde. If the strategy is traded daily or less frequently then this is less of a concern. However if the strategy is traded multiple times per day this will likely require more work. This is because there will need to be more automation involved (see the next section below).
The asset classes and traded instruments involved will dictate whether it is necessary to handle specific operational issues. Correctly handling equities, for instance requires keeping track of corporate actions and distributions. Futures contracts may need automated rolling. Hence if the strategy is multi-asset, multi-instrument then there is likely to be more work (and a higher cost) associated with development.
If there is a need for full automation then it will be necessary to utilise a broker that supports an Application Programming Interface (API). This allows the coded software to communicate with the broker without the need for a graphical user interface (GUI). Any generated orders and requested market data can be dealt with in an automated fashion rather than carried out on a manual basis. Examples of brokers with APIs include Interactive Brokers, OANDA and IG.
Level of Automation Required
Another important aspect to consider is the overall level of automation that is desired for the strategy. This needs to be thought out prior to hiring a coder as it will determine the level of necessary computational infrastucture—and the cost—of the overall implementation project.
Many systematic traders are content with a system that automates the process of market data download, signal generation, portfolio construction and target order generation. The trader will then carry out order execution in a manual fashion. Retail traders who trade weekly or monthly, with tactical asset allocation style rebalances can often be found in this group. Since the manual aspect is not too time consuming there is very little need to fully automate the execution.
Such a setup is relatively simple from the point of view of infrastructure. A script can be run at the desired trading frequency that outputs a list of rebalance trades. These can then be manually executed at the desired broker. It is likely that only a laptop or desktop workstation will be required for this sort of trading setup.
The next level up from systematic order generation is to carry out fully automated execution. However the scheduling of the trading logic is still carried out manually. That is, a script or codebase will be run that generates all signals, desired portfolios and connects to a brokerage to submit rebalancing orders. The key difference between this and full automation is the trader decides when this script is run. It is not scheduled by an automated process. It allows the behaviour of the orders to be manually monitored, but without the time-consuming aspect of manual execution if there are a large number of rebalancing trades to carry out.
The fully-automated approach carries out all of the above but makes use of an automated scheduling tool such as Windows Task Scheduler or cron on Mac/Linux to execute the trading logic and order submission. They difference between this level of automation and the previous two is that this system will often be run in a remote cloud-based server and will have some monitoring software and infrastructure built around it.
This infrastructure will need maintenance since many aspects of the system can fail (often at the worst possible time). Erroneous market data, counterparty/brokerage systems failure and hosting provider failure are all possible reasons why the strategy may not execute correctly.
Once full automation is considered it is clear that the costs of the project will increase significantly. It will be necessary to rent a cloud server, administer it and keep it maintained throughout the lifetime of the strategy. This is to say nothing of data retrieval or storage, which can add another layer of complexity.
As with computers themselves, a software development project will be more likely to succeed if the desired outcome is specified in as much detail as possible. It should be clear what the system will take as input (up-to-date market data, the current portfolio) as well as output (a set of rebalance orders).
The strategy rules, portfolio construction process and risk management approach will often be proprietary to the trader. However it will be necessary to provide the software developer(s) with as much detail as possible about how these aspects work. Otherwise the developer will have to make discretionary decisions about implementation, which can lead to divergence in the trader's original understanding of the methodology. The more detail that can be provided here, particularly around 'edge cases', the more a software developer will be able to produce an implementation that matches what was initially desired.
The software developer will ultimately be producing a script or a codebase, along with any necessary server infrastructure to be run manually or in an automated fashion. While a good software developer will endeavour to ensure that the code remains bug free, extensive testing can be time-consuming (and thus costly). Hence it is imperative to discuss with the software developer upfront how the code will be tested. These tests will often form part of the spec itself and will help provide confidence that the code is doing what it is supposed to do.
Disclaimer: Nothing in this article constitutes legal advice. It will be necessary to consult with a qualified attorney or solicitor for further information on intellectual property and the formation of non-disclosure agreements.
A key issue surrounding hiring a software developer (or larger firm) to implement a trading strategy is sensitivity to proprietary details. Theft of intellectual property is always a concern. However there are possibilities to mitigate this problem. One is to have a Non-Disclosure Agreement (NDA) drawn up prior to the point at which strategy details will need to be disclosed with the software developer.
Larger firms will be well-used to handling sensitive client details and so the possibility of 'pushback' from signing such a document is reduced. On the other hand, an individual software developer may not be as familiar with such documents and may be hesitant to sign.
In general however most software developers with no familiarity of systematic trading practices will not be in a position to 'copy and paste' a strategy in order to benefit from it. Instead they will be far more concerned with receiving their fee from the development.
Ongoing Support and Maintenance
It should be noted that developing a trading strategy implementation in code is rarely a one-off project. It may be necessary to modify strategy parameters, add a new portfolio construction technique or an extra risk management mechanism as market behaviour changes. Hence it will be necessary to consider how the project evolves through time.
Software developers utilise many tools to ensure ongoing development with code preserves old functionality as new features are added. It will be necessary to discuss with the developer how this is to be carried out. Version control software is popular for this purpose. Respected products include GitHub, GitLab and BitBucket. Infrastructure requirements will need to be decided and budgeted for.
Software can eventually become out of date. New versions of programming languages, along with their code libraries are constantly updated leading to deprecation of functionality. Brokerages continually update their APIs and might replace their connectivity mechanisms. It will be necessary to periodically refresh functionality within the script or codebase to ensure the strategy is still behaving as expected. Once again, such maintenance will need to be budgeted for.
Ultimately the costs of server infrastructure, ongoing maintenance and market vendor data will need to be balanced against trading revenue.
Where To Find Coders
As with any vendor the quality of the work will likely be correlated significantly with cost. Trying to have a trading strategy coded up 'on the cheap' will almost certainly lead to problems later down the line. It will be necessary to factor in the initial development, as well as 'surprise details' that crop up and any ongoing maintenance required. Hence the software development should be considered more of an ongoing partnership rather than a one-off project.
If the budget for software development is small then it is possible to find freelance developers on marketplace sites such as Upwork and Freelancer. It is essential to consider their prior work history as well as client feedback. Contact the individual to gauge how rapidly they reply as this will be indicative of their likely future responsiveness. Ask them how they prefer to work and what they will require in order to produce a strong implementation. Since these sites charge on an hourly rate basis it will be necessary to estimate total project cost upfront. However be aware that cost overruns are common and should be budgeted for.
An alternative is to approach a larger software development agency to carry out the work. The advantages of doing so will likely include significantly more experience, a wider range of skills due to a larger team, as well as a potentially more professional client relationship. Perhaps most importantly they are likely to provide guidance throughout the entire project in order to ensure the project is delivered as intended. The obvious downside is cost. Agencies will charge substantially more than individuals. They will also potentially deprioritise the project if it is unlikely to provide revenue commensurate with the time spent on it, which could lead to delays. Software development agencies are generally best found through a search engine query or recommendations from individuals within your network.
When deciding to hire a coder it will be necessary to determine how much of the trading process is going to be automated. A high frequency, fully automated strategy will require infrastructure in excess of a standard laptop or desktop and hence will have an ongoing cost associated with it. The upfront consideration of a tight specification is also extremely important.
Intellectual property sensitivity is an issue but can be mitigated somewhat by the creation of NDAs and intellectual property agreements. Ensure any developer hired is well aware of this aspect prior to engaging them to develop a strategy.
Ultimately the quality of the project will be correlated with budget. Agencies will charge more, but will likely deliver a better product and will have a more professional approach.
For those with any questions that have not been sufficiently answered by this article, please feel free to contact us at firstname.lastname@example.org and we will do our best to provide guidance.