Wrong price sending atm strategy

[Verd991]

Hello, I am having problems with an indicator. The indicator launches entry stop orders with an associated ATM strategy. The indicator in a normal market works perfectly, but when the market is fast and the entry stop order is filled, the ATM strategy is constantly rejected because the stoploss price is not valid. It is not that the market has moved too fast and the stoploss is no longer correct, because the stoploss is wider than that, what happens is that the ATM prices are not sent where they should, and the stoploss being above or below the market is rejected. Why ATM stoploss is sent to a wrong price? And how can it be solved?

[NinjaTrader_Jesse]

Hello Verd991,

That is a normal item that can happen, if you are trading a fast market you generally will need to increase offsets for targets so that when they are submitted they are on the correct side of the market. If you have too small of offsets being used the target could be priced on the wrong side of the market. When orders are submitted they will be submitted at a specific price, if the market moves fast while that order is in the process of being transmitted that price may no longer be valid when the order is processed.

[Verd991]

I understand what you're saying, but that's not the problem. The problem is that the ATM strategy is not sent at the price it should. The stoploss is far enough away that the stoploss is not executed, but for some reason it is sent to the wrong price. Doing exactly the same thing manually there is no problem. The problem is that through the indicator the ATM strategy is sent to the wrong point.

[NinjaTrader_Jesse]

Hello Verd991,

The ATM manages the targets based on the settings you set in the template. I could only suggest to adjust the settings you are using in the template to avoid the order being placed on the wrong side of the market in fast moving markets. If this is only happening in the indicator you would also have to debug that indicator to see why that is happening.

[b.j.d]

NinjaTrader_Jesse I can concur with Verd991 statement on this. This is in fact an issue I have been dealing with for a long time. There is something internal to how ATM strategies are getting the LastPrice of the market that is not closely in sync with realtime, because I have seen many cases where it is attempting to submit stops at a Price that is on the wrong Side of the Market, even when the StopLoss for the ATM has a wide margin, 5, 10 points and stops are attempting to be submitted 5+ points above the last traded prices. There are actually 2 cases of this in the script I just created to help with the Error Dialogs showing this. The Bad Price and then the second error for reuse of the OCO Id for the Targets after the stop is rejected are both logged in my example here:

• https://forum.ninjatrader.com/forum/...35#post1319635

This should be investigated. Sometimes it appears that the ATM Application is trying to use a prior stop price when it is being applied rather then an offset from the realtime prices. This issue can certainly be exacerbated in Playback at higher speeds, but I can concur that the attempted stops were not a price that the market was even near within seconds of the application of ATM; so there is something deeper in that code that needs to be addressed.

[b.j.d]

NinjaTrader_Jesse -- Here's an example where I was able to capture logs showing that the "Current" Bid/Ask/Last was not near the price, even the High of the bar was a tick below where the ATM strategy was trying to place a -5 point StopLoss.

This script also tried to Apply the ATM a second time after 5 seconds. Another Interesting Point about this -- The targets look precise (OCO rejects), e.g. exactly 150 Points Above the Ask in both cases as the ATM dictates. The Stop is however not -5 points below the Bid. This is a bug. If Verd991 and I are seeing it; others are too and it should be fixed.

[b.j.d]

The Failed Log message is being printed about 500ms after the ATM fails to apply (waiting to see the orders created). So it's not precisely when the ATM strategy applies, but close enough. There seems to be about a 1pt offset above/inside recurring in these entries when I see the failures occur. Not sure if that helps diagnose the problem in the code, but seems fairly repetitive.

[b.j.d]

I have been able to reproduce this in Simulated Data Feed, so it is not an issue of fast moving markets (that thing moves dang slow even at full throttle Long). There is a bug in the ATM code in calculating the StopPrice.

What I have witness occurring is that once a position has achieved BreakEven, further applications of the ATM will attempt to use a StopPrice that is on the wrong side of the Bid. E.g. for Longs, the new StopPrice is "BreakEven Offset" above the Bid Price. that's why all the errors above were about 1pt above the Bid, I had a 1 pt @ 4 pts breakeven on that ATM strategy. Changing this to 2 @ 4 in SimulatedDataFeed affirms this behavior. Once BE is achieved, the Stops are trying to be placed 2pt above Current Bid. (See logs below showing the 2pt above Bid affirmation).

Simulated Data Feed appears to have the problems reported in the past of "Lingering CancelPending" orders, which cause ATMs to stay active rather then clearing, so it may be hard to create a scripted reproducible scenario here. But I would ask that you have your dev team look closely around the above mentioned situation with regards to ATMs, how is the StopPrice being calculated after AutoBE, etc. As you can see from my examples above, the Target is precise, but the StopPrice should be 155 points from the TargetPrice (150 + 5 StopLoss). However, due to this bug, (1pt above for BreakEven), it is 149 points.

[b.j.d]

Just pasting this, because the "Stale ATMs" are related to this issue, here you can see I have 4 active instances of the same ATM. Orders that get stuck in CancelPending often cause this, in SimulatedDataFeed I'm seeing them linger even when all orders appear canceled on ChartATM (no Orange Orders), but in the Orders tab it does show CancelPending Orders; this differs from PlayBack or Realtime behavior I see with regards to stale orders. Something related to AutoBreakEven and stale ATMs are likely the scenario that causes this bug.