Why Over-Trading Quietly Kills a Strategy

One of the more useful failures in this project did not look like a failure at first. I had a selective strategy, the kind that sits on its hands most of the day. I optimized it. The optimized version started trading far more often, and for a while I read that as progress.

It was not progress. It was the strategy losing the exact thing that had made it work.

Why does trading more feel like progress?

This is the part that lands hardest for anyone who has traded manually. Being in a position feels like working. Sitting flat feels like missing out. The mind quietly converts activity into productivity, and more signals into more opportunity.

I felt it when I traded by hand, and I was mildly surprised to find that the same bias can survive the move into code. It does not disappear when you automate. It just relocates. It moves into your choice of what to optimize for, and it hides there, wearing the clothes of a technical decision.

That is the honest version of what happened here. I did not decide to over-trade. I chose an objective, ran the optimizer, and the optimizer gave me exactly what I asked for, which turned out not to be what I wanted.

What did the extra trades actually cost?

Every fill pays something. Spread, slippage, commission. Individually these are the boring line items that nobody writes threads about.

The framing that finally made it concrete for me: on a system that trades a few times a day, costs are a tax. On a system that over-trades, costs are the story. A tax you can absorb if the edge per trade is large enough. A story you cannot argue with.

The added trades were lower quality than the original set, and each one still paid the full toll. So the account bled out through the cost line while the headline statistics still looked respectable.

I had been treating fills as effectively free, if not on the spreadsheet then in spirit. Real tick data ended that illusion quickly. In the Dquants engine I developed every fill now has commission, spread, and slippage subtracted before I read a single profit and loss number. Costs go in first, not last. If a result only survives when you model fills generously, it is not a result.

Your broker is a counterparty on every single trade. Model that, or it models you.

How can a high win rate hide a losing system?

The uncomfortable detail is that the win rate barely moved. It still looked fine.

A win rate tells you how often you were right. It tells you nothing about the size of being wrong. A system can win most of its trades and still lose money if the losses are large enough and frequent enough, and cost drag makes that arithmetic worse in a way that is easy to miss because it never shows up as a dramatic single event. It shows up as a slow, unremarkable decay.

This is why I stopped reading win rate as a headline number. On its own it is closer to decoration than evidence.

What was the edge, actually?

When I dug into it, the answer was almost too neat. The thing that made the original strategy work was precisely the thing the optimization had removed.

Its discipline. Its willingness to do nothing most of the time.

I optimized the patience out of it and called that an upgrade. Sometimes more signals is just less edge, more often.

I find that genuinely worth sitting with, because it inverts the instinct. Selectivity was not a limitation of the strategy that a better version would relax. Selectivity was the strategy. The rejections were doing the work.

What does this change about how I optimize?

Mostly, what I let the optimizer reward. An objective function that quietly prefers more activity will find more activity, and it will look scientific while doing it. Trade count is now something I inspect on every parameter set rather than something I discover afterwards, and a large jump in trade frequency reads as a warning rather than a feature.

The broader lesson is not about a specific setting. It is that an optimizer has no taste. It cannot tell the difference between an edge and an artifact of the objective you handed it. That judgment stays with the person who wrote it.

What am I still not able to claim?

Two honesty notes belong in this article, because leaving them out would make the story cleaner than it is.

The first is a labelling problem. Parts of my method lean on a volume profile, but the retail feed I work with measures quote activity, meaning how often the price was updated, not actual traded volume. Those are not the same thing, and treating one as the other is a claim I have not earned. So I relabeled it honestly and left it that way until a second source can confirm the structure holds. The MasterVP research workflow reads levels from that volume profile structure, so getting the label right is not academic. It is part of the foundation the product stands on.

The second is sourcing. All of my tick data comes from a single broker's feed. That is enough to study timing and spread. It is not enough to claim an edge is universal. A pattern that is real on one feed and absent on another is a feed artifact, not a market truth, and I will not make cross-broker claims until I have checked across brokers. One data source is a strong opinion, not a fact.

Confident, or certain?

I am confident in the process. I am not certain about any single strategy, and those are different feelings that should stay different.

Confidence comes from the rigor of the testing. Certainty would require access to a future that nobody has. Anyone selling certainty about markets is selling something.

Trust the method enough to follow it, and doubt any forecast enough to risk manage it. The over-trading episode is a small, specific example of what happens when that second half goes quiet: the system stops rejecting, the costs compound, and the statistics stay polite about it right up until they cannot.

MasterVP exists to make that structure visible on the chart so a setup can be reviewed calmly rather than reacted to. It does not remove the need to think, and it has no live track record to point at. What it has is a research process that is willing to publish its own failures, and this was one of them.

---

This article was composed from the KenKem build-log series. Educational purpose only. Not financial advice. Past performance does not guarantee future results.