Recently, Man AHL, a “Trend Following Wizard”, announced in this press release some of the benefits from their “hard work to increase trade efficiency”:

In the past two years, the Asia desk has reduced Asian trading costs by more than 20%, and 98 per cent of regional trading can now be processed electronically […].

We have honed our execution style and algorithmic trading services to boost risk management and performance […]. These improvements have enabled us to add new asset classes to our trading models and we’ve recently expanded trading of several instruments including Asian stock index futures, interest rate swaps, relative value strategies, and a number of Asian currencies.
[Emphasis mine]

Algorithmic Trading: Really a Novelty?

You will have noticed the use of “algorithmic trading” in the copy above.
The recent rise of High-Frequency Trading (HFT) has placed algorithmic trading in the spotlight, making it appear as the new trendy (and controversial) development in financial markets.

But algorithms are not necessarily the overly complex and sophisticated processes used in HFT. As Merriam-Webster defines it, an algorithm is simply:

“a step-by-step procedure for solving a problem or accomplishing some end, especially by a computer”.

For example, a simple traffic light could be operated based on a fairly straight-forward algorithm (cycling colors in a predetermined sequence and time interval), in the same way as a trading system can have simple rules for Buy and Sell signals, like MA cross-overs. In practice, the algorithms are obviously more complex, for both traffic lights and trading systems.

But any mechanical (a.k.a. rule-based) trading system, such as those Trend Following programs employed by most CTAs would fit in the “algorithmic trading” category. In effect, any system that can be back-tested has to be based on algorithms.

A Duality in Algorithmic Trading Applications

There is a distinction between alpha-generation models and order execution models. The former has been implemented by CTAs with algorithmic trading for decades (using rule-based systems), whereas the latter is usually what the term algorithmic trading refers to nowadays (computerisation and automation of order flow in financial markets – as defined in wikipedia).

And this is naturally an area that also applies to CTAs. Whereas small retail traders face the opposite problem, CTAs’ larger size can represent an issue in terms of market impact and slippage, especially when dealing in less liquid markets.

As the Man press release highlights, not only does execution algorithmic trading benefits CTAs in reducing trade friction, it also allows them to tap extra markets, usually less liquid.

Example of Algorithmic Trading for Execution: Aspect Capital

Employing seasoned traders to execute orders dictated by the “alpha model” is one way to increase efficiency in trade friction. In this Automated Trader interview, Robert Wakefield, then COO of Aspect Capital – another London-based Trend Following Wizard – explains how their approach of mixing algorithmic execution with a desk of human traders allowed Aspect to reduce their net trading costs from 400 to 80 basis points.

The article is a few years old (2007) but gives an interesting example of the evolution of execution algorithmic trading within the CTA space.

Some excerpts (emphasis mine):

Ultimately, the focus for us is to use the execution strategies to reduce our footprint in the market. Our order flow is now definitely more difficult to identify and prey upon. An important input into the algorithm design stage is that our counterparties are becoming more sophisticated at exploiting systematic order flows. So delivering an order flow that is invisible is a key requirement for us in building up capacity in the trading models we are running and also protecting the returns generated from them. Minimising predation of our order flow is absolutely critical for us.

At the moment about 90% of our electronic trading is managed by our algorithmic execution model.

Commodities have stood out over the past year in terms of reduced trading costs. That has been partly due to the fact that some commodities are trading side by side on the floor and electronically, which has thrown up opportunities for price improvement.
In addition, we built some liquidity-seeking algorithms […] that allow us to trade instantly once our size and price conditions have been met. I think these algorithms have given us a real edge in commodity markets […] because we have been able to respond immediately while other participants have been looking at the floor price and the screen price and taking time to decide which price to trade.

We already have the capability to completely automate the execution process right from our “alpha models” (which generate the raw trading signals) through to our execution systems and the back office. However, while we have this capability, we still prefer to take advantage of the value that human traders bring to the trading process.

All signals generated by the alpha models are published as core position requests on the trading floor. However, we allow the traders a degree of freedom around these core positions, which we refer to as a “risk corridor”. Intriguingly, you sometimes find that the traders who outperform are those who do less trading and are at the lower boundary of the corridor. In range bound conditions the alpha model may wish to trade more than is actually ideal for the market conditions, so the trader can actually add value by doing less.

You can read the full interview there.
 

A few months ago, I got quite interested when Trading Blox announced that they introduced a new walk-forward functionality in their latest version. I just got round to upgrading, and giving that walk-forward testing a go. Amongst other things, some of the chart features have been improved – as can be seen in the eye candy above.

How it works

You can check this previous post for an explanation of how walk-forward works, from a general point of view. Robert Pardo (usually credited with the invention of walk-forward) has also written his bookfew books on the subject.

This new feature is a combination of small enhancements to the core application (ie. silent tests, dynamic date and starting equity settings, etc.) and a semi-custom script implementing the walk-forward testing procedure. It feels more like a (good) hack leveraging the core stepping functionality, rather than a functionality built from the ground up, but it does the job rather well (I looked at the underlying code and its ingenuity is actually pretty cool).

A minor issue is that you have to work out the number of optimization/out-of-sample cycles. If you get that wrong, the test will not cover the desired time interval and it makes the process less automated. Apart from that, the settings are pretty straight-forward, you can choose lengths of optimization and out-of-sample phases as well as other options:

In the settings above, there are 8 cycles, each having a 5-year optimization phase and 1-year out-of-sample phase

Objective Function

At the end of the optimization phase of each cycle, the system picks the best set of parameters to be used in the out-of-sample phase. However there are many ways to determine the best system. Do you use raw CAGR, MAR, Sharpe ratio, etc.?

There is a need to define the objective function (also called bliss function, as explained here, which will be used to determine the best system performance.

Trading Blox calculates standard statistics (MAR, CAGR, Drawdown, etc.) which can all be used as the objective function, but also allows the implementation of custom statistics calculations. These custom statistics can then be used as the objective function.

Output

This is where you realise the functionality is not fully integrated into the app. The system shows the individual results of each out-of-sample runs:

The stats calculated relate to each out-of-sample run (1 year in my example), whereas ideally these should all be spliced together, to form one system with its own stats. Same applies to equity curves, which are charted year by year (as individual charts). It is still possible to access the Daily Equity log file to do this yourself but it would be nice to have it better automated. The fact that it is a script and not compiled core code might make it possible to customize it to implement this automation.

Another log file also allows you to investigate the results of each optimization run and check their performance:

Starting optimization run ,225,2005-01-03, to ,2010-01-01, with starting equity ,166470686.069881530,
 
Run ,225, of ,256, Stepped Parameters: ,
Name,Step Value,Goodness Measure of ,64.497285767,
Run ( Index ),8.000000000,
Optimization Run,1.000000000,
Entry Breakout (days),20.000000000,
Exit Breakout (days),10.000000000,
Starting optimization run ,226,2005-01-03, to ,2010-01-01, with starting equity ,166470686.069881530,
 
 
----------------------------------------,
Best goodness of ,64.497285767, was on run ,1.000000000,
----------------------------------------,
 
Starting out of sample test ,241,2010-01-01, to ,2010-09-07, with starting equity ,166470686.069881530,

Test Results

For my first “test ride” of the walk-forward functionality, I used the good ol’ Donchian system.

The system parameters being tested are the Entry and Exit breakout lengths ranging from 20 to 50 days for the entry and 10 to 25 days for the exit.

The parameters for the walk-forward procedure are a 5-year optimization phase and 1-year out-of-sample phase with the plain CAGR stat being used as the objective/bliss/goodness function. The dates of the test go from 1998 to 2010 (but bear in mind that the first out-of-sample result is from 2003, ie. 1998 to 2002 are used as first optimization period).

The results (year by year) are the ones shown in the section above.

For an interesting comparison, I ran a standard stepped test using the same Donchian system and parameter values. Check below how the walk-forward system performance stacks up against the range of outputs from the stepped test:

All test results with the walk-forward result in yellow

In hindsight, it would have been better to pick other systems that performed better, but the advantage of the walk-forward process is that it adapts itself to pick a system.

In Closing

The walk-forward functionality is definitely not a fully-fledged feature of Trading Blox (yet?) – however it does allow for some automation of the process. The fact that it is “open” is probably a good thing as it can be tinkered with and improved easily. A nice addition to the product…

Quant Fund Management meets Crowd-Sourcing

In an adaptation of the web 2.0 model, the company aims to leverage the content (quant strategies) provided by their users. In order to attract these quant users, AlgoDeal do provide you the following:

• Free backtesting software: their proprietary java-based MarketRunner
• Free infrastructure: computer grid to run backtests and optimizations and low-latency data/exchange connectivity
• Free clean historical market data: covering 80 futures markets
• Access to institutional funds

And in good ol’ 2.0 fashion, this is still a beta platform…

The Business Model

The access to the software, infrastructure and market data is completely free; but the guys at AlgoDeal are not running a charity for hedge-fund-less quant traders…

For each backtest you receive a scorecard with each metrics evaluated (CAGR, Sharpe ratio, MaxDD, etc.) and a final score. AlgoDeal selects the best scoring systems and allocates its clients’ funds to the selected strategies.

This is done via a legal agreement that ties you for a fixed-term, but the ownership of the strategy remains yours.
And you get paid: 10% of the strategy profits (which would amount to 50% of the variable part in a typical 2/20 fee arrangement).

Techie’s corner

So you’ll need java if you want to use AlgoDeal’s platform. There are 2 options, you can either edit the strategies directly on the website or download MarketRunner and run it in your favourite IDE (the only real viable option..) such as Eclipse, etc.

The whole grid aspect is hidden from you: it should just mean that the backtests and optimizations that you submit online should be parallelized and run faster.

Regarding the execution side of things for live trading, AlgoDeal have entered into an agreement with QuantHouse to provide fast access to markets (proximity hosting, exchange connectivity with proprietary fiber optic network, etc.).

Finally, the historical data is all continuous contracts, rolled automatically (no mention of what rolling algorithm is used). They currently only provide daily data going back from 1999 but expect to go down to 1-min frequency in the coming months.

Beta version

This is still a beta version and as a result things are still moving. AlgoDeal have a published Roadmap on the site which lists coming improvements over the next 3 months, such as risk management, improved money management, multi-strategy systems, etc.

The beta tag also means that this is not yet a final, stable release. One example of this last night: I could not get to run one of their canned quick start examples, simply getting the message:

Something went wrong! some backtests failed

However, the developers do seem to be responsive on the forum they maintain (they also communicate through their blog). There is also a fair deal of doc available.

Free invites

This beta release is by invite only and new registrations seem to be closed for now. However I contacted AlgoDeal directly to request a special “blogger” invite, which they kindly obliged. They also mentioned that they would allocate 100 invites for you, my readers:

We can allocate an initial set of 100 logins to referrals from your blog, once they have left their email on our website ask them to send an email to support@algodeal.com with in the subject line “On behalf of Jez’s blog”

Note: for the record, I am not associated with AlgoDeal in any way and I am not getting anything out of these invites. I just thought that sharing these might be of interest to you.

First impressions

It is obviously not as sophisticated (yet?) as a “proper” backtesting platform such as Trading Blox, and I only played with AlgoDeal and their simple canned examples on the online editor. I assume there will be lots of progress and improvements in the coming months, before their proper launch (Q2 2010?).

I think the real selling point for serious quant traders is the “easy” access to institutional money, provided that the platform is flexible enough to implement “sophisticated” strategies. I am not sure whether long-term Trend Following strategies are the best way to get selected on this platform (backtest market data only goes back to relatively recent 1999, typical higher return volatility might be an issue, etc.)

In any case, this is a “free” way to get access to a large quant fund infrastructure and capital raising without the hassles and headaches that come with setting up your own fund or working for one (and looking a much better option than covestor, KaChing or collective2). I do not know how much external capital AlgoDeal have secured for fund allocation, but each strategy could be allocated between $100k to $10M, and the 10% share of profits makes it potentially an attractive proposition.

A platform and space to watch…

Vortex is present in chaotic movements such as fluid mechanics - picture courtesy of NASA

The indicator logic is described in the January issue of TASC (Technical Analysis of Stocks and Commodities) and sounds intriguing (link to PDF article). Without rehashing the details of the indicator calculation, it is very similar to Welles Wilder’s Directional Movement Index Calculation (DMI) except that Wilder’s Directional Movement (largest part of today’s range outside of yesterday’s range) is replaced by calculating the differences between today’s High and yesterday’s Low (positive Vortex Movement) and today’s Low and yesterday’s High (negative Vortex Movement).

TASC provides the Vortex indicator implementations in a wide collection of backtesting platforms (here). Unfortunately the Trading Blox implementation is not provided, which provided me a perfect opportunity to test and learn my new “backtesting toy” out.

System Logic Flaw?

The authors of the indicator provide a sample Excel spreadsheet to illustrate their calculation. By replicating the logic in Excel to get a handle on it (link to Excel spreadsheet), I uncovered what I think is a flaw in the logic of the indicator of the calculation.

The VM calculations take the absolute value of the difference of opposite price extremes (High and Low) between today and yesterday. The screenshot of this Excel spreadsheet below clearly illustrates that this is a problem when dealing with gaps.

Additionally, one could argue that the simple summation/averaging of the VMs is different from the original DMI calculations which use Wilder Moving Averages.

I have emailed the authors of the indicator with a suggestion for a fix. I’ll relay their answer here.

Trading Blox implementation

First and foremost, this is a Trading Blox coding exercise so I was not too concerned about these flaws (although I might be tempted to implement my own version addessing both flaws later).

I suggest you follow the calculation logic on the PDF article or the Excel spreadsheet. Here is how I implemented the Vortex Indicator in Trading Blox:

1: Create Auxiliary Block

This will hold all indicators and implement their calculations. Call it Vortex Indicator.

2: Create parameters

There is one parameter: the period for the Vortex indicator (VI) calculation:

3: Create Indicators

These are the first-level calculations: the daily True Range (TR), and VM+ (plusVM) and VM- (minusVM).

VM+ indicator using a calculated formula

The code for each of these indicators is:

plusVM (VM+ is the difference between today’s High and yesterday’s Low):

Abs(instrument.High - instrument.Low[1])

minusVM (VM- is the difference between today’s Low and yesterday’s High):

Abs(instrument.High[1]-instrument.Low)

TR (standard True Range calculation):

Max(instrument.High-instrument.Low,Abs(instrument.High-instrument.Close[1]), Abs(instrument.Low-instrument.Close[1]))

4: Create Instrument Permanent Variables (IPV)

This is for next-level calculations (Sum of TR, Sum of VM+ and VM-, VI+ and VI-). Setting these up as IPV allow for their values to be made available to other blocks (such the Entry block of a system).

Notice how the variable scope has been updated to System

The values for these IPVs are updated in the block Update Indicators script:

plusVMSum=Sum(plusVM,viDays,0)
minusVMSum=Sum(minusVM,viDays,0)
TRSum=Sum(TR,viDays,0)
plusVI=plusVMSum/TRSum
minusVI=minusVMSum/TRSum

Use in Trading Blox

Adding the auxiliary block to any System will enable it to access the values of the vortex indicators.

Here is how it could be done for a simple reversal system switching from Short to Long when VI+ crosses with VI- (and vice-versa).

Create an Entry Exit block

The system will have the Vortex Indicator Auxiliary block and our new Entry Exit block.

Add VI+ and VI- as IPV to the Entry Exit block

This is just a declaration to indicate that the values of these indicators are calculated in another block (our Vortex Indicator Auxiliary block).

The IPV is defined externally in another block (Vortex indicator)

The other parameters and indicators in this block are standard ATR Stop elements.

Code up the entry formula

Simple logic to enter long when VI+ is above VI- and no long position are in and opposite for short entry:

VARIABLES: pvi TYPE: Floating
pvi = plusVI
VARIABLES: nvi TYPE: Floating
nvi = minusVI
VARIABLES: pos TYPE: String
pos = instrument.position
 
IF 	plusVI > minusVI AND
	instrument.position <> LONG THEN
 
	IF useATRStops THEN
		broker.EnterLongOnOpen( instrument.close - averageTrueRange * atrStop )
	ELSE
		broker.EnterLongOnOpen
	ENDIF
 
ENDIF
 
IF	plusVI < minusVI AND
	instrument.position <> SHORT THEN
 
	IF useATRStops THEN
		broker.EnterShortOnOpen( instrument.close + averageTrueRange * atrStop )
	ELSE
		broker.EnterShortOnOpen
	ENDIF
 
ENDIF

Trading Blox test

Although I would like to do a more complete test to compare the Vortex Indicator to the DMI, all I have time left for today is a simple run of the system described above. I arbitrarily chose 39 for the VI period and here is the result:

Logarithmic Equity curve from Vortex indicator system

And as a side note of caution when dealing with backtest results, I’ll show you a quick trick that will allow me to nearly double the CAGR (Compounded Annual Growth Rate) by not touching the system at all:

Logarithmic Equity curve from Vortex indicator system (truncated period)

Notice what happened there: I just dropped years 1996 to 1999 from the backtests. Et voila! Surely a trick employed by more than one dubious trading systems salesmen…

Conclusion

The authors claim that the Vortex indicator improve on the DMI invented by Welles Wilder Update: the authors have sent me an email to clarify that they have not made such claim (I was merely interpolating, given the ressemblance of the Vortex indicator with the DMI). It would be interesting to test this as the idea of mixing chaos/fluid mechanics concepts to price movements is appealing. Fixing the indicator flaws would be good too. More to come… (update: on the next post, I also explain the authors response to my claim of the indicator having flaws).

Code download

Please find below the individual components (blocks) for download:
link to Vortex indicator block file (tbx)
link to VI sample Entry Exit block (tbx)

I wanted to test the MMDI as a follow-up to Moving Median: a better indicator than Moving Average?. This also provided a good opportunity to test Trading Blox (which I am thinking of buying).

MMDI: What is it?

In short, this is an indicator very similar to the MACD, except that the short moving average of the MACD is replaced by a moving median.

Portfolio Filter: Trade with the trend

One concept often used to improve the edge of a trading system is to look at 2 or more timeframes. The main timeframe (shorter one) is used for triggering trading signals (eg Donchian Channel breakouts), and the longer timeframe is used to determine the direction of the main trend. The filter rules prevent any trade signal to be taken if it goes against the main trend.

Trading Blox: a componentized testing framework

A great feature of Trading Blox is that it provides you with a skeleton workflow that forms the framework for the backtesting process. What this means is that Trading Blox implements and runs its logical workflow in the simulation loop (ie read data, update indicators, check entry signals, check exit signals, post-simulation scripts, etc.) but provides you with hooks at every step (about 35 hooks per simulation loop) where you can write your own code for customisation (with access to Trading Blox internal objects).

Next is the concept of blocks, which represent the different components of a trading systems (Entry signals, Money Management, Risk Management, Portfolio Filter, etc.). These blocks are easily reusable in any system and implement the functionality required via the code contained in their scripts.

One such block we are interested in for today is the MACD Portfolio Filter:

MACD Portfolio Filter Blox

This block stops the system from opening new trades in the opposite direction to the trend (the direction of the trend is derived from the MACD value).

MMDI Portfolio Filter

It was easy to use the standard Donchian channel system that ships with Trading Blox and replace its MACD Portfolio filter block by an implementation of the MMDI Portfolio filter. All it took was a copy of that block and an update of some of the scripts to implement the MMDI indicator and the filtering based on its value.

Indicator calculation:

mmdiIndicator=Median(ohlcDiv4,mmdiShort)-emaIndicator

Filtering code (long side):

[...]
' If positive, then allow long trades
IF ( mmdiIndicator > 0 ) THEN
	instrument.AllowLongTrades
ENDIF
[...]

And applying the new block (MMDI Portfolio Filter) to the system in the system editor screen:

System Editor

Test Scenario

The test is a comparison of the standard Donchian Channel breakout Tend Following system with MACD Portfolio Filter against its variation using the MMDI Portfolio Filter.

In order to get more data points (and to test Trading Blox parameter stepping), the comparison was run over a combination of system parameters:
- Long MMDI Moving Average: 200, 250 and 300
- Short MMDI Moving Median: 50, 62 and 74
- Donchian Channel Length (Entry): 20, 30 and 40
- Donchian Channel Length (Exit): 15
- Stop level: 2 x ATR(40)
- Slippage: 15% of ATR (+3% at rollover)
- Commissions: $12.50 per contract
- Dates: 01/01/2001 to 09/30/2010
- Instruments: 28 liquid futures (currencies, commodities, financials)

Test Results

Here are the two results tables produced by Trading Blox, showing a few stats for each system tested:

MACD Portfolio Filter Results - click to expand

MMDI Portfolio Filter results - click to expand

Looking at the CAGR and Sharpe ratio on aggregate, here is the how the systems compare:

Conclusions

First on Trading Blox: it was fairly straight-forward to code up this new indicator and system. The stepped parameter tests were also really quick to run (<1 min). Still pretty pleased and feeling at ease with it.

The test results show a small improvement in the MMDI favour. A possible explanation might be that the more volatile nature of the moving median (as illustrated in the moving median indicator post) allows it to pick up changes in trend faster (and get in them at an earlier, better price).

The whipsawing produced in the Moving Median crossover run would normally take place during range-bound markets, where few Donchain breakouts would happen, therefore cancelling the extra noise and losses associated with them.

Might be worth investigating further…
 
 
PS: David’s code for MMDI on TradeStation is available for free on his dvindicators.com website

PS2: As a comparison, and to illustrate the impact of a portfolio filter, here are the results for the same system without any Portfolio Filter:

Only 3 sets of results as the MACD/MMDI stepped parameters have been removed - click to expand

Without the trend filter applied to the portfolio, the Donchian channel breakout system now exhibits a negative performance (-2.68% on average across the 3 backtests). The trend is definitely your friend!

Regular readers might think that I suffer from backtesting-software-indecision-itis. Having first settled for TradersStudio, I then evaluated (and purchased) AmiBroker and found that it was 25 times faster than TradersStudio (at least for the calculation of the e-ratio). However, AmiBroker is not really geared towards true portfolio allocation testing with Futures and could not just replace TradersStudio – so I purchased it as a (cheap: $199) complement to it.

Why TradersStudio in the first place?

During my first round of evaluation, I did hesitate between TradersStudio and Trading Blox. At the time, it appeared that there was not a huge difference in functionality but a substantial price difference ($499 for TradersStudio, $3,000 for the full version of Trading Blox Builder). And this is how the choice was made.

However, I never really got past my TraderStudio’s first (not so good) impressions. Ultimately, I find the platform awkward to work with, documentation rather poor and the user community is very small.

So I decided to give Trading Blox another go and test their latest trial version (v3.3), and give you a teaser review of it.

Trading Blox: friendly, efficient, fast, professional

Trading Blox is vastly superior in terms of user interface “friendliness” and efficiency (love that script management/edit screen!). This makes the documentation lookup less necessary (and in any case, it is rather better).

The simulation runs are also very fast (300 stepped parameter tests under 7 minutes) and the software comes pre-packed with about a dozen ready-coded systems including the famous Turtle Trading system.

Finally, the numerous backtest options (slippage, commission, rollover slippage, volume, interest, etc.) should simulate trading reality much more closely.

Overall, it feels that the difference between Trading Blox and TradersStudio can be summed up by Pro vs. Amateur: both good at what they do, but playing in different leagues.

User community

Trading Blox forum is very good, with top-notch contributors. I joined it a few months ago and the discussion there is top-level, be it on all aspects of trading in general, backtesting, Data problems, Trading Blox questions, etc. It also has a marketplace where users can exchange code/systems, etc. This forum played a big part in my decision to re-consider Trading Blox (TradersStudio’s own forum and yahoo user group are barely ticking…).

In closing: screenshots

I feel I am about to give in and “cut my losses short” with TradersStudio and redeploy my resources towards Trading Blox. In the end, it is a “time vs dollar trade” and I feel that the initial outlay will give a great payback (in time savings and progress made). After all, automated trading is a business and one should not shy away from the essential investments.

Tomorrow, I should post a detailed system test using Trading Blox; but for now please find below some screenshots of the software (click to zoom in):

Result Reports

rich choice in general options

System Editor

Blox Editor

Heat map for stepped parameter

• Broker Account – The starting point to trade in the markets
• Live Market Data – To feed to your trading robot so that it can generate trading signals. Most brokers provide market data with proprietary or third-party technology- although market data can also be obtained from an independent vendor (e.g. eSignal).
• Order Routing – To transmit your orders to the exchange. These can be proprietary to the executing broker or third-party based (e.g. Zen Fire).
• Broker Trading Platform – To access your account information, place orders, etc.
• Charting Platform – Sometimes the broker platform charting capabilities are mediocre and an independent charting platform is required (e.g. eSignal)
• Signal Generation Platform – The actual trading robot: it analyses market data, account and positions information and implements the automated trading strategies to generate trade management signals (i.e. Buy / Sell / Exit, etc.).
• Excecution Platform – Receives trade signals and forwards them to the order routing.
• Platform Hosting – You can host the trading robot on your local machine, host it in a dedicated rented server or entrust a specialised broker to host and run your trading robot.
• Historical Market Data – Used as source for back-testing trading strategies
• Strategy Development Application – Allows for coding, optimisation, back-test and result analysis of trading strategies.
• Statistical Analysis package – for in-depth statistical analysis of back-testing results.

Some of these distinctions are physical, some are logical. For example, TradeStation packs many of the points above into one system: a broker account and a trading platform that allows you to:
Access live market data + Visualise price charts + Automate trading strategies that generate signals + Route the trading signals as orders on the exchange + Access account information + Store historical data + Back-test strategies

Sounds like it fits the bill perfectly, doesn’t it?
Well let’s look at the areas you need to consider when deciding on your automated platform.

Type of broker

Different issues to consider: is the broker a clearing broker, a non-clearing FCM or an introducing broker? If the latter is it an independent introducing broker or a guaranteed introducing broker (backed by a clearer)? It would seem that the closer to the exchange you broker is (in terms of relationship), the better/safer it is. See Anatomy of a Futures transaction for more detail on the different types of brokers.

Markets supported

Every broker offers access to different products and different markets. For example Interactive Brokers offers one of most complete coverage (worldwide Futures, Options, Equites and Forex) all “housed” under the same Universal Account. Other brokers only offer access to specific products/markets.

Latency/Speed

For some type of trading strategy, this can have a large impact and various platforms/feeds offer different levels of performance. This has led to specialist companies such as Zen Fire or Trading Technologies – which locate their servers very close to the exchange – achieving speed and reliability for data feed and order routing. They offer their services to brokers who can in turn offer it to their clients.

Development Language

This is mostly a matter of personal preference, experience and expertise. TradeStation has been around for longer and a big collection of Easy Language scripts are available for re-use while NinjaTrader, for example, uses C# and CQG Trader their own language.

Strategy Complexity vs. Platform Functionality

Most of the automated trading platforms that offer back-testing functionality lack sophistication of dedicated applications such as Mechanica, TraderStudio or Trading Blox. For example portfolio testing is usually not available in the live trading platforms. This might work for some simple strategies but not for more complex Money Management ones.

Hosting

You can run the trading robot on your machine, which makes you subject to power and connection failures or you can choose to rent a server to host your robot. Some brokers also offer trading strategy hosting and execution on their own servers.

Charting

Some specialised platforms offer better charting capabilities than the standard trading platforms and can be used as a standalone charting application. Some, such as eSignal, also offer a data feed.

Costs

An obvious one but between platform costs, execution costs, hardware, etc. there exists a wide range between bottom-end and top-end offerings.

What/how to choose?

While researching for this article I have come across many different packages offering different solutions. One of the best ways to help you decide on a solution that makes sense to you is to list your goals and cross-check each platform against them in this fashion (PDF doc).

There are endless possibilities for combining all the differenty packages. Just for fun I tried to “virtually build” the opposite of an all-in-one package such as TradeStation (which will probably not address most automated trader goals) – here is one “wacky” implementation.

A trader decides to use TradeStation as a signal generating platform. However she does not want to use TradeStation data feed and instead decides to go for the eSignal package integrating the broker Dorman Trading and the Zen-Fire connection for market data and a charting platform. In order to route the market data to TradeStation, she needs a bridge application - OwnData from TS Support for example. The backup feed solution would be TradeStation data feed. For the execution side of things, our trader decides to send the trading signals generated by TradeStation to NinjaTrader, which can route the orders to the exchange through a broker. The primary route is through Velocity Futures broker using Trading Technologies order routing, while the secondary route is through Interactive Brokers via their TWS trading platform and API! Additionally, the strategy research and testing is performed with Mechanica using CQG tick data while the results are analysed using R.

Conclusion

Sorry to end up on a cliche but there are no silver bullet to making the choice. If you take away one point is that you need to list your own requirements clearly and make the choice for yourself based on them.

Check that 60-page thread at EliteTrader if you want an endless discussion as to which is the best platform/architecture…

Here is a “gradual” description of how a Futures trade takes place with all intermediaries involved:

A BUYER AND A SELLER

In its most basic form a transaction involves 2 parties: a buyer and a seller.

A buyer transacts directly with a seller

THE EXCHANGE: A CENTRAL “MEETING” PLACE

However buyers need to find sellers and vice-versa. This is where exchanges come into play. They are a central place where trading takes place.

For example, the Chicago Board of Trade (CBOT) is the central place where wheat trading takes place. All sellers and buyers meet and agree on transaction prices there. Exchanges also enforce rules such as standardised terms (e.g. wheat futures contract provides for delivery of 5,000 bushels of any of several varieties of wheat during March, May, July, September, or December).

All buyers and sellers come to the exchange to transact

COUNTERPARTY RISK

Futures contracts are an agreement between two parties for future delivery of an underlying (e.g. wheat) in exchange for a Cash amount (settlement) dictated by the agreed price. Up until settlement, there is risk that one of the parties will not be able to fulfil its obligation and result in a financial loss to the other party. This is called Counterparty Risk.

To avoid this situation, an intermediary, part of the exchange, will guarantee the trade. This is the Central CounterParty. All trades are actually given up to the Central CounterParty – which means that technically you buy from the CCP and your counterparty (the other side of the trade) sells to the CCP.

The CCP enforces each party to maintain adequate levels of initial and variation margin to cover any potential losses. All of the CCP trades are cleared through its clearing house.

The exchange provides a Central CounterParty and Clearing House to act as a guarantee between buyer and seller.

BROKER INTERMEDIATION

Now, there are millions of buyers and sellers that want to trade on the exchange. The exchange is not going to deal with all buyers and sellers. Instead, an exchange is a B2B-only platform where broker-dealer firms place their trades between each other.

For a buyer to trade, she needs to go through a broker to place her order/trade on the exchange. However broker-dealers (also called Futures Commission Merchant – FCM) are large independent firms, or part of large investment/commercial banks. As such they will not deal with most clients (retail and small institutional). Those clients would go through Introducing Brokers (IB), which will act as an extra intermediary between the client (you) and the exchange in a B2C fashion – delegating the trade execution, back-office operations, etc. to the FCM.

There is a further distinction between FCM:

• Clearing FCM, which is a clearing member of an exchange
• Non-clearing FCM, which must clear its trade through a clearing FCM

The picture gets fuller with broker intermediaries: Introducing Brokers, clearing and non-clearing FCM.

HOW TRADING TAKES PLACE AT THE EXCHANGE

In the old days, most trading took place in open outcry, on the trading floor of the exchange, between the local representatives of the broker-dealer firms (traders, brokers, market-makers/specialists). Floor traders stand in a trading pit to call out orders, prices, and quantities of a particular commodity by making “crazy hand gestures” (think of the last scene of Trading Places). Note that open outcry is pre-dated by blackboard trading.

Electronic trading has emerged in the last decades and gradually replaced open outcry. The electronic platform of an exchange (e.g. e-cbot for CBOT) is essentially a matching engine which all broker-dealers connect to and submit their orders.

The full picture.

With the advent of electronic trading a new class of brokers has appeared: Direct Access Trading (DAT) brokers. They offer their clients (including retail) an electronic platform that allows for a direct access to the exchange (as opposed to more traditional online retail brokers, which are just an electronic IB). DAT brokers usually offer to retail investors low transaction costs and high execution speed.

I hope I have not forgotten anything. If so, please let me know in the comments. In a next post I will investigate how the various automated trading platforms fit into that model.

Software and manuals

You can download a fully-functioning Amibroker demo (you cannot with TraderStudio and even when you buy it you have to wait for CDs by post!) which contains some limitations (i.e no more than 5 markets back-tested at a time, etc.).
The manuals are all online and very thorough, complemented with additional articles, presentations and other materials. This makes it very handy (again compared to TradersStudio printed 300 page manual – yet incomplete) as you can search them electronically to look for exactly what you need.

Large Community

The Amibroker community seems much wider and as a result there is loads of available scripts for re-use. There is actually a whole library hosted on amibroker website.
There is also much, much more information available on the internet. As a sample test I googled “Amibroker Donchian” vs. “TradersStudio Donchian”: 23,200 results vs. 17 (including this blog!).
Finally the yahoo group is much more active. There are about 10 times more daily messages (although the TradersStudio one can go days without getting a single message). As an example I posted a question related to the custom backtester and got a useful answer the next day.

The platform

It takes a bit of time to get used to the concept and principles of Amibroker. It is quite different from TradersStudio. For example, all afl files are self-contained and might implement indicator, system, back-test procedure, scan and exploration code all at once (although only one part really runs at once – alightly confusing at first). In TradersStudio you can also define functions to be called in other code files; this does not appear possible in Amibroker (you would have to copy/paste the code over and over again). Both platforms allow you to build COM dlls to code up your functions.

The GUI is different but I would not say better or worse than TradersStudio.The charting forms a more central part of the Amibroker platform and just firing up a chart with several indicators is pretty quick. At first glance the money management/portfolio allocation does not appear very rich in Amibroker (in terms of functionality) but I would have to do more testing to confirm this.

AmiBroker screenshot

The language to create your own indicators, systems, etc. (AFL: Amibroker Formula Language) is based on C and not very hard to pick up especially with the very useful in-line help – it does help to read the tutorials first (!) to get a grasp of the main keywords/built-in functions.

Data loading

Loading the data extracted from CSI Unfair Advantage was fairly straight-forward and there seems to be a bunch of ready-made interfaces with other data vendors in addition to the Amiquote utility – which allows you import quotes in Amibroker. It seems that there is more flexibility in the type of data fields that can be loaded.

Conclusion

Overall I was pretty pleased at what I was able to achieve in a short amount of time. For some reason I found it very hard to get into TradersStudio whereas Amibroker was easier to tackle (once you understand its working concept).
Obviously I have not explored all the functionalities of either software and this is definitely not an exhaustive review. As a result of all this I will be buying a copy of Amibroker to complement (or replace?) TradersStudio. I am sure both platforms each have their pros and cons so having both is probably a good idea (and not a very costly one since Amibroker costs only $200!).

In the last few posts I have been exploring the e-ratio and wrote the code in TradersStudio. I also tried to implement it in AmiBroker AFL language mostly to check how it performed speed-wise – as I found TradersStudio quite slow.

While testing AmiBorker, it actually felt so fast that I decided to perform a more formal speed comparison test.

Conditions of the test

I exported the CSI data via the API for a proportionally back-adjusted Corn contract going back to 1949. The data was imported in both AmiBroker and TradersStudio via their ASCII Import.

The system tested is a simple 20-day Donchian Channel Breakout (Buy-only) and the ATR used to normalise the MAE/MFE is 20-day also.
The optimiser in both systems were used to generate the e-ratio for 50 51 different trade durations (from 10 to 50 days).

One of the condition to validate the results of the test was that the trades generated by both systems are similar (to double-check I did not make a coding mistake resulting in simpler/faster process for one of the platforms).

The computer I was running the test on is a quad-core CPU (2.4 GHz) with 3.25 GB of addressable RAM. Only one platform was running at the time it was tested.

Results are in!

And they look astoninglishly good for AmiBroker:

• The TradersStudio test was run first and took 4 mins 15 sec to complete and produce the custom report (which needs to be manipulated in Excel to calculate the e-ratio). Furthermore, it appeared that every incremental run in the optimisation process took slightly longer than the previous one.
• The AmiBroker test ran in (…drumrolls…) 10 sec! And the e-ratio was readily available from the results grid:
  
  

  AmiBroker optimisation results showing the e-ratio. Click to expand

Both apps maxed out their allocated CPU (i.e. overall CPU usage of 25% = a quarter of the quad-core CPU available).

I then decided to run the AmiBroker code over 5 markets to get a feel of how long it would take. I added Crude Oil (going back to 1985), Cotton (1968), Gold (1975) and Yen (1972).
AmiBroker ran the same code + optimisation in 2 mins 20 sec, twice as fast as one market in TradersStudio!

Applying a simple proportional calculation to derive the time it would take in TradersStudio for the same dataset would give us a completion time of 1 hour (59 min 30 sec exactly…). Since the performance seems to degrade over the course of the optimisation in TradersStudio (i.e. the first back-test is quicker than the last one of the optimisation run) we could assume that it would actually take longer, which is what I experienced when I was testing on similar data in the last few weeks.

So here you have it: AmiBroker is 25 times faster than TradersStudio and it gives you the results in a much more friendly format.

Trade Reconciliation

As mentioned earlier, to ensure that the test was valid, the set of trades generated by both systems should be compared. I ran one back-test of the system over the Corn data for a single optimisation step (e-ratio for 20 days duration) in both systems.

I could find that 296 trades out of 340 presented a very good match (some matches had one day difference on the Entry date and rounding differences on the prices). But overall the trade comparison was good enough to give assurance that the same systems and results were being tested.

I’ll keep investigating for myself where these errors are coming from (and post a further code update if warranted) but we can assume that the differences are trivial with regards to performance comparison.

Did I mention that AmiBroker is 3 times as cheap with a much wider following (many more code samples, better docs, more forums, etc.)?…