[GSoC-PortA] Use case for PortfolioAnalytics

Peter Carl peter at braverock.com
Wed Jun 19 16:23:18 CEST 2013


Brian suggested that I send a few thoughts on a use-case for
PortfolioAnalytics.  I'm going to use a real situation, although I'm going
to skip over some of the details about *why* some of these issues exist. 
Apologies in advance for the length - I couldn't restrain myself from
talking more broadly around the specifics I lay out here.

The workflow I'm presenting here is similar to the one developed in
presentations that Brian has already pointed out:
- http://www.rinfinance.com/agenda/2012/workshop/Carl+Peterson.pdf
- http://www.rinfinance.com/agenda/2010/Carl+Peterson+Boudt_Tutorial.pdf
Many of the things I say here are reflected in those presentations, but I
hope I can emphasize a few points here.  In this use case, I'm more
concerned about describing the decisions than the workflow or the specific
data.

Portfolio construction is still a frequently neglected part of the
investment process.  It has, in practice, come a long way since the days
of Jessie Livermore-style overbetting (he lost 90% his wealth in 1907 on a
blown cotton trade).  That said, investors still don't always understand
the specific trade-offs they are making in optimization, or the
sensitivity the techniques show to the data and estimation error around
the inputs.  Many, many investors prefer to use simple rules-of-thumb and
common sense instead - which work to keep the portfolio out of hot water -
not realizing that they could add actually add value during this step by
explicitly expressing their objectives and constraints and generating
alternatives.

In going through this exercise of constructing a portfolio from individual
elements, there are a few issues that are important to me as a
decision-maker.  In general, I want:
  - to be approximately correct rather than precisely wrong (accuracy of
the method should be considered in the context of estimation error);
  - to define risk as potential loss rather than volatility (even
Markowitz wanted this);
  - the flexibility to define any kind of objective (in fact, I want to
compare several);
  - the ability to combine constraints (I have specific position-level
reasons for doing so);
  - a framework for considering different sets of portfolio
constraints for comparison through time; and
  - to build intuition about optimization through visualization.

Many people would add that they are sensitive to the calculation time, as
well.  Given the rebalancing frequency proposed in this case, calculation
time doesn't matter as much in this case.

0. Understand the portfolio constituents

Often left unsaid, but this step affects judgments about what comes after.
 In this case, I have three categories of commodities futures traders -
one of which tends to be extremely volatile but uncorrelated among the
peers (sector specialists).  Another category shows high correlation among
themselves, but run relatively low volatility strategies (trend
followers).  Those strategies can show autocorrelation, however, and can
find themselves in extended drawdowns.  The third category of manager are
somewhere in between those two (macro).  We tend to think of these in
groups, even where managers don't fit perfectly.

1. Set limits that are position-specific

The first step is to specify individual position limits.  In my more
specific case, where I'm allocating with actual managers (as opposed to
the EDHEC indexes in the 2012 presentation), those may come at the:
  - individual level (e.g., no single manager can represent more than 15%
of AUM) or
  - group level (e.g., no group of managers using Systematic strategies
can represent more than 30% of AUM).
There may be a specific direction of change:
  - Managers may not be able to accept additional capital, so that the
position may only be reduced from current levels;
  - Managers may be receiving an allocation subject to a minimum amount of
investment;
  - Positions may be subject to gates or lockups such that the investment
may not be decreased; or
  - We simply don't want too much manager risk, so that if they imploded
our losses would be limited to the amount invested (e.g., 10% of
capital).

These may be specified across all funds, for a sub-set of funds, or for
each individual fund.  In my specific case, I have an individual maximum
for each type of manager (e.g., a sector specialist may be no more than
10% of the portfolio).  I am not setting limits to the group today, but I
may want to in the future (e.g., no more than 60% to the sector
specialists).  I usually have a minimum investment level below which I
want to drop the investment (usually I want a position larger than 1-2%). 
I can't short in this portfolio (individual weight must be greater than
0%).

2. Set limits that are portfolio-specific

I have different sets of constraints around the sum of the portfolio
weights.  In some cases, all my managers' weights must sum to (about)
100%.  In this particular case, I can add leverage in such a way that the
sum can be greater than 100%.  There's always an upper limit to that
leverage as well (e.g., no more than 200%).

I also want to target a particular portfolio volatility (>10%), with the
view that volatility is also an element of upside potential.  In this
case, competitive products have a volatility between 10-16%, and since
investors use a heuristic of fees relative to the level of volatility I
want to make sure the portfolio volatility is roughly in that range.


So far, all of these issues represent constraints in the context that
Brian already discussed, in that they:
  - operate only on the weight vector (or a calculation of its components);
  - may include metadata about the components (the type of manager); or
  - describe the inputs to the objective function (target portfolio
volatility and/or return level).

3. Choose measures for constructing portfolio objectives

>From there, I then have a variety of measures by which I want to evalute
(rank) portfolios.  An objective may be composed of several measures,
which then have to be combined in a way that makes sense.  That is, the
measures may need to be normalized such that they relate to one another
proportionally.

I may want to vary my objectives by the amount of estimation I'm required
to do:

  - if I don't want to do any estimation, I can think about a 1/N
portfolio.  That's also a good benchmark to determine whether I can add
value in portfolio construction; OR

  - if I believe my volatility estimate, then I want a 1/sigma portfolio; OR

  - if I have confidence in both my volatility and correlation estimates,
then I'm able to calculate:
    + minimum variance or minimum CVaR portfolio;
    + equal volatility or CVaR contribution portfolio; OR

  - If I have good estimates for higher moments, I can do the same with
modified CVaR; OR

  - If I have an estimate for mean return I can examine the tradeoff
between return and risk (e.g., MSRP).

As we move down this list, additional estimates are required and we lose
degrees of freedom.  I'm going to ignore the issues of forecast horizon
here.

In this particular use case, I want to:
  - equalize the (ex-ante) contribution of volatility to the portfolio
among it's constituent managers.
  - target a volatility level (as described above).

4. Examine other objectives

But I also want to understand that portfolio in the context of the other
possible objectives I could have, namely:

  - Equal contribution to:
    + Weight (1/N);
    + Variance without correlation (1/sigma);
!   + Variance with correlation; <- my objective
    + Risk (mETL).
  - Reward to Risk:
    + Mean-Variance;
    + Mean-mETL.
  - Minimum:
    + Variance;
    + Risk (mETL);

Even though I have a preference for one objective, I want to know about
other objectives as well.  Those might be considered allocation
benchmarks, but they serve a role as markers (or buoys) in the constraint
space rather than as 'benchmarks' for performance.

Each of these is best expressed as an objective, of course, since they are
each:
  - calculated on a weight vector; and
  - describe a portfolio objective for the outcome of the optimization
(e.g., it describes the portfolio that is the minimum variance portfolio
within the constraint space).

The portfolios when compared this way can reveal some interesting aspects
of the underlying decision - say, when comparing a 1/sigma portfolio to
one calculated with correlation estimates one can see the impact of the
trade-offs made for the correlation among the constituents.

In my experience, constraints are typically very position-specific and
must be related directly to the data of the instrument in question;
objectives tend to be related to the portfolio in the aggregate.


This brief description probably doesn't go far enough into the broader
workflow.  It's pretty obvious and it isn't as linear as I'm representing
it, but I'll state it anyway:

1. organize data
2. describe the data statistically
3. develop methods for construction (broken down in the steps above)
4. get results
5. analyze results
6. interact with collaborators

This broader context suggests a few more requirements for
PortfolioAnalytics from the user's perspective.  One is that the
traceability of the solutions has to be maintained and well documented
(What did I do? Where did the data come from? How were the results
calculated? With what parameters?).  We can end up with a great deal of
derived data, and the user will probably need some helper functions to
navigate through it all.

Second, the results need to be well organized such that they can be easily
compared, especially visually.  Currently, this requires a great deal of
manual manipulation to organize the data and make the objectives
comparable.  This also requires some thought when specifying objectives:
calculations that need to be done for comparison that don't carry any
weight in the objective itself (e.g., portfolio variance is calculated for
a mean-CVaR objective, but has a multiplier of zero).

Third, the sensitivity of the results should be addressable.  This is
probably a topic unto itself, because it can be manifested in several
ways.  Along one of these dimensions is the ability to examine portfolios
that are not the optimal, but are "close-by," in that they rank below the
optimal (e.g., the 10 nearest portfolios in RP).

Food for thought,

pcc
-- 
Peter Carl
http://www.braverock.com/peter




More information about the GSoC-PortA mailing list