The secret to trading system development is to fail faster

If I am to offer only one advice with regard to developing trading systems then this is it — fail faster.

The sad truth to trading is that there is no magical system that can guarantee profitability indefinitely. A reason top firms like Renaissance Technologies employ hundreds of PhDs and is still actively hiring is because one can never reach the end of the rainbow in trading. A system can always be made better or made obsolete. In fact, you need to stay ahead of the curve as competitions are like vultures that will eat away your game if you don’t keep moving. Not to mention the changing dynamics of the market itself is a moving target. As such, you simply need to keep innovating.

My way of innovating boils down to executing five cyclical steps. Conceptualising, implementing, testing, measuring, and analysing, over and over again. In essence, my innovation methodology is a simulated annealing process that might or might not eventually lead to a breakthrough. I do this because:

1. I am intelligent but I am not a genius. As such, I don’t expect myself to make leaps and bounds with regular sparks of genius. Instead, I take small steps. Adding a 1% yield to your system is extremely difficult. Adding 0.01% is a lot easier. Adding 0.0001% is almost pedantic. So I aim for achieving smaller improvements and do it hundreds of times over a development cycle.
2. My view of the world is not absolute. In fact, I am more often wrong than right. So it follows that most of my ideas don’t have all the pieces right. Thus, it is inherent that I need to polish my ideas through trials and errors.

Failure is inevidentable when developing trading systems. It is part of the process. You come up with an idea, implement it, test it, find out why it isn’t up to your expectation, and then make it better. So the quicker you can fail and learn from it, the quicker you can discover something useful.

Software design, trading development process, and Ikea

I spent a few months between 2010 and 2011 not on the market, not on coming up with new strategies, but on developing a software framework for my trading system. For my trading strategy development, I make use of a continuous systems development life cycle process from the engineering realm. Starting from planning, to analysis, to design, to implementation, to maintenance, and finally, back to planning, and so on for each and every new concept that I have. (see Sir James Dyson’s guest column on Wired)

Imagine that if you need to write a new strategy file for each and every idea and for each of its design iteration. Pretty soon you’ll have many strategy files and a lot of boilerplate codes. What if you found a bug or figured out some enhancements to a particular component of your strategy? Then you’ll have to sift through all those files and make the changes to all those relevant codes to make the update across the board.

Hopefully, this isn’t the approach you’re taking. Yet, a few trading API that I have used before inherently encourage or even limit you (EasyLanguage and MQL4) to this archaic procedural programming paradigm.

Luckily, Java is an object-oriented programming language. However, it is only as object-oriented as you make it to be. JForex, the trading API that I use, actually runs on the edge of breaking this object-orientedness as I have recently lamented.

The bad news for the beginning developer is that practically every published strategy which I have seen or guilty of posting myself are illustrations of what not to do with software design. In that there’s none in it whatsoever. Think of common published strategies like the Ikea mini-model showrooms. Everything is crammed into a tiny space but it is a simple way to convey the gist of a room design (read: the trading algorithm). However, they are not built for practical use. Real strategies are like suites in an apartment building. There is an underlying architectural commonality for easy management and maintenance while enabling diversity in the strategies.

My recently completed software framework dramatically made my life easier in the tasks of implementation and maintenance. Software maintenance, in particular, is most often needlessly and overly complicated in trading strategy development because of the lack of a good design. Because at the end of the day, most programmers spend the majority of their time debugging, maintaining, and extending their code. A true object-oriented design decouples all its components so that you can use a divide and conquer approach with no repetition of work.

Do you have a development process in place? I’d like to hear how you tackle this problem.

Just because it’s math does not mean it’s not without its caveats

I am more than half way through my first speed run of the CFA level 1 material. This chapter discusses portfolio management. In particular, I just read the Markovitz Efficient Frontier. What strikes me most about this chapter is that these mathematical material are presented so matter-of-factly.

Recalling in chapter 1, Ethics, the idea of prudence and due diligence was evident. This was exemplified later in the Financial Statement chapter. Methods of drafting balance sheet, income statement, and cash flow statement were presented in excrutiating details before a discussion about ways to analyze them. Just so we can understand the mechanics of it to spot bias, pitfalls, misrepresentation, and outright frauds. In fact, a good portion of the section were reserved for discussing the caveats in financial statement analysis. As boring as it was to sit through the accounting details, that was good prudence and good due diligence.

Fast forward to this discussion on Modern Portfolio Theory (MPT), it is simply explained in the text that expected risk of a portfolio with individual asset correlations less than 1 will be less than its weighted average risk. Where are the billboard-sized warnings and neon-red danger signs?

Perhaps criticisms of MPT will be discussed later or perhaps I simply missed it with my ~200 pages/day scanning pace (in which case, just ignore me). But if I don’t see a caveat lector on MPT in bold, underlined, and boxed fonts later, then I am surely going to be very disappointed.

This is a big deal because of the historic events of 2008. In which we witnessed the havoc caused by countless funds that blindedly rely on MPT’s validity (i.e. diversification of risks on the naive basis of constant correlations and normally distributed returns), and other risk models, go under. There can be no worse mistake than underestimating your risk in trading. Let me repeat that, there can be no worse mistake than underestimating your risk in trading. Careless use of MPT (not MPT, per se) leads to exactly that.

The problem is that people take these financial theories to heart too much without reading the fine prints. Just because it is presented in mathematical formulas does not mean a theory is law. The least the CFA text can do is to broaden financial prudence from not only dissecting financial statements but to encompass other important intellectual matter related to the job too.

I am appalled by the fact that thousands of CFA level 1 hopefuls might actually believe that you can always reduce portfolio risk and identify an efficient asset mix from mere correlations and standard deviations (which in and of themselves are flawed in the real world), with no strings attached.

“Science is the belief in the ignorance of the experts”, Richard Feynman.

6 ways to filter data for your trading system

The imminent extortion of metered internet usage here in Canada got me thinking about the large amount of data (at least a few GB a month) that I use for my trading work. In particular, I’d like to talk about methods to filtering time series price data in this post.

There is a tradeoff between reading every tick that comes in or sampling the data at less-frequent intervals. A common way discretionary traders present data is by using open-high-low-close-volume (OHLCV) bars of a certain time period. A 5-minute chart looks similar but shows different information than a 4-hour chart, for example.

Technically, this is one way of filtering, or presenting, data by sampling at a fixed time interval. The thing with summarizing tick data into 5-min or 4-hour data is that you lose details in exchange for simplicity. However, the reduction in the amount of data is significant. A year’s worth of tick data of a single currency pair, for example, runs in the gigabytes range. Whereas a year’s worth of the same data in 5-minute OHLCV bars is merely a few hundred megabytes.

Another factor to consider is that market data are inherently noisy. Would feeding your system with each and every tick be useful? Of course, if your system is able to handle the noise, or even better, make use of it, then all the more reason to opt for more details in the data. But that’s another topic in itself.

In any case, there are 6 ways to present/filter data that I can think of.

1. Time interval.

As discussed above, this is probably the most common method of filtering data. You sample the data regularly based on a fixed time period.

2. Price interval.

Data is filtered based on a fixed price interval. Say, you can lump all the volumes together for every 100 pips and the horizontal axis would show how much time the instrument has spent in that 100 pips. A visual example is the Point and Figure chart.

3. Volume interval.

Each index of the data would have a fixed volume. Time still remains in the x-axis, in a non-linear manner. Volume intervals were my favourite for a while when trading futures and I programmed some of my earliest algorithmic strategies using it back then.

4. Regression modelling.

Essentially algorithms to model time-series data with one or more lines/curves of best fit. A simple concept but complex to execute. There are three fundamental approaches to segmenting (i.e. dividing up the time-series data into segments and modelling each segment with regression), sliding window, top-down, or bottom-up. A good paper to get started with time-series segmentation is Liu et al., “Novel Online Methods for Time Series Segmentation,” IEEE Transactions on Knowledge and Data Engineering, Vol. 20, No. 20, December, 2008.

5. Frequency filtering.

A common time-series data filtering technique in engineering is actually to transform the data into the frequency domain, truncate certain frequencies (usually the higher components), and then transform it back into time-series. Low-pass filter is very common in hardware circuits. In software, this is done typically with the Fast Fourier Transform algorithm. This algorithm is so popular that it’s a built-in function in many data analysis software, and even some calculators.

6. Wavelet transform.

This one I am just reading about recently. A seminal paper in this topic is Chan et al., “Efficient time series matching by wavelets,” Proc. Int. Conf. on Data Engineering, 1999. A search on Google Scholar for DWT or wavelet transform will yield more literature.

As you can see, massaging data is not limited to choosing the time period for your OHLCV bars. In fact, it’s a whole distinct field involving their own IEEE journal, Knowledge and Data Engineering. There is probably many other ways to filter data than these 6 that I introduced. This is yet another topic that I would like to know more to improve my trading system.

The Power of Tangential Learning

According to Wikipedia,

tangential learning is the process by which some portion of people will self-educate if a topic is exposed to them in something that they already enjoy.

I was just organizing my bookshelf the other day and is surprised by how fast my collection of statistics books have grown. I studied statistics back in school as a stepping stone to learning stochastic process for wireless communication theories (e.g. CDMA). Detecting radio-frequency and resolving wireless signals to meaningful messages is fundamentally about assessing the state of random processes. I hated statistics back then because I didn’t get it and did poorly in those courses. It is ironic that years later I would realize how much I have grown to rely and love the little p‘s and q‘s in my little hobby of quantitative trading.

I still don’t like statistics (or theoretical math), per se. I just love applying them in my trading and quant programs. The more that I learn about statistics, the more that I realize how powerful they can be and how ignorant I am. For example, in my clinical study days I used either t-test or ANOVA for everything under the sun. Now that I’ve come to understanding about inferential statistics, I am aware of the assumptions and pitfalls such as the assumption of t-tests of homogeneity of variance between the two samples tested. If this assumption is violated, then the unequal variance t-test should be used.

Finer points like these are routinely ignored in practice because many clinical studies are inherently designed in the experiment to meet these criteria. However, that’s not the case when I am making creative use of statistics in my trading. I don’t have a clinical study committee watching over my back. If I make a false or weaker-than-expected claim and don’t know better, then it is my bank account that will suffer the consequences.

Learning statistics was initially due to this got-to-know-better necessity. However, the more that I learn about statistics, the more that I appreciate it. If used correctly, statistics can provide a new dimension to the scientific assessment of your trading performance and market data.