[GSoC-PortA] Use case for PortfolioAnalytics

Wed Jun 19 23:40:25 CEST 2013

Peter,

Thank you very much for sending, that was very interesting and enlightening
for me from a real use case perspective. No apology necessary regarding the
length, I really appreciate your detailed thoughts on the points you
discussed. I will use this as a reference as I work on this and may come
back to you for additional clarification on certain points.

I have a few questions regarding point 1. Set limits that are
position-specific. Your text is italics and mine is inline below.

*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*
This is equivalent to setting box constraints and is currently implemented
for all solvers, correct?

 * - group level (e.g., no group of managers using Systematic strategies**
can represent more than 30% of AUM).*
Group constraints are only implemented in the ROI optimization method.
Could we use the fnMap function for DEoptim or add group constraints to the
randomize portfolio function?

*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*
These seem similar to a turnover constraint. Similar to my question on
group constraints, is it feasible to implement these constraints using
fnMap with DEoptim?

Thanks again!
Ross

On Wed, Jun 19, 2013 at 9:23 AM, Peter Carl <peter at braverock.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20130619/3676d18f/attachment-0001.html>