Covering All the Bases
Priorities change; to be truly effective, today's platforms for trading model design have to cover a wider and more varied number of bases than just five years ago. Development speed, lower cost, flexible security models, tighter execution environment integration and stringent control of operation risk are all now major priorities. Michael Unetich, ADL product manager at Trading Technologies, outlines one way to address them all. Michael co-founded TickIt Trading Systems and served as its CEO until Trading Technologies acquired the company in June 2010.
While different categories of participant tend to have differing requirements when it comes to model development platforms, in today's markets some general principles still apply across the board. Anyone, from high frequency proprietary traders, to brokers designing execution algorithms for their client base, will tend to have several important criteria in common.
The need for speed - but not in the usual sense
While reducing execution latency tends to attract a lot of headlines, an equally important consideration is reducing model development latency. There is a general acceptance that the profitable lifespan of trading strategies has declined and continues to do so. While various reasons (such as wide availability of low cost computing and analytics) are cited for this, the bottom line is that the need to reduce time to market for new strategies is intense. Any delay in getting a strategy to market risks losing inefficiency opportunities to similar competing strategies that are deployed faster.
Under those circumstances, hand crafting code is not an appealing option; even if extensive code re-use is possible. Another major issue here is that the trader or manager who generates the trading ideas may not be a programmer. If they have to collaborate with a programmer to get a model deployed, that raises the risks of misunderstandings, errors and delays. Some products attempt to circumvent this with simplified macro languages intended for non-programmers, but the trade-off is that these typically compromise the degree of model sophistication and/or execution speed.
It is for these reasons that Trading Technologies' ADL (Algo Design Lab), a new tool integrated within the firm's X_TRADER order-entry platform, may be poised to create a paradigm shift with its approach to trading model development. Currently in beta and scheduled for launch this quarter, ADL is a visual programming platform with functionality blocks (see Figure 1) that users can drag and drop within a GUI to create a complete trading strategy. A variety of blocks are available that cover a broad range of trading functionality (including market data, mathematical functions, Booleans, order management and messaging), which effectively means that there are no practical limitations on the type or sophistication of strategy that can be built.
However, the key point is that each functionality block is automatically associated with a block of extensively tested C# code. Therefore the process of dragging and connecting blocks is mirrored behind the scenes with the underlying code, with any parameter values specified (such as moving average length) automatically inserted correctly in the code. This workflow massively expedites the development process; a strategy that would otherwise involve writing hundreds or even thousands of lines of code can be assembled in a matter of minutes. A further
workflow advantage is that it is also possible for users to pre-build their own custom sub-assemblies out of functionality blocks that can then be re-used ("group blocks"). Finally, ADL's 'virtualization' feature allows portions of an existing trading model to be cloned so that multiple versions of the same model can be quickly created and run simultaneously.
Apart from speed, ADL's automated method of code generation also minimises the operational risks arising from manual programming errors. The code modules that underlie the ADL functionality blocks have all been battle hardened through frequent real time use and testing. This would be important under any circumstances, but in an environment where there is heavy time pressure to get models to market as fast as possible, the risks of manual programming errors are obviously higher.
A further safety mechanism is that ADL automatically prevents the user from making various types of erroneous block connections. Some of these relate to standard programming errors, such as circular references, but others are more trading-specific and/or relate to unintended designs. For example, if an Order block (which generates orders) is connected to more than one Order Container (which manages orders) there is the risk of conflicting control, so ADL will flag this up automatically (see Figure 2).
Finally, while ADL allows assembled models to be immediately implemented live in the Trading Technologies' platform, it is also possible to deploy and test them in live simulation mode to ensure that no unintended behaviour results.
Apart from the misunderstandings that can (and do) arise between traders and programmers, the costs associated with this two-handed development approach look increasingly untenable in market conditions where the alpha of new models can be quickly eroded by competition.
Up until now, the development of programming code has been a complex, expensive undertaking. TT aims to commoditise programming code with ADL. By enabling traders and managers to quickly build and live simulate their models themselves using ADL, considerable IT overhead savings can be made. A further cost saving is the time lost to code iterations between traders and programmers, especially where misunderstandings have arisen and a code release has to be discarded. Furthermore, ADL does not add license costs to the IT budget; it is included at no additional cost within Trading Technologies' X_TRADER front end.
Flexibility, security and deployment risks
Where trading models are deployed beyond just those responsible for generating a firm's intellectual property (IP), a number of additional risks arise. One of the most obvious is control; how much autonomy should a trader managing a model have in terms of adjusting its parameters? ADL handles this by allowing the strategy's original designer to specify precisely which (if any) parameters can be adjusted by whom and the range of parameter values permitted. This prevents inadvertent disasters, by preventing the use of untested parameter values or trader access to any of the underlying source code.
This security-conscious approach also minimises the risk of IP theft, because access to ADL 'circuit board' designs can be tightly controlled. Furthermore, this security model is flexible, as in common with any other model component it can be modified on the fly. Finally, ADL's flexibility also extends to external data and calculations in that it can also access values from Excel via dynamic data exchange (DDE).
One of the classic obstacles to efficient and timely deployment of trading models is the 're-coding hurdle', where the platform used for model development can't be used for live trading; models then have to be re-coded for the live platform, thereby increasing costs, causing delay and introducing the risk of translation errors.
ADL avoids these issues by being tightly integrated with the rest of Trading Technologies' platform. Once a model is built in ADL, it can be immediately deployed in either simulation or live mode via a dropdown menu on X_TRADER's MD Trader ladder (see Figure 3) or the Algo Dashboard.
In a highly competitive market, anything that aids rapid and efficient deployment of IP and trading capital is valuable. However, that needs to apply to more than just one category of model or trading entity; flexibility here is also essential. ADL can deliver this flexibility across the board in terms of model (grey/black box), security, time frame (from daily to ultra high frequency) and - above all - development environment.