< All Topics

Avoiding TradeStation same entry/exit issue

The Issue

TradeStation has had a very long outstanding issue in their backtest engine that periodically produces unexpected (and, to me, undesirable) trade results.  This has real-time trading ramifications, too.  This situation is a cross between a “bug” and “valid, but unexpected behavior”.  It is not a bug in the sense that I can report it to TradeStation and ask them to fix it.  I don’t think they would see it that way.  But it does lead to the placement of trades that are entered and then immediately exited, which means you’ll pay the commission/slippage penalty and add complexity to the order process at the trading desk.  I would rather keep the order flow clear rather than unexpected and confusing.

Also, this entry/exit phenomenon is the exact same phenomenon in this true TradeStation bug I reported back in 2015 and remains unresolved to this day.  That makes me leary.  This issue appears to be multi-faceted, which may be why that 2015 bug has not been resolved.

So the consequences are difficult to assess since we don’t know for certain what is happening within the TradeStation codebase.  But it is so simple to avoid and only takes a few extra seconds of your time when writing a strategy.

See this video for a quick demonstration of this issue.

The Solution

The rule-of-thumb is to ALWAYS qualify your trade exits so that they match the current market position.

For example, if you find code that has this (or write it this way yourself):

if  openpositionprofit<-(sloss*ncons) or barssinceentry>=bse then begin
    sell ncons contracts next bar at market;
    buytocover ncons contracts next bar at market;
end;

Change it to this:

if  openpositionprofit<-(sloss*ncons) or barssinceentry>=bse then begin
	if ( MarketPosition = 1  ) then sell ncons contracts next bar at market;
	if ( MarketPosition = -1 ) then buytocover ncons contracts next bar at market;
end;

Here’s another example using stop orders. It would seem to make sense that TradeStation would ignore the stop order that does not apply to the current market position, so having both a long and short stop active at all times seems okay. But it is not and leads to unexpected order interaction depending on the current position or other orders placed on the bar.

So do not do this:

sell ("MW StopLoss-L") next bar at longprice stop; 
buytocover ("MW StopLoss-S") next bar at shortprice stop;

Instead, change it to this:

if ( MarketPosition = 0 or MarketPosition = 1 ) then
    sell ("MW StopLoss-L") next bar at longprice stop; 

if ( MarketPosition = 0 or MarketPosition = -1 ) then
    buytocover ("MW StopLoss-S") next bar at shortprice stop;

If you do not include an IF statement that aligns with the exit, then there may be times within the lifetime of your strategy that produces an unexpected interaction of the trade orders.  The result is that a position will exit, a new position will be created and then immeidately exit again, costing the perforamnce hit of slippage and commission as well as throw off the logic flow of the next strategy signal because of this “order hiccup”.

It also makes me wonder if it is also responsible for incorrect real-time trades, such as missed stops or trades that never made it to the trade desk.

Even if a strategy backtests profitably WITH this unexpected behavior, why risk it? For just a few extra seconds of your time, type out the “If MarketPosition…” and protect the exits from this strange TradeStation behavior.

Example: Dissection of a trade

I dug into one of these same entry/exit trades and compared the orders generated to the orders generated for the solution I proposed above. The results were revealing and clearly demonstrate just why this “phantom” same entry/exit trade was created.

My test strategy was a simple breakout.

Entries were:

if ( MarketPosition <> 1 ) then Buy (“BrkOut-L”) next bar at ExpectedLongEntryPrice stop;
if ( MarketPosition <> -1 ) then Sellshort (“BrkOut-S”) next bar at ExpectedShortEntryPrice stop;

Exits were custom stop loss stop-order and custom profit target limit-order.  These emulate the behavior of TradeStation’s SetStopLoss and SetProfitTarget.  However, using those keywords triggered this TradeStation bug, so I could not use them.

I chose one of the same entry/exit trades and dissected the orders.

Orders WITHOUT my “If MarketPosition…” solution:

The current position was short.

Breakout order:
Buy (“BrkOut-L”) next bar at -1.7582 (ExpectedLongEntryPrice) stop

Profit target orders:
sell (“MW ProfitTarget-L”) next bar at -1.7655 (longprice) limit
buytocover (“MW ProfitTarget-S”) next bar at -1.8369 (shortprice) limit

Stop loss orders:
sell (“MW StopLoss-L”) next bar at -1.8131 (longprice) stop
buytocover (“MW StopLoss-S”) next bar at -1.7893 (shortprice) stop

The two orders in red did not match the current short position, but were included since there was not the IF qualfication to exclude them.

The sell limit order was active on the bar during the short position. When the short position was stopped out, price hit the buy stop at -1.7582, which was above the active limit order at -1.7655, making the limit order trigger an immediate sell.

The two extra sell orders (in red) caused this unexpected condition. It also had the effect of defering the next trade signal, interrupting the expected flow of the strategy.

Allowing only orders that match the current position remove the possibility of unexpected and confusing order interactions.

Orders WITH my solution:

Breakout order:
Buy (“BrkOut-L”) next bar at -1.7582 (ExpectedLongEntryPrice) stop

Profit target orders:
buytocover (“MW ProfitTarget-S”) next bar at -1.8369 (shortprice) limit

Stop loss orders:
buytocover (“MW StopLoss-S”) next bar at -1.7893 (shortprice) stop

Only orders that matched the short position were placed on the bar. This made order flow more sensical and reduced the possibility of unexpected behaviors, like a limit order being immediately triggered. The strategy’s logic was able to continue without interruption.

Table of Contents