IOrder states logic

[misova]

I tried to understand the logic of order states.
I drawed some first diagram for better understanding.
Do you think it is correct? Any improvements/tweaks ?
Thanks for any insights.


--------------------------------------------------------------------------------------
This old image is obsolete now - there is improved version in following replies of this post
--------------------------------------------------------------------------------------

[NinjaTrader_AlexG]

Hello,
Thanks for posting today.

This is a very well done diagram and thank you for your time and effort put into it.

My one critique would be that when a change to order is made this change would go back to the initialization ---> pending Submit ---> Accepted--->Working

Each order and change would go through that process.

Thanks for creating this great resource.

[NinjaTrader_DaveI]

This is great -- thank you very much for sharing.

[misova]

Thank you, I have updated the diagram.

Is there any case, when changed order can goto Rejected state? or this is not possible?

[NinjaTrader_AlexG]

Hello misova,
Thanks for the reply.

A change would be another order essentially. When you request a change it still needs to initialize then pending submit and then may be rejected.

So a change would not be directly rejected until received by the brokerage and then rejected.

[misova]

Handling different OrderState(s) in strategy vs. at exchange

I would like to ask about possible scenarios,
where known order-state in strategy is different as real current order-state at exchange.

It is hard to prepare/simulate this events during backtesting, if even possible.



Question 1: Working Limit order changed (but Filled at exchange in the meantime)
------------------------------------------------------------------------------------------------------
What happens, when strategy changes Working limit order --> but it is Filled during the meantime at exchange? Running strategy is not aware about the fill, so it just moves the order according to the logic of the strategy.

What happens now? Will the changed order be rejected ? What happens or how to solve it in strategy?

[NinjaTrader_AlexG]

Hello,
Thanks for the inquiry.

When an order is submitted is filled at the exchange and if a change order is sent this order will be rejected.

The strategy would be unable to change this as the order was filled at the exchange before the change was received by the exchange.

Please let us know if we may be of further assistance for anything NinjaTrader.

[NJA_MC]

Hi,

This diagram is great, is it possible to add OVERFILLs to this chart? It would be nice to know what causes that error.

Thanks!

[misova]

When an order is submitted is filled at the exchange and if a change order is sent this order will be rejected.
The strategy would be unable to change this as the order was filled at the exchange before the change was received by the exchange.

Understand, the idea, but not sure about this - because the order was filled in the meantime at exchange --> it will be rejected by exchange and gets Rejected status.

Now, it has state Rejected, but in reality, the order was filled at exchange (partially or completely) --> so I would expect it to reflect the reality and have Filled / PartFilled status.

How to understand the mismatch, between reality (Filled/PartFilled) and Rejected ?
I suppose these states should be completely exclusive, are they ?



What looks unclear to me, is the understanding of the Rejected and its various use cases. I understand Rejected state to occur in case when::

A)
New invalid / irational order was submitted - for example buy stop below market price.
In this case there is no fill and this order is completely out of game (is it true ? is it logical to resubmit Rejected order again with different price?)

B)
Existing order was changed to some invalid price, so the broker/exchange denies it. In this case there is no fill also.

C)
Existing order was changed by user, but at the same time filled at exchange. In this case, there IS a real fill.



I naturally expect, that if the order is Rejected, then it should not be filled (partially/fully) at the same time.
And vice-versa, when order is really filled, then does not seem logical to me to be Rejected (as in case C).

I expect these states should be exclusive, because this states drives the logic how developer can work with the order:

• if the order is Filled -> I understand, that it is fully filled and the order cannot be modified/cancelled anymore
• if the order is PartFilled -> I understand, that there is some position, but remaining part can be still cancelled or we can change the price of the remaining part.
• If the order is Rejected -> I expect, it was denied byt platform/broker/exchange and nothing more can be done. We should submit another order, if we want to do anything else.

How does it play together, that order is filled at exchange in reality, but its real status is Rejected? Could you put more light on this please ?




What is also unclear is what really happens, when existing order is changed?
A) technically the old order is removed and new one created ?
B) the existing order is just changed. If successfully, then it will have Accepted/Working status and if not-successfully -> then it will get Rejected status?

Which one is closer to reality, A) or B) ?

[misova]

Hi,

This diagram is great, is it possible to add OVERFILLs to this chart? It would be nice to know what causes that error.

Thanks!

That's good idea - it is real part of the possible results. I will update the diagram and let you know.

I see, there is more complexity, that needs to be added like:

• Overfill (cancelling order was not successfull, because it was filled in the meantime)
• Unsuccessful change of existing order-> that leads to Rejected, because order was filled in the meantime

[misova]

Another question:

Should be Accepted (=accepted by broker) state treated as temporary state (similar to PendingXXX states), that is expected to be moved into Working (accepted by exchange) state ?

If yes (i.e. Accepted is treated like temporary state), then I expect, that we should never call CancelOrder(..) OR ChangeOrder(..) when order is in Accepted state. Reason is that the order may stil be rejected by exchange (even it was accepted by broker). and then there is no sense to cancel Rejected order.
Is it right ?


Are there any cases, when order is stored just at broker (not sent to exchange), so it will remain in status Accepted only ?
I would expect, in this case it could be logical to cancel / change order in this state ?
Is it right ?


Is there any way, how can I distinguish these 2 cases above ?
I mean, if Accepted is just temporary state going to the Working state OR if Accepted is last state, never going to Working ?

[NinjaTrader_AlexG]

Hello,
Thanks for the reply.

Once it is accepted by the broker it will then go to working at the exchange. This order can not be rejected once it is accepted by the broker. Working then means that it is actively being tried to fill.

There is no need to cancel a rejected order as the order can't be canceled since rejected is its final state.

There is a brief moment when the order is accepted and waiting at the broker. This is based on how the broker handles orders being received. Here is a link to a forum post that explains where orders reside. http://www.ninjatrader.com/support/f...ead.php?t=5349

The above link should give you an answer based on the broker you are connecting to your next questions.

Please let us know if we may be of further assistance for anything NinjaTrader.

[misova]

This part is understood now, thank you.

Could you put more light on Comment #9 also please?
There is a problem discussing, that Rejected and Filled status should be exclusive states,
but probably they are not. ..

Thanks

[misova]

As I am reading another forums, I think I start to understand the mechanics of Rejected order state.

I misunderstood: that if order is in state Rejected, then it was refused and could have Filled Quantity. My simple logic said: order was Rejected, so it could not be filled.

But now I start to see my mistake: In reality, order can be in state Rejected could be filled (=have Filled Quantity).

It is most common scenario, that order that was filled is in state Filled or PartFilled, but it can be also in state Rejected.

This is something new for me...

[NinjaTrader_AlexG]

Hello,
Thanks for the reply.

If an order is filled and you attempt to modify the order before the filled status is received the order modification order will be rejected. The original order will be filled and is not rejected.

The modification is the rejection and the original order will be filled.