<div dir="ltr">Peter,<div><br></div><div>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.</div>
<div><br></div><div style>I have a few questions regarding point 1. Set limits that are position-specific. Your text is italics and mine is inline below.</div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><i><span style="font-family:arial,sans-serif;font-size:13px">The first step is to specify individual position limits. In my more</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">specific case, where I'm allocating with actual managers (as opposed to</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">the EDHEC indexes in the 2012 presentation), those may come at the:</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> - individual level (e.g., no single manager can represent more than 15%</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">of AUM) or</span></i></div><div style>This is equivalent to setting box constraints and is currently implemented for all solvers, correct?</div><div style><br><span style="font-family:arial,sans-serif;font-size:13px"> <i> - group level (e.g., no group of managers using Systematic strategies</i></span><i><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">can represent more than 30% of AUM).</span></i></div><div style>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?</div>
<div style><br><i><span style="font-family:arial,sans-serif;font-size:13px">There may be a specific direction of change:</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> - Managers may not be able to accept additional capital, so that the</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">position may only be reduced from current levels;</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> - Managers may be receiving an allocation subject to a minimum amount of</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">investment;</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> - Positions may be subject to gates or lockups such that the investment</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">may not be decreased; or</span></i></div><div style>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?</div>
<div style><br></div><div><br></div><div>Thanks again!</div><div style>Ross</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 9:23 AM, Peter Carl <span dir="ltr"><<a href="mailto:peter@braverock.com" target="_blank">peter@braverock.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Brian suggested that I send a few thoughts on a use-case for<br>
PortfolioAnalytics. I'm going to use a real situation, although I'm going<br>
to skip over some of the details about *why* some of these issues exist.<br>
Apologies in advance for the length - I couldn't restrain myself from<br>
talking more broadly around the specifics I lay out here.<br>
<br>
The workflow I'm presenting here is similar to the one developed in<br>
presentations that Brian has already pointed out:<br>
- <a href="http://www.rinfinance.com/agenda/2012/workshop/Carl+Peterson.pdf" target="_blank">http://www.rinfinance.com/agenda/2012/workshop/Carl+Peterson.pdf</a><br>
- <a href="http://www.rinfinance.com/agenda/2010/Carl+Peterson+Boudt_Tutorial.pdf" target="_blank">http://www.rinfinance.com/agenda/2010/Carl+Peterson+Boudt_Tutorial.pdf</a><br>
Many of the things I say here are reflected in those presentations, but I<br>
hope I can emphasize a few points here. In this use case, I'm more<br>
concerned about describing the decisions than the workflow or the specific<br>
data.<br>
<br>
Portfolio construction is still a frequently neglected part of the<br>
investment process. It has, in practice, come a long way since the days<br>
of Jessie Livermore-style overbetting (he lost 90% his wealth in 1907 on a<br>
blown cotton trade). That said, investors still don't always understand<br>
the specific trade-offs they are making in optimization, or the<br>
sensitivity the techniques show to the data and estimation error around<br>
the inputs. Many, many investors prefer to use simple rules-of-thumb and<br>
common sense instead - which work to keep the portfolio out of hot water -<br>
not realizing that they could add actually add value during this step by<br>
explicitly expressing their objectives and constraints and generating<br>
alternatives.<br>
<br>
In going through this exercise of constructing a portfolio from individual<br>
elements, there are a few issues that are important to me as a<br>
decision-maker. In general, I want:<br>
- to be approximately correct rather than precisely wrong (accuracy of<br>
the method should be considered in the context of estimation error);<br>
- to define risk as potential loss rather than volatility (even<br>
Markowitz wanted this);<br>
- the flexibility to define any kind of objective (in fact, I want to<br>
compare several);<br>
- the ability to combine constraints (I have specific position-level<br>
reasons for doing so);<br>
- a framework for considering different sets of portfolio<br>
constraints for comparison through time; and<br>
- to build intuition about optimization through visualization.<br>
<br>
Many people would add that they are sensitive to the calculation time, as<br>
well. Given the rebalancing frequency proposed in this case, calculation<br>
time doesn't matter as much in this case.<br>
<br>
0. Understand the portfolio constituents<br>
<br>
Often left unsaid, but this step affects judgments about what comes after.<br>
In this case, I have three categories of commodities futures traders -<br>
one of which tends to be extremely volatile but uncorrelated among the<br>
peers (sector specialists). Another category shows high correlation among<br>
themselves, but run relatively low volatility strategies (trend<br>
followers). Those strategies can show autocorrelation, however, and can<br>
find themselves in extended drawdowns. The third category of manager are<br>
somewhere in between those two (macro). We tend to think of these in<br>
groups, even where managers don't fit perfectly.<br>
<br>
1. Set limits that are position-specific<br>
<br>
The first step is to specify individual position limits. In my more<br>
specific case, where I'm allocating with actual managers (as opposed to<br>
the EDHEC indexes in the 2012 presentation), those may come at the:<br>
- individual level (e.g., no single manager can represent more than 15%<br>
of AUM) or<br>
- group level (e.g., no group of managers using Systematic strategies<br>
can represent more than 30% of AUM).<br>
There may be a specific direction of change:<br>
- Managers may not be able to accept additional capital, so that the<br>
position may only be reduced from current levels;<br>
- Managers may be receiving an allocation subject to a minimum amount of<br>
investment;<br>
- Positions may be subject to gates or lockups such that the investment<br>
may not be decreased; or<br>
- We simply don't want too much manager risk, so that if they imploded<br>
our losses would be limited to the amount invested (e.g., 10% of<br>
capital).<br>
<br>
These may be specified across all funds, for a sub-set of funds, or for<br>
each individual fund. In my specific case, I have an individual maximum<br>
for each type of manager (e.g., a sector specialist may be no more than<br>
10% of the portfolio). I am not setting limits to the group today, but I<br>
may want to in the future (e.g., no more than 60% to the sector<br>
specialists). I usually have a minimum investment level below which I<br>
want to drop the investment (usually I want a position larger than 1-2%).<br>
I can't short in this portfolio (individual weight must be greater than<br>
0%).<br>
<br>
2. Set limits that are portfolio-specific<br>
<br>
I have different sets of constraints around the sum of the portfolio<br>
weights. In some cases, all my managers' weights must sum to (about)<br>
100%. In this particular case, I can add leverage in such a way that the<br>
sum can be greater than 100%. There's always an upper limit to that<br>
leverage as well (e.g., no more than 200%).<br>
<br>
I also want to target a particular portfolio volatility (>10%), with the<br>
view that volatility is also an element of upside potential. In this<br>
case, competitive products have a volatility between 10-16%, and since<br>
investors use a heuristic of fees relative to the level of volatility I<br>
want to make sure the portfolio volatility is roughly in that range.<br>
<br>
<br>
So far, all of these issues represent constraints in the context that<br>
Brian already discussed, in that they:<br>
- operate only on the weight vector (or a calculation of its components);<br>
- may include metadata about the components (the type of manager); or<br>
- describe the inputs to the objective function (target portfolio<br>
volatility and/or return level).<br>
<br>
3. Choose measures for constructing portfolio objectives<br>
<br>
>From there, I then have a variety of measures by which I want to evalute<br>
(rank) portfolios. An objective may be composed of several measures,<br>
which then have to be combined in a way that makes sense. That is, the<br>
measures may need to be normalized such that they relate to one another<br>
proportionally.<br>
<br>
I may want to vary my objectives by the amount of estimation I'm required<br>
to do:<br>
<br>
- if I don't want to do any estimation, I can think about a 1/N<br>
portfolio. That's also a good benchmark to determine whether I can add<br>
value in portfolio construction; OR<br>
<br>
- if I believe my volatility estimate, then I want a 1/sigma portfolio; OR<br>
<br>
- if I have confidence in both my volatility and correlation estimates,<br>
then I'm able to calculate:<br>
+ minimum variance or minimum CVaR portfolio;<br>
+ equal volatility or CVaR contribution portfolio; OR<br>
<br>
- If I have good estimates for higher moments, I can do the same with<br>
modified CVaR; OR<br>
<br>
- If I have an estimate for mean return I can examine the tradeoff<br>
between return and risk (e.g., MSRP).<br>
<br>
As we move down this list, additional estimates are required and we lose<br>
degrees of freedom. I'm going to ignore the issues of forecast horizon<br>
here.<br>
<br>
In this particular use case, I want to:<br>
- equalize the (ex-ante) contribution of volatility to the portfolio<br>
among it's constituent managers.<br>
- target a volatility level (as described above).<br>
<br>
4. Examine other objectives<br>
<br>
But I also want to understand that portfolio in the context of the other<br>
possible objectives I could have, namely:<br>
<br>
- Equal contribution to:<br>
+ Weight (1/N);<br>
+ Variance without correlation (1/sigma);<br>
! + Variance with correlation; <- my objective<br>
+ Risk (mETL).<br>
- Reward to Risk:<br>
+ Mean-Variance;<br>
+ Mean-mETL.<br>
- Minimum:<br>
+ Variance;<br>
+ Risk (mETL);<br>
<br>
Even though I have a preference for one objective, I want to know about<br>
other objectives as well. Those might be considered allocation<br>
benchmarks, but they serve a role as markers (or buoys) in the constraint<br>
space rather than as 'benchmarks' for performance.<br>
<br>
Each of these is best expressed as an objective, of course, since they are<br>
each:<br>
- calculated on a weight vector; and<br>
- describe a portfolio objective for the outcome of the optimization<br>
(e.g., it describes the portfolio that is the minimum variance portfolio<br>
within the constraint space).<br>
<br>
The portfolios when compared this way can reveal some interesting aspects<br>
of the underlying decision - say, when comparing a 1/sigma portfolio to<br>
one calculated with correlation estimates one can see the impact of the<br>
trade-offs made for the correlation among the constituents.<br>
<br>
In my experience, constraints are typically very position-specific and<br>
must be related directly to the data of the instrument in question;<br>
objectives tend to be related to the portfolio in the aggregate.<br>
<br>
<br>
This brief description probably doesn't go far enough into the broader<br>
workflow. It's pretty obvious and it isn't as linear as I'm representing<br>
it, but I'll state it anyway:<br>
<br>
1. organize data<br>
2. describe the data statistically<br>
3. develop methods for construction (broken down in the steps above)<br>
4. get results<br>
5. analyze results<br>
6. interact with collaborators<br>
<br>
This broader context suggests a few more requirements for<br>
PortfolioAnalytics from the user's perspective. One is that the<br>
traceability of the solutions has to be maintained and well documented<br>
(What did I do? Where did the data come from? How were the results<br>
calculated? With what parameters?). We can end up with a great deal of<br>
derived data, and the user will probably need some helper functions to<br>
navigate through it all.<br>
<br>
Second, the results need to be well organized such that they can be easily<br>
compared, especially visually. Currently, this requires a great deal of<br>
manual manipulation to organize the data and make the objectives<br>
comparable. This also requires some thought when specifying objectives:<br>
calculations that need to be done for comparison that don't carry any<br>
weight in the objective itself (e.g., portfolio variance is calculated for<br>
a mean-CVaR objective, but has a multiplier of zero).<br>
<br>
Third, the sensitivity of the results should be addressable. This is<br>
probably a topic unto itself, because it can be manifested in several<br>
ways. Along one of these dimensions is the ability to examine portfolios<br>
that are not the optimal, but are "close-by," in that they rank below the<br>
optimal (e.g., the 10 nearest portfolios in RP).<br>
<br>
Food for thought,<br>
<br>
pcc<br>
<span class="HOEnZb"><font color="#888888">--<br>
Peter Carl<br>
<a href="http://www.braverock.com/peter" target="_blank">http://www.braverock.com/peter</a><br>
<br>
<br>
_______________________________________________<br>
GSoC-PortA mailing list<br>
<a href="mailto:GSoC-PortA@lists.r-forge.r-project.org">GSoC-PortA@lists.r-forge.r-project.org</a><br>
<a href="http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta" target="_blank">http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta</a><br>
</font></span></blockquote></div><br></div>