by Haksun Li | Jan 6, 2015 | AlgoQuant, Algorithmic Trading, Seminars

This blog article is taken from our book [1]. In most entry-level materials on pairs trading such as in [2], a mean reverting basket is usually constructed by this relationship: , where is the price of asset at time t, the price of asset at time t, and the price of the mean reverting asset to trade. One way to find is to use cointegration. There are numerous problems in this approach as detailed in [1]. To mention a few: the identified portfolios are dense; executions involve considerable transaction costs; the resultant portfolios behave like insignificant and non-tradable noise; cointegration is too stringent and often unnecessary a requirement to satisfy. This article highlights one important problem: it is much better to work in the space of (log) returns than in the space of prices. Therefore, we would like to build a mean reverting portfolio using a similar relationship to (eq. 1) but in returns rather than in prices. The Benefits of Using Log Returns When we compare the prices of two assets, [… TODO …] A Model for a Mean Reverting Synthetic Asset Let’s assume prices are log-normally distributed, which is a popular assumption in quantitative finance, esp. in options pricing. Then, prices are always positive, satisfying the condition of “limited liability” of stocks. The upside is unlimited and may go to infinity. [5] We have: is the return for asset between times 0 and t; likewise for asset . Instead of applying a relationship, e.g., cointegration (possible but not a very good way), to the pair on prices, we can do it on returns. This is possible because, just like prices, the returns at...
by hao.ding | Apr 23, 2014 | AlgoQuant

Markowitz suggests in his Nobel Prize-winning paper Markowitz(1952) that when one selects a portfolio, he/she should consider both the return and the risk of the portfolio. Most of us, if not all, are risk-averse. Risk-averse means that if there are two portfolios with the same return, but different risks (in this article by risk we mean the standard deviation of the portfolio), we would choose the one with the smaller risk without any hesitation. Therefore given a set of risky assets and an expected return, we are interested in finding their best combination, i.e. the weights which will minimize the risk of the portfolio. And if we find the minimum risk of the portfolio for any return, we can draw a curve on risk-return plane. This curve is the famous efficient frontier. Assuming there are risky assets, and their return vector and covariance matrix are and respectively, then the points on the efficient frontier are computed by solving the following problem: where is the pre-defined expected return, and is the weight vector. The above problem can be solved using Lagrange multipliers. And we denote this problem as “Problem 1”. In AlgoQuant, we use another approach to compute the efficient frontier. The problem we solve is based on the utility function: , , and are the same parameters in Problem 1. The newly added parameter , is risk-averse coefficient. And this problem is denoted as “Problem 2”. The larger the , the less risk the investor is willing to take. Although most of us are risk-averse, the degrees of risk-averse are different among individuals. As a result, a coefficient that describes the risk-averse degree is introduced. Note that in some papers, risk...
by Ken Yiu | Jun 19, 2013 | AlgoQuant, Algorithmic Trading, Investment

Many portfolio optimization methods (e.g., Markowitz/Modern Portfolio Theory in 1952) face the well-known predicament called the “corner portfolio problem”. When short selling is allowed, they usually give efficient allocation weighting that is highly concentrated in only a few assets in the portfolio. This means that the portfolio is not as diversified as we would like, which makes the optimized portfolio less practically useful. In [Corvalan, 2005], the author suggests to look for instead an “almost efficient” but “more diversified” portfolio within the close neighborhood of the Mean-Variance (MV) optimal solution. The paper shows that there are many eligible portfolios around the MV optimal solution on the efficient frontier. Specificially, given the MV optimal solution, those “more diversified” portfolios can be computed by relaxing the requirements for the portfolio return and risk in an additional optimization problem: where , is the Markowitz MV optimal weights, are the relaxation tolerance parameters, and is a diversification measure for the portfolio (for example, , ). In other words, the new optimization problem looks for a portfolio with the maximal diversification around the optimal solution. Corvalan’s approach can be extended to create an approximate, sufficiently optimal and well diversified portfolio from the optimal portfolio. The approximate portfolio keeps the constraints from the original optimization problem. References: SuanShu Javadoc Alejandro Corvalan (2005). Well Diversified Efficient Portfolios. Documentos de trabajo del Banco Central, no....
by Ken Yiu | Feb 16, 2013 | AlgoQuant, Algorithmic Trading

[Lai, Xing and Chen, 2010], in the paper “Mean-Variance Portfolio Optimization When Means And Covariances Are Unknown”, proposed a ground breaking method to do portfolio optimization. In what follows we summarize their idea and use it to implement a periodic rebalancing strategy based on the AlgoQuant framework. Harry Markowitz won the Nobel prize for his work in mean-variance (MV) portfolio optimization in 1950s. The theory is widely regarded as fundamental in financial economics. It says, given a target return of a portfolio of m assets, the optimal (in terms of information ratio) weighting is given by where is the expected future returns, and is the expected covariance matrix of future returns. This problem is readily solved by quadratic programming. Nonetheless, the assumption that and are known in advance is very dubious. This has been referred to as the “Markowitz optimization engima”. The attempts made so far are to better forecast these estimators, namely and , as accurately as possible. The maximum likelihood estimate (MLE) from the training sample is an example. It turns out, however, that MLE performs poorly because the estimators are quite different from the realized values [Michaud, 1989]. Since then, three approaches have been proposed to address the difficulty. The first approach uses a multi-factor model to reduce the dimensionality in estimating [Fan, Fan and Lv, 2008]. The second approach uses Bayes or other shrinkage estimates of [Ledoit and Wolf, 2004]. Both approaches attempt to use improved estimates of for the plug-in efficient frontier. They have also been modified to provide better estimates of , for example, in the quasi-Bayesian approach of [Black and Litterman, 1990]. The third approach uses bootstrapping...
by Ken Yiu | Dec 21, 2012 | AlgoQuant, Programming

Bloomberg maintains tick-by-tick historical data for only 140 days. However, you may want to backtest your strategies with a longer history. In this case, you can archive these tickdata by yourself and do backtesting with the archived data. Since version 0.2, AlgoQuant supports downloading tick-by-tick data from Bloomberg and saving them as CSV files via the Bloomberg Java API v3 (assuming that you have access to a Bloomberg terminal). After you download the AlgoQuant package, you will find that there is a folder lib/blpapi-dummy which contains the Bloomberg API jar file (blpapi3.jar). This file is a dummy for AlgoQuant to compile. To use the Bloomberg Java API, you need to replace the file with the real API jar file. If your machine has been deployed the Bloomberg API, you can find the real jar file in your hard drive, for example, C:\blpAPI\APIv3\JavaAPI\v3.4.3.2\lib\blpapi3.jar Note that the version number of the API may be automatically upgraded by Bloomberg. The code for connecting, downloading and saving the tickdata is located in the package com.numericalmethod.algoquant.data.historicaldata.bloomberg. You can find in the package a simple demo application “TickDataDownloadApp“, which accepts command-line arguments and downloads tickdata of a given period for a given security: Usage: TickDataDownloadApp <security> <startDate (yyyy-MM-dd)> <endDate (yyyy-MM-dd)> <output dir> Note that the start date should be within 140 days as it is the oldest history you can download from Bloomberg. Here is how it works. The Bloomberg system provides a core service named “//blp/refdata” which allows downloading a wide range of market data. The code opens a session to connect to the localhost at port 8194 (change the settings in SimpleSessionFactory if you are using a...
by Haksun Li | Oct 27, 2011 | AlgoQuant, Algorithmic Trading, Programming

I posted my presentation titled “The Role of Technology in Quantitative Trading Research” presented in HKU-HKUST-Stanford Conference in Quantitative Finance. Dec 9, 2011. Workshop On Recent Developments Of Financial Mathematics (REDFIN2011). Dec 13, 2011. You can find the powerpoint here. Abstract: There needs a technology to streamline the quantitative trading research process. Typically, quants/traders, from idea generation to strategy deployment, may take weeks if not months. This means not only loss of trading opportunity, but also a lengthy, tedious, erroneous process marred with ad-hoc decisions and primitive tools. From the organization’s perspective, comparing the paper performances of different traders is like comparing apples to oranges. The success of the firm relies on hiring the right geniuses. Our solution is a technological process that standardizes and automates most of the mechanical steps in quantitative trading research. Creating a new trading strategy should be as easy and fun as playing Legos by assembling together simpler ideas. Consequently, traders can focus their attention on what they are supposed to be best at – imagining new trading ideas/strategies. Excerpts: In reality, the research process for a quantitative trading strategy, from conceptual design to actual execution, is very time consuming, e.g., months. The backtesting step, in the broadest sense, takes the longest time. There are too many details that we can include in the backtesting code. To just name a few, data cleaning and preparation, mathematics algorithms, mock market simulation, execution and slippage assumptions, parameter calibration, sensitivity analysis, and worst of all, debugging. In practice, most people will ignore many details and make unfortunate “approximation”. This is one major reason why real and paper...
## Recent Comments