I am not sure whether there needs to be any communication between the different strategies.  To me it seems like the need for this communication would be negated by the strategy manager.  Also, I would say that the strategies would all be run on the same thread.  When an event came in, the manager would send the event to all of the strategies (sequentially), which would in turn send trading signals to the manager.  When all the strategies had finished processing the event, the manager would process the trading signals generated by the strategies and trade accordingly.

We would provide a default strategy manager, but probably also allow you to write your own if you needed more customization.

Does it sound like this type of system would address everyone's needs?

Thanks,
Daniel

-Pete
(See also rightedge-ats Yahoo group )

WL/Amibrokers main strenghts lye in this feature and due to the pluggability of .Net, one could even have a standalone "executor" that would run multiple strategies at the same time.

This is still on our feature list, but I have a few ideas for being able to easily run multiple strategies in a single script that I think would work pretty nicely.

I'd start with the normal script, but it would basically just be a shell to instantiate strategy classes, wire up events that would exist in each of these strat classes, and then have a top level order management class to handle allocations to each individual strategy.

Actual coding, at this point, is an exercist left to the reader

If what you mean by the term "strategy manager" is "money manager" then I agree. I'll continue using the strategy manager reference for consistencies sake though. I sort of agree with what you're saying except I'd have the strategy manager work differently. The strategy manager would need to have "intelligence" and the authority to activate/deactive systems and/or markets (for a basket system) based on perfoermance analsysi of each system that is running live. This analaysis would also be the basis of position sizing decisions made by the strategy manager. It would then tell each system what it's position sizing vector is for the next trade.

I think having the strategy manager excute the trade based on signals generated by each system blurs the boundary too much between control and execution.

My real point here is though that they strategy manager's job would be to monitor and manage the strategic performance of the users trading plan in order to manage risk. It would not actually enter any trades just specify their size.

Agreed.

I think specifying what the strategy manager can do is fine (Core Strategy manager). How it would implement it is down the end user to produce the logic(strategy manager extensions). Maybe someone might, as you suggest, want to produce their own completely different strategy manager - that's okay. To my mind the extensions would be where the action is though. Maybe the RightEdge developers could code default extensions which the community can work with and evolve to their own liking. There's no doubt though that this would be an important part of the trading framework.

Some kind of control function is definitely needed IMO.

Thx - D

It may be just a technicality, but to my way of thinking, if the strategy manager is going to size the positions, then it is going to enter the trades.  If the strategy is entering trades directly, then it will ultimitely have control over the size of a position.  You could have a system where the strategy "asks" the strategy manager what size its position should be, and then opens a position for that size.  But then there is no guarantee that the strategy will follow the guidance of the manager, or even call the function to determine what the position size would be.

Basically, I'm thinking that when a strategy calls OpenPosition(), that call will be routed to the strategy manager, where the position size will be determined.  The trade might even be rejected based on risk parameters.  If it is accepted, then the manager will make the call to the broker to open the position.

Perhaps this is pretty much what you were thinking of anyway, but we were using different terms to describe it.

Daniel

The way you're thinking about this seems to be bottom up while mine is top down. I'm confused by your approach somewhat. You almost seem to be suggesting that Systems be relegated to the role of indicator and that the strategy manager be the system. Don't know how wedded your are to this view but the more I thin about it the more I dislike it. Sorry

Thx - D

The way I look at it, consider the case of multiple strategies but only one (shared) pile of money to draw from. How to apportion among the strategies? How to set an upper commitment to a (shared) symbol? How to 'pace' buy/sell to a single symbol? Where best to apply round lots or not? These are all 'distribution of funds' considerations and I see no way to do so optimally except centrally. So I guess I see the dividing line where the strategy aggregates the signal logic, basically down to yes/no, and the strategy manager handles funding and sizing, and issuing and tracking orders.

I know my thinking is incomplete. How, for example, would scaling in and out be accomplished? Still, I thought I would toss these thoughts into the mix just to keep things lively.

Pete

-Pete
(See also rightedge-ats Yahoo group )