The Gateway to Algorithmic and Automated Trading

Algorithmic Trading: What do I really need to do?

Published in Automated Trader Magazine Issue 10 Q3 2008

Some bright spark is suggesting that your organisation needs to build its own execution algorithms. They loudly point out all the advantages your competitors have gained by doing this. But what is actually involved in embarking on such a project? Dr Paul Lynch, managing partner of PE Lynch LLP, spells it all out.

By Dr Paul Lynch, managing partner of PE Lynch LLP
By Dr Paul Lynch, managing partner of PE Lynch LLP

Why are you building algorithms?

The answer to this most fundamental of questions is (or should be): to reduce trading costs, increase productivity and attract new business. Stick to this answer, repeat every hour and you might produce something useful. Or not start in the first place…

What do you need to know before planning an algorithmic solution?

In order to reduce trading costs, one must have a very clear idea of their current level. There is no way of telling if an algorithmic solution will be worthwhile unless the current trading costs are known, so establish these before embarking on anything else.

Of course, accomplishing this is not always a simple task. The trading costs are a mixture of execution costs, infrastructure, office space and salaries. The execution costs themselves can be subdivided into performance cost (price paid versus a performance benchmark) and DMA (Direct Market Access) cost.

To complicate matters further, trading costs may vary by geography; some investment houses choose to pay away DMA for different countries. Your execution cost in some countries may be significantly higher than in others. Therefore, obtaining a clear picture of your overall existing trading costs may take some time, but it will help clarify what your algorithms need to achieve. A further related task, assuming your prospective algorithms are not just intended for internal use, is estimating how much new business/revenue can be obtained by being able to offer them to third parties.

So, what is the plan?

• Who needs the algorithms? Is it for the program desk, cash trading, or external clients?

• What will it cost?

• What is the budget?

• What is the time line?

• What countries do you need execution algorithms for? Just those where existing trading costs are high, or where you currently choose to pay away?

“…it is probably easiest to buy in a 100Mb pipe where you can for equities, rather than risk data constipation later.”
"…it is probably easiest to buy in a 100Mb pipe where you can for equities, rather than risk data constipation later."

What infrastructure do you need?

- Do you have any historical data?

Algorithmic trading uses statistics based on historical data, so both Level 1 and Level 2 tick data are required.

If you have historical data, where did it come from? (Was it from a vendor or direct from an exchange?) Can its accuracy be relied upon? How were its ticks time stamped? Does it all use the same file format? Is it currently held in a consolidated database?

And of course, if there is no historical data - how much will it cost to buy in?

- Do you have any live data?

What live data feeds do you have and how resilient are they? How many instruments will you need to subscribe to? What future bandwidth will be needed? Estimate bandwidth over next 3 years - it is probably easiest to buy in a 100Mb pipe where you can for equities, rather than risk data constipation later. Again, how much will it cost?

- How do you engineer your code?

How will your code process a tick and how will the algorithm subsequently fire off an order? Or is this already the first stumbling block?

Is the current software infrastructure robust enough for algorithmic trading? The system will need to be stress tested to at least ten times the maximum order flow it has previously handled.

If the current system is not suitable, then sit down and actually draw what is needed. Then have a software engineer formalise the design. How do the ticks get into the algorithm? How does the code subscribe to the data? Which programming class will crunch the stats? Which class will broadcast output to the monitoring application? Which class will send out the resulting orders to the market? How will the orders be sent to the market? Will you build your own gateways or use sponsored gateways? How will the algorithms link up with the trader's Order Management System (OMS) or Execution Management System (EMS)?

- Do you have the appropriate hardware?

A crucial point to consider. (Although using Java as the programming language can make this less of a concern because of its platform portability.) If you will be writing multi-threaded code for your algorithms, then you'll be needing multi-cored and/or multi-processor machines. Don't stint on memory specification. Ideally you want plenty of RAM, so you can keep the existing database 'in memory', as well as being able to write real time ticks to memory and then dump to file outside market hours. Finally, check how power hungry your hardware will be (more on this potential issue later).

- Where will you place the system?

In house

There is always the risk that the cleaner might unplug a server to plug in a vacuum cleaner 30 minutes before market open. Also, office space is expensive at £80+ per sq foot. Do you really want to populate this pricey real estate with ugly, noisy servers?

“…it is probably easiest to buy in a 100Mb pipe where you can for equities, rather than risk data constipation later.”
"…it is probably easiest to buy in a 100Mb pipe where you can for equities, rather than risk data constipation later."

Co-located at the exchange

Whilst this may be fashionable, it doesn't make much sense in a fragmented marketplace. For example, being co-located at the LSE means that the algorithm will need to make a full round trip to Chi-X if the price is better there.

Find a neutral data centre

Depending on individual circumstances, this may be the best alternative.

It hopefully goes without saying that any data centre you choose must be both technologically robust as well as financially solvent.

One important point when buying space is to check how much power (sold in amps) is available. 42U racks can indeed house a lot of servers. However, if you are only given 13 amps per 42U rack (not uncommon), then it is unlikely you will be able to run more than three servers/firewalls/routers or switches per rack. This leaves a lot of empty space that you will still be paying for.

How do you get the algorithms into production?

It is best to roll out the algorithms to the program trading desk first. By entering program trades with a mixture of buy and sell orders, execution volatility is minimised, hence traders can establish the true execution costs faster.

Once the algorithms are built, the aim is to compare the current execution costs with the execution costs of the algorithm. When measuring the execution costs of an algorithm (e.g. execution price vs. VWAP) it is important to understand that a large sample size is required. Any relative evaluation must compare apples with apples. If the execution cost without algorithms is based on USD5bn dollars of flow across a mixture of liquid and illiquid stocks, then putting USD100mn dollars of flow in illiquid stocks through the algorithms is clearly not a valid comparison.

Once the algorithms are built, the aim is to compare the current execution costs with the execution costs of the algorithm. When measuring the execution costs of an algorithm (e.g. execution price vs. VWAP) it is important to understand that a large sample size is required. Any relative evaluation must compare apples with apples. If the execution cost without algorithms is based on USD5bn dollars of flow across a mixture of liquid and illiquid stocks, then putting USD100mn dollars of flow in illiquid stocks through the algorithms is clearly not a valid comparison.

Once your program traders are happy with the performance, the algorithms can be rolled out to the cash traders and finally (assuming all has gone according to plan) deployed to clients.

“An algorithmic solution should ultimately be measured by just one metric alone: profit.”
"An algorithmic solution should ultimately be measured by just one metric alone: profit."

How will the algorithms be maintained in the future?

A good algorithmic solution will always have access to recent historical data and will always need to update trading statistics. Sometimes market rules change, which requires changes in algorithmic behaviour (for example the recent rule changes regarding short selling).

Another important point to bear in mind is that algorithmic trading is constantly evolving. The emergence of smart order routing in Europe is the latest new challenge facing algorithmic trading systems. Algorithms will always need to be updated or improved to cope with these. Therefore algorithmic trading systems require constant investment in order to provide the best service to traders.

Finally - is it worth it?

The true benchmark of any algorithmic solution is whether the input yielded a worthwhile return on investment. In a perfect world, building algorithms leads to cash generation via a reduction in trading costs and increased revenues from new business. So if the cash thus generated will not significantly exceed the cost of building the algorithms, then don't bother for the sake of a vanity project. An algorithmic solution should ultimately be measured by just one metric alone: profit.