Experimenting with buy only on uptick and sell only on downtick

[AlgoJason]

The "SpreadStrategy.cs" is a base class which simulates the idea of waiting for an uptick to fill long orders and for a downtick to fill short orders.

The idea is to account for the bid/ask spread and avoid selling at the ask and buying at the bid.

The "SpreadStrategy.cs" class is intended as base class to derive strategies from.

The "SampleMACrossOverReversion.cs" is a modification of the standard SampleMACrossOver NT example strategy which allows mean reversion.

"SampleMACrossOverReversion.cs" does not wait for upticks or downticks and just submits orders straight away. Because of this, there are many trades where the buy was at the same price as the sell or where the buy was at a bid price and the sell was at an ask price.

The "SampleMACrossOverSpread.cs" is just like the "SampleMACrossOverReversion.cs" apart from it implements uptick/downtick enforcement for trades using the "SpreadStrategy.cs" class.

Backtesting over 1 second bars for 2010 yields extremely different results using the two methods, as expected.

Trading extremely fast, such as a mean reverting 10/25 MACO on 1 second data is expected to generate massive losses due to the BID/ASK spread cost.

"SampleMACrossOverSpread.cs" does generate huge losses (greater than $3M) due enforcing that shorts get filled on the next downtick (which means it is at the BID since we are using Trade/last Tick data) and longs get filled on the next uptick (which means it is the ASK).

"SampleMACrossOverReversion.cs" however, generates a profit (greater than $173K) in the backtest.

I reckon that the profits in "SampleMACrossOverReversion.cs" are artificial and would not occur in live trading. (see .PNG image).

I reckon also that in live trading, the profits would look more like "SampleMACrossOverSpread.cs". (see .PNG image).

I may have made an error or there may be a bug. Who knows.

This is the juice...

SpreadStrategy.cs:

/// <summary>
        /// This is sealed by the SpreadStrategy class. Override OnBarUpdateSpread() instead.
        /// </summary>
        protected sealed override void OnBarUpdate()
        {
            // User can submit orders here just as with OnBarUpdate()
            OnBarUpdateSpread();
            
            // Bars.GetOpen(CurrentBar+1) is the price at which any orders submitted to NT will be filled.
            // Close[0] is 1-tick in the past. NT does not fill at Close[0].
            var newPrice = Bars.GetOpen(CurrentBar+1);
            
            // BUY orders can only be executed on an uptick so the only get submitted if the open of the bar
            // (which just opened and triggered this call to OnBarUpdate()). For this reason we delay the NT
            // submission until there is an uptick. The same applies to SELL orders and downticks.
            if(newPrice > Price)
            {                
                SubmitLongEntries(); // These are BUY orders
                SubmitShortExits();  // These are BUY orders
            }
             
            if(newPrice < Price) {
                SubmitShortEntries(); // These are SELL orders
                SubmitLongExits();      // These are SELL orders
            }

            this.Price = newPrice;
            

        }

SampleMACrossOverSpread.cs:

        protected override void OnBarUpdateSpread()
        {
            if (CurrentBar < BarsRequiredToTrade)
                return;

            
            if (CrossAbove(smaFast, smaSlow, 1)) {
                ISubmit submit = new Submit();
                 if(MeanReversion) 
                {
                    base.SubmitEntryShort(submit);
                } 
                else 
                {
                    base.SubmitEntryLong(submit);
                }
            }
            
            else if (CrossBelow(smaFast, smaSlow, 1)) {
                ISubmit submit = new Submit();
                if(MeanReversion) {
                    base.SubmitEntryLong(submit);
                } else 
                {
                    base.SubmitEntryShort(submit);
                }
            }
        }

What do you guys think? Let's discuss!


Related:

https://ninjatrader.com/support/forum/showthread.php?t=107791

https://ninjatrader.com/support/forum/showthread.php?t=107667

https://ninjatrader.com/support/forum/showthread.php?t=107464

[lonechaos]

can tell u right off the bat, it's a losing strategy since you didn't take into consideration commission cost. 300k+ in trade = $1.2m in commissions.

From people who have successfully deployed algos, if any strategy can't survive commission and at least 1 slippage, it's not worth deploying live.

[NinjaTrader_PatrickH]

Hello AlgoJason,

Thank you for your post.

Can clarify what you are asking for here in this thread? Is this a general question on performance of your two strategies or more geared towards a flaw in executions?

I look forward to your response.

[AlgoJason]

Clarification

Hi lonechaos. Thanks for your reply. My apologies for not being very clear. I should have taken more time to explain. I might make another thread later which will be much more clear about what my question is.

Firstly let me say that NT is a fantastic piece of software and that this is not a criticism of NT. Like any tool, it has to be used with an understanding of what it is doing.

My hypothesis is that

"If we only have Trade/Last data then it seems like a good idea to wait for a downtick before filling a sell order and for an uptick before filling a buy order"

This is probably going to be true if we only have either the bid or the ask but not both, which is always the case with NT.

can tell u right off the bat, it's a losing strategy since you didn't take into consideration commission cost. 300k+ in trade = $1.2m in commissions.

From people who have successfully deployed algos, if any strategy can't survive commission and at least 1 slippage, it's not worth deploying live.

You are correct that a mean reverting 10/25 MACO on 1 second data is a losing strategy after trading costs because it trades extremely quickly. It is a winner if there is no trading costs. I am not proposing this as any kind of viable strategy to trade.

Commissions alone would indeed turn this strategy into a loser, but here I am focused on the Bid/Ask Spread component of costs, its absence in NT simulations and how to rectify that.

My purpose in choosing the fast MACO was to illustrate that the unrealistic fills in NT mean that NT backtests this losing strategy as making money, whereas with more realistic fills, it losses money extremely rapidly.

What is the issue with the NT fills? The issue is that both long and short orders can get filled at the same price, without a spread applying.

This is especially stark if you have Trade data. That data represents the last trade which went through the exchange, where a trader hit the bid or the ask. In this case the price may appear to be changing, but it is in fact not changing. It is just flicking between the bid and the ask.

With this kind of data, NT will unrealistically fill long orders at the bid and short orders at the ask. Essentially an artificial arbitrage opportunity which does not exist in reality.

This is what gives NT an unrealistic fill and results in it saying that a mean reverting 10/25 MACO on 1 second data will not loss money like it is going out of fashion.

The "SpreadStrategy.cs" contains code which delays the call to EnterLong/EnterShort/ExitLong/ExitShort until there is and uptick (for a buy) or a downtick (for a sell) and in this way it may more correctly simulate the reality of the bid ask spread. That is what I want to discuss.

I applied the "SpreadStrategy.csv" (one might call it an extremely primitive "fill engine") to the mean reverting 10/25 MACO and it does indeed show a huge loss which would be expected from the "Bid/Ask Spread Cost". That was an illustration of the principle that I am talking about. That was to reason to chose such a fast trading system.

What I am asking is for a discussion on whether using "SpreadStrategy.cs" gives a more realistic simulation of what might really happen compared to just using EnterLong/EnterShort/ExitLong/ExitShort without waiting for an uptick or downtick as appropriate.

If NT staff agree that it is a more accurate way of simulating then I guess I would next be asking whether they could build this kind of behaviour into NT. But primarily I just want to hear people's thoughts about it and have a good old discussion about it.

[AlgoJason]

Hello AlgoJason,

Thank you for your post.

Can clarify what you are asking for here in this thread? Is this a general question on performance of your two strategies or more geared towards a flaw in executions?

I look forward to your response.

Hi Patrick, please see my reply to lonechaos for clarification.

This question is 100% about a potential flaw executions and a proposal of how to fix it and is not at all about whether or not is is sensible to trade a 10/25 MACO on 1 second data (it is not sensible and nobody should ever do that).

[NinjaTrader_PatrickH]

Hello AlgoJason,

Thank you for your response.

As we discussed at the following link this is due to backtesting on one series: https://ninjatrader.com/support/foru...76&postcount=7

As you noted the fills can occur at any price the series you test hit. The Playback connection allows you to replay the market as it was built with the bid and ask update. If you are looking for realistic fills you may wish to start testing in Playback.
Please visit the following link for details on Playback: https://ninjatrader.com/support/help...connection.htm

We have also added your vote for custom fill engine at the following link: https://ninjatrader.com/support/foru...00&postcount=5

Please let me know if you have any questions.