Cancelling same-price limits in OCO not working?

[JoshDance]

See this video:

http://www.screenr.com/wCv8

I am surprised that after entering 3 separate OCO brackets with 3 separate stop prices and 1 same limit price, that when decreasing the quantity from 3 to 2 for the limit order, that not one of the stops is cancelled. Am I doing this wrong, or is this a bug?

[NinjaTrader_Cameron]

Hello JoshDance,


Thank you for the informative video, I'll let our Support Lead know about this issue as well.

I'm setting up the 2nd part of your video test on my end as well.

However, can you check the Orders tab of the Control Center -> OCO field.

When you increase the quantity do you see those new limit orders take on a new OCO ID, share an existing ID or no ID at all?

Additionally, have you tried placing the Stop order first before the limit?

[koganam]

See this video:

http://www.screenr.com/wCv8

I am surprised that after entering 3 separate OCO brackets with 3 separate stop prices and 1 same limit price, that when decreasing the quantity from 3 to 2 for the limit order, that not one of the stops is cancelled. Am I doing this wrong, or is this a bug?

Actually what you have demonstrated is the difference in the way that humans think and how computers process data. What you described is logical for the way that a human thinks that he is increasing and matching OCO orders, but that is not the way that the processing engine sees it. When you did your first failing scenario,

1. You had one OCO order
2. Then you increased the quantity on one side
3. Then you placed another order as the putative OCO counterpart.

The processing engine saw just that you increased one order and placed another floating order that you declared to be OCO. However, you never placed an OCO counterpart order: you just increased an existing order, and placed a Stop order. Nothing really ties them together in the click context.

IOW, in human terms, increasing the order meant that you placed a new order at the same price (of course, very logical). However, to the processing engine, that interpretation is missing. I am not sure if that is the correct way for the programmers to look at it or not, but it is safe (in programming context, not in trading terms!!! ): no attempt is being made to interpret what increasing an order means, other than the order quantity was increased.

To demonstrate this, do this instead. Create the order in the same manner as your very first scenario: 3 separate OCO orders. Then stack the Limit orders. It will look visually exactly the same as your first failing scenario. Then decrease the order, and you will see that the Stops will be decremented one-for-one.

Now, I understand that that is inconsistent with NT claiming that when you increase an order, they simply add another order to the queue, so as to preserve your place in the queue. If so, then increasing the order should count as placing a new order.

Again, however, in programming terms, that opens another can of worms. The case is clear when you increase the quantity by 1. How about if you increased the limit by 3 say? Do the next Stops match the increase in Limit orders in OCO fashion. If so, how? Remember why we have to switch on and off the OCO function manually as we place matching orders?

Just my $0.02. FWIW.

[JoshDance]

Now, I understand that that is inconsistent with NT claiming that when you increase an order, they simply add another order to the queue, so as to preserve your place in the queue. If so, then increasing the order should count as placing a new order.

Again, however, in programming terms, that opens another can of worms. The case is clear when you increase the quantity by 1. How about if you increased the limit by 3 say? Do the next Stops match the increase in Limit orders in OCO fashion. If so, how? Remember why we have to switch on and off the OCO function manually as we place matching orders?

"Do the next Stops match the increase in Limit orders...?"

Does not matter, IMO.

OCO is on, so any orders created (which increasing the limit does) get that OCO tag, end of story. If I want to shoot myself in the foot and place 3 limits to sell and only 2 stops to sell, that is my problem. Try for yourself, after enabling OCO mode you can place a 2 lot sell limit above the market, and three 1 lot sell stops below the market, turn OCO off, and any fill or cancellation will wipe them all out.

In short, no, I don't remember why we have to switch on and off the OCO function manually... why?

http://www.screenr.com/8mv8

[JoshDance]

Additionally, have you tried placing the Stop order first before the limit?

http://www.screenr.com/9Kv8

Video time of 5 minutes cut me off at the end, what I was going to say is this:

When you place a new stop order with the middle mouse button on a price with an existing stop, you have created a separate order, and it behaves as expected. We can't do this with limit orders, as left-clicking the price selects all orders at that price to move them. Changing the quantity of a stop order via the selector (as opposed to a middle mouse click) actually modifies that order, not add a new one, so that behavior is as it should be I think.

Seems logistically that since new orders are created by increasing quantity, that this should behave differently than it currently does.

[koganam]

...

In short, no, I don't remember why we have to switch on and off the OCO function manually... why?

http://www.screenr.com/8mv8

From the NT Help text:

NOTE: It is important to reset the OCO indicator after the completion of submitting an OCO order group otherwise you may run into problems where orders are rejected due to usage of duplicate OCO id values.

[NinjaTrader_Cameron]

JoshDance,

Thank you for the update and the new video.

I noticed with my testing that it was behaving as your first example.


As you demonstrated towards the end of the second video, the middle-mouse press to add a Stop Market order allows you to place multiple orders at the same price. However, when you left click to place another limit order, it uses lets the Order Modification functionality take over.

In terms of a work around to have multiple 'targets' or limit orders at the same price, for now, enable OCO place a Limit order at a different level then place your Stop, so they have the same OCO ID, then modify the Limit order to the price.

koganam, has hit the functionality right on the head, but I'll have our Development Team look this thread over to add any further clarification.

[JoshDance]

From the NT Help text:

Since OCO functionality is all locally simulated (for most brokers anyway), I cannot think of a scenario when an order would be rejected due to a duplicate OCO ID--can you?

[JoshDance]

I'll have our Development Team look this thread over to add any further clarification.

Thank you Cameron, I look forward to this, and hopefully they will see this as important enough an inconsistency to change the current behavior.

[NinjaTrader_Brett]

Josh,

Thanks for the feedback.

I will have it added to our list to review for next major release.

I can see your scenario where this would be advantageous and I can also see another scenario where the user wants to increase QTY of PT and SL and have OCO remain the same which would cause issue as with FIFO optimimzation as a second PT order is submitted on this action and if one profit target fills at the front of the line then the second PT would share the same OCO ID and would try to be cancel the profit target at the end of the line which would not be desired in this scenario.

What I recommend for now if you need this is simply placing the profit target at different prices to begin with OCO linked as you like then stack them on top of each other. It is an extra step but if you needed them stacked with OCO would be what you needed to do.

-Brett

[JoshDance]

Brett, I do see the other side of the argument in favor of the way it currently works now. In fact, it makes quite a lot of sense, and I think stacking as you and others have recommended is probably the most clear way to ensure that it works.