[GSoC-PortA] Use case for PortfolioAnalytics

[Doug Martin]

Peter,

Great set of comments and suggestions.  At the moment I would just say that
our challenge is to figure out which of all the possibilities to prioritize
and implement sooner rather than later.  I will come back later with some
thoughts about this.

Thanks,
Doug



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Peter
Carl
Sent: Wednesday, June 19, 2013 7:23 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: [GSoC-PortA] Use case for PortfolioAnalytics

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


_______________________________________________
GSoC-PortA mailing list
GSoC-PortA at lists.r-forge.r-project.org
http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta