QC Algorithm Plugin Framework - Open Call For Feedback

The images got down sampled in creating the post: this is the block diagram, and this is the code flow chart.

I've made quite a few variants of these (obviously, much less feature complete) so I'll describe some common concerns of mine:

1. I want to be able to trade the same Security with different sub-algorithms (by managing "virtual" positions that form a real position). Doing this today is pretty complicated and the risk of creating bugs.
2. Related; With several sub-algorithms, there's an issue of deciding which gets access to capital (after all, many all sub-algos want to trade at the same time, but there needs to be risk management interfering here).
3. I've been implementing VWAP and Stand Deviation ("Bollinger band"-style execution models). The problem isn't so much coding them, but rather testing them. How do I know they correspond to live performance on broker? It turns out it's very difficult... (Backtests becoming more accurate w.r.t. fills would be a first step, but that's on the way already.)
4. There should be a simpler way (i.e. higher level API) for stoploss strategy. The API for stoploss orders isn't entirely obvious and it's at either rate complicated to ensure code works (live) when managing multiple orders in the same Security.

The Lean API would definitely become even more productive with additional standard "lego bricks" so to speak.

Maybe I'm missing something, but I cannot see the advantage repect to what Lean offers today. I mean, today you can "...divide a large algorithm into discrete pieces which you could copy & reuse between projects." by using classes for each one of the modules (alpha, Risk, etc.) and those classes (if they are SOLID) can be reused by other algorithms.

Thanks guys for posts:

@Petter - I appreciate that a multi-algorithm setup is tricky today. Ideally that would be another class above the algorithm IMHO -- "MultiAlgorithmFramework()" which takes QCAlgorithms as inputs and handles the cash allocations and routes orders out the bottom. That way each could have its own stack described above and be managed / plugged independently?

"but there needs to be risk management interfering here" - like global / fund level risk management?

Potentially the multi-algorithm-framework could also have a risk control plugin at the bottom before it gets routed to the brokerage.

Now that we've finished the bulk of options and futures we're fixing bugs and will start adding depth everywhere across LEAN. This includes fill models and frameworks like the one above to make LEAN better.

@JayJayD - The key difference would be the plugins would be sharable. If I make a better execution model and share it to the community others could instantly use it with one line of code. This also allows us to make a GUI as all the models will be pluggable and follow defined interfaces. 

Also in the long term we'd like to make a market place of these components; so people could sell proprietary modules.

" Also in the long term we'd like to make a market place of these components; so people could sell proprietary modules."

THAT will be awesome!

Big supporter of the concept of a pluggable trading framework.  

if done right, could allow for great levels of code reuse across the community, leading to increased robustness and the ability to potentially "mix and match" subcomponents. 

Biggest challenge i see is clearly defining to interfaces between components.  Primarily between the  Volatility Model and the Signal Model.  As this is effectively the link between a a suite of indicators to logic that interprets them.

In general, I would like to think about such a system as a graph of components.  Many simple algorithms can likely overlook this construct, however, it can be a very powerful addition.

Also, when considering such a system, I would like to ensure support for both manually defined/tuned algorithms, as well as machine learning based components.

I am specifically interested in a component that could provide online scoring of a Signaling Model.  This could then in turn be used as either feedback to the signaling model for online or batch based learning purposes, or as input to a Risk model evaluating multiple parallel Signaling Models.

Happy to elaborate or discuss these ideas in more detail if there is shared interest from the community.

@Petter Hansson
Robert Carver's book systematic trading answers 1&2 while rolling in kelly criterion. His modular framework written in python is on:

Thanks @WilliamNhongo; we'll take some inspiration and make it better in LEAN.

@Jeffery; "clearly defining to interfaces between components." -- Agree. I tried to define those in the sketch above. The signal model currently defines the output as expected return for an asset and variance of that outcome. This should be generic enough for  genetic and literally implemented strategies.

"input to a Risk model evaluating multiple parallel Signaling Models" -- interesting; that could be a good way of allowing an algorithm of algorithms. 

@WilliamNhongo: Interesting, I will have a look. It's definitely something that must be a very common problem with several open source solutions like this one.

@Jared: If I could somehow run several QCAlgorithms simulanteously (with some coordination layer) that would definitely be a quite clean solution.

By risk management, I was hinting at smart capital allocation that can e.g. limit how much capital is invested in a single security, even if all my sub-algorithms individually indicate that security should be invested into. Sorry if I'm misusing the term.

Just to reiterate on what I'm looking for: The ideal for me as an independent trader is if I can spend most of my time on alpha generation and not have to bother building my own execution and risk management code. Alpha generation is a difficult enough topic as it is.

On a side note, my most recent framework looks like this:

MyAlgorithm: Subclass of QCAlgorithm, "Server provider"/god class. Can be regarded a singleton at present.

Tradable: Wraps a Security since actions on a Security must be coordinated anyway.

Strategy: There are 1+ strategies per Tradable, currently having a strict prioritization scheme where only one strategy is enabled per Tradable only. It would obviously be better to allow multiple strategies.

A strategy requests a volatility adjusted capital allocation, determined by MyAlgorithm depending already allocated capital and some other factors.

Having multiple QCAlgorithm subclasses/instances instead of Strategy would be way cleaner I think because there is a large risk of strategies colliding when they are observing and manipulating their Tradable/Security (they might need to observe it even when disabled).

good idea

If you can make it like Lego Mindstorms visual programming, that would appeal to a very wide audience, esp those without coding experience. Basically building a strategy using a flow-chart interface and building with drag and drop elements.

Seems like you are biting off more than you can chew.

One thing that I would *love* to see is the following extensions added to the existing Portfolio class:

For most new users, capital allocation (position sizing) and trade execution are cumbersome and boring to write.

They are also highly dependent on your strategy.

For example, my primary focus is a variation of a pairs trading strategy, which involves quite a lot of capital allocation.

Here's some of my pseudo-ish code

Just thinking about this 'plugin' concept some more.

The Lean codebase is an excellent example of a well thought out, well implemented framework.

What I've written on top of the Lean framework, even though it is a sensible group of classes, it is a chaotic mess of code that I would be embarrassed to share.  

strategy: a QCAlgorith subclass, a TradeScore class

a RiskManagement subclass that roughly encapsulates position sizing  & portfolio risk management

trade execution: SwapReason, SwapPair

My subclasses include absolutely *no* data hiding, and here's why:

1) At any point in the path from strategy through trade execution through to exiting a position, I need to be able to collect stats about my strategy so that I can log them later.

If a trade actually does make its way through the strategy => RiskManagement => Execution gauntlet, I then capture my own statistics about what strategy went into that trade. For example, RSI indicator value, Macd values, etc. etc.

Later on (after deciding to exit a position or after a certain holding period), I capture the stats into a record to be logged.

This process includes a *complex* reverse engineering of QC's TradeBuilder.ClosedTrades, especially Trade.ProfitLoss.

In my case, this is complex because I typically am rebalancing a portfolio of stocks using limit orders that are being filled drip-by-drip.

Once the algorithm is finished, I log each of these records stats in .csv format, cut and paste the log into a .csv file, and map the trades against their ProfitLoss in excel using scatter plots.

2) This is a fun project...  Ain't no one got time for data hiding!

In the real world, trading using limit orders sucks, because a limit order from some retail schmuck like me tends to scare away the little fish, and attract sharks.  At this point, writing a competitive trade execution phase seems harder than writing a self-driving car.  You're trading against real-world pros who are out to get you.In the real world, trading using limit orders sucks, because a limit order from some retail schmuck like me tends to scare away the little fish, and attract sharks.  At this point, writing a competitive trade execution phase seems harder than writing a self-driving car.  You're trading against real-world pros who are out to get you.

By the way, my scatter plots revealed ghostly patterns in the noise....  subsequent adjustments = wildly huge Sharpe ratios!  Curve fitting is easy.  In the real world, my algorithm performed worse than SPY over the past 3 months.  Oh wells, glad I wasn't using leverage!)(By the way, scatter plots reveal ghostly patterns in the noise....  subsequent adjustments = wildly huge Sharpe ratios!  Curve fitting is easy.  In the real world, my algorithm performed worse than SPY over the past 3 months.  Oh wells, glad I wasn't using leverage!

When I cut/paste, it pastes twice.When I cut/paste, it pastes twice.

I'm guessing this will extend the University's:  Strategy Example: Complete Algorithm Framework?

Ian we're thinking to design it from scratch with a more wholistic approach. There are a few fundamental differences between the QC University design and this one. We're trying to abstract away the different types of strategies into their core so you could use the same framework for a portfolio based strategy or a single stock scalping one.

I'd love to see the use cases you've got that is driving you to this design. For example:

• Use case 1: I need a global view of current and future risk with my proposed trade
• Use case 2: I need to be able to run multiple algorithms
• Use case 3: etc...