I noticed recently that the number of strategies added to my collection seems to vary over time and I just observed it in real-time this morning.

For example, about an hour ago the collection counts across 5 Chrome instances were:
1, 5, 5, 3, 5

and now an hour later they have updated to:
1, 5, 5, 3, 4

I'm aware that in a given Chrome instance, the number of Collection strategies will be lower than the Ascended count due to the correlation filtering. This is all fine.

My concern is that I don't understand how a collection can grow and then shrink like this?

Is this a bug?
Happy to send any details you need.
Thank you

I want to break both down in a realistic way, because both approaches exist, and both can work depending on how they are used.

First of all, I want to be clear that this is not about saying one is “wrong”. There are definitely skilled builders who can make shorter datasets work in live trading. But the behavior and implications of both approaches are very different.

Building on broader datasets
When you build on a longer historical range, the strategy is exposed to more market regimes, more conditions, and more variation.
Every candle represents past behavior of the market, including different trends, ranges, volatility phases, and reactions to events.
Because of that, the strategy is forced to adapt to a wider range of conditions during the build process.
In my experience, this tends to produce strategies that are more stable and more consistent over time.

Another advantage is that you usually don’t need to constantly replace them. They are built with more “experience”, so to speak.
The downside is that you might get fewer strategies passing your filters, and the process can feel slower.

You can also look at it from a different perspective.
Imagine you are choosing a trader to manage your capital.
Would you choose someone who has been trading for 2–3 years, or someone who has been consistently profitable for 15–20 years?
Most people would naturally lean towards the trader with more experience, because they have already gone through more market conditions and proved themselves over time.

It’s a similar idea when building strategies.
A strategy that is built on a broader dataset has effectively “seen” more of the market before being tested further.
Of course, just like with traders, past performance is never a guarantee. Time will always be the final test.
But more exposure during the build process generally gives a stronger foundation.

Building on shorter datasets
When you build on a shorter range (for example a few years), the strategy is exposed to much less variation.
That means fewer market regimes, fewer structural changes, and less overall information during the build process.
Even if you use OOS inside that range, the total amount of information is still limited.
Because of that, strategies can look very good in backtests, but they are often more sensitive when new conditions appear, especially when the market behaves in ways that were not present in the build data.
This approach can work, but it usually requires more rotation, more monitoring, and more frequent replacement of strategies.

Another consequence of this approach is that constant rotation can sometimes lead to throwing away strategies that were not actually broken, but simply going through a normal drawdown or stagnation phase.
When the build-and-replace cycle becomes too frequent, it becomes harder to distinguish between a genuinely weak strategy and one that just needs more time.

You can take the idea even one step further.
Even when people think they are using “enough data”, in reality the effective build data is often much smaller than they realize.

For example:
If you build a strategy on 8–10 years of data while using 50% out-of-sample, then only half of that data is actually used for building and optimization.
So in practice, you are not building on 10 years.
You are building on 4–5 years of effective in-sample data.
That is not a lot when you think about how complex and changing the market really is.

It means the strategy is trained on a relatively limited window, and then validated on another limited window within the same overall period.
And while that can still work, it also means the strategy has not been exposed to a truly wide range of market conditions yet.
That is exactly why I prefer working with broader datasets.

Because even after applying out-of-sample, there is still enough depth and variation left in both the build phase and the validation phase.
It simply gives more information, more exposure, and a stronger foundation before the strategy ever reaches demo or live trading.

The goal of building strategies is always the same:
To extract something that survives outside the data it was built on.
And from that perspective, the amount of data matters a lot.
More data means more exposure.
More exposure means more information.
More information generally leads to more robust behavior.

The same principle applies later in the process as well.
You wouldn’t judge a strategy after just a few trades or a couple of weeks. You want enough data and enough observations before trusting it.
So it makes sense to apply that same logic during the build phase.

Both approaches can work, but they lead to very different styles.
One focuses more on long-term stability and consistency.

The other relies more on adaptation, rotation, and active management.

From my experience, the more data a strategy is exposed to during the build process, the more robust it tends to be when facing new conditions later on.
That does not guarantee success.
But it significantly increases the probability of building something that can actually survive real market conditions.

Most people think they are building robust systems.

In reality, many are just building on limited information without realizing it.

I would like to optimize for other things like the default ones in the optimizers. Is it doable to ajust the code for that?
An example would be to optimize for a specific win rate percentage ond only that. Or add other custom optimize goals.

is the Generate Best For and Optimize best for Goal accessable for a advanced user to code custom requirement?

how would one have to proceed to generate lots  of eas with WinLoss 30% or 50% hit rate. without having to look in the last pages of the collection after generated them?

I’d like to open a practical discussion about AI in the context of EA Studio.

Not the usual idea that AI will somehow generate profitable strategies automatically. I think most people here already know that this is not the real point, YET!

What interests me much more is something simpler and more practical:

Where can AI actually improve the workflow of people developing EAs with EA Studio?

From my experience, the real value is not in replacing EA Studio, but in helping us manage scale, improve decisions, reduce noise, and better understand what is really happening inside a large EA workflow.

Here are some use cases that I think are genuinely useful. Some of them we are already using in practice.

Strategy & EA understanding
    •    Clustering similar EAs*
Group strategies that are basically variations of the same idea, so we do not think we are diversified when in reality we are not.
    •    Winners vs losers analysis*
Compare profitable vs unprofitable EAs to understand what really separates them: logic type, trade frequency, exit structure, SL/TP profile, market regime fit, and so on.
    •    Feature extraction from strategies
Detect recurring patterns like trend-following, mean reversion, breakout behavior, volatility sensitivity, session dependency, and other structural characteristics.
    •    MQL code analysis*
Review and compare EA logic directly from the code. This can be very useful for debugging, understanding third-party EAs, or checking whether two bots that look different are actually doing something very similar.

Trade-level analysis
    •    Trade distribution analysis*
Study how trades are distributed across time, duration, sessions, weekdays, symbols, and setups.
    •    Winners vs losers at trade level*
Analyze what losing trades look like compared with winning trades: duration, volatility context, time of day, adverse excursion, favorable excursion, exit behavior, etc.
    •    Entry and exit behavior analysis*
Understand whether the edge is really in the entry, in the exit, or in the trade management.
    •    Floating drawdown and recovery analysis*
Look at how trades go into negative territory, how deep they go, how often they recover, and what kind of floating pressure an EA creates before closing.
    •    Trade sequence analysis*
Evaluate losing streaks, recovery sequences, and whether deterioration starts appearing first at trade level before it becomes obvious at EA level.

Incubation & live monitoring
    •    Incubator monitoring*
Detect which EAs are improving, stagnating, or deteriorating over time.
    •    Automatic labeling / classification*
Tag EAs into practical buckets like promising, watchlist, pruning, or ready for promotion based on how performance evolves.
    •    Early warning signals
Spot when an EA starts behaving differently from expectations before the damage becomes too large.
    •    Performance drift detection
Identify when live or demo behavior starts drifting away from the original profile.

Portfolio construction
    •    Diversification support*
Help build portfolios with lower correlation across symbols, logic types, and timeframes.
    •    Role classification*
Identify which EAs behave mainly as profit engines, drawdown stabilizers, or hybrids / bridge strategies.
    •    Exposure mapping
Detect hidden concentration, for example several different EAs all leaning on the same currency or market behavior.

Workflow validation
    •    Process validation at scale*
Check whether the generation + filtering workflow is actually producing better candidates over time, not just more output.
    •    Monte Carlo / WFA interpretation
Summarize robustness results across many strategies when the volume becomes too high for manual review.
    •    Success rate tracking*
Measure how many selected EAs actually survive incubation and become usable.

Operations & scaling
    •    Documentation and tagging*
Keep structure and memory across many EAs, tests, and incubators.
    •    Experiment design support*
Help organize structured tests, for example grid vs no-grid, different parameter families, or broker comparisons.
    •    Reporting and dashboards*
Produce clear summaries of what is happening across the whole workflow.
    •    Log analysis
Detect technical issues, broker execution differences, VPS instability, or unusual behavior in platform logs.

Curious to hear from others:
    •    Are you already using AI in your EA workflow?
    •    Where does it help the most?
    •    Have you found use cases that really improve results, and not only save time?

My personal view: AI is not yet the edge. The edge is still the workflow. But AI can make a good workflow significantly stronger.

* The starred use cases are things we are already actively using in our workflow.

Vincenzo

I’m trying to define a Longevity Index for EAs generated with EA Studio, based on how long strategies remain in a “top band” according to your selection criteria, filters, or KPIs once they are promoted to live trading.

The idea is not to change the selection rules, but to better understand persistence and durability after promotion.

Has anyone here worked on something similar?

A few practical questions:
    1.    Do you track how long an EA keeps meeting your “good” criteria after going live?
    2.    Do you see a real difference in longevity between stronger entries and more borderline ones?
    3.    Do you evaluate this with fixed horizons like 1 month, 3 months, 6 months, etc.?
    4.    How do you treat EAs that drop below the threshold and later recover?
    5.    If you already measure this, what is your typical expectation in terms of months?

I’d be interested in practical experience, constructive exchange, proven best practices…not only theory.

Happy Easter everyone — and thanks in advance for any insights.

Vincenzo

What I did here is actually very simple, but the impact is huge.

In the #2 screenshot, you see the strategy built on data from 2009 until 2020.

This is close to how I was actually doing it back then in early 2024.

Back then I was using slightly different starting ranges as well, sometimes more like 2007–2019 and then extending forward, but the idea itself was exactly the same.

That is the important part.

The principle never changed:

build first, then push the same strategy into extra unseen data.

This is the normal build phase. This is where the strategy is generated and optimized. At that stage, the strategy already looks solid. The equity curve is good, the net profit is there, the trade count is decent, and the SQN is already 3.45.

For many people, that would already be enough to say the strategy looks good.

But this is where I started thinking differently.

Because for me, it is not enough that a strategy looks good only on the period where it was built and optimized.

That is exactly where many people stop too early.

They build, they check the normal out of sample inside EA Studio, and then they move on.

But I wanted to push the strategy further.

I wanted to see what really happens when you expose it to data it has never seen.

So what I started doing back then was this:

after generating and optimizing the strategy, I do not touch the strategy itself anymore.

I do not change the rules
I do not reoptimize
I do not tweak anything

I only change one thing:

the data end.

So the strategy stays exactly the same, but now I extend the end date forward.

And this is exactly what you see in the #1 screenshot.

The same strategy is now extended from 2009–2020 to 2009–2024.

And that is the key point.

That extra period was never optimized.

So what you are looking at there is pure unseen data.

Real out of sample.

No fitting
no tweaking
no hidden optimization

Just the strategy being pushed forward into new market conditions.

And this is exactly where weak strategies usually break.

That is why this became such an important step in my workflow.

Because if a strategy looks good until 2020 but then falls apart when I extend it to 2024, then I already know enough.

I don’t care how nice it looked before.

It is not stable.

But if I extend it and it keeps going, stays stable, and even improves, then now we are talking about something completely different.

And that is exactly what you see here.

The strategy holds.

The equity curve keeps moving.

The structure stays intact.

That is what you want to see.

For me, this is one of the clearest ways to separate:

strategies that look good
from strategies that are actually stronger

Because now you are not looking at in-sample anymore.

You are forcing the strategy through a completely new period it has never seen.

That is real testing.

That is why I always say:

strategies break or survive on out of sample.

And this is just one more layer of that idea.

Simple concept.

Huge difference.

One important thing I want to add here about the build process itself.

When I build strategies, I use full data optimization with 40 steps.

And there is a reason for that.

A lot of people are afraid of heavy optimization because of overfitting.

But that is exactly where Monte Carlo comes in.

Monte Carlo is not there to replace optimization.

It is there to test it.

So I actually push the optimization harder on purpose.

I give the strategy room to explore the data.

And then I use Monte Carlo to check if that structure is still stable under randomness.

This strategy you see here was built with 40 optimization steps.

And then you can clearly see what happens when it goes through heavy Monte Carlo testing.

That is the balance.

Strong optimization → then strong validation.

And on top of that, the extra out of sample period is not optimized at all.

So that is pure OOS.

Also during the build itself, I already use 50% out of sample in EA Studio.

So from the start there is already a separation between in-sample and out-of-sample data.

But the extra OOS trick is what really pushes it further.

That is where things get exposed.

After that, I move to the next step.

Monte Carlo.

Normally, like I explained before, I use:

50 runs
then 100 runs as confirmation

But here I pushed it much further.

I ran 1500 simulations.

And this is where things become very clear.

Because now you are not looking at one equity curve anymore.

You are stress testing the same strategy across a massive number of variations.

Randomized history
randomized spread
randomized slippage
different starting points

Everything gets pushed.

And if a strategy is weak, this is where it shows immediately.

Now look at the confidence table.

Even under heavy randomization, the structure holds.

The performance stays consistent
the SQN remains solid
the degradation is controlled

Even at higher confidence levels, the strategy is still standing.

That is not normal for weak strategies.

And if you look at the editor, you can see the magic number.

This is EA 165.

So again, this is not a random example.

This is a real strategy.

And this strategy has been running live for around a year.

That is also why I was confident enough to push it to 1500 Monte Carlo simulations.

Because by that point, I already had real live data behind it.

But the important part is this:

back then, when I first built it, I was not doing 1500 runs.

I was doing 50 → then 100 runs as confirmation.

Exactly like I explained before.

The 1500 runs you see here are just an extra layer on top of something that was already proven step by step.

So what you are really seeing here is this:

a strategy built on historical data
then extended into real unseen data (extra OOS)
then stress tested through massive Monte Carlo

And it still holds.

That is what I call confirmation.

Not one good backtest.

Not one lucky curve.

But multiple layers, all pointing in the same direction.

That is the difference.

That is also why for me this is not optional.

This is a filter.

If a strategy fails here → it is out.

If it survives → it earns the right to move forward.

That is the whole idea.

Data
out of sample
extra out of sample
Monte Carlo

Stack those layers.

And you will see very quickly what is real and what is not.

Simple idea.

Huge difference.

For the live results of EA 165, you can check here:
https://forexsb.com/forum/topic/10057/building-robust-eas-on-xauusd-a-structured-workflow-that-works/

One last thing to make this even more clear.

After everything you just saw, I extended the same strategy even further.

From 2009 all the way to 2026.

Again:

no changes
no reoptimization
same logic

Just more unseen data.

And this is what matters.

Because at this point, you are not just looking at a strategy that survived a small extension.

You are looking at a strategy that continues to hold its structure over an even longer period.

The equity curve keeps moving
the behavior stays consistent
the structure remains intact

That is not something you fake.

And if you compare this with the previous topic where I shared the live performance, you can start connecting the dots.

This is exactly the point.

Not one test.
Not one phase.

But consistency across:

build
extra out of sample
extended data
Monte Carlo
demo
and live performance

That is where real confidence comes from.

Everything has to align.

And when it does, this is the result.

I know many builders in EA Studio use Monte Carlo directly inside the Reactor phase.

And I understand why.

It makes the workflow faster.
It automates filtering.
It removes weak systems early.

But there is one important limitation that most people overlook:

You cannot actually see the structure of the Monte Carlo result.

When Monte Carlo is used inside the Reactor:

You only see that a strategy passes or fails.

But you do NOT see:
- the simulation chart
- the equity curve variations
- the confidence table behavior

And that matters more than people think.

Why this is a problem

From experience, I have seen strategies that:

pass Monte Carlo in the Reactor 
but are structurally weak when you actually look deeper

For example:
- unstable equity distribution
- inconsistent degradation
- hidden weaknesses in higher confidence levels

These are things you only recognize with a trained eye.

And you cannot develop that eye if you never look at the actual Monte Carlo output.

What I do instead

I use the Reactor for:
- generation
- optimization
- initial filtering

Then I take selected strategies into the Collection.

And only there I run Monte Carlo manually.

Why?

Because then I can actually SEE:

- the simulation chart
- the spread between curves
- the structure of degradation
- the confidence table behavior

That visual feedback is critical.

Key point

Monte Carlo is not just a filter.

It is a diagnostic tool.

If you only use it inside the Reactor,
you are using it blindly.

Final thought

Automation is useful.

But understanding structure is what makes the difference.

If you want to become better at building robust systems,
you need to look at Monte Carlo not just pass it.

What Monte Carlo is (in practice)
Monte Carlo is not a tool to improve a strategy.
It is a stress test.
It takes your existing system and runs multiple variations of it under slightly different conditions:
price sequence changes
spread variation
slippage
starting point shifts

The goal is simple:
to see whether the strategy is dependent on perfect conditions
or if it can survive realistic market imperfections

The settings I use
I keep my Monte Carlo settings simple and focused on realism.

Market variations
Randomize history data → ON
The market never moves exactly the same way twice.
Small differences in price sequencing are normal.
This test checks whether the strategy depends on perfect candle structure.
This is one of the most important tests.

Randomize spread → ON
Spread is never constant.
Broker conditions change continuously.
Especially on XAUUSD, spread has a major impact.
Without this, backtests are often too optimistic.

Execution problems

Randomize slippage → ON
Slippage is part of live trading.
Especially during volatility and fast moves.
This tests whether the system can handle execution imperfections.

Randomly skip position entry → OFF
This option simulates missed or skipped entries.

That can happen in specific situations, for example with news filters, spread filters, or execution restrictions.

But in my workflow, I do not use it as a standard Monte Carlo condition.

I use Monte Carlo mainly to test the broader structure of a system under realistic market stress, not to simulate every possible exceptional filter or execution scenario.

For that reason, I leave this option OFF.

Randomly skip position exit → OFF
This option simulates missed or skipped exits.
That is not something I consider a realistic standard condition for normal EA execution, so I leave it OFF.

Randomly close position → OFF
This simulates manual interference.

In my approach:
I do not interfere with robots.
That is a hard rule in my workflow.

The only time I broke that rule was earlier on, when I had a stack of XAUUSD robots all going against me at the same time with wide stop losses. That was an exposure mistake on my side, and I had to partial close twice because the total exposure was too high.

I learned from that. I later made structural adjustments to prevent that situation from happening again, which I explained in more detail in the previous topic:
https://forexsb.com/forum/topic/10058/why-multiple-profitable-eas-can-still-hurt-your-account/

Backtest start

Randomize backtest starting bar → ON
This checks whether the starting point matters.
A robust system should not depend on a perfect start moment.
Together with history randomization, this is one of the strongest robustness checks.

Strategy variations

Randomize indicator parameters → OFF

Important clarification:
This is not re-optimization.
It slightly shifts parameters to test sensitivity.

Sequence:
Reactor → optimization
Monte Carlo → validate stability

Not:
Reactor → Monte Carlo → search for new parameters

This is an important distinction.

How I use the Confidence Table
The Confidence Table is where most of the real information is.

Each row represents a confidence level:
20% → optimistic scenario
50% → median
85–95% → stress zone
100% → worst case

These are not new backtests.
They are variations of the same system under stress.

What I look at
I do not read the table row by row.

I read it vertically:
How fast does performance degrade
How stable is Return / DD
How does drawdown evolve
Does SQN collapse or remain meaningful

My key metric

For me, Return / DD is one of the most important signals.

Example:
If the original Return / DD is around 12, then ideally I want to see at least around half of that still remaining at the 80–85% confidence zone.

So in that example, a value around 6 would be very strong.
That means the system still holds a significant part of its structure.

That is a strong sign of robustness.

That said, I am not overly strict with it.

If the rest of the system still looks good in terms of equity curve, overall metrics, and general behavior, I can still accept a Return / DD around 4–5 in the 80–85% confidence zone.

If I were too strict on Monte Carlo alone, I would end up throwing away too many systems that are still good enough on paper and often still worth testing further.

What I want to see

A good system:
Profit decreases gradually
Drawdown increases in a controlled way
SQN declines but stays relevant
Behavior remains consistent

A bad system:
Profit collapses quickly
Drawdown spikes aggressively
SQN breaks down
Equity structure changes completely

Number of simulations

In my workflow, I use 50 Monte Carlo simulations as standard.

That is my default test.

For me, 50 runs are already enough to judge whether a strategy is structurally stable or not.

Sometimes, after a system passes well on 50 runs, I do an extra test with 100 simulations.

Not because 50 is suddenly not enough.
Not because I want to make the test artificially stricter.
And not because I am looking for perfection.

I do it for one reason only:

to see whether anything changes structurally when the number of simulations is increased.

If the behavior stays broadly the same at 100 runs, that gives me extra confidence that the result at 50 runs was not just noise.

So to be clear:

50 runs = my standard Monte Carlo test
100 runs = optional extra confirmation

The exact number is not the most important factor.

What matters most is whether the system behaves consistently when stress is increased.

Important note

Monte Carlo is not a guarantee.

Passing Monte Carlo does not mean a system is ready for live trading.

It only means:
the system has survived a realistic stress test

It still needs:
Out-of-Sample validation
demo phase
live validation

Final perspective

Monte Carlo is one of the core filters in my workflow.

If a system fails here clearly,
and the rest of the metrics are not convincing,
I discard it immediately.

There is no reason to continue with a weak structure.

Over time, your eye becomes trained.
You start to recognize stability patterns very quickly.

But that intuition always starts with a solid Monte Carlo foundation.

This is not about finding perfect systems.

It is about filtering out fragile ones before they ever reach demo or live trading.

Monte Carlo example (real system)

Below you can see two Monte Carlo tests of one of my systems (EA 628):

50 simulations (my standard test)
100 simulations (extra confirmation)

This is not a random system.

This robot has already been:

backtested (tick data MT4)
tested in EA Studio
validated on demo
and traded live

So what you are seeing here is not theory
this is a system that has already proven itself, now being stress-tested.

What stands out immediately

If you look at the simulation charts, you can see:

All curves follow the same general structure
No chaotic divergence
No random collapse scenarios
The system keeps its shape under stress

That is exactly what you want to see.

A fragile system would show:

wide spread between curves
inconsistent behavior
completely different equity structures

That is not the case here.

Confidence table interpretation

Now the most important part: the confidence table

What matters is not the exact numbers, but the structure.

You can clearly see:

Profit decreases gradually
Drawdown increases in a controlled way
Return / DD stays relatively stable
SQN declines slightly but remains meaningful

This is what I call a stable degradation curve.

50 runs vs 100 runs

This is where it becomes interesting.

When moving from 50 → 100 simulations:

The structure remains the same
No new weaknesses appear
No sudden breakdown in performance
The behavior is consistent

That confirms that the 50-run result was not random noise.

This is exactly why I sometimes run 100 simulations:
not to make the test stricter,
but to confirm that the structure holds.

Key takeaway

Monte Carlo is not about perfect numbers.

It is about structure.

This system shows:

consistency
controlled degradation
stability under stress

That is what robustness looks like in practice.

Also keep in mind:

This is a system that already proved itself in:

backtest
demo
live trading

Monte Carlo is not used here to “find” something.

It is used to confirm that the structure remains intact under variation.

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.

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.

Is that also in FSB-Pro?

Download files:
https://drive.google.com/drive/folders/ … sp=sharing

FSB News Companion indicator for MT4 (FSBNewsCompanion_fix5.mq4)

I tried to implement something similar for FSB Pro using the same news-feed.txt data source as used by Expert Advisor Studio .

The solution is using 3 components:

1. Downloader = data source updater for MT4
2. Gate = strategy execution filter on FSB Pro and exported strategies for MT4
3. Companion = chart UI / situational awareness for MT4 (optional)

What makes this architecture especially clean is that the three components are tightly related, but loosely coupled. They share the same local source news-feed.txt and the same health globals, but they do not overlap responsibilities. The feed is downloaded and served locally for other strategies or charts for manual trading, which makes this very lightweight.

The FSB news ecosystem achieves by splitting responsibilities into three focused components: a Downloader that maintains the local data source, a Companion that visualizes upcoming events on MT4 charts, and a Gate that applies the actual trade-permission logic inside exported strategies. The result is a workflow that is both practical and lightweight: Downloader = data source updater for MT4, Companion = chart UI / situational awareness for MT4, Gate = strategy execution filter on FSB Pro and exported strategies for MT4.

1) FSB News Downloader = feed maintenance service (FSBNewsDownloaderEAv2_2_fix1.mq4)

Uses only one FSB News Downloader EA for single MT4 instance.
Default feed refresh value is 360 minutes, do not make this smaller.

The Downloader is the foundation of the entire stack. Its role is not to decide trades and not to decorate charts. Its role is simply to keep the feed current, healthy, and locally available for the rest of the system. In the FSBNewsDownloaderEAv2_2 line, the EA downloads news-feed.txt, saves it into the MT4 files area.

Need to edit MT4 settings - allow WebRequests to https://forexsb.com

FSB News Downloader EA for MT4

2) Gate = strategy execution filter for FSB Pro and MT4 (FSBNewsGate_v2_1.cs and FSBNewsGate_v2_1.mqh)

FSBNewsGate_v2_1 was designed as a directionless LIVE MT4 news permission gate. On the FSB Pro side (.cs), the indicator keeps a clean UI and parameter contract, but always outputs allow=1 during FSB Pro runtime because the indicator is forward-looking and depends on live feed behavior. On the MT4 side (.mqh), the real blocking logic happens: it reads the offline news-feed.txt, applies symbol/currency matching, applies the configured news-priority mode and pre/post windows, and decides whether long and short entries are currently allowed.

That distinction is crucial. The Gate is not a downloader and not a visual aid. It is a strategy execution filter. It is the final policy layer that tells the strategy whether to open trades around upcoming news. In v2.1, the design was improved further by mirroring the priority mode into an MT4-visible numeric parameter so operators can choose Disabled / High only / High and Medium directly from MT4 after export. That keeps FSB Pro and MT4 aligned while still preserving the execution responsibility inside the Gate itself.

FSB NewsGate indicator for FSB Pro and MT4

3) Companion = chart UI / situational awareness (FSBNewsCompanion_fix5.mq4) (Optional)

The Companion exists because having a healthy feed is not the same as seeing the market context. FSBNewsCompanion_fix5.mq4 is deliberately chart-focused: it reads the local news-feed.txt, filters events to the current symbol, optionally includes USD on all charts, limits visibility to M1-H1 by default, and draws future events as vertical dotted markers with human-readable tooltips. It does not download anything and it does not make trade decisions. It is a visibility layer a situational-awareness tool for MT4 charts.

FSB News Companion indicator for MT4 (FSBNewsCompanion_fix5.mq4)

Download files:
https://drive.google.com/drive/folders/ … sp=sharing

I made various updates and upgrades to the forexsb.com server during the last 10 days.

The upgrade includes updates to the PHP versions, the proxy servers, and the backend frameworks of the following applications:
- the Custom Indicators Repository for Forex Strategy Builder Professional.
- the Wiki software with the applications' User Guides
- the forum
- a backend control panel for managing the users' accounts.

All updates finished successfully with minimal service interruption of 20 seconds.
There are no changes in the behaviour of the updated applications.

The forum's mailing system has also been updated. I wanted to be sure our emails are meeting all security recommendations and are whitelisted by the major validation services.

I invest a lot of time and effort to provide the best service in the industry.

As a result, we have a 12-CPU-core server with 0% load. (With 15 applications running)

EA Studio loads for 300 milliseconds without cache. (And without any errors.)

The next and best strategy builder loads in the browser without internet !!! (Pure magic)

I'm happy with these results and return to the usual application development.

Have a great trading session!

Further it would be interesting to built a Portfolio out of the WF equidity lines and of course multisymbols ;) But that is easy work in excel, but the journal would help a lot.

Looking forward to hearing from.

Open Long when Macd Line crosses the zero line upward
Close Long when Macd Line crosses the zero line downward

but it has not closed, I had to close the position manually:

PLease find EA studio EA attached.

Thanks