My five MT5 trading bots finished July 20 with a combined realized loss of ¥542.
The closed trades produced three wins and five losses. The average winning trade made ¥32.7, while the average losing trade lost ¥128. That gives an average payoff ratio of only 0.26.
BoundSniper Bot was the only system to finish positive, earning ¥16.
GateGrid AI lost ¥151, LLMBridgeTrader lost ¥167, and ML_ScoreAnalyst lost ¥240. I did not receive a confirmed report for MAribbonTrader, so I recorded it as an unverified ¥0 rather than assuming that it made no trades.
When I first reviewed the day, I thought the main issue was the exit logic.
Several different bots were producing the same pattern: small profits were closed quickly, while larger losses were allowed to remain.
That interpretation was not completely wrong.
However, after a deeper investigation into GateGrid AI, I reached a different conclusion.
The exits were weak, but improving them was not enough. Better entry selection was not enough either.
The GBPUSD version of the strategy could not produce a positive expected value under realistic trading costs.
The real issue was not simply how intelligent the bot was.
It was the relationship between the strategy, the currency pair, and the cost paid on every trade.
The July 20 loss became the final reason to reconsider whether GateGrid AI should continue trading GBPUSD at all.
Results by Bot
GateGrid AI: -¥151
GateGrid AI traded GBPUSD and finished with zero wins and two losses.
A buy stop was triggered first. The sell-side order was then triggered as well, and both positions were closed roughly one second later.
The two results were -¥135 and -¥16.
Looking only at this sequence, the problem appeared to be the position-management process after the opposite side was filled.
Should the system keep both positions as a hedge?
Should it treat the second fill as a reversal and close the first position?
Should it classify the situation as abnormal and close everything?
The trade report did not show which rule caused the exit.
In the past, I would have responded by adding more detailed exit logs and adjusting the position-management logic.
In fact, I had already made many such adjustments.
The long-term performance still failed to improve.
BoundSniper Bot: +¥16
BoundSniper Bot traded USDJPY.
It bought at 162.348 and closed approximately four minutes later at 162.364, producing a ¥16 profit.
One trade is not enough to evaluate the quality of the underlying signal.
However, the execution path worked correctly. The bot received the TradingView webhook, placed the MT5 order, closed the position, and left nothing open.
BoundSniper Bot does not predict the market by itself. Its job is to carry an external TradingView signal into MT5.
For that reason, the important risks are different: communication latency, duplicate orders, symbol conversion failures, rejected orders, and missed exits.
The profit was small, but the execution process was clean.
LLMBridgeTrader: -¥167
LLMBridgeTrader traded EURUSD.
Its three results were -¥141, +¥73, and -¥99.
That produced one win and two losses. The average win was ¥73, while the average loss was ¥120, giving an average payoff ratio of 0.61.
All three positions were closed at market before reaching their original stop-loss or take-profit levels.
This suggests that the LLM-based OPEN, HOLD, CLOSE, and REVERSE decision process was active.
But an active decision process is not necessarily a profitable one.
Did the model close profitable trades too early?
Did it correctly detect a reversal?
Did it wait longer when a position was losing than when it was winning?
The trade history alone cannot answer those questions.
The system needs to record the model name, prompt version, market inputs, confidence score, proposed action, final action, and exact exit reason for every decision.
ML_ScoreAnalyst: -¥240
ML_ScoreAnalyst traded GBPJPY.
It produced one ¥9 profit and one ¥249 loss.
Its average payoff ratio was only 0.04.
It would take nearly 28 wins of ¥9 to recover a single ¥249 loss.
This bot uses a CatBoost score to select entries. However, a high entry score is not enough when the expected price movement is much smaller than the stop-loss distance.
Raising the score threshold alone will not solve the problem.
The score threshold, trading session, ATR, entry volatility, stop distance, and target distance need to be tested as one combined policy.
The bot also carried an unrealized loss of ¥97 into the next day.
That unrealized amount was not included in the realized loss of ¥542. Including it would bring the total daily mark-to-market result to -¥639.
MAribbonTrader: Unverified ¥0
I did not receive a July 20 trade report for MAribbonTrader.
I therefore recorded it as an unverified ¥0 rather than declaring that it made no trades.
For an LLM bot that reads chart images, BUY and SELL are not the only meaningful outputs.
WAIT and EXIT are also decisions.
The input image, higher-timeframe context, support and resistance levels, model response, and reason for waiting should all be recorded.
A day with no trades can still contain valuable information, but only if the system distinguishes between deliberately waiting and failing to run.
GateGrid AI Was Winning Most Trades and Still Losing Money
I did not judge GateGrid AI from the two losses on July 20 alone.
Across its live trading history, the bot won approximately 62–68% of its trades.
At first glance, that appears acceptable.
Despite that win rate, its live profit factor was only 0.62, and its lifetime loss was approximately ¥19,000.
The problem was not just an occasional large loss.
The system was losing small amounts on an almost daily basis.
Converted into pips, the average winning trade made only 4.3 pips, while the average losing trade lost 15.3 pips.
The average loss was roughly 3.5 times larger than the average win.
With that payoff structure, the break-even win rate is approximately 78%.
The actual win rate of 62–68% was not close enough.
A minor improvement in entry accuracy could not bridge the gap.
This asymmetry was not simply a programming bug.
GateGrid AI closes profitable positions relatively quickly and adds exposure when the market moves against the grid.
Small gains are collected frequently, but losing baskets become much heavier.
The negative skew was embedded in the strategy itself.
GBPUSD Trading Costs Were Too Large Relative to the Average Win
Spread was another factor quietly damaging the system.
In live observations, GBPUSD spread sometimes reached roughly 1.2 pips.
For a strategy whose average winning trade was only 4.3 pips, that cost was substantial.
A 1.2-pip spread consumes about 28% of the gross winning distance.
In my cross-pair simulations, I used a 0.7-pip spread for GBPUSD. Even under that more favorable assumption, it remained expensive compared with the roughly 0.3-pip conditions available on EURUSD and USDJPY.
For a strategy targeting large moves, a difference of 0.4 pips may be relatively minor.
For a system repeatedly collecting around four pips, that difference sits near the center of the expected value calculation.
Reducing the spread paid on every trade can matter more than improving entry accuracy by a few percentage points.
I Had Already Made Extensive Exit Adjustments
GateGrid AI’s exits had not been ignored.
I increased the trailing ratchet from 0.7 to 0.9.
I added a time-decay mechanism that gradually reduced the global stop-loss distance to 15 pips after 180 minutes.
I introduced an ¥800 basket loss limit.
I blocked new entries on Mondays and before the trading curfew.
These changes reduced the size of the tail losses.
However, they did not close the gap between the required 78% win rate and the actual win rate of roughly 68%.
Exit adjustments could reduce the severity of the losses, but they could not reverse the expected value of the strategy.
That left one remaining possibility: improve the entries.
Six Attempts to Improve Entry Quality Failed
I used one rule for every experiment.
A change would only be accepted if it improved performance consistently across multiple periods.
A policy that worked in only one selected period would not be considered valid.
Regime Switching
I tested a model designed to classify whether the market was ranging or breaking out and then change the grid behavior accordingly.
The holdout AUC was 0.57, and the resulting trading policy showed no improvement.
The model could describe something resembling market conditions, but it could not separate profitable conditions from unprofitable ones.
Gate Model Version 2
I used 16,715 previously unused market snapshots and generated counterfactual labels to rebuild the entry gate.
The real holdout AUC reached 0.61.
Despite the higher classification score, the trading policy became worse by ¥46 per trade.
A model can improve its statistical metric while reducing actual trading performance.
This experiment also revealed that the existing combined policy of threshold filtering, Ollama judgment, and the clean gate was better than simply sorting trades by the model score.
Replacing the LLM
I attempted a shadow test using gpt-oss:20b in place of the current Ollama decision model.
Under the current configuration, however, the model returned empty responses.
It appeared faster only because it was not producing a usable decision.
The comparison could not evaluate judgment quality, so the replacement was rejected.
One-Sided Grids
Ollama produced a directional opinion on nearly every setup, yet the grid placed orders on both sides roughly 98% of the time.
I tested using the direction signal to place orders on only one side.
The result was -¥268 over the full period and +¥441 over the recent period.
It improved one period while damaging another, leaving the combined result close to neutral.
The cost of two-sided whipsaws was replaced by larger losses when the directional prediction was wrong.
Full Exit-Space Search
I performed a broad parameter search across trailing settings, global take-profit levels, and global stop-loss levels.
I could not find a stable region where the actual win rate exceeded the required break-even win rate.
Widening the winning distance reduced the win rate.
Preserving the win rate kept the winning distance too small.
Changing the global take-profit level often had little effect because the trailing logic closed profitable positions first.
The asymmetry moved around the parameter space, but it did not disappear.
Trend Capture
The final idea was to trade only when the post-entry price movement developed into a strong trend.
The correlation between realized profit and actual post-entry trend strength was only +0.03.
It was effectively zero.
GateGrid AI did not consistently win because the market trended, nor did it consistently win because the market ranged.
Its results depended heavily on the exact price path after entry.
Even perfect knowledge of future trend strength would not have separated the winning trades well enough.
There May Have Been Very Little Signal to Predict
GateGrid AI produced only one profitable day across 13 trading days in July.
That day was July 14, when it earned ¥852.
However, Tuesday itself was not consistently profitable, and no reliable time window remained after excluding that single day.
The reason the predictive models remained around an AUC of 0.5 may not have been model weakness alone.
There may have been very little useful entry-time signal separating future winners from future losers.
The strategy’s average result was pulled slightly below zero by transaction costs, while path-dependent noise created wide fluctuations around that negative mean.
In that environment, a more complicated model has very little stable structure to learn.
When the Strategy Cannot Be Fixed, Change the Market
After the other experiments failed, transaction cost remained the main variable that could still be changed.
Using the same GBPUSD price movement but reducing the simulated spread from 0.7 pips to 0.3 pips improved the recent profit factor from 0.80 to 0.96.
That was still below break-even.
However, it closed a large portion of the gap and confirmed that spread was a major factor.
I then examined the conditions already available in the same GaitameFinest account.
EURUSD and USDJPY were already offered at roughly 0.3 pips.
There was no immediate need to search for a different broker or a separate raw-spread account.
GBPUSD was simply the relatively expensive pair.
The question changed.
Instead of asking how to improve entry selection on GBPUSD, I began asking what would happen if the same grid strategy traded a lower-cost currency pair.
EURUSD Was the Only Pair That Remained Positive Across Both Periods
I tested the same strategy and the same exit policy across several currency pairs using their actual spread assumptions.
I split the evaluation into an earlier April–May period and a later May–July period.
GBPUSD produced a profit factor of 1.33 in the first period and 0.87 in the second.
It was profitable in one environment and unprofitable in another.
EURUSD produced a profit factor of 1.19 in the first period and 1.18 in the second.
The numbers were not spectacular.
What mattered was that the sign did not reverse when the period changed.
After several weeks of testing, this was the first configuration that remained profitable across both out-of-sample segments.
The improvement came from two factors.
First, the spread was only about 0.3 pips.
Second, EURUSD’s lower volatility produced shallower average losses.
The average loss was approximately ¥305 on EURUSD, compared with about ¥371 on GBPUSD.
The win-to-loss relationship improved from roughly 1:3.5 to about 1:2.5.
The required break-even win rate fell to approximately 71%, while the actual win rate was about 75%.
For the first time, the observed win rate exceeded the required win rate.
The EURUSD version also worked without the GBPUSD-specific gate model.
I did not need to rebuild the entire entry model. Allowing entries through without that gate produced a more stable result.
Narrowing the Grid Step Made the Results Worse
EURUSD is less volatile than GBPUSD.
The intuitive response would be to reduce the grid spacing to match the smaller price movement.
That adjustment made the results worse.
The wider four-pip step originally designed for GBPUSD remained the strongest configuration.
Its profit factor stayed around 1.16–1.21 across the two periods.
A narrower grid caused both buy and sell orders to be triggered more often by small price oscillations.
The wider spacing reduced the number of entries but also acted as a filter against two-sided whipsaws.
The obvious rule that a lower-volatility pair needs a narrower grid turned out to be incorrect.
I Switched the Live System to EURUSD on July 21
On July 21, with no open position and no active order exposure, I changed the main GateGrid AI system from GBPUSD to EURUSD.
The position size remained 0.01 lots.
The GBPUSD-specific gate was intended to be bypassed.
However, the system initially placed no orders.
Several defensive layers originally tuned for GBPUSD were rejecting EURUSD setups.
The first issue was the gate threshold.
I had set it to zero in the .env file, but the startup batch file contained another value that overrode it.
I corrected the batch-file setting.
The second issue was the Ollama avoidance profile.
A classifier trained around GBPUSD conditions was incorrectly identifying EURUSD setups as situations to avoid.
I increased the avoidance threshold from 0.60 to 0.90.
The third issue was a timing-avoidance condition hard-coded into the application.
The condition remained active even after the currency pair was changed.
I moved it into an environment variable so that it could be adjusted separately for EURUSD.
Finally, I terminated the old process still running with the previous configuration and restarted the system cleanly.
Only then did the EURUSD grid orders appear.
The first live order was a 0.01-lot BUY STOP near 1.14.
The forward test had begun.
This Is Not Yet a Success Story
Positive backtest results do not prove that the migration has succeeded.
A profit factor around 1.18 is not large. A small amount of slippage, worse execution, or spread expansion could remove the edge.
The test period may also be too short.
EURUSD could eventually experience the same regime instability that damaged GBPUSD.
For that reason, I will not judge the new version by win rate alone.
I will track actual spread, slippage, average winning pips, average losing pips, maximum favorable excursion, maximum adverse excursion, one-sided fill frequency, two-sided fill frequency, holding time, time-of-day expectancy, and the gap between backtest and live results.
The most important question is whether the average live winning distance remains large enough.
A narrow spread cannot save the strategy if live execution reduces the winning distance again.
What the Five-Bot Test Really Showed
The five bots lost a combined ¥542 on July 20.
By itself, that could be treated as one ordinary losing day.
The deeper GateGrid AI investigation produced a more useful lesson.
Better entries can improve a strategy.
Better exits can improve a strategy.
A larger AI model can improve a strategy.
But those statements only hold when the underlying structure still contains a predictable edge.
When the combination of payoff structure and transaction cost makes the expected value negative, a smarter model may never be enough.
Exit logs are still necessary.
Entry models still need testing.
Risk controls still matter.
But before continuing to optimize them, it is worth checking whether the strategy can mathematically survive on the current currency pair.
Five numbers reveal much of the answer:
Average win, average loss, required win rate, actual win rate, and spread.
The final response to the July 20 loss was not a more intelligent entry rule or a more complicated exit rule.
I stopped trying to repair a version of the strategy that could not overcome its own cost structure.
I kept the underlying logic, abandoned GBPUSD, and moved the live test to EURUSD.
The next question is not whether EURUSD can produce a few profitable days.
It is whether the small edge found in testing can survive real spreads, real slippage, and real execution.
This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit fxaibotlab.substack.com/subscribe