# An introduction to Risk Parity

Hello everyone!

In this post, I’d like to start talking again about asset allocation and in particular to introduce you to a relatively new concept in
the field: risk parity. Don’t get me wrong, this approach has been around for quite a while now — I think the first to create a product around this concept were Bridgewater in the 90s — but it is a philosophy which I believe is still not taught frequently enough in finance classes and hence is still widely unknown.

# Motivation

I first started to pay attention to risk parity about 5 years ago. In the classic Modern Portfolio Theory (MPT thereafter), the optimization problem has two inputs:

• the covariance matrix of the assets available
• an expected return for each asset considered

Both are difficult to estimate, but researchers tend to agree that estimating covariances is easier than estimating returns.

Nevertheless, a lot of asset managers came up with expected future returns based on “their experience” or on “their view of the market” — there is no real mathematical framework available. This causes a real issue because it has been shown that the mean-variance optimization problem (the one behind MPT) is really sensitive to the expected returns inputs: changing slightly the expected return figures can result in a big optimal allocation change. Therefore, estimating wrong expected returns makes manager select potentially pretty sub-optimal portfolios.

Estimating the covariance matrix is not an easy task either. However, there exist frameworks on which managers can rely and estimates they are usually not too far of the reality  (risk tends to be more stable than returns).

What I tried to look for 5 years ago, was an asset allocation method which was independent from the expected returns, as I found them very difficult to estimate accurately. Risk Parity is a perfect example of such method.

# How does it work?

I will try to explain to concept without getting into equations. For those who are interested in the maths, please have a look at Thierry Roncalli’s presentation and paper to start with.

The basic idea is to have a portfolio where risk is diversified as much as possible — ideally perfectly diversified. The remaining challenge is to define how to quantify diversification; defining risk is somewhat arbitrary as you could choose different risk measures (volatility, expected shortfall etc) depending on your preference as an asset manager.

## Quantifying diversification

Let’s assume that we are considering the simplest risk measure, volatility. Once the covariance matrix of all considered assets has been determined, one can then compute the volatility of a portfolio given the weights of each asset. Furthermore, one can also compute how much each asset contributes to the total volatility (i.e. total risk) of the portfolio. In risk parity the goal is to have each asset contributing equally to the total risk.

Let’s consider a portfolio with two assets $A$ and $B$ with 50% of weight for each asset (so-called equally-weighted portfolio) and let’s assume the total volatility is 8%. By computing the contribution and assuming $A$ is more volatile than $B$, then you could see that $A$ contributes by 6% and $B$ by 2% only (numbers here are arbitrary and taken for the sake of the example).

According to our diversification measure, the portfolio is not very well balanced as it is much more exposed to $A$.

## Finding risk-parity

In his paper, Roncalli shows how one can implement an optimization method to find the portfolio where both $A$ and $B$ would equally contribute to the portfolio’s total volatility. Since I want to keep this post fairly non-technical I voluntarily want to skip the details of the methodology. Let’s assume we are provided with an optimizer which gives us the risk-parity portfolio. It would look like something with 70% weight on $B$ and 30% on $A$ and which would result in a total volatility of about 3%.

This time, our portfolio is optimally balanced as it is equally exposed to both assets from a risk point of view. Note that the total volatility of the risk-parity portfolio cannot be chosen, it is purely a result of the optimization.

There is much more to say on the properties of risk-parity, and I will write more about this in later posts.

# Functional approach to portfolio modeling

Good evening everybody, I’ve been paying attention to portfolio modelling for the past few months. When you tackle such problem, you first try to think about how you could represent a portfolio as an object so that you can dive into your C#/C++/Java code so that you can start making money ASAP. However, you’ll soon find yourself cornered in numerous problems, especially when you want to backtest different allocation strategies.

## The object-oriented approach

Usually, when people model a portfolio, they will see it as a mapping between assets and weights associated to a date. There is however a misinterpretation of what a portfolio is. Indeed, what the common programmer describer above in his model is in fact a snapshot of the portfolio stat at some time t. If you were to make some changes in between two dates (all the subsequent instances of the portfolio will then be erroneous and the programmer would have to recompute them all to get the right simulation. Let’s take an example. Say we have a portfolio going through time t=1,2,3. We assume the stock has two assets, Microsoft (MSFT) and Yahoo (YHOO), and that the allocation strategy is to have an equally weighted portfolio (weights={0.5,0.5}). Here’s how the implementation would look like (in C#):

class Portfolio
{
public DateTime date;
public Dictionary<Asset,double> allocation;

public Portfolio() {}

public void Optimize()
{
int n=allocation.Count;
foreach (var pair in allocation)
{
pair.Value=1/n;
}
}
}

class History
{
public Dictionary<DateTime,Portfolio> history;

{
}
}


Now assume you want to add another stock (STO) to the portfolio at time 2, the previous implementation needs to be extended as follows:

class History
{
public Dictionary<DateTime,Portfolio> history;

{
if (history.Any(x=>x.Key>=t))
{
/* Compare the new portfolio composition with the subsequent states
* Take the necessary operation to adjust the portfolio.
* OUCH!!!! This is complicated.
*/
}
}
}


As you can see in the comments I added, backward changes requires recomputing the portfolio at time 2 and 3. This is computationally intensive and the kind of function you really do not fancy writing. I’m not even discussing the probability that some bug will exist or the change that you would have to add if you were to make more complicated backward operations. Furthermore, assuming you want to see how the portfolio behave before a change, all the information about the previous simulation would be lost. This is because the class actually stores the stateof the portfolio, not really the portfolio itself. “Thanks for the heads-up Einstein! You got anything better to do?” Well, as a matter of fact, yes.

## The functional approach

I would like to introduce a different way of representing a portfolio; a way which would be especially meaningful in a functional environment (F#, Scala). First of all, I would like to define a portfolio snapshot as a list of tuples of an Asset and a double representing each asset and its weight. To me, a portfolio is a strategy more than an object. In terms of allocation, the strategy outputs portfolio snapshots with weights, and these weights can actually generate buy/sell order to adjust a “real” portfolio (a basket of real assets) position. But the whole point here is that the portfolio is in fact just as set of operations. In my opinion, the correct way of representing an operation in a programming language is a function. In our case, an operation would be a function. This includes adding an asset to the portfolio, optimizing a portfolio and so on. The portfolio is hence a list of tuples of type DateTime*Operation (the date being the time at which the operation should occur). Let’s just define some formal definitions to these concepts (in F#):

type Action<'a>='a->'a

type Change<'a> = System.DateTime * Action<'a>;

type History<'a>; = Change<'a> list


An action is a function taking some type as an input and return a modified version of this object (actually, a new instance of the object with the modification included). A changeis an action happening at a certain time. Finally, a history is a list of changes. Simple. Now, how do we apply this to portfolio modeling? First, some more definitions:

type Weight=float

type Asset = string

type AssetAlloc=Weight * Asset

type PortfolioAlloc= AssetAlloc list

type PortfolioAction=Action<PortfolioAlloc>

type PortfolioChange = Change<PortfolioAlloc>

type Portfolio = History<PortfolioAlloc>


Thanks to the F# syntax, the code is pretty much self-explanatory. Now, let’s define a simple portfolio action consisting in adding an asset to the portfolio:

let addAsset (ass:Asset) (w:Weight) (pFolioAlloc: PortfolioAlloc) : PortfolioAlloc =
match List.tryFind (fun p -> snd p = ass) pFolioAlloc with
|Some _ -> (w,ass) :: pFolioAlloc |> List.filter (fun pa -> snd pa <> ass)
|None -> (w,ass) :: pFolioAlloc


For those of you not familiar with functional programming, this might look complicated, but if you look a bit into the language (particularly Pattern Matching), you’ll see it’s actually quite trivial. Let’s continue with the optimization of the portfolio:

let equWeightPortfolio (pFAlloc:PortfolioAlloc) : PortfolioAlloc =
let w:Weight = 1.0/(float pFAlloc.Length)
pFAlloc |> List.map (fun alloc -> (w, snd alloc))


Trivial. Finally, we need a function that will evaluate the portfolio. This requires the application in succession of all the changes to an initial portfolio allocation (most of the time, an empty portfolio, initially). This kind of operation is well-known in functional programming, it simply consists in foldinga list:

let getPortfolioAllocFromInit (pFolio:Portfolio) (t : System.DateTime) (init:PortfolioAlloc) =
pFolio |> List.filter (fun pc -> fst pc <= t)
|> List.sortBy (fun pc -> fst pc)
|> List.map (fun pc -> snd pc)
|> List.fold (fun alloc action -> action(alloc)) init

let getPortfolioAlloc (pFolio:Portfolio) (t : System.DateTime) = getPortfolioAllocFromInit pFolio t []


The first function implements the general logic: first sorting the operations and then applying them sequentially. The second function just modifies the first one by giving an initial empty portfolio. The application of this model is as follows:

let addSPAction : PortfolioAction = addAsset "S&P500" 0.0;;
(System.DateTime.Parse("31.01.2011"),equWeightPortfolio);
(System.DateTime.Parse("28.02.2011"),equWeightPortfolio);
];;
let myPortfolioAlloc t = getPortfolioAlloc myPortfolio t;

let endAlloc = myPortfolioAlloc System.DateTime.Now;;

let janAlloc = myPortfolioAlloc(System.DateTime.Parse("01.02.2011"));;


which outputs:

val endAlloc : PortfolioAlloc = [(0.5, "MSFT"); (0.5, "S&P500")]
val janAlloc : PortfolioAlloc = [(0.0, "MSFT"); (1.0, "S&P500")]


When hence see how trivial it is to compute the state of the portfolio at different times. With this representation, altering a portfolio at time t=2 means actually adding a function to a list, but does not change the subsequent operations. The state of the portfolio (the snapshot) is computed on demand. Let’s try doing so:

let addYHOOAction:PortfolioAction = addAsset "YHOO" 0.0
let myPortfolioAlloc2 t = getPortfolioAlloc myPortfolio2 t
let endAlloc2 = myPortfolioAlloc2 System.DateTime.Now
let janAlloc2 = myPortfolioAlloc2(System.DateTime.Parse("01.02.2011"));;


which outputs:

val endAlloc2 : PortfolioAlloc =
[(0.3333333333, "MSFT"); (0.3333333333, "YHOO"); (0.3333333333, "S&P500")]
val janAlloc2 : PortfolioAlloc =
[(0.0, "MSFT"); (0.5, "YHOO"); (0.5, "S&P500")]


As you can see, no rocket science to add backward operations! Note that we could have done so for any portfolio action… The model could be improved of course, but the idea is here. Keeping track of the old simulation would just mean keeping the date of creation of the change. I hope you enjoyed the ride, please feel free to comment! See you next time!