Updating stop price from an Order.

[NetTecture]

Hello,

sorry to bother - just a confirmation needed.

I am moving my strategy to advanced order handling. Seems to be the only way to reliably handle certain elements.

* Is there any way to update orders? The only way I can see is issuing a new order resulting in a price change. There seems to be no way to send an update based on an IOrder that one got.
* Is the result if the exit commands (ExitLong, ExitShort) guaranteed? I think mostly of timing issues - a limit order getting partially filled, the exit command coming, possibly a fill still coming.
* Is it correct that I can - using those commands - make PARTIAL exits? What else is the quantity parameter for in the Exit methods?

[NinjaTrader_Ben]

Hello,

* Is there any way to update orders? The only way I can see is issuing a new order resulting in a price change. There seems to be no way to send an update based on an IOrder that one got.
>>Yes, cancel the existing and reorder.

* Is the result if the exit commands (ExitLong, ExitShort) guaranteed? I think mostly of timing issues - a limit order getting partially filled, the exit command coming, possibly a fill still coming.
>>It is guaranteed that NT will send the request to completely exit the order if your connection, exchange, broker, etc. are all set up and connected well. However have the request is sent to your broker it is up to your broker how they will handle it. Hope that helps. This link may help:

http://www.ninjatrader-support2.com/vb/showthread.php?t=5349

* Is it correct that I can - using those commands - make PARTIAL exits? What else is the quantity parameter for in the Exit methods?
>>For scaling out please review this link:

http://www.ninjatrader-support2.com/vb/showthread.php?t=3751

[NetTecture]

Ok, lets see.

How much do you guarantee you will send the correct request?

Basically, here is my problem scenario:

* There is a large order to fill a position. Let's say it is buy 100 contracts with a limit.
* The market plays pretty exactly at that position. As the order is large, the market is slow, it gets filled over time. Unlikely, but this is an edge case and there to see how well you did your job with that state engine.
* At one time, the market has filled 66 contracts from the 100 to buy. The Algorythm decides to scrap the deal, says "ExitLong".
* WHILE the orders get send to the broker, another fill arrives, lets say for 5 contracts.

What you do?

Here are possibilities, and sadly you did not provide documentation:

* You send the cancel and sells to the broker, based on the amount currently bought - then you are dead (as in wrong). You have send a command to sell 66 contracts and close the buy, but in the meantime another 5 gut purchased. Not nice.
* You do the same as above, but have special logic to follow up with late fills, then you are fine. Basically, when the fill for the cancelled order arrives, you send another request to sell the 5 surplus contracts.
* You first cancel the buy order at the broker and WAIT FOR THAT TO COMPLETE (and be confirmed from the broker), then the amount of contrats is determined, and then send the according sell commands to the broker.

As you can see, the most simple approach basically has a small timing leak - one I am sure most programmers are not even able to see. Sadly that does not mean it can leave the robot in a bad situation and me loosing money As you have not provided state change diagrams for your order handling, I can not validate that

I actually had a situation where my robot would accumulate - in secondary markets with bad parameters - because fills would come in even after I had asked for all positions to be closed.

If you have a problem in there, then basically it means I Have to recode th ExitLong / ExitShort orders and handle this myself (as per example 1 actually).

[NinjaTrader_Ben]

Hello,

I think your issue is in-flight execution related. Here is our documentation regarding this:

http://www.ninjatrader-support.com/HelpGuideV6/RisksOfElectronicTradingWithNinjaTrader.html

I will have someone assist you further on Monday.

[NetTecture]

I am aware of that.

What I wonder about is how it comes that a professional product like Ninja, for a strategy:

* Does not try to handle such in flight situations itself. I came up with an approach within 5 minutes, sadly I can not implement it due to API problems at NInja strategy levels (i.e. sell / buy something without opening a position to be tracked). The solution? Here it is - once an order is supposedly cancelled, track it on a separate list until it comes so from the broker. All filld you get in the meantime you immediately undo (i.e. sell / buy at market).

* Does not consider it necessary to stop the strategy, flatten out the position, inform the user or even WRITE AN ENTRY IN THE LOG FILE when such a situation occurs - the absolute minimum which I would expect.

This can cost money. This looks like the person planning it - with all respect - should work at Burger King. Hugh glaring oversight.

[NinjaTrader_JoshP]

You need to manage these things yourself. When you submit a cancel the order is NOT cancelled unless you receive a cancelled state back in OnOrderUpdate().

In-flight executions is a reality of electronic trading and you need to program in a manner that minimizes your risks. By this I mean you should NEVER just submit orders and expect that to be it. You should always check states as to what actually happened and address any scenarios like the receiving of additional in-flight executions.

[NetTecture]

Now, and HOW do I manage those?

Dont get me wrong, I have most of the logic in place.

But how can I throw out such a position, if your API blocks me from doing so?

I can not just enter an ofsetting transaction, you know

[NinjaTrader_JoshP]

If you receive an execution the strategy will know about it. All the position methods will be able to let you know the position is there and when a position is open you for sure can use Exit() to close it. Or are you saying you aren't even seeing this position from the strategy at all?

[NetTecture]

Well, the problem is more.... if I cancel an order, how do I get rid of fills that arrive at my placeafter the cancel has been sent?

Example: I have a stop loss, 3 contracts. I decide t oexit at the market, so I cancel the stop loss, exit 3 contracts at the market. Bad news> the market was close, runs against me. THe stop is sitll in the market when it is hit.

Result:
* I am "long" 3 contracts from the market order, which cancel out my original position.
* I am long another 3 contracts from the stop loss.

How do I get rid of those?

To make things more complicated... actually realistic for the scenario i work in.
* I had another entry order to buy another 3 at the market. The business case was: I was short three, with a stop, want to cloe that out, and buy another three.

Good thing, those additional three have another signal (ends in L, not in S on my side).

But in general, how do I close the three surplus long contracts now?

[NinjaTrader_JoshP]

You don't "get rid" of them. They are part of your strategy. You just submit orders to address the scenario. You should be receiving OnExecutions for these orders. If you receive additional OnExecutions on an order that you already know you cancelled then you know its an overfill and you can just send additional orders to close that position.

If you are long 3, send a sell 3.

Secondly, if you are going to cancel an order, you should submit the other order to close the position AFTER you receive cancel confirmation of the first, not before.

[astrolobe]

Josh, can you point me to a sample strategy that handles the possibility of in-flight issues?
thanks.

[NinjaTrader_JoshP]

astrolobe,

Unfortunately there is no reference sample that handles inflight executions. This is a concept that you should keep in mind from the start so to prevent running into problems with inflights to begin with.

So, lets say you had something like ExitLongStop() in place. Don't decide that you just want to close the position and submit an ExitLong() market order. That will raise the risk of inflight executions of the stop being filled right as the market order was received by the brokerage. The brokerage would then continue and execute the market order on top of that stop order and then now you are short.

[r2kTrader]

Josh,

This is really a shortcoming of the broker api then, no?

From what I gathered, we can either buy or sell with certain properties, but they (brokers) don't have a way to say "exit" a long position, rather than just "sell"?

In other words, do we need to manage this granularly because the Broker API doesn't have a method for closing an open position specifically? It would seem that is best handled on the broker side anyway.

Is anything easy? lol.

astrolobe,

Unfortunately there is no reference sample that handles inflight executions. This is a concept that you should keep in mind from the start so to prevent running into problems with inflights to begin with.

So, lets say you had something like ExitLongStop() in place. Don't decide that you just want to close the position and submit an ExitLong() market order. That will raise the risk of inflight executions of the stop being filled right as the market order was received by the brokerage. The brokerage would then continue and execute the market order on top of that stop order and then now you are short.

[NetTecture]

There is nothing the broker can do about it without knowig a lot more about your trading than they normally do.

What please is a position?
* The execution of another order? Bad news - what if my strategy uses multiple orders to add to one logical position?
* All the contracts in a specific symbol? Bad news - what if I trade multiple strategies on the same symbol and they happen to be active in the same moment?

It does not work that easily.

What COULD be done from a trading API level is:
* Have a failsafe close method. ExitLong should not (not sure it does) send a market order, but (optionally? performance may differ) cancel open orders FIRST, then on last confirmation close the position. That STILL Does not solver the issue in reall fast markets and very close stop loss / profit target order situations. I have seen exactly that - stop loss trailing very close, profit target hit, market reverses FAST and hits trail - was a VERY thin market during news.
* Realize when a non-expected execution happens. Basically if I get a fill after cancelling an order, then the fill is not expected. This can be handled in various ways, but an automated mechanism can be provided (got an unexpected +1 fill - well, let`t notify the user AFTER selling one at the market).

After that, there is not really a lot. I dont think the broker would ever do that. THey would have to take a lot more responsibility for that and in their API accept a (string based) "logical position" indicator, so that one could then deal with logical positions. THat simply is not how they ever worked with, though.

[r2kTrader]

NetTecture,

What I meant was, it would seem logical to have a more advanced level of communication between the Broker and trading platform. The API could offer more granularity just as NT offers granularity.

Regarding your concerns, I agree with you. I just think it makes more sense for the broker ot handle some of the advanced issues as this would seem to make the syncing of strategy and broker more reliable.

For example. An api feature that would send an order and then was sent with a tag that would flatten the order if for any reason the broker was no longer able to communicate with the trading platform.

I understand this may be a limit of the exchange, and perhaps I am really saying we should have advanced tags for the exchange which the broker would incorporate into the api. For example OCO comes to mind, or FOK. Couldn't there be other tags which could do some failsafe checking?

I mean after all, they sure as heck don't let you submit an order if the cash isn't on the account, lol, so they have the ability to intercede, lol!

There is nothing the broker can do about it without knowig a lot more about your trading than they normally do.

What please is a position?
* The execution of another order? Bad news - what if my strategy uses multiple orders to add to one logical position?
* All the contracts in a specific symbol? Bad news - what if I trade multiple strategies on the same symbol and they happen to be active in the same moment?

It does not work that easily.

What COULD be done from a trading API level is:
* Have a failsafe close method. ExitLong should not (not sure it does) send a market order, but (optionally? performance may differ) cancel open orders FIRST, then on last confirmation close the position. That STILL Does not solver the issue in reall fast markets and very close stop loss / profit target order situations. I have seen exactly that - stop loss trailing very close, profit target hit, market reverses FAST and hits trail - was a VERY thin market during news.
* Realize when a non-expected execution happens. Basically if I get a fill after cancelling an order, then the fill is not expected. This can be handled in various ways, but an automated mechanism can be provided (got an unexpected +1 fill - well, let`t notify the user AFTER selling one at the market).

After that, there is not really a lot. I dont think the broker would ever do that. THey would have to take a lot more responsibility for that and in their API accept a (string based) "logical position" indicator, so that one could then deal with logical positions. THat simply is not how they ever worked with, though.