Order Type Implementations

[dysonance]

Implement a Julia type, Order (or AbstractOrder from which more concrete order types could be children, like MarketOrder, LimitOrder, StopOrder, etc.) for storing, processing, and manipulating orders.

This type should be able to interact with a Portfolio object in a highly structured order queue processing pattern. In other words, when a Signal/Rule triggers some market action, it should be communicated through an Order type.

At a broad level I imagine it would look somewhat like this.

1. Indicator function runs computations on raw market data at each time t
2. Signal function fires based on results of Indicator calculations
3. Rule dictates what action to take when the Signal is triggered
4. At time t, when a Rule is processed, it should should output an Order
5. This Order object should then be placed in an order queue to be handled at time t+1
6. Based on the order type logic and perhaps some other settings (e.g. which price to trade at, generally assumed to be the open), at time t+1 all orders should be "processed"
7. This Order "processing" logic should probably depend on a Portfolio object, which should receive a series of Orders and make the appropriate adjustments at time t+1 to the position holdings and update the per-asset portfolio weights

Questions:

• Given an order queue containing some n, how should capital constraints be applied in deciding how to allocate trades under capital budgeting constraints? In other words, if we have $100 in the bank and all of today's orders would have us buying $120 worth of stocks, how should these trades be allocated? Just allocate pro-rata based on the sizes of all the orders?
• How should the above consideration be altered in the face of different asset classes? There should be logic added at some point that is intelligent enough to know that submitting an Order to buy an equity constitutes a cash outflow at time t but that the same does not go for a futures contract. But futures contracts should probably have their own logic as well (e.g. initial margin, maintenance margin, etc).

[alexandrebrilhante]

Some thoughts.

1. This is a classic optimization problem. We can either implement a ressource allocation algorithm or leverage JuMP.jl (probably overkill).
2. Each asset class should have its own logic to avoid confusion.

[dysonance]

@brilhana Thanks for your thoughts! This is something I've been meaning to get back to for some time. I agree that each asset class should have its own logic. Obviously what makes this tricky is getting sufficient coverage for different asset types and the corresponding ordering and portfolio management logic, particularly when asset types are mixed within the same portfolio (e.g. using futures and equities in the same strategy).

The other challenge is creating logic flexible enough to allow different targets/objectives for the optimization problem. I agree adding a JuMP.jl dependency is probably overkill, but what's needed is a good understanding of how to set up the optimization in the right way so that it is useable and flexible.