QuantConnect Community

Hi Fabien,

Yes, that is exactly what happens in the Algorithm Framework. See the attached backtest for a demonstration. To overcome this behavior, the alpha model needs to be made aware of the securities the risk management model liquidates. However, doing so violates the separation of concerns design principle.

Best,
Derek Melchin

So using risk managment models inherently requires breaking separation of concerns?

Not necessarily, but if the PCM is too simple it may result in that behavior. The execution targets set in the execution model should be emptied once they're hit removing the "immediate rebuy" case.

By execution targets are you referring to portfolio targets handled in the execution model? I'm not clear on how that would avoid the rebuy.

Hi Fabien,

Yes, Jared is referring to the targets handled in the execution model's Execute method. To avoid rebuying, we can utilize a custom risk management model which saves the symbols that it has liquidated in the past. This way, if the PCM requests a position in a symbol that the risk management model has previously liquidated, it won't set targets for the execution model to repurchase.

See that attached backtest for the full example.

Best,
Derek Melchin

Hi Derek, do you have any suggestions on how to reset self.liquidated every time new insights are emitted? 

Use case would be:

• Insights are emitted on a scheduled basis (say every Friday)
• Portfolio Model assigns weights, returns target quantities
• Risk Model continuously monitors positions, liquidates above threshold
• Liquidated symbols are saved in a set/dict like in your example to prevent rebuying
• [Once new insights are emitted] Reset self.liquidated and start over

Example:

However this does not work as algorithm refers to the QCAlgorithm object, not RiskTest. 

Got it to work with:

Hi Adam,

We can see in the attached backtest logs that the `liquidated` set is cleared on each call to the ManageRisk method. This causes the algorithm to reinvest in securities immediately after the risk management model liquidates a position, even if no new insights have been emitted by the alpha model. The only workarounds to this problem violate the separation of concerns design principle. We could either move the risk management logic inside the alpha model or just save a reference to the risk management model inside the alpha model. Applying the latter means removing any symbols in the `liquidated` set before the alpha model emits an insight for it.

In this situation, I recommend using the classic algorithm design instead.

Best,
Derek Melchin

Interesting. I think the reason why 'liquidated' is being cleared with every call to the risk model in your example is that EqualWeightingPortfolioConstructionModel is using '.DetermineTargetPercent' which is a function of portfolio value. Thus as portfolio value changes, new targets are set and continuously rebalanced.

Here's a slight modification of your example with a custom portfolio model's '.CreateTargets'. We can see that the workaround I posted above works in this case: 'liquidated' is reset once at the start of the algorithm, hits the stop loss, then remains flat for the rest of the backtest.

Logs:

Here's an example where multiple insights are emitted during a backtest (in this case, every Friday).

In short, the workaround:

can be used to reset the Risk Model when new insights are emitted only if the portfolio model does not change the targets (i.e. via rebalancing) in between insight emissions.

Hi Adam,

Nice catch. Indeed, this procedure works if we utilize the custom portfolio construction model described above. Although, it should be pointed out that if a risk management model relies on the use of a specific portfolio construction model to operate, the two models are still coupled together to some degree.

Best,
Derek Melchin

Agreed. For anyone considering implementing that workaround, please keep that in mind.

Separation of Concerns is a great programming design principle for developing clean modular code that is nicely abstracted (and very reusable via a plug-and-play approach), and I highly recommend users try to adhere to it as much as possible. 

However for financial algorithms, there does often tend to be cases where it is necessary to break this separation to some extent. For instance, an Alpha Model based on computing relative weights of asset holdings in a portfolio does not make sense with an equal weighting portfolio model. Or a trend-following strategy based on some indicator cross-overs might want to set stop losses/targets (risk management) based on values computed by the Alpha Model rather than a fixed threshold. However the abstraction into modules and keeping the coupling to a minimum is still good practice.

What are your thoughts on implementing some sort of optional "state storage" that allows for minimal communication between modules in the Framework? For instance, we define an object StateStorage() that holds certain variables. 

Simple example:

- In Alpha Model, compute something and set the variable StateStorage.stopLossPrice = 1.3 based on confidence

- In Risk Model, we liquidate if price < StateStorage.stopLossPrice

- As new data comes in, Alpha Model updates the variable

Naturally this violates the separation of concerns to an extent, but each module is still concerned with a specific task and at least any breaking (if necessary) is more readily transparent.

I hope we can make the framework fully support all use cases. It does require thinking slightly differently though. The alphas are factors, not responsible for anything related to trading. They are simply setting a prediction of the future.

In your simple example I'd recommend:

 - Alpha Model - prediction and confidence.
 - Risk Model - Confidence Weighted Maximum Drawdown Risk Management Model
 - Alpha Model - continues to emit insights based on new information. The risk model can choose to update its risk exposure or not.

I know its tempting to install a storage/communication system but I think/hope there's always a way to avoid it! 

That makes sense. If i'm not mistaken however, the risk model receives the algorithm instance and an array of PortfolioTargets. Thus if someone wanted to set stop loss drawdowns based on real-time Alpha Model's computations (to let's say, a drawdown % of 1-confidence), how would a Confidence Weighted Drawdown Risk Model work?

"Communication" between Alpha Model/Portfolio Model is feasible and enough for most use cases based on the emitted Insight properties, but between Alpha Model/Risk is a bit unclear.

Hi Adam,

After confirming with Jared, the above is a typo. Instead, it should read

• Alpha Model: prediction and confidence
• Portfolio Construction Model: Confidence Weighted
• Risk Model: Maximum Drawdown Risk Management Model

As explained above, the risk model does not receive insights and thus cannot make decisions based on confidence.

Best,
Derek Melchin

Hi Derek,

Was encountering something similar when trying to use the max drawdown per security risk management model. In the above I saw you mentioned referencing the risk management class in the alpha source. I wanted to ask if this was in regards to maybe importing the risk targets list into the alpha and using that to clear the insights if it is present in the list? Or would there be another way to clear out the insights? 

Or would it be better to call the risk management module in the OnData class of the main algo and clear insights there? My main concern here is that because the liqudate command is in the RM class, the portfolio just reinvests. 

Thanks in advance for your help!

Hi Miguel,

Yes, if the alpha model has a reference to the risk management model, we can choose to only emit insights in the alpha model for symbols that aren't in the risk management model's `liquidated` set. Although, if a framework algorithm violates the separation of concerns principle like this, we recommend resorting to the classic algorithm design instead.

Best,
Derek Melchin