Protective Orders with IB

[KirkHammett]

Hi!

I have some questions on protective orders with Interactive Brokers:

1. Should I place protective orders from OnOrderUpdate or from OnExecutionUpdate?

I am a bit confused if I should make my protective Orders from OnOrderUpdate or from OnExecutionUpdate with IB. In the Help Guide it says: "When using a NinjaScript strategy it is best practice to only work with passed by value data from OnExecution." So the HelpGuide recommends using OnExecutionUpdate if I understand it correctly. However, in the forum it is recommended to place protective Orders in OnOrderUpdate: When is OnPositionUpdate called? - NinjaTrader Support Forum - see Jim's Post 4

2. From my research in the forum I understood that the Position object (Position.Quantity or Position.MarketPosition) called within OnBarUpdate doesn't have these problems. So using the Position object only within OnBarUpdate should work correctly also with IB, is that correct? To me this seems not logical because it shouldn't matter where I call the Position object since its a matter in which order the code is being executed.

3. Do I understand it correctly that I also have to make a custom calculation for the Average Fill Price while in OnExecutionUpdate or OnOrderUpdate because the Position may be wrong here?

4. How can I get the accurate Account Position from IB directly via code?

5. Are there any other things I should consider because of IB?

Thanks in advance!

[NinjaTrader_Emily]

Hello KirkHammett,

Thank you for your post.

Whether you place protective orders in OnOrderUpdate() or OnExecutionUpdate() is up to you. I understand this may seem like conflicting information between the help guide vs. Jim's post, but the main takeaway is that for Interactive Brokers and Rithmic, the sequence of updates is not guaranteed so you should track your position and place protective orders solely within either OnOrderUpdate() or OnExecutionUpdate(). The idea is to use one or the other and not to have code in both that would require one portion to trigger before the other.

As Jim mentioned, and related to what you may have seen in your research in the forums, using the Position object within OnBarUpdate rarely has problems. I wouldn't say that it doesn't have problems; you should be fine to use the Position object within OnBarUpdate although if you would like to have extra security you could also use other events to keep track of your position. You could even track position updates through other events such as OnOrderUpdate, OnOrderUpdate, OnExecutionUpdate, and OnPositionUpdate and place Print() statements in your script to compare tracking the position via those methods with tracking the position via the Position object in OnBarUpdate to get a better understanding of this concept. OnPositionUpdate() is called when the position has been updated. While the order that this is called may not be guaranteed, it is typically after the Execution has updated. This is why the Position object is usually correct within OnBarUpdate but due to the API with Interactive Brokers it is possible for OnPositionUpdate() to be called in a different order. You could see Jim's example from post number 4 at the link you mentioned where he keeps track of _CalculatedPosition in OnOrderUpdate(). This is not a way to get the account position from IB directly (that is what happens when OnPositionUpdate() is called), but it is a way to keep track of the position based on order update events and when orders are filled the calculated position is adjusted accordingly.

There aren't necessarily any other things to consider because of IB, it is just important to keep in mind that the Connection Adapter may sent event updates in different orders. It is not reliable to count on Order, Execution, and Position updates to come through in that order so it is wise to keep your code consolidated within either OnOrderUpdate() or OnExecutionUpdate() and not add logic in both that relies on those updates in a specific order.

Please feel free to reach out with any additional questions or concerns.

[KirkHammett]

Hi Emily!

Thanks for your response. I understand it better now I think. However, the Help Guide says the following in the OnOrderUpdate Section: "Critical: If you want to drive your strategy logic based on order fills you must use OnExecutionUpdate() instead of OnOrderUpdate(). OnExecutionUpdate() is always triggered after OnOrderUpdate(). There is internal strategy logic that is triggered after OnOrderUpdate() is called but before OnExecutionUpdate() that can adversely affect your strategy if you are relying on tracking fills within OnOrderUpdate()".

Am I really safe using OnOrderUpdate for my protective orders like Jim suggests in his post? What can "adversely affect" the strategy if I rely on tracking fills in OnOrderUpdate?

Thanks in advance!

[NinjaTrader_Emily]

Hello KirkHammett,

Thank you for your reply.

That statement says, "OnExecutionUpdate() is always triggered after OnOrderUpdate()" which is the case for providers other than Rithmic and Interactive Brokers. Because the order of events is not guaranteed with Rithmic/IB, that statement does not apply. As long as your logic is isolated to either OnOrderUpdate() alone or OnExecutionUpdate() alone you would not be subject to the internal strategy logic that is mentioned. The whole point of isolating your logic to either one method or the other is to avoid any adverse effects from the order that the methods are called or the possibility of them being called in an unexpected order, as there is no guarantee that Rithmic/IB would call updates from Order, then Execution, then Position as is typically expected from other providers.

Thank you for your patience. Please let us know if we may be of further assistance.