Forex Forum - Mobile View

I want to share something practical from live trading that builds on my previous post about XAUUSD and my workflow:
https://forexsb.com/forum/topic/10057/building-robust-eas-on-xauusd-a-structured-workflow-that-works/

This is not about building strategies, but about what happens after they go live and start interacting with each other.

I currently run a group of EAs (for example magic numbers 628, 165, 712 and others).

Most of these robots were built in 2024 in the same week using EA Studio.

They all use different indicators, logic, and entry conditions, so they are not identical strategies.

Over time, and especially once these robots were exposed to real portfolio conditions, I noticed something important.

To be honest, I was not really paying close attention to exposure on the demo accounts in that way.

The reason is simple: at that time I was running 70+ XAUUSD robots per demo account, so having 20 or 30 trades stacked at the same time was normal in that phase.

On demo, I mainly used them to observe broader behavior, metrics, and consistency.

But live is different.

Fewer robots, real money, real sizing, real conditions, and real emotions.

That is where the portfolio-level exposure becomes much more real.

Even though they are different, in live conditions they often open trades around the same time

This does not always happen in exactly the same way.

For example:

628 often opens first
284 (a variation of 628) often opens around the same time, but not always
165 sometimes follows later, but not consistently
712 often aligns with 165 or enters slightly after

So there is overlap, but not identical behavior.

Sometimes only one robot enters, sometimes multiple, sometimes they stack.

At first, this did not seem like a problem.

Individually, the strategies were solid.

They showed consistent behavior across:

EA Studio backtests
MetaTrader tick data backtests
demo trading
live trading

The patterns were very similar across all stages, which is a strong confirmation.

The real issue appeared at the portfolio level.

Because I was running around 8 robots together, all using relatively wide stop losses and no fixed take profit (mostly indicator exits or SL), exposure could build up.

Even with small lot sizes, the combined drawdown can still become significant if multiple robots are in the market at the same time and all use very wide stop losses. That was the real issue. A 0.02 lot size sounds small, but with an extremely wide SL, the loss can still go above 1000 euros if that stop gets hit. So if the market moves against me while 8 positions are all exposed in the same direction, the total exposure becomes too large. That is exactly why I had to interfere against my normal rules and use partial closes, not out of panic, but simply to protect the account.

That is when I started thinking differently.

Instead of rebuilding strategies, I focused on structure and risk.

I asked myself:

what happens if I reduce stop loss and rebalance position sizing?

So I went back and tested each robot individually in MetaTrader using tick data.

I adjusted stop loss values and observed how each robot behaved.

Once I found stable levels, I increased lot sizes accordingly.

This change made a big difference:

the robots started taking more losses, but those losses became smaller and more controlled
when they catch a move, they ride the trend as long as possible
because of that, winning trades have a much stronger impact
overall performance improved significantly

The strategies themselves did not change, but their efficiency inside the portfolio improved.

Another important step was creating variations.

For example:

Robot 628 mainly opens buy trades, with occasional reverse trades depending on the logic.

I used that idea to create a variation (robot 284):

628 → mainly buys
284 → both buys and sells

They are structurally similar, but behave differently.

Sometimes they enter together, sometimes only one enters.

This creates variation instead of full overlap.

On top of that, I added a take profit to robot 284 based on historical behavior.

This allows it to secure gains earlier, while other robots continue running without TP.

So instead of all robots behaving the same, they now complement each other.

At the moment, I run these robots across multiple accounts with different risk profiles (some more aggressive, some more conservative).

What I observe is that they consistently participate in strong movements on gold.

They are not perfect, but they behave in line with expectations.

The main lesson for me is this:

Building good strategies is one step.

Understanding how they behave together in live trading is another level.

Sometimes the biggest improvement does not come from new strategies, but from managing existing ones better.

To make this more concrete, I am sharing a few real examples from my main live account.

Robot 628:
- one screenshot shows the earlier phase, from March 2025 to September 2025, when it was still running with lower lot sizes and wide sl
- another screenshot shows the transition phase, which started around early December, when I began adjusting the structure and increasing lot sizes after testing

Robot 284:
- this is the variation of 628, with both buy and sell behavior and a different role inside the portfolio

I also included a real example of partial closes when exposure became too heavy.

These screenshots do not show the full stack of all robots, but they do show the kind of live behavior that led me to rethink the overall portfolio structure.

What you’re describing is actually very common, and I ran into the same problem before.

The issue is not really the OOS itself, but how it is used.

If you generate on a full data range and then select strategies based on OOS performance inside that same range, you are still indirectly fitting to that entire dataset.

In that case, OOS becomes just another layer of selection, not a true unseen test.

Even when using OOS during generation, the strategy is still developed within the same overall data environment.
So it is not truly unseen in the sense of completely new market conditions.

What made a big difference for me was separating the build period from truly unseen data.

For example:

build on a limited range (e.g. 2009–2022)
use OOS inside that range
but then extend the data to newer years and observe behavior without any re-optimization

That last step is where many strategies break, and it sounds like that is what you are seeing.

Another thing that can make a big difference is the amount of data used for building.

If the dataset is too short, the strategy simply hasn’t experienced enough different market conditions and regimes.

In that case, even if it looks good in-sample and out-of-sample, it can still fail once it encounters new conditions.

From my experience, using a broader data range helps a lot, because the strategy is forced to adapt to more variation before being tested further.

So instead of trying more IS/OOS combinations, I would focus on making sure the strategy is forced to survive data it has never seen at all.

In my experience, that changes everything.

Monte Carlo failing is often not just about the settings, but about how the strategy was built before reaching that stage.

I also use the default Monte Carlo settings, but I look at the results in a specific way.

I don’t read the table horizontally, but more vertically.

What I focus on is:

how fast the metrics break down
where stability disappears
whether the strategy degrades gradually or collapses

A strong strategy usually:

loses profit gradually
shows a controlled increase in drawdown
and the SQN drops, but still stays meaningful

A weak strategy usually:

loses profit suddenly
drawdown spikes hard
and SQN collapses quickly

Personally, I focus a lot on the 80–85% confidence levels.

For me, that represents a realistic stress scenario, not just an extreme worst case.

At that level, the strategy should still look healthy in terms of behavior.

Another important point is that I don’t look at Monte Carlo in isolation.

The base strategy still matters.

A strategy with weak metrics but a “good” Monte Carlo result is not something I would trust.

On the other hand, a strong strategy with solid metrics that shows slightly weaker Monte Carlo results, for example around 70%, can still be valid, as long as the behavior remains stable and does not collapse.

I also work more portfolio-based, so I don’t expect every robot to be perfect on its own.

What matters to me is whether it is structurally robust enough and behaves consistently under stress.

Also, from my experience, if a strategy struggles on unseen data before Monte Carlo, it will almost always fail Monte Carlo as well.

So usually I don’t try to “fix” Monte Carlo. I try to improve the process before it.

For me, it’s always about the full picture, not just one test.

Another important point is that Monte Carlo should be realistic.

I make sure the spread has enough room and the slippage is realistic.

For me, the goal is not just to “pass” Monte Carlo, but to make it resemble live trading conditions as much as possible.

That means trying to reflect your broker environment as closely as you can.

Appreciate it.
At the end of the day, I can only control the process.
The rest is just time, observation, and seeing if the systems keep behaving the way they should.

Looks like you are prepared to make a great effort, I will be interested to see your progression.

Why XAUUSD Is One of the Best Markets for Building Robots

I want to explain why XAUUSD became my main market for building robots, and why it started producing much better results for me once I combined it with the right workflow.

I tested multiple pairs over time, but things only started to change once I stopped looking at random backtests and began forcing my robots through a much harder process before trusting them. The workflow came first. XAUUSD came after that. Once both came together, I started finding multiple systems that were not only profitable on paper, but also much more robust in demo and live conditions.

The workflow is the foundation of everything.

First, I set the Data Horizon like this:

Min start date: 01/01/2009
Max end date: 31/12/2022

This becomes the build period.

On top of that, I also use 50% Out-of-Sample during the build process.

Once I have enough strategies, I go back to the Data Horizon and change the Max end date from 2022 to the most recent data available, for example 2026.

At that point, robots that were built on 2009–2022 are now being tested on unknown data from 2022–2026.

This is a very hard extra Out-of-Sample test inside EA studio.

Then I select based on the full 2009–2026 view. What I look at is:

the equity curve
stability
behavior

If the robot still behaves well there, it moves to the next step.

After that, Monte Carlo is mandatory.

The main Monte Carlo tests and checks I focus on are:

randomize history data
randomize backtesting starting bar
spread changes
slippage
confidence table

If the robot fails Monte Carlo, it is removed.
If it passes Monte Carlo, it becomes a candidate for export.

After that comes an extra check, which is optional, but I do it personally.

I export the robot and backtest it in MetaTrader on:

2003–2026
100% tick data

This gives me extra Out-of-Sample data before 2009, and also more realism because live trading is tick-based.

Then comes the demo phase.

The robots go to a demo VPS first. My minimum is:

60 trades ideally
45 to 50 trades can still be acceptable, but that is more aggressive

Anything below that is too little information.

Even good demo robots can still fail in live trading, because demo is not the same as live. Spread, slippage, and execution can all be different.

Then comes the live decision.

I compare live behavior with:

EA Studio metrics
MetaTrader backtest
demo behavior

If live behavior stays within the expected pattern, it is fine.
If it falls outside the pattern, I become careful, reduce trust, pause it, or move it back to demo.

The most important thing to understand is this:

Robots are allowed to have bad months or even bad years.

What matters is:

survival
consistent behavior
long-term performance

That is the workflow.

Now, why XAUUSD?

For me, XAUUSD stands out because it has the right mix of movement, structure, and opportunity. Gold has strong directional phases, strong expansions, and enough volatility to give systems room to perform. It also ranges, but even its ranges often still have movement inside them. That matters a lot.

Compared to many lower-volatility forex pairs, gold often behaves in a cleaner and more readable way. I am not saying other pairs do not work, because they do. Using the same workflow, I also built a strong set of USDJPY robots that are performing cleanly in live trading. But for me, XAUUSD was the market where this workflow started producing multiple robust systems more consistently.

Another important point is timeframe.

I only build robots on M30 and higher.

The reason is simple. Lower timeframes contain too much noise. More noise means less stability. Less stability means a higher chance that a robot looks good in backtest but starts failing in demo or live conditions. Higher timeframes give cleaner structure, more stable behavior, and better long-term consistency.

Data is another major reason why this works.

I always prefer broad historical data. The more data the robot is forced to go through, the more market regimes it experiences. That matters a lot. You can compare it to football. If you want to judge a player properly, you do not choose someone who has only played a few matches. You want someone who has already gone through many different games, situations, and conditions. It is the same with data. More data means more experience. More experience means a stronger test.

But broad data alone is not enough. You still need to separate the build period from unseen data. That is exactly why the extra Out-of-Sample step matters so much. Many people use a lot of data, but they let the strategy see everything during generation. I do not want that. I want the robot to prove itself on data it never touched during the build process.

Another lesson I learned is that simplicity matters more than complexity.

A lot of people think more indicators automatically create a better system. In my experience, that is false. The more indicators you add, the more conditions you force into the strategy, and the more ways you create fragility. More complexity usually means more ways for the robot to fail later.

Yes, I do have one robot that uses seven indicators in total and still performs well. But that is an exception, not the standard. In general, the simpler the logic, the more robust the system tends to be.

It is the same in manual trading. You can fill your chart with indicators and create more noise, or you can keep the chart clean and focus on what actually matters. In the end, all strategies are still reacting to price action and important levels. There may be millions of strategy variations, but everyone is still reacting to the same key structures in one way or another. That is why I believe complexity is often overrated. Many traders think adding more will improve the system, while in reality it often increases the chance of failure.

I also want to be clear about something. I am not saying XAUUSD is the only market that works. I am saying that with this workflow, XAUUSD became one of the best markets for me because it gave me multiple robots with strong behavior, clean equity curves, and enough movement to let the edge express itself.

The robot examples I included in this topic are not random. I chose them because they show that it is possible to build strong and robust systems on gold with EA Studio when the workflow is correct. I am not sharing the robots themselves, only the overviews, but that is enough to show that this can be done.

There is also a bigger reason why I want to show them. Behind these robots there is a process of observation. By watching live robots carefully over time, you can sometimes make small adjustments that improve them further without re-optimizing them or destroying the original logic. That is something I want to explain in a future topic, because I think it can help people a lot once they start managing robots in real conditions.

My main point is simple.

It is possible to build good systems with EA Studio.
It is possible to do it on XAUUSD.
But it only becomes realistic when the workflow is correct, when you use enough data, when you respect unseen data, when you stay on higher timeframes, and when you keep the systems as simple as possible.

This is not about finding one perfect backtest.
It is about forcing a robot to survive multiple layers of reality before it earns a place in demo or live trading.

Hello TradeMaster,

Thank you for your post! Please clarify your questions.

> I would like to now how EA Studio choose the parameter for a given criterion.

What parameters do you mean?

> Since its better to take a parameters set from a "platform" is better than from "Spikes"

What is "Platform" and what is "Spikes"?

I would like to now how EA Studio choose the parameter for a given criterion. Since its better to take a parameters set from a "platform" is better than from "Spikes", it would be interesting to know if the optimiser has some function like that integrated.

Is that also in FSB-Pro?

Also, it would be awesome. that from the user given setting for optimization gonna apply to WF. Till now it just opitmize over the criteria but dont use the optimize acceptance criteria like count of trades. That would be awesome to fix.

Also if the do the Walk Forward Stress test in the validator, it would be awesome to get directly to the WF-Result by clicking on the passed strategies.

P.s. Will your next application included in the FSB-Pack?

You can easily disable the "noise" protection by setting the "sigma" value to 0.

It is on line 101 of your expert.

This is the original code:

Set it like that:

const double sigma = 0.0;

Backtest the expert in the MetaTrader tester before and after the change and compare the results.
I did it on Dukascopy MT5, and it shows no difference.

It may or may not show differnce in your data.

...

If you want, you may slightly modify the closing signal formula. It is on line 370 of your expert.

Change it from:

void ManageClose(void)
  {
   // MACD (Close, 12, 26, 9)
   double ind2buffer[]; CopyBuffer(indHandlers[0][2][0], 0, 1, 3, ind2buffer);
   double ind2val1  = ind2buffer[2];
   double ind2val2  = ind2buffer[1];
   bool   ind2long  = ind2val1 < 0 - sigma && ind2val2 > 0 + sigma;
   bool   ind2short = ind2val1 > 0 + sigma && ind2val2 < 0 - sigma;

   if((posType == OP_BUY  && ind2long) ||
      (posType == OP_SELL && ind2short))
      ClosePosition();
  }

To:

void ManageClose(void)
  {
   // MACD (Close, 12, 26, 9)
   double ind2buffer[]; CopyBuffer(indHandlers[0][2][0], 0, 1, 3, ind2buffer);
   double ind2val1  = ind2buffer[2];
   double ind2val2  = ind2buffer[1];
   bool   ind2long  = ind2val1 <= 0.0 && ind2val2 > 0.0;
   bool   ind2short = ind2val1 >= 0.0 && ind2val2 < 0.0;

   if((posType == OP_BUY  && ind2long) ||
      (posType == OP_SELL && ind2short))
      ClosePosition();
  }

The change is from:

   bool   ind2long  = ind2val1 < 0 - sigma && ind2val2 > 0 + sigma;

to:

   bool   ind2long  = ind2val1 <= 0.0 && ind2val2 > 0.0;

After the modification, the signal will sound like: MACD becomes greater than zero after being below or equal to zero.