This thread and system reads like a cautionary tale for overfitting backtested results.
Its def been an ENDLESS battle of SMARTY-Smart Martingale vs overfitting. Recent posts to this dev log have been devoted to stable parameter selection and NOT overfitting the parameters. My current parameter selection backtests arent near as pretty as my previous ‘fitness’ algorithms that had a touch of ‘overfit’. The current are more anti-overfit and still project returns with very low DD risk at Monte-Carlo 95% (10% skip). I’ve been slowly boosting risk since DD has only been 1.2% since I finalized SMARTY algo Mid Dec 2025.
I’ve been computing my own ‘fitness’ formula to combat overfitting and I thought I had cracked it earlier until chatting with a couple of the LLM’s. I never talk in specifics to them. Only topics and they showed me proof that my solution wich partially relied on a LARGE number of trades and the law-of-large-numbers as secondary verification could return valid and ‘overfit’ solutions. It def sparked my current anti-overfit solution and showed me how easily a genetic solution could be ‘overfit’ - even with safeguards.
So, at this point I’m past the coding challenge and almost any recent changes have been adjusting my pre-programmed algo controls. Posted are my current parameter selected backtests. Results are downside since I test with 100ms delay and VPS is often more profitable.
Currently running C2 with larger lot multiplier than backtest for higher RR with much room to expand. I’ll make sizing adjustments every 3 months. Finishing my system was well timed with the end of 2025. Finished the code and moved it to a new more powerful VPS server for execution stability. 2026 should be exciting!
I WILL NOTE: that its BETA=0.01 is holding up quite well against the STORM thats happening in Stocks, Metals and Bitcoin. Its def showing its ‘Edge as a Hedge’. You almost cant see the storm reflected in the trading activity and the algo trades 24/5 non-stop. No intervention.
Guess Who’s BLACK!! - BlackOpz with SMARTY-Smart Martingale. Sheeesh!! These last few months have been a slog. I usually comment anytime winning or losing since my algo has been in the process of active development and progress wasnt static. This time I wanted to wait until I had a profitable month. (I think I made $5 this month soooo BINGO!)
The current graph isnt showing its best self but I believe ‘The Best Is Yet To Come’ Mode is ACTIVE. This all traces back to my last few posts where I realized that even good algos are locked to their settings so the #1 job of good optimization is to find settings that are robust enough to operate in unpredictable regimes since I want 100% hands-off operation. What really tortured me was that fact that even after a bad month you can always run an optimization that could have traded the same period yet produced a profitable result. How can you discover those near robust settings BEFORE approaching the next time period?
Hmmmm… That sent me down a rabbit hole. Show & Tell: I have a copy-traded FTMO 10K account linked to these same trades. A much smaller multiple but the performance tracks closely with C2 (even though with sharp FX movements, C2 gives slightly more negative slippage).
Let’s start with February: Having a ‘Losing’ algo is easier to improve than one that is inconsistently profitable. When you see that algo has periods of profitable trading then a losing streak you can’t tell the difference between acceptable performance and expected variance when drawdown never dips dramatically. Especially this algo that was working well before this Trump term.
February represents a typical trading month at that time. The algo is quite active and usually trades every day, often multiple times per day. As you can see from the calendar (@MatthewKlein which I wish was a viewing option on C2 - So much easier to see day to day action) the algo had about an equal chance of being profitable/loss for the day. Normally netting more on profitable trades than losing trades BUT I couldnt create a loss filter that didnt hurt the profit side.
March was going along fine until some Trump action that freaked the markets out. The currencies were moving and gapping wildly BUT I would have still been profitable if I wasnt taking losses on TWO currencies at once. This is when I really fixated on trying to come up with some method of reducing the trading frequency. ‘Cowboy’ mode was gonna need some taming.
April was similar to March. With plenty of positive trades for the month with the monthly end result being hurt by a single, multiple losing trade day. Grrrrr…
May was my first real breakthough where I stopped trying to have an algo that could trade ‘most’ of the market to one that only trades its A++ setup. BINGO!! - I was shocked!! This was the first time I’ve ever traded a system that trades so infrequently. It felt weird at first. I was so used to viewing trade signals everyday that I ‘felt’ the loss of action.
Also, in only trading A++ setups the chances of both currencies trading at the same time were greatly reduced. Resulting in my biggest loss day being only half the loss of previous ‘bad’ days. During this time I was also refining my parameter selection method. Now I had reduced my trading frequency via smarter trade selection (‘Edge’ trade only). In May I also modified my optimization criteria to target more robust parameters.
June is when it all came together. The first week of June, I was reoptimizing the parameters. Unfortunately, it takes about 2 to 3 days to optimize each currency and I spent most of the first week optimizing using my improved method, so I’m pretty sure that largest loss was before my new method was implemented. (ideally I run multiple optimizations and stack them for higher parameter accuracy. Of course, I’m dreaming of a future maxxed PC that can render 48 hours tests in less than 2 hours)
Also, my updated optimization criteria was showing GREAT promise in testing. A few additional ‘light-bulb’ moments expanded and improved this selection criteria. June was more active than May but thats due to currency movement and not algo code. May was flatter than June and the algos tendency to ‘not’ trade caused the algo to trade less. May and June used the same trade triggers BUT June was using my more ‘accurate’ and expanded parameter selection method.
Also ‘Edge’ trading doesnt require monthly optimization since the algo doesnt need to ‘learn’ the market as much. Its just waiting for its ideal setup. For now I’ll prob re-optimize every 2 months just to be more market adaptive with the possibility of extending that to 3 months but so far everything seems to be operating as expected.
Below are the new parameters optimizations I’ll be using for July/August. Both have >50% (near 60%) win rates and C2 for the last few weeks has been trading at about 60%. July will be the first full month of this method but I expect it to be solid within variance.
The result of the past 5 months was WILD! - With so many winning days you can see how hard it can be to ‘improve’ an algo that keeps losing to ONE bad day per month. When LOSING you know you need to ‘fix’ something but treading water is really a confusing state. For me, trimming the ‘equity pullback’ side of profit surges shaves off enough losing trades to boost my win-percentage and end result.
Combined on a 50K account the $5,700 gain is roughly 11% projected gain for the core signal account. I’m running C2 at about 2X sizing for 20%ish gain. After the next couple months I’ll considers boosting it higher if the drawdown continues to track near its projection. After July/August I’ll review the drawdown but 30% to 40% gain with less than 10% drawdown looks like its on the table. Time will tell. Stay tuned…
Ladies and Gentlemen… I Think We Got 'Em. SMARTY - Smart Martingale had a meh month, but it helped turn some final screws that should tip the balance going forward.
The BIG news of the month was the USDJPY Black Swan that killed tons of traders that finance other investments with that trade. The dip was MASSIVE:
I was in active trades the entire time and didnt even touch the algo. I didnt even know it happened until hours later. (The JOY of unattended algo trading). All of my concentration on risk management and downside protection came into play and worked textbook! On the USDJPY side the algo easily switched from BUY to SELL and profited from the volatility. In this situation, I’m more concerned about ‘Do No Harm’ so having even mild upside was nice. In a perfect world, I would have had a few more larger wins, but the movement whipsawed so wildly that my trailers kept getting activated and hit early.
USDJPY June Parameter Optimization:
Also, profitably USDJPY trading the madness is replicated in my ‘what-if’ check backtest. Below is my original backtest optimization with 40% OOS ending 06/01. Since this is 2-Months later I run the same parameters and lengthen the time period to 08/01, extending the OOS period to 60%. I do this to see how closely the extended 2 months match what actually happened (the start of the test is moved forward 2 months to keep the profit comparable).
USDJPY 6 Months Extended OOS:
The algo has been updated in ways that further reduce risk and aren’t present in the 1st backtest. In the future, backtests will be more apples-to-apples. So this shows that even with the backtest trading through the USDJPY crash, the algo predicted the smooth sailing that the code showed in actual trading performance.
That def gives me confidence that my algo optimization method can actually discover parameters with alpha and my backtesting methodology can be ‘trusted’. The BEFORE June selected parameters that ‘should’ work, DID WORK going forward, and they did in both backtest confirmation and actual execution. NICE.
GBPUSD June Parameter Optimization:
On The Other Hand: GBPUSD was also just as accurate, except it shows and verifies a LOSS that happened in both backtest AND actual trading. Ughhhh.. The extended OOS test also accurately reflected what happened in actual trading. When USDJPY Black Swanned so hard that it created opportunity, GBPUSD just whipsawed without direction, hitting my volitility/volume limits and causing the algo to ditch the trade. In that instance, I can see how my updated risk management would have limited the loss even further.
GBPUSD 6 Months Extended OOS:
It looks like a scary dip but in reality its only 1.59% but it looks HUGE in relation to the small bumps up to that point. In actual trading the loss was probably closer to 2% BUT this loss activated rarely triggered risk code and provided the info I needed to optimize its function. In the future my previous worst-case losses will be trimmed by 25% to 40%.
C2 July ended with a -1% loss but I’m pretty sure I could have been BE or positive. During the month I experienced a few Platform Transmit errors and outages that OF COURSE only happen when it’s a profitable trade that would be missed. Between the missed trades (since updating to latest PT its been 100% OK - so fingers crossed) and the July higher allowed loss limits (since lowered) I think the July 1% ‘learning’ cost will be easily repaid 100X times over in the future.
Even though on its face the July -1% month is 'Meh. Overall, it helped me tighten my risk-management code even more and def prevented a worst-case scenario. If any future ‘Black-Swans’ events only cost me 1%… I’ll Take It!! It also helps validate that my optimization process can actually find an alpha path in historical data. USDJPY shows that when working properly the backtesting/optimization process is a valid pipeline, while GBPUSD shows the same profitability possibility and downside protection.
Putting Both USDJPY/GBPUSD Backtests Together:
Combining the 60% OOS backtests accurately shows that July SHOULD have been about a 1% loser. Other than July most other months are profitable. What’s weird about July is that it would have been mentally easier for me to take the loss from USDJPY since it Black Swanned than GBPUSD that didn’t (Ooof).
NOTE: I run C2 at 2X of these sizes so possible Yearly Profit is 27.86% and Max Drawdown should be about 7.24%. I also performed 5% skipped trades Monte-Carlo on the OOS portion only and it predicts 3.21% drawdown at 95% confidence (So C2 18.82% Profit and 6.42% C2 DD at 2X sizing)
I’ll probably keep pushing drawdown to near 10% to 12% to maximize profitable upside. I’ll be running this <10% DD configuration for the next couple months then consider making adjustments if needed. Also these numbers should be worst-case scenario. In actual trading, the algo uses an additional filter that limits losses seen in these backtests so I feel pretty confident using these numbers since actual trading should outperform them.
JULY Changes: - Mid Month increase in C2 sizing from 1X to 2X+ since drawdown remained low. Code updates to limit Black-Swan losses (should reduce losses by 25% to 40%). Increasing upside risk while lowering losses should increase profit with minimal downside risk cost.
