SetStopLoss() & SetTrailStop() Concurrent Use

[whitmark]

I thought I would restate this as a new thread as it is an important topic that would have been buried elsewhere.

The built-in functions of SetStopLoss(), SetTrailStop(), SetProfitTarget() are common exit strategies that alleviate the need for the strategy developer to focus on tick-by-tick position management processing and instead focus on on-bar-close trading signals. Other advantages of these functions include:

No need to wait until the entry bar is complete before placing a stop, the stop order is set on the next tick after an entry order is filled
Entry, stop and target orders are tethered together via OCO so no open orders are left behind when a position is closed.
Stop and target levels can be changed dynamically during the life of the open position.

A common use case for this type of functionality is to set both a Stop Loss and a Trailing Stop. From my testing, each on its own works fine, however, when I try to use these function concurrently, only the SetStopLoss() will work, regardless of the sequence it is declared, and will render the processing of the SetTrailStop() inoperable. As a workaround, I attempted to use just the SetTrailStop() function and then use ExitLongStop and ExitShortStop orders as a Stop Loss, but was not satisfied that I had to wait until the end of the entry bar to place a stop. I know I can make it an update-by-tick vs an on-bar-close strategy but that defeats the purpose of these value-add functions. I have used similar functions concurrently in other platforms, although NinjaTrader may be the first I am aware of to allow the values to be changed dynamically without the need to manage the position details in your strategy code.

Can you confirm that the current implementation of these functions work as I have described and whether any enhancements are planned to enable concurrent operations. I would also ask that the help facility be updated accordingly to reflect this naunce. Many thanks!

Whitmark

[NinjaTrader_Ray]

Your understanding is correct and I will amend the Help Guide. There are not plans to change this behaviour since both SetStopLoss() and SetTrailStop() generate live orders that protect an open position. If both were operational simultaneously for a position opened by the same signal name, you would get real-time order rejections from your broker.

For clarification, both can work simultaneously in the same strategy provided they are acting on different signals names.

[whitmark]

Thanks for the confirmation . . . can you tell I've been putting in some time to get this to work? :) I've been spoiled by the use of ATM strateges both manually and through the ATI that enable:
the setting of stops as soon as possible after an entry order is filled without waiting for the entry bar to close.

the use of stop loss and auto trail functionality to work concurrently using a single stop order

the management of entries, stops and targets using OCO so no open orders are left behind when a position is closed

I hope its not a surprise why those of us that have enjoyed these ATM features (which may have attracted us to NinjaTrader in the first place) now desire to incorporate aspects of this functionality into our NinjaScript strategies for backtesting and optimiztion purposes. I would like to get your thoughts on the following workarounds and their potential to achieve the objectives stated above:

Operate on a CalculateOnBarClose=false basis or tick-by-tick. I don't think this mode is available to NinjaScript strategies or would cause other stability issues. I suspect backtesting / optimization would be extremly slow.
-

Introduce a position management data series at a shorter interval and multiple of the trading signal dataseries that is presented on the chart. For example, a 15 minute chart would also have a 30 second data series linked to it to ensure stops orders are never placed more than 30 seconds after an entry order has been filled and that trailing stops are ratched at 30 second intervals.
-

Create a new built-in function that will manage a concurrent Stop Loss and Trailing stop request and add a single profit trigger too. I would say identical to an ATM AutoTrail with one Step and and a Frequency of one. With this, a single stop order can be managed effectively. For example:

SetStopLossTrailStop(string fromEntryname, CalculationMode stopmode, double stopvalue, CalculationMode trailmode, double trailvalue, CalculationMode profittriggermode, double profittriggervalue);
-
Is there any other way to achieve this using regular orders ExitLongStop or ExitShortStop that would not delay the submission of a stop order?



Your insights on these different potential approaches would be greatly appreciated. Comments from other traders/developers are most welcome.

Regards,

Whitmark

[NinjaTrader_Ray]

Hi Whitmark,

1) A backtest will only run with CalculateOnBarClose == true since only the bar OHLCVT data is known and not all the ticks that compose the bar. Therefore, when running a strategy tick by tick one must be aware that any code that is tick specific may operate different during backtest. However, running tick by tick will get orders to the market quicker since OnBarUpdate() is evaluated intrabar.

2) Although you can add lower time frames to your strategy currently (multi time frame) their does exist a limitation currently by where you can only place orders on the primary bars object (primary time frame). With 6.5 (beta in a few months) we will have removed this limitation and added additional features by where you can handle events such as order state, executions, position changes, connection status changes etc...The SetStopLoss(), SetTrailStop() and SetProfitTarget() methods do work in real-time and will submit protective orders as soon as executions come in, even on partial fills ensuring that your position is protected immediately.

3) This is on our list.

4) Not currently however, with 6.5 we will officially support OnMarketData() and OnMarketDepth() which will also allow the submission of orders and thus you will be able to do what you wish.

[whitmark]

I wanted to follow-up on a couple of suggestions made previously as workarounds to enable concurrent use of StopLoss & TrailStop functionality on the same signal name primarily for backtesting operations. Clients continue to request this functionality based on ideas shaped by similar functionality in other platforms and its availability when using ATM strategies. Since the current SetStopLoss() and SetTrailStop() functionality is spoken for, I wanted to follow-up on the status of the following idea:

Whitmark writes:
Create a new built-in function that will manage a concurrent Stop Loss and Trailing stop request and add a single profit trigger too. I would say identical to an ATM AutoTrail with one Step and and a Frequency of one. With this, a single stop order can be managed effectively. For example:

SetStopLossTrailStop(string fromEntryname, CalculationMode stopmode, double stopvalue, CalculationMode trailmode, double trailvalue, CalculationMode profittriggermode, double profittriggervalue);

I understand this idea (or derivative thereof) is on the list? Any update as to its priority or delivery?

Also, regarding functionality available in 6.5 Ray writes:
4) Not currently however, with 6.5 we will officially support OnMarketData() and OnMarketDepth() which will also allow the submission of orders and thus you will be able to do what you wish.

I realize there are several ways to address this for forward testing/trading (e.g., OnMarketData per Ray's suggestion) but will this work for backtesting that is updated on a OnBarUpdate basis? Please confirm and let me know if I am overlooking a backtestable workaround for concurrent SetStopLoss/TrailStop functionality.

Thanks,

Whitmark

[NinjaTrader_Ray]

OnMarketData() will not work for backtesting.

[whitmark]

Thanks Ray, I assume the same is true for OnOrderUpdate?

[NinjaTrader_Ray]

Thanks Ray, I assume the same is true for OnOrderUpdate?

Incorrect. Only OnMarketData() and OnMarketDepth() are not triggered during a historical backtest since this information does not exist in a backtest. All other event-driven methods are triggered in backtest.

[whitmark]

Excellent . . . thanks for the clarification