[GSoC-PortA] Use case for PortfolioAnalytics
Peter Carl
peter at braverock.com
Thu Jun 20 03:32:12 CEST 2013
Whoops - resending to the list as well.
pcc
--
Peter Carl
http://www.braverock.com/peter
> This is equivalent to setting box constraints and is currently
implemented for all solvers, correct?
Yes.
> Could we use the fnMap function for DEoptim or add group constraints to
the randomize portfolio function?
I'm not familiar with the fnMap function - maybe Brian has a take there.
Within RP, group constraints should be relatively easy to add.
> 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?
Not really - at least, not as I think about turnover. In my mind, a
turnover constraint applies at the aggregate portfolio level - e.g., no
more than 25% total turnover during a period. These are individual
position limits that can be described in inequalities: <= current
position, = current position, or >= minimum investment position not
described by policy (imposed by manager).
HTH,
pcc
--
Peter Carl
http://www.braverock.com/peter
> 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
>>
>
More information about the GSoC-PortA
mailing list