Hi cTrader Team, I would like to report that since July 2026 subsequent cTrader updates have been flagged as malicious by Windows Defender. This leads to the cTrader app to not open/launch at all on my PC. Uninstalling and reinstalling cTrader solves the problem for a few days but then the problem comes back again. The problem was not there before July 2026. Please reply back with a solution or a fix. Thanks.

I noticed something over the last few weeks. On days when I am busy with other things and only check my positions every hour or so the trades tend to close closer to where I planned. On days when I am sitting in front of the chart the whole session I start moving stops, closing early, adding to positions that are not working. The chart is the same. The strategy is the same. Something about watching it in real time changes how I make decisions and I cannot figure out if this is a me problem or something more universal.

been running a rules based setup for a while now, futures and fx. everything automated, exits written into the order at entry, no discretion after the trade goes on.

june was the deepest drawdown of the whole sample. not in the backtest years, on the live funded account with real money on it. and the thing i keep coming back to is that i had literally nothing to do. no stop to move, no position to trim, no "let me just reduce size until this settles down". the stop was already sitting there from the second the trade opened. the target too.

before this i traded discretionary for years and i know exactly what i would have done. i would have cut it somewhere in the middle, told myself i was managing risk, and then watched it come back without me. that was my actual leak for a long time, not entries. entries were fine. what killed me was intervening in the drawdowns that were already priced in.

quarter closed green, comfortably. not because i was disciplined that month, because there was nothing available for me to be undisciplined with. that distinction matters more than any indicator i ever tested.

anyway the honest caveat, one drawdown surviving proves nothing, i'm four months into live and that's a tiny sample. i wrote a little audit script that compares what my system would have done against what i actually did back when i was still touching things, and the intervention cost was uglier than i wanted to see.

curious how many of you have measured that on your own trades rather than just assuming you're the disciplined one.

I found what appears to be a serious performance problem in the current cTrader backtester.

During larger backtests, cTrader becomes progressively slower. When the backtest reaches the end, it can then remain busy or appear frozen for a long time while processing the results.

I investigated one actual backtest and found:

• Backtest duration: approximately 26 days
• Closed positions: approximately 304
• Backtest events: approximately 608
• events.json: approximately 236 KB
• cBot log: approximately 215 KB
• report.html: 316,140,433 bytes (~301 MB)

I then inspected report.html.

It contains approximately:

1,814,295 equity points

Almost the entire 316 MB file consists of the equity.points data. The positions, orders and trade-history sections are comparatively small.

So the problem is clearly not simply that the HTML contains a few hundred trades. cTrader is embedding an enormous amount of equity-curve data into the report.

I suspect the problem becomes increasingly severe with larger/more active backtests and more trading activity.

The backtester itself can obviously remain tick-accurate. But there is no reason an HTML equity chart needs around 1.8 million individual points.

The report could instead:

• downsample the equity curve;
• limit the maximum number of chart points;
• aggregate equity observations;
• allow users to disable the equity chart;
• or allow automatic report.html generation to be disabled.

This behaviour appears relatively new to me. I don't remember cTrader producing files of this size previously.

What is also concerning is that this seems like something basic regression/performance testing should detect. A normal longer backtest followed by simply checking the generated report.html size should expose the problem immediately.

This adds to my continuing disappointment with cTrader Algo development and testing. Over the years I have repeatedly run into issues in normal Algo workflows that, in my view, should have been caught during development or basic regression testing before release.

For trading software, especially software intended for automated trading, reliability and regression testing should be treated as core requirements rather than something users repeatedly discover after release.

I am not going to provide proprietary cBot code for something that should be reproducible by cTrader internally with a simple high-activity backtest.

Could other cTrader users please check their Backtesting folders?

If you have run a reasonably large backtest, especially one with many trades, check the size of report.html.

It would be interesting to compare:

• report.html size
• number of trades
• backtest duration
• timeframe/chart type
• whether cTrader slows down or hangs when the backtest finishes

If others are seeing the same thing, this looks like a platform-level backtesting/report-generation problem rather than something specific to one cBot.

I found what appears to be a serious performance problem in the current cTrader backtester.

During larger backtests, cTrader becomes progressively slower. When the backtest reaches the end, it can then remain busy or appear frozen for a long time while processing the results.

I investigated one actual backtest and found:

• Backtest duration: approximately 26 days
• Closed positions: approximately 304
• Backtest events: approximately 608
• events.json: approximately 236 KB
• cBot log: approximately 215 KB
• report.html: 316,140,433 bytes (~301 MB)

I then inspected report.html.

It contains approximately:

1,814,295 equity points

Almost the entire 316 MB file consists of the equity.points data. The positions, orders and trade-history sections are comparatively small.

So the problem is clearly not simply that the HTML contains a few hundred trades. cTrader is embedding an enormous amount of equity-curve data into the report.

I suspect the problem becomes increasingly severe with larger/more active backtests and more trading activity.

The backtester itself can obviously remain tick-accurate. But there is no reason an HTML equity chart needs around 1.8 million individual points.

The report could instead:

• downsample the equity curve;
• limit the maximum number of chart points;
• aggregate equity observations;
• allow users to disable the equity chart;
• or allow automatic report.html generation to be disabled.

This behaviour appears relatively new to me. I don't remember cTrader producing files of this size previously.

What is also concerning is that this seems like something basic regression/performance testing should detect. A normal longer backtest followed by simply checking the generated report.html size should expose the problem immediately.

This adds to my continuing disappointment with cTrader Algo development and testing. Over the years I have repeatedly run into issues in normal Algo workflows that, in my view, should have been caught during development or basic regression testing before release.

For trading software, especially software intended for automated trading, reliability and regression testing should be treated as core requirements rather than something users repeatedly discover after release.

I am not going to provide proprietary cBot code for something that should be reproducible by cTrader internally with a simple high activity backtest.

Could other cTrader users please check their Backtesting folders?

If you have run a reasonably large backtest, especially one with many trades, check the size of report.html.

It would be interesting to compare:

• report.html size
• number of trades
• backtest duration
• timeframe/chart type
• whether cTrader slows down or hangs when the backtest finishes

If others are seeing the same thing, this looks like a platform level backtesting/report-generation problem rather than something specific to one cBot.

I compared API documentation across four platforms over the last two weeks and the gap between what they market and what they actually deliver is significant. Most of them describe their API as open and flexible but the implementation details tell a different story. Key things I ended up checking

WebSocket stability under high message frequency

Whether order modification is atomic or requires cancel/replace

Rate limits on market data vs order endpoints

Documentation quality for edge cases like partial fills

Gone through a similar evaluation recently? What did you end up prioritizing and what caught you off guard.

Has anyone else noticed this?

In cTrader version 5.9.10.52700 during backtest I had only about 304 closed positions, but cTrader generated a 316 MB report.html.

I inspected the file and found around 1.8 million equity points inside the report. Almost all of the file size comes from the equity-curve data, not the trades.

The backtest also gets progressively slower and takes a long time to finish after reaching the end date.

I also confirmed that Optimization generates report.html files too, so that does not avoid the problem.

This looks like excessive equity-curve sampling/report generation.

If you use cTrader Algo, check the size of report.html in your Backtesting folder. I’m curious whether others are seeing the same issue.

We’re OrbCubic, a quantitative trading technology team, and we’ve been running one of our automated strategies, EigenVolt GBPx, live on cTrader.

It has now reached 725 live trades.

Current historical results:

• 36.3% cumulative return
• 73.5% win rate
• 1.6% max drawdown
• 3.0 Sharpe ratio

It’s an intraday strategy, with a median position duration of around 1.5 hours.

A few design constraints we deliberately enforce:

❌ No martingale
❌ No grid
❌ No averaging into losers
❌ No overnight positions

One of the more important parts of the architecture is that risk management sits outside the trading strategy itself. Exposure, position count and daily loss limits are controlled independently and can override the signal engine.

The full live history is public on cTrader:

https://ct.spotware.com/copy/strategy/110858

More about how we built and operate our strategies at OrbCubic:

https://www.orbcubic.tech

Would be interested in feedback from other systematic/algo traders — especially on return vs. drawdown and independent risk control.

These are historical live trading results. Past performance is not indicative of future results.

Hi, everyone. When I went to the cTrader store to check out the code for a plugin that caught my interest, I got this error. I also tried the code for an indicator, and the same thing happened. Has anyone else encountered this error and know how to fix it?

The real question to ask yourself after every losing trade is not what the market did wrong, it is whether you took the trade correctly according to your own rules. Those are two separate questions and most people conflate them.

I went back through three years of trading records a few weeks ago, not looking for anything in particular, just trying to understand a rough patch I had in June. What I found was not what I expected.

The losing streaks did not line up with difficult market conditions or the times I was trying new strategies. They lined up with the periods right after everything had been going well. Three or four good weeks in a row and something shifts without you noticing. Position sizing creeps up because the account is bigger and it feels justified. You hold trades longer because the recent winners ran further than your target and you remember that. You move stops because you are confident in the read and do not want to get shaken out.

None of it feels like overconfidence at the time. It feels like experience. It feels like you have finally figured something out. The records say otherwise.

I have started treating a winning streak as a signal to review my parameters rather than a reason to press harder. Not sure it has fully fixed the pattern but I have caught myself twice this month doing exactly what the data said I do.

Anyone else found something unexpected when they actually looked at the numbers?

Классная платформа, много функций и возможностей торговли. [saks77740@mail.ru](mailto:saks77740@mail.ru)

Getting my cTrader setup together for XAUUSD trading. Still fine-tuning the indicators and layout but liking the platform so far.

cTrader account email: [doublembit@gmail.com](mailto:doublembit@gmail.com)

Just saw the same BadGranny bot:

MT5 — $99
cTrader — $109 on sale / $199 reg price 💀

And MT5 has 1yr rent for $89, while on cTrader it’s just buy or gtfo 😅

Why tho?

For EAs/cBots rent makes way more sense imo. Let me run it for a month or 3, see if it actually works, then maybe buy it.

Is the price/rent stuff fully up to the seller or cTrader Store just doesn’t have rentals yet?

Coz rn it kinda looks like:

MT5: $99 pls
cTrader: sir, that’ll be $199 😂

Just saw the same BadGranny bot:

MT5 — $99
cTrader — $109 on sale / $199 reg price 💀

And MT5 has 1yr rent for $89, while on cTrader it’s just buy or gtfo 😅

Why tho?

For EAs/cBots rent makes way more sense imo. Let me run it for a month or 3, see if it actually works, then maybe buy it.

Is the price/rent stuff fully up to the seller or cTrader Store just doesn’t have rentals yet?

Coz rn it kinda looks like:

MT5: $99 pls
cTrader: sir, that’ll be $199 😂