January 16


Best Day Of The Week To Trade

By Kevin Davey

January 16, 2017

System: Backtesting

What is the best day of the week to trade? Actually, this is a tricky question – let me explain…

Part of my normal routine is developing new trading strategies. I am always testing new ideas, creating new strategies, and adding the successful ones to my live portfolio. That is what most of my Strategy Factory students do too – producing new strategies is really the lifeblood of any serious systems trader.

Anyhow, the other day I was looking at a strategy I developed. It had a pretty nice walkforward (out-of-sample) equity curve, and it was profitable most years, and even most months. Then I looked at results for each day of the week, and I was shocked. If my strategy did not trade on Thursdays, my backtest profit would increase by over 60%! WOW!

My first reaction was to then adjust my strategy code, and prevent trades on Thursday. My second reaction was to admire the greatly improved non-Thursday equity curve. I was ecstatic! My third reaction was to throw away those results, and stick to the original strategy.


Simply put, I realized I was just optimizing for a day of the week. It did not seem like optimization – after all, I did not run my trading software through any kind of computerized optimization – but it was optimization just the same. I took existing results, and then when I found something better, I accepted the improved results. That is optimization. And that is bad.

Many people do things like this, with either day of the week, time of the day, or even certain months of the year. They will look at results, and then decide what to keep and what to eliminate. Then they’ll go back with their filtered strategy, and bask in the glory of the improved results.

Wrong, wrong, wrong…

Could there be some significance to certain times of the day, days of the week, or months of the year? Absolutely! I am not saying that you can’t develop a strategy that takes advantage of these situations. You just have to do the development correctly.

So, what is the correct way to frame this problem?

Here is what I do…

BEFORE I do any testing, if I think time/day/month matters for my strategy, I’ll develop a hypothesis or guidelines. For example, I might be developing a natural gas system, and I don’t want to get bounced around by the weekly US government energy report (usually on Thursdays), so I’ll just eliminate that from the strategy – no Thursday trading. Or, maybe I’ll make sure all Fridays end flat, to eliminate weekend risk. Maybe I’ll even exclude certain months for stock index futures (the old “go away in May” adage).

The point is I develop the idea before I test it, not after. It is easy to look at results, and then develop a reason why certain periods should be excluded. But that is just hindsight bias – Monday morning quarterbacking.

It is much, much harder to come up with the reason before you test. But it is the right way to do things.

So, there may be a best or worst time, or day, or month to trade your system. But don’t look for that after you test. If you instead come up with your filtering/exclusion approach before you test, you’ll probably get worse results (no more cherry picked results), but those results might just work better going forward.

Do you do things differently? I’d love to hear your comments!

–by Kevin Davey from blog KJ Trading Systems

Kevin Davey

About the author

Kevin Davey is a professional trader and a top performing systems developer. Kevin is the author of “Building Algorithmic Trading Systems: A Trader's Journey From Data Mining to Monte Carlo Simulation to Live Trading” (Wiley Trading, 2014.) . He generated triple digit annual returns 148 percent, 107 percent, and 112 percent in three consecutive World Cup of Futures Trading Championships® using algorithmic trading systems.

His web site, www.kjtradingsystems.com, provides trading mentoring, trading signals, and free trading videos and articles. He writes extensively in industry publications such as Futures Magazine and Active Trader and was featured as a “Market Master” in the book The Universal Principles of Successful Trading by Brent Penfold (Wiley, 2010).
Active in social media, Kevin has over 15,000 Twitter followers. An aerospace engineer and MBA by background, he has been an independent trader for over 20 years. Kevin continues to trade full time and develop algorithmic trading strategies.

  • I sometimes fudge a little. Say I’ve come up with a theory, I’ll then design and optimize over a subset of data. For example, 2000-2009. Then I’ll see how it performs in the out of sample set, 2010-present. I may then have an idea that I think may improve the system. I do NOT test on the entire 2000-present data. I go back and implement the change and optimize on the original set of data. This change must improve results in both the in-sample and OOS sets of data for me to even consider it.

    Not strictly kosher. While I’m not optimizing over the entire data set, I’m still allowing some selection bias in. But I can’t just erase the good idea from my brain! And really, anyone who has looked at a chart more than once is going to have selection bias from historical OOS data. One has to just eventually take a chance with small positions to see if it’s really valid.

  • I think optimization is a good and necessary thing provided it is then applied logically in terms of searching the parameter space. When you don’t isolate variables and optimize then you have no idea if good results are fluke or more likely robust. Fluke would be a spike on a profit graph (or whatever your desired outcome variable is) in the midst of mediocre results. “More likely robust” would be a high plateau region of profit. So in this case, you’d want to plot net profit vs. day of the week.

    I think with day of the week you could make a case for insufficient granularity but this is how I conceptualize the overall approach.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Learn To Code & Build Strategies
    Using EasyLanguage.