Practice English Speaking&Listening with: Idea Streams #1 - Traunch Rebalancing Risk Parity

Difficulty: 0

Hi my name is Jared Broad, and I'm the founder and CEO of QuantConnect.

Today we're going to be doing a slightly different video where we're going to be

looking at some of the recent movements in the market and then trying to test

some of those ideas that we've picked from the current trends and themes that

we're seeing and testing them and building a strategy on them in QuantConnect.

So the idea is for us to explore a hypothesis and to test that hypothesis

in the platform, and then see if we can see how it goes and implement it in a

fairly raw way where you can see how we go about the process of debugging and

fixing those challenges and building that strategy from scratch. So there's

probably gonna be a lot of bugs, and I'm going to try and be very transparent about

how we're going about evaluating and building the strategy, and yeah I'm glad

to have you with us. Let's get started the topic that I was interested in

recently was this theory called risk parity. Since about the 90s there's been

a strategy where you do an allocation to stocks and bonds, and depending on the

the breakdown of that you can apparently mitigate your risk. A lot of the funds

which were based on risk parity strategies suffered in the very recent sell-off in

March because the theory is that when the stocks fall bonds normally rise, so

the challenge is though that in March we actually saw stocks and bonds fall

simultaneously. The strategy people claim that it broke down, and that it's

kind of like this underpinning core thesis to all of the robo-advisors that we

see today, and a lot of the very large funds like AQR and Bridgewater they're

all based on this risk parity idea. Let's test that theory and specifically I came

across this fascinating thread on twitter by Corey Hoffstein. He is

suggesting that rather than having a strategy which is just fixed 60/40

between bonds and stocks that you should

actually do rebalancing in small amounts and frequently. Imagine that you

take your $100,000, you put $60,000 into stocks, $40,000 into bonds, and

then a year goes past and your stocks have increased in value, and the bonds

are about the same. So you actually need to readjust your portfolio to get it

back to an equilibrium which is 60/40 in stocks and bonds. A lot of the

questions people ask about this sort of strategy are when do I rebalance? How

frequently do I rebalance? Do I rebalance every day, and how many fees do I get

from rebalancing so frequently? So these are all things that we can backtest.

Let's take this as our thesis that doing traunched rebalances as in you don't

need to rebalance your entire portfolio but rebalance say 1/12th of your portfolio and

do it every month. Do it frequently in relatively small amounts to get the best

performance. So this is based on research published by AQR. We can see here that

depending on the rebalance mechanism you can get very substantially different

results. Using a platform like QuantConnect we can go in, and we

can just set up an easy experimentation framework where we can test all these

different ideas. Let's start there, go to the algorithm lab. The key insight from a

strategy like this actually doesn't change. You have a 60% weighting

on stocks, and a 40% weighting on bonds.

So there's actually no need to do any sort of intraday insight creation or

anything like that. We're just going to keep it very simple

and make a universe which is the S&P 500 via the SPY ETF, and a bond ETF, and then

have a fixed insight that goes for the whole period because there's no actual

change to the strategy. So firstly we want to try and choose a period which

covers as long as possible. Ideally we could get the 2000 crash,

the 2007 crash, and then the current crash that were in now so that we could

see how the strategy performs. This is also probably best tested on a larger

capital base, so we can increase that to a million. Here we can create our universe.

Universe and portfolio construction, and we can pull that from the documentation.

Big fan of not needing to remember this stuff, so you can just paste in a

lot of this from the docs. So this is actually pretty close to what we want, so

here we're going to be using daily resolution because we could be

backtesting very long periods very quickly, and then we want an index ETF, and the

bond ETF. So what should we use as our bond ETF? We want something with a

very long very long track record, and we can go to the ETF DB, and we can see

a listing of whole bunch of bond ETFs. Here we've got the biggest one by volume

here is AGG, so let's open a few of the high volume ones and see which one

might suit us. The general rule of risk parity is to get something which

is more about government Treasury bonds not corporate bonds, so we can skip

the corporate ones here. SHY, okay and then there's no hard and fast rule here

or if there is I'm not familiar with it, but we might pick an ETF which allows us

to test a long period. So AGG is September 2003. 2007 for Vanguard,

and SHY is 2002, so maybe we can use SHY to kick us off.


So we've made a universe, let's just get a basic equal weighting algorithm

running, and then we can come back, and we can start building our

hypothesis after that. So let's go to execution, we just need an immediate

execution model, and we can go to portfolio construction, and to kick this off

let's just use some of the stock portfolio construction models here.

This is just the equal weighting portfolio construction, and we can just throw that in.

In Alpha here we can just take the constant alpha model.

Okay, and then the last one here we don't actually need to set, but just

for completeness let's set the null risk execution. Okay, so this is just the

absolute basic framework algorithm, so we're going to build this framework

algorithm from these stock components and just have a SPY and SHY, and because

of the way that we've coded this we're using an equal weighting portfolio

construction model, so this is going to be 50/50. This is just to get us running,

to get the the basic algorithm running, and actually this won't work

because SHY as we saw has an inception date of 2002. Let's start the backtest

from 2003. SPY has been around forever, so we can start from 2003 and

run a backtest from there.

Alright great. So we're off the ground. We've got this thing placing trades. We

can see here there's an equal allocation between SPY and SHY, and then you can

see down here we're doing a lot of insights, and you can see from the fees

we're doing a lot of trading. The default rebalancing models, the default in the

framework is this daily rebalance, so we can start looking at ways to firstly get

our 60/40 weighting, and then also to reduce the rebalancing so that we're not

doing daily rebalancing and costing $9,000 in fees for such a simple strategy.

Let's start with getting the 60/40, and then we can do the rebalancing fix after

that. Probably a nice way to do this in the framework is to use a model which

ships with LEAN. It's the insight weighted portfolio construction model,

and that will just allocate capital according to the weights that are

assigned on the insights. With a framework model there are these insights that

are generated which are predictions and it's supposed to set the the direction of the

portfolio, and so for this because we have the same allocation forever we can

actually just produce an insight forever that's exactly the same, and we'll say we

want 60% on stocks and 40% on bonds. To do that it's probably easiest to

create our own alpha model. So we can come to the documentation here, and we

can copy just the basic scaffolding.

We can say here risk balance alpha, and we

need to do some work and return insights.

Okay, and then here we're not going to have a whole bunch

of security changes here, so we can just pass, and use this as our new alpha.

We're going to set our alpha as this risk balance. We have here SPY and

SHY, and so this is just a simple array, and this is zero and one, so let's pass

that in because we could have our assets configurable.

So this would be SPY, this would be SHY, and then we need a constructor here

to catch that.

And so we can pass in the two symbols that we want to create a insight for.

Let's save those two.

And then probably because this is going to be a very simple insight,

we can actually just create insights here. So we can say self.insights

equals something, and then we'll have insights here that we can return,

and we'll return them here. So now we just need to create some

insights which are weighted. So we can go to the docs here, Creating Insights,

We can see the creating an insight class here.

Here's an example of creating a weighted insight.

So, insight.price, take this here and paste it in. And so we want to

create an insight of 60% for the risk asset and 40% for the safety asset.

Okay, risk and safe, and then we're running this backtest since 2003 let's just say

20 years, so we're going to say days equals 20 times 365. The idea here is

we're just going to create an insight which lasts for twenty years and is

going to be 60% SPY, and 40% safe, and then we'll do all of the work in our

rebalancing code after that. So, we've created these insights.

Let's return them here.

Let's just do a quick test of that.

Okay, cool. The code's built and running. We haven't finished coding, so obviously

we expect it to not be quite trading the perfect balance yet.

The next step is we're emitting these insights with 60/40,

but we have set here a equal weighting

portfolio construction model which isn't built to respect them. So we have

somewhere in LEAN an insight weighted portfolio construction, so the

best way to find out would probably just be to go to LEAN, and we've got a bunch

of these modules underneath the algorithm framework here. Under

portfolio and then insight weighted portfolio construction model. The Python

implementation here. And you can see we've coded up the implementation to do

a portfolio construction model weighted by the insights themselves.

So we've set that here and test that. Let's see how we go.

Okay cool. Once the backtest is done we should

probably do just a really quick sanity check. So we haven't even started on

doing the rebalancing frequency yet, but we'll get to that. So the first thing we

might want to sanity check is the simple 60/40.

We do some quick napkin math.

Here we've got 9,000 shares filled at $63 dollars for SPY.

9,550 times $63 dollars, and so we're seeing

$600,000 allocated in our first trade to SPY.

That lines up with what we're expecting, a 60/40 weighting, so of the

million dollars in the portfolio when we started the very first trade is setting

it to be six hundred thousand. So it's a good start and then the next point

before we get onto traunching and looking how to optimize this, let's look at

getting the rebalancing under our control. So there was a recent discussion

in the community about this, and we went into a relatively new feature here, so we

can actually now, using the portfolio construction models we can disable the

automatic rebalancing and make it use completely manual rebalancing. The

first step to that is disabling this rebalance on insight changes. So that

means before, typically by default, it would rebalance when an insight expires,

or when you added a new insight to the portfolio. By using this you're saying

don't do any rebalancing on those new insights, and then secondly rebalance on

security changes which is when a new security was added to the universe,

trigger rebalance. So both of those things are disabled.

And then finally the third thing which was discussed here, too, is using a

rebalancing function. A rebalancing function is a function which will return

the time at which you should do a rebalance. So this allows you to build

some sort of rules into for example monitoring for portfolio deviation or

monitoring for some sort of trigger that you want to use to trigger that

portfolio rebalance. So that's just the function, and you can pass it in to

the portfolio construction model, and then when you return a time it will

rebalance on that time. Otherwise if you return none it will continue asking you

until you give it the time to rebalance. We actually have an example here.

Again on GitHub.

You can see here it's simply just passing in the function. So we want

to define the function here in our code.

We can see this rebalancing example function here.

This one's a much more complicated one, but the keys that we

need to take away is that it has a time here, and you can return none. So let's

just copy something simple here. Constantly return none. Sometimes I like

to just run backtests to sanity check things. In this case we've changed

our code to prevent all rebalancing, and so a nice sanity check

there would be to run a backtest and see nothing happen. And that way we can

just know that we're in complete control of when the algorithms doing

rebalancing. So you can see even though we've got hundreds of insights

we're not doing any trading whatsoever. That's a great start. We're now

in control of the portfolio, and we're generating insights.

One thing that we might want to check here,

this is emitting hundreds of insights; there are two every single day, and the insights are

for twenty years, so really we don't need to emit thousands and thousands of these,

and it's just a huge waste of energy. Let's update that, so we're going to say..

We're going to detect if we've already emitted the 20 year insights, if we've

already emitted them then just return nothing. Otherwise set our flag, and

then emit the 20 year insights once. The idea would be that we would get rid

of all of this noise that are emitting for years and years, which is presumably

going to slow things down. So let's sanity check that and run a backtest.

Cool, so we see here we've got exactly one prediction for each one, and we've

got one trade here. The very beginning of our backtest, and so that's exactly what

we wanted to do. Now when should we rebalance? This is the key, this is what

everybody's talking about for their 60/40 models. Let's try the basic. What most

people do is some sort of time rebalance of their entire portfolio, and if you

recall the thesis was that to do a time rebalance of 1/12 of the portfolio.

Every month rebalance a fraction, and so over a year period you would be

eventually fully rebalanced. We'll get to that partial rebalance. At the moment, these

insight weighted, all the portfolio construction models that are included

rebalance the entire portfolio, so we can start by simply getting this to go

every month. If we get this going every month then we can work on the

rebalancing a fraction of the portfolio after that. A very simple way to

detect month changes would be to literally detect the month change. We can

also, on all of the portfolio construction models they take date and

time schedule rules, which is automatically handled by QuantConnect,

that when the month changes we can trigger a new rebalance. Just for

simplicity, and so that you can fully see how this is under your control we

can say month, and do this here. Do something like this. Just if..

This is skipping any scheduling rules here, we're just creating this,

initializing this flag at negative one and then it's always a good idea to

handle the starting case, the null case we're here detecting the negative one

and returning the time, and then here we're saying that if the month changes

that the current time changes, then set it and return the time.

Otherwise do nothing. So we would expect this once a month to do rebalancing of

the entire portfolio. So let's see how it goes.

Okay so we have it trading again, and

our rebalancing function is triggering trading, and the though bug that we're

seeing is that it's trading every single day, so we're seeing the same $8,000 in

fees that we saw before. So let's dig into this, and see where I got it

wrong. Look at this. If the month is equal to -1 just return time and

don't do anything else. So we need to set this here. So this will handle our default

case, and then the next time around we'll come through and set this properly. Okay.

Hopefully we see, what we'd expect now is to see the fees drop from $8,000 down to

something more manageable, and then we can verify that with the trades and

check each trade. So already the backtest is finished, we've

seen the fees drop from $8,000 to $500 so we're probably doing fewer trades. cool

And we can come down here, and once it's done.. cool.

Let's look at the trades. Okay on the first of January

we've done some position sizing, and then you see here the first of February, March,

April, perfect. So you can see here the the large trade occurred at the very

beginning, so this is opening our initial portfolio, and then the subsequent trades

are relatively small because it's just a slight rebalancing to maintain the 60/40

split. So that's good, that's a good foundation to build from. We have

relatively low fees, we have monthly rebalancing, we have the 60/40 split.

The last piece here is the traunch rebalancing. So instead of rebalancing

the entire portfolio every single month the thesis by Cory was that the best

portfolios are if you rebalance them a fraction of them every single month. The

expense of rebalancing the entire portfolio is probably too high, and so

you might be able to save costs by only rebalancing a fraction. So it's kind of

like this hybrid of dollar cost averaging where you buy the dips on the

way down and risk parity. So let's see if we can try and get that technology into

this algorithm. So there's nothing built like that ready to go in QuantConnect

for you so the only thing we can do is take the existing portfolio construction

model and try and improve on. Here we're using an insight weighted portfolio

construction model. Let's use that as our foundation and create something off that

to achieve the 10 or 12% rebalancing each month versus rebalancing

the entire portfolio each month. So this is the Python code for the

insight weighting portfolio construction model, and we want to try

and use this as our foundation and build off that. You can start just by

copying this code. So this is all open source, this is inside the LEAN framework

folder here under the portfolio construction models, and so we can come

into our algorithm, create a new file, and we're going to have our own portfolio

construction file here. I always like to delete a lot of the noise, too many comments

for me, so we can trim this down.

Okay cool. Let's just start by renaming this.

We'll call it our traunch portfolio construction model.

Put this here, and we need to import this.

from our code import everything. Sorry. So this is our portfolio file so from

portfolio file input star, so this is gonna be all this, and then before

this is the insight weighting portfolio construction model. So before it

was extending the equal weighting, so unlike the equal weighting the insight

weighted just uses a slightly different weighting, but rebalances the entire

portfolio anyway. So what we're doing here is quite different we're going to

only rebalance a fraction of the portfolio every month, so we can extend

from this and try and tweak it to what we need to do.

The core of how these work firstly it gets the list of active

insights. So the portfolio construction models don't need to worry about

generating those signals they just take them from the alpha model. Then it

goes back to here, and it determines the percent of the portfolio we should

allocate to that asset, and in this particular case it's an array

where we group the insights, and in a double weighting that we assign to those

insights. So we are determining the target percent here, and so in our

example we're going to have a portfolio that was say started out at 60%

and then over time it's drifted to 80% on stocks

because the stocks have gone up in value, so we need to find the difference there,

so we need to find 80 minus 60, and the 20% that we need to move we

need to do that slowly. So before we were doing all of that 20% rebalancing

in a single traunch, so now we want to try and take this 20% and do it over

a slower period. To do that we can probably start by calculating the

difference here and then get a factor to apply to discount the full move because

we don't want to move the full 20% in one trade. So here we

can even say for example, this is going to constantly say that we want

60/40 on those two insights, and we could actually just edit the results here, so we

could do something on the previous calculations to slow that migration so

that it doesn't occur in a single trade that occurs in many trades. So it's a bit

of an approximation, but I think just multiplying it by a factor to slow it

down would be good enough for our testing. For example this can be

our benchmark, and perhaps we want to pick a specific period which will show

some pretty significant rebalancing. So here if we look at say the period from

September to October 15th or September first. Maybe March.

Yeah March to April 2009. This period has got a very significant rally,

and so it'll trigger a very significant rebalance. So we can probably

see that in the trades from 2009 if we increase this just so that we can get a

sanity check on our our code that it's working as expected.

You can see that here so March to April we see large trades of stocks

both directions in a single month.

We dramatically increase our position and dramatically decrease

it the very next month. So this is a nice example case of the rebalancing causing

churn in the portfolio going one way then the other and triggering lots of

fees when there's only been a very short time, and that's something that this

style of traunch rebalancing might be suitable to to improve.

Let's have a look, keep this in mind. We'll come back to this one here.

We see 480 and then 300 the very next month, -300 the very next month.

Actually, so after doing some thinking about

how this code would look after we try to heck it in to

where we need it to be I think it might actually be simpler in cleaner to leave

the insight weighting portfolio model and to do this with a slightly different

approach. Instead of us adjusting the portfolio targets each

month the portfolio target is relatively static it's 60/40, and the goal is to use

100% of the portfolio. The difference is though that by doing it in traunches were

effectively executing that vision slower. So instead of just executing 100% of it

every single time immediately when the portfolio comes through we're going to try

taking the targeted rebalance, and then reducing that by a factor and executing

that reduction. So the hope is that by doing this by the time the next month

rolls around if there's a big event like 2009 where there was a major rebalance

one way then the other way, because we had that slow rebalance we won't have

made a shift in the wrong direction too quickly. With that slight change in tack

let's go back and revert a couple of these changes. You can delete the

portfolio, our custom portfolio, and then revert this back to the insight weighted

portfolio construction model. That's good. Now we're back to the point where

we have an insight weighted portfolio construction model, and we have this

immediate execution model. So let's do the same thing we were doing here and go

take a look at the immediate execution code. That's all open source here. For this

one actually it is open source, but it's done in C# just for speed.

So you can actually find that.

There you go the algorithm. And so we can just copy this guy, and create a new execution

model in our algorithm. Okay hopefully this is a better track and will keep us

from needing to write some really ugly code.

We're figuring this out on the fly though, so let's see.

We'll just call this the slow execution model.

So the execution models are delivered targets. These targets are what the

portfolio construction model would like you to execute, and then it's up to the

execution model to know and do the actual filling of the the targets that

were given to it. So you can do whatever sort of logic you need.

We have helper collections here like this one, so a portfolio target

collection which is just a helper to hold the collection of those those

targets from the portfolio construction model.

So when targets come in here it can add them to this collection, and then it can

do things like tell you if you're trading in the right order. For

example you might want to sell some shares if we buy others so that you have

enough buying power to place the trades, and that's all handled for you in

these helper methods like portfolio target collection.

Here again this is another helper method, order sizing. You

can get the unordered quantity, so if you pass in the algorithm with this

portfolio in the target that you're trying to execute, it will go and do the

math for you to figure out based on the orders which are open how much of the

target have we got left to fill. We can actually cheat a little bit here, we know

that this is being called once a month, and so we can sort of use that for now

to get this bootstrapped, and see here we're saying we just get the unordered

quantity, and then we place a market order directly for that stock.

What we might want to do instead is simply let's say divide this quantity by

10, and then fill it slowly over time. So one thing that I'm not sure about yet is

this is a daily resolution algorithm. This might be filled over 10 days, or it

might be filled over 10 method calls, and I'm not sure whether or not this

method gets called every day, or whether it gets called every rebalance so we'll

figure that out quickly and then we'll come back and change the code. At the

moment we'll just divide it by 10 so that it fills slowly, and so that we can see

the change in the orders that have been created. Then we can debug what it's

doing exactly. To get a benchmark case because we were making a change in the

execution model let's actually set the immediate execution

model to get our benchmark so we know what we're looking at. Then we can

compare our new execution model to that benchmark.

Okay great.

So we have our benchmark here, we can see a couple of things say here February

the first trade that came in was 126 we sold the bonds, and that's filled

immediately. So let's tweaked it to our execution model.

And just a hunch we'll probably see it fill over the next ten days. So we

will see a slow fill in the the first trade as well the large one, and we might

see a spike in the fees. Wow.

So previous fees rebalancing once a month for about $500. We're up to

$8,000 here. Obviously placing a whole bunch of small trades is going to cost

you a lot of money, so we need to make sure that we're rebalancing every month

and not just causing an increase in trading.

So we need to adjust how that execution model is filling.

You can see the dates here, 2013 August 9th, 10th, 13th, 14th, 15th,

so the hypothesis that the code was running every single day and updating the

execution model is correct. We need to make sure that we do this execution

every month and not just every single day otherwise we're right back to our

daily rebalancing. The core of the traunch rebalancing was that we would take 1/12

of the portfolio and rebalance that. So with the targets that come in these

equate to 100% of the portfolio, and so by dividing it by 10 or 12 here we're

trying to adjust it to to be 1/12 of the portfolio's rebalance every month.

So we can change this slightly so we get the new set of targets at the beginning of

the month. We then allow it to execute a new traunch of the of the rebalancing.

So we'll do the same simple month logic here

if the month is -1 you want to trigger.

And then make sure to save the month.

And return.

And then otherwise if this is a normal rebalancing we'll do the same thing.

if month equal to.. so I've just

made place orders up. We'll create the method in a minute, but it's just doing

the same thing that, we want to do these executions relatively slowly every month,

but start rebalance a fraction of the portfolio.

So let's come to that now.

So we'll come through, this is the execution code which is

called every day, and every time the month changes we'll recalculate the

traunch to rebalance and allow some market orders to go through and rebalance

their traunch.

Alright this looks good, so every month now is going to be getting

the orders, the targets that it needs to fill by the margin impact. So what that

means is it will sell the the ones which need to be reduced first so that

we can free up the buying power. Then we'll get the quantity we need to trade

to hit the targeted rebalance, and then divide that at the

moment by 12 to convert it into a sort of monthly rebalancing, and then send off

the market order for that symbol. This one here is just tidy up, it's just

saying to clear out the targets collection if we've fully fulfilled that

target. There is little differences here which will make a slightly inaccurate,

and I'm not sure if it matters. So for example every month this quantity is

going to be exponentially decaying. There will always be a little fraction that

isn't being rebalanced, so in an ideal world you would literally do 1/12 of the

quantity, and we wouldn't need this. But this way it's appreciating that the

markets probably not going to move in the same direction forever and that

you're going to have changes in what this quantity is requesting.

We'll come back to that maybe we can make that more accurate slightly later.

So let's try this.

And execute.

There is one catch with what we've written, too. First we need to pass

in the algorithm here, and then here if you notice even on the first month this

is only going to be placing one twelfth of the trades that needs to do which

isn't right. We need to, on the first month we need to make the full position

size so that we can compare apples-to-apples, so let's make this

a factor here that we pass in, and we can use that factor in the division.

So here this is divided by one for the first month and then for the subsequent

months we'll do one divided by twelve.

Let's see how this goes.

I'm just going to rename this one here "benchmark". This

benchmark was our rebalancing every single month the entire portfolio, so

we're trying to beat this one. Alright let's see how we go.

Wow, it's smoother than I thought.

Okay good, so we have adjusted the factor that we're using to

rebalance. The first month will rebalance the entire portfolio.

After that we'll only do 1/12 of the portfolio for every 1/12 of the

requested rebalance every time. So here this factor is being passed in to scale

the orders down, and so if we have a look here. Wow 6 trades,

so we've seen relatively low fees and a Sharpe ratio of 1.0, and here we

go back to the beginning you can see as expected we did a massive rebalance on

the 1st of January. Yeah the trades don't look as expected, so let's dig into

this see if we can figure out why. This is our benchmark, every month, and here

was the the target rebalance was supposed to sell SHY and buy SPY, and the

quantities here are relatively small, and then our current backtest it looks like

it's not respecting that at all it's actually increasing the leverage

which is very strange. So let's dig in to that. Presumably this is something

about our execution model and not filling all of its trade.

Well for starters we can see that from the trades that it's processing on February

1st, February 3rd, February 4th so it's not respecting the month rebalancing. That's

number one. That should be an easy one to spot, let's find that, here we go.

If the month isn't equal to the algorithm time month we're placing the

trades and we're not actually resetting our month clock. So now we reset the

month clock we should absolutely be rebalancing once a month. We should be

filling the trades once a month I mean. So let's replace that one. We need to

figure out why the portfolio targets that are being passed in are so huge.

Wait for the trades to finish.

Looks like it might be compounding. Might be some

sort of effect of the portfolio targets growing each month. Let's experiment with

this here. We'll eventually go look at this code, but for now let's experiment by

only adding the targets when the month changes. We don't really care about the

the interim targets, or what I guess is happening is there's 22 trading days in a

month, and the target rebalance here for the first one was 126, so 126 times 22.

It's on that order of magnitude anyway it looks like it's compounding the

rebalance target, so let's just only add the targets to our collection when we

want to actually do the rebalance.

I always like to look up the classes and see how they

work, so you can pretty much find any class of LEAN just

by going to LEAN and looking at search this repository. We've got the test there,

we can look here, and we can find the actual class. There you go. Portfolio target

collection. And so the key thing is here don't get scared off because it's C# it's

just another piece of code, and then you can see here we're adding the portfolio

targets, we're setting the targets for that symbol, so they shouldn't be accruing.

Adding range, we set all the targets for that symbol

We're clearing fulfilled here, this is the code we're calling at the end.

Cool, so look at the actual holdings of that security, and then see whether to remove

that target from the collection.

A lot of other boilerplate code for the dictionary.


So when we do this add range here, we're overwriting any previous targets.

It should be fairly safe. We can actually leave that here as it was before.

Then we can see here that if the month changes we're going to do our place order routine.

Maybe something here about getting the unordered quantity because this is what

gives us the quantity, and then we come down here to see the quantity traded. So

maybe let's see if we can understand how get unordered quantity works.

So, looking up the get unordered quantity, the very last one here is the order sizing,

and the method we're calling as get unordered quantity.

We can find that one here.

It's relatively simple. It's just the target minus the holdings and rounding

it down to the lot size, so it shouldn't be skewing there. Ah there we go.

Just a simple error. Here we're doing divide by factor, so we just need to do

multiply by the factor because otherwise we're going to be scaling up

our quantity. So let's see how that goes.

What we would expect is 1/12 of this to be

the first order in February so roughly 13 shares, 12 or 13 shares.

Let's see where that is.

Our fees are right about where they were before, so we're seeing slight reduction

in fees, and here on the first of February. Oh sorry, jump to the first one.

Okay so here on the first of February 2003

you see about 10 shares filled, and then five SPY. So we jump to our benchmark we

can confirm yeah it's roughly 1/12 and then roughly 1/12 so looks like we are

filling and rebalancing slower than we were before as we'd hoped. So the

thesis here was really that we would for example in the period of 2009 where you

have a very volatile dip and then a very volatile rise that we could see a more

efficient rebalance. So if we can jump to 2009 about halfway.


from yeah, it looks like we've reduced the positions that we're changing

we can compare that to the numbers from 2009 from our benchmark.

So from here to here, this is our test case.

See on March 2nd 2009 we increased our

position of SPY by 500, and then immediately

decreased that to 300. So then over this

period doing the same thing we can see that we increased it by 200 and then

reduced it by 123. So it is slowing, oh sorry it's the other way around.

Oh no there you go, so see here it's SPY, so we increased it by 200, and then we

went on to increase it again by 146. So because it had the time to do the

rebalancing it didn't immediately flip the position over that one month

it was continuing to increase our holdings versus simply just flipping.

Hopefully that's actually reducing the churn and maintaining a little bit of

momentum in those rebalancings.

Let's see how that does in terms of performance.

So we can see the overall trading is compared to the benchmark about the same roughly,

about the same amount of trading. Our drawdown on the benchmark was 35%.

Our drawdown was 32% with our new rebalancing. Just in case it

wasn't clear before the benchmark here I'm using as a monthly rebalance of

everything, versus a monthly traunch rebalance, and so we can see here

the Sharpe ratio is 0.615 versus 0.595

So there is a slight improvement in the Sharpe ratio by doing this traunch

rebalancing. Just for fun let's see if instead of

doing 1/12 let's just slow it down say a third, and see how it goes.

Overall it's about the same fees, same trading, drawdown slightly

increased, Sharpe ratio's decreased, and let's just confirm it's

operating as we expect. We can see here instead of the 10 that was placing

before, now we've jumped up to shuffling 40 and 21 which is

roughly a third of the benchmark which is doing 113 on this first trade.

So you can see that here. 130 versus 63 and on our new one with our factors

you can see it's effectively rebalancing about 1/3 of the portfolio each month.

So that's good, that's a good framework now we can use this to experiment and so

the overall thesis about whether traunch rebalancing

is more effective than a simple full portfolio rebalancing every month seems

to hold up. We saw a reduction in drawdown and a increase in the Sharpe

ratio, so that was kind of the point to test this thesis and see how it went, and

I'm glad that we saw a positive result, and now we have this scaffolding where

we can test portfolio rebalancing and traunch rebalancing in a relatively easy

way just by changing a factor on the algorithm. So I think that concludes this

video. Thank you for watching, and we're going to try and continue this series of

investigating algorithms about the market and about things we're seeing in

the markets every week. So tune in if you've got ideas of current events that

you would like to be covered please let me know in the comments, and yeah look

forward to chatting with you next week. Cheers.

The Description of Idea Streams #1 - Traunch Rebalancing Risk Parity