• If this is your first visit, you will have to register before you can post. To view messages, please scroll below and select the forum that you would like to visits. Questions? Be sure to check out the Forum FAQ.


No announcement yet.

Partner 728x90


Backtest NT managed orders are left in state working when reversing position.

  • Filter
  • Time
  • Show
Clear All
new posts

    Backtest NT managed orders are left in state working when reversing position.


    here is a demonstration of the rare but still existing case where NT gets confused and does not either cancel or fill an order during backtesting with managed positions.
    This happens when reversing a position and stop/profit takers are set that will also result in a fill.
    It doesn't make or break a system but it's still a bug.

    In my example I am using 10000 vol bars on CL starting from 01/Jan/2020 non merged and 10 fast 259 slow(times are in EST). If it helps I can supply as many bar/parameter combinations as necessary for reproduction with exact dates.

        public class SampleMABracket : Strategy {
            private SMA smaFast;
            private SMA smaSlow;
            protected override void OnStateChange() {
                if (State == State.SetDefaults) {
                    Description = "Sample MA Bracket";
                    Name = "SampleMABracket";
                    Fast = 10;
                    Slow = 25;
                    // This strategy has been designed to take advantage of performance gains in Strategy Analyzer optimizations
                    // See the Help Guide for additional information
                    IsInstantiatedOnEachOptimizationIteration = false;
                } else if (State == State.DataLoaded) {
                    smaFast = SMA(Fast);
                    smaSlow = SMA(Slow);
            protected override void OnBarUpdate() {
                if (CurrentBar < BarsRequiredToTrade)
                if (CrossAbove(smaFast, smaSlow, 1)) {
                    if (Position.MarketPosition != MarketPosition.Long) {
                        SetStopLoss(CalculationMode.Ticks, 30);
                        SetProfitTarget(CalculationMode.Ticks, 30);
                } else if (CrossBelow(smaFast, smaSlow, 1)) {
                    if (Position.MarketPosition != MarketPosition.Short) {
                        SetStopLoss(CalculationMode.Ticks, 30);
                        SetProfitTarget(CalculationMode.Ticks, 30);
            #region Properties
            [Range(1, int.MaxValue), NinjaScriptProperty]
            [Display(ResourceType = typeof(Custom.Resource), Name = "Fast", GroupName = "NinjaScriptStrategyParameters", Order = 0)]
            public int Fast { get; set; }
            [Range(1, int.MaxValue), NinjaScriptProperty]
            [Display(ResourceType = typeof(Custom.Resource), Name = "Slow", GroupName = "NinjaScriptStrategyParameters", Order = 1)]
            public int Slow { get; set; }

    Hello MojoJojo,

    Thanks for your post.

    It is possible that Historical overfills can occur in managed approach strategy when 3 orders are filled in the same bar.

    Please repeat the test with strategy analyzer's High order fill resolution set to 1 tick.

    Paul H.NinjaTrader Customer Service


      Hello Paul,

      thank you for acknowledging the bug and your advice how a user should deal with it.

      The discerning eye notices that 3 fills on 2 bars happened(but you are right it only looks like it in the chart but not in the log) and that the third order gets the system long. However NT never closes the position an continues as if nothing happened from then on.

      I don't want to exaggerate this bug's importance, it rarely ever happens but it does occur and has an impact. I only noticed it after writing code to verify NT's trade management, luckily most other users will never find out.

      Coming from the team lead I am assuming this represents NinjaTrader's official solution to the problem.
      Last edited by MojoJojo; 07-09-2020, 12:30 PM.


        Hello MojoJojo,

        Historical overfills can happen with Standard Fill Resolution and it is a known limitation. Since the bar data is used to fill the orders, there is a wider range for where the orders can fill. We can encounter cases where one bar fills multiple orders at once which then causes the historical overfill.

        This is seen when using non-OCO orders and when using Standard Fill Resolution. I.E. if we use Enter/Exit methods by themselves or in combination with Set methods.

        Submitting orders to a single tick data series, or using High Order Fill Resolution will have the orders filled with intrabar granularity so the issue would be far less possible to hit.

        Using native OCO with the Unmanaged Approach can work around, as well.

        Improving this for Standard Fill would involve a lot of work changing fragile code, and since there are workarounds, this matter is left for now and we are tracking the impact. I have noted your impact with our tracking ticket SFT-2778.

        Let us know if you have any additional questions.
        JimNinjaTrader Customer Service


          Hello Jim,

          thank you for expounding on the subject and creating a ticket.

          The positive side of my test is that with the rare exception NT's order simulation is reliable.

          Having completed the test new capabilities unlock for me for backtesting strategies in conjunction with the platform.


          Latest Posts


          Topics Statistics Last Post
          Started by jeronymite, Today, 09:26 PM
          0 responses
          Last Post jeronymite  
          Started by ttodua, Yesterday, 06:45 AM
          2 responses
          Last Post NinjaTrader_ChelseaB  
          Started by franco12364, Today, 08:08 PM
          2 responses
          Last Post franco12364  
          Started by smcllr, Today, 06:10 PM
          1 response
          Last Post NinjaTrader_ChelseaB  
          Started by lupearadu, Today, 01:58 PM
          7 responses
          Last Post NinjaTrader_ChelseaB