In today’s post, we are going to look at how the research application’s outputs become a custom application.

The application is planned to be divided into individual modules for each trading approach. Each module will have formalized output defined by given trading strategy: backtest and detailed analysis (with charts and metrics). The user can create own strategy by chosen input parameters.

One of mentioned trading approaches is Relative value, what is based on bets on convergence when the discrepancy between similar or same stocks widens. It means searching for opportunity to exploit from gaps in the price or rate of the same or similar securities. It supposes that the differences are only short-term and the rate of the prices will revert back to original (normal) ratio soon. Relative value funds are perceived as hedge funds as they do not trade the price of a specific security alone and the policy of benefitting from the pricing discrepancies is to buy one security (considered undervalued) and sell the other (considered overvalued) in a form of pairs trading.

The user (fund manager) will build this kind of trading strategy in some basic steps:

- selection of suitable pairs
- identification of situations leading to do trading actions

According to this universal framework, a lot of questions will rise and the application should allow the fund manager to solve them.

No doubt that the phase of suitable pairs selection is crucial. Potential fund manager has to find two stocks that are similar enough. In the data preparation step of the analysis it is necessary to solve problems like:

- what historical period to consider for pairs selection
- what indicators (technical, fundamental etc.) and what role will they play in the similarity detection, e.g. find assets what have moved together historically
- determine what to consider as normal differences (the similarity)
- what to do with pairs where the assets are too similar (nearly the same) in considered indicators (it will probably generate no arbitrage opportunity)
- which assets according to some (fundamental, technical etc.) factors to select or filter out from consideration

Next step in the pairs selection process is to do the proper analysis of prepared data. Here the questions are mainly:

- what approach or algorithm to use for similarity calculation – widely known and used are cointegration, correlation, regression etc.
- evaluate the pair robustness/power (total, in various periods)
- determine strictness of condition for pair identification
- how many pairs minimally is suitable to have in portfolio
- what to do with assets that take part in more pairs
- what role can play the upcoming fundamental events (fusion, bankruptcy etc.) in identified pair stability

After the crucial step of pairs selection the trading part of the strategy follows. It deals with determination of trading signals, e.g. define rules solving problems like:

- how much the assets in the pair should differ for opening the positions
- are there other relevant indicators disproving suitability of opening the planned position (long position planned and the RSI shows the overheated asset etc.)
- determine the ratio of assets in open positions
- what dissimilarity of assets should lead to close the positions
- how long to wait maximally for the spread returning to normal state or for closing the positions regardless to trade result (avoiding possible higher losses)

Naďa Chalupová

In today’s post, we are returning to the Relative Value Approach topic, where we have put a methodology for analyzing stocks, in particular stock couples that show co-movement. **We will use **this** co-movement to create a market-neutral trading strategy (in this case pair trading).**

In the last post we introduced the part of the application that searches in the given stock titles and selects those whose logarithmic price differences are mutually correlated. However, this result is static, valid for the moment we run the application. The user will also be interested in the stability of these pairs (or their correlation) over time. Therefore, the application is extended by a walk forward test, which is testing the development of correlated pairs over time.

### Methodology

A non-anchored test is performed within the walk forward test. The beginning and the end are scrolling, ie the test window is not extended. As in the previous case, batching is calculated by linear correlation of logarithmic price differences.

### Computation

For each pair of in / out-sample correlation thresholds, a walk-forward test was performed:

- Each walk forward test is a set of partial tests for different walk-window lengths (walk-windows ranging from 2 years to 20 years with a 1 year step)·
- Each walk-window has a different length of in / out-sample (1 – 20 years, with 1 year step)·
- The start of in-sample section has been shifted from the beginning of the data by the length of the out-sample section (eg, the 5-year test starts from 1997 to 2013, ie the end of 2018)·
- The “survival” of the pairs in each walk-window was monitored, ie the number and / the proportion of those in-sample pairs that were also identified in the out-sample section·
- For example, 80% means that 10 pairs were found in the in-sample, in out-sample were found 8 of these pairs.

### Results

The heatmap summarizes the walk-forward test results for a pair of correlation thresholds (in-samle and out-of-sample data). Each stripe of numbers parallel to the main diagonal in the figure represents the results of a set of tests for a certain walk-window length (the sum of the numbers on X and Y is the window length).

The individual boxes show the results for each combination of in-sample and out-sample window lengths. The horizontal axis (X) shows the in-sample window lengths, the vertical (Y) out-sample windows. E.g. the values for the 5-year window test are the points with coordinates (X, Y): (1, 4), (2, 3), (3, 2), (4, 1). Missing fields below the main (or secondary – see above) diagonal mean that no pair in walk-window in the in-sample was found in any of tests. The shorter the walk-windows, the more times they can move over the full length of the data, ie the more partial tests take place, and thus the resulting aggregate value (average, median, etc.) is more robust.

The more favorable (desirable) results are darker, unfavorable lighter, each metric has its “color” (average – blue, median – green, test properties – red, range – purple).

### Mean

In the first image, in the area of narrowing “1” line near the main diagonal, the survival of couples are extremely negative (0 or crossed out) as well as positive (100%). The area copied the narrowing line of “1” in the number of tests performed (the first red chart), ie the tests performed only once (due to long out-sample / sliding windows). The “XOM-CVX” pair is almost always the result, so it’s the strongest pair across different seasons.

### Median

The figure below shows similar results as in the previous case, only the “survival rate with the highest frequency” is calculated instead of “average survival rate”. In other words, the average is replaced by median.

### Conclusion

The output of this application function is robustness testing, or better stability of pairs over time. Let’s take an example when a user of the application selects to date a list of couples which are suitable for pair trading.

Then the user thinks about the list and thinks about how the list would change if the export was done yesterday or a year ago … The answer is just a **walk forward test that tracks and evaluates changes in the list of pairs over time**. By using this feature, the user recognize that XOM-CVX (Exxon Mobil Corporation and Chevron Corporation) is one of the pairs with the strongest interrelationship between the analyzed assets.