Building a Smarter Trading System
Building a Smarter Trading System: Planning the v5.0 Multi-Regime Architecture
Date: December 17, 2025 Category: Architecture Planning Reading Time: 8 minutes
The Problem with Static Trading Systems
When I first built Trader-7, it was designed around a simple premise: follow trends, manage risk, and let the LLMs handle the nuanced decision-making. And it worked—mostly. But after running the system live for several weeks and analyzing the results, a pattern emerged that I couldn't ignore.
The system was making the same kinds of decisions in wildly different market conditions.
A 68% confidence LONG signal in a strong bull market isn't the same as a 68% confidence LONG in a bear market with 15% drawdown from highs. The technical setup might look identical, but the risk profile is completely different. My static system couldn't see that distinction.
Today, I finished planning the most significant upgrade since launch: Trader-7 v5.0, a complete architectural transformation from static trend-following to dynamic, multi-regime, risk-aware trading.
What's Changing: The 10-Sprint Roadmap
After reviewing feedback from 6 different LLMs (yes, I had AI review my AI trading system) and validating against 5 years of historical data, I mapped out 10 sprints covering approximately 70-90 hours of implementation work.
Here's the high-level breakdown:
Phase 1: Safety First (Sprints 37-39)
The 59-Minute Blind Spot
My current system runs hourly decision cycles. That means if the market crashes 10% in 15 minutes, I won't know until the next cycle runs. In crypto, 59 minutes is an eternity.
Sprint 37-38: High-Frequency Risk Monitoring
I'm implementing a separate 5-minute "Risk Loop" that runs alongside the main decision engine. It doesn't make trading decisions—it just watches for danger:
- Portfolio drawdown exceeding 15%
- Intraday crashes (5% drops within 15-minute windows)
- Stale data or degraded exchange performance
- Margin health deterioration
When it detects problems, it can halt trading or close positions immediately without waiting for the next decision cycle.
Sprint 39: Correlation-Aware Risk Management
Here's something that surprised me in the analysis: during market crashes, BTC, ETH, and SOL have a 73.9% correlation. So if I'm holding positions in all three during a crash, I don't have diversification—I have 3x concentrated risk.
The new CorrelationManager tracks "notional delta" per correlation cluster and blocks trades that would create excessive concentrated exposure. Maximum $50k notional in the "major crypto" cluster (BTC/ETH/SOL), separate limit for XRP (regulatory risk is different from market risk).
Phase 2: Dynamic Regime Detection (Sprints 40-41)
Beyond Binary BULL/BEAR
The current system thinks in binary: trending or choppy. But markets have nuance. A coin 15% above its 200-day moving average behaves differently than one 5% above. One is euphoric bull territory; the other is cautious optimism.
Sprint 40: 4-Tier Global Regime Architecture
The new system detects four distinct market states based on BTC's distance from its 200-day MA:
| Regime | Condition | Strategy Bias |
|---|---|---|
| STRONG_BULL | >10% above 200MA | Full trend-following |
| WEAK_BULL | 0-10% above | Cautious trend-following |
| WEAK_BEAR | 0-15% below | Favor mean-reversion |
| STRONG_BEAR | >15% below | High-conviction mean-reversion only |
Each regime has its own Policy Matrix that adjusts:
- Risk multipliers (how much to size positions)
- Confidence thresholds (how sure we need to be)
- Which strategies are even allowed
In STRONG_BEAR, trend-following is completely blocked unless Fear & Greed drops below 10 (extreme fear = contrarian opportunity).
Sprint 41: Asset-Specific Risk Profiles
Not all coins are created equal. SOL has high volatility and occasional network outages. XRP has regulatory overhang. The new asset profiles adjust:
- ATR multiples for stop-loss calculation
- Base risk allocation (SOL gets 0.5x, BTC gets 1.0x)
- Volatility-based sizing overlays
One important fix: the original spec had a bug that double-counted ATR in volatility calculations. Caught that during the planning phase—better now than in production.
Phase 3: Exploiting Edges (Sprints 42-43)
Sprint 42: Funding Rate Optimization
The current system avoids high funding rates (good), but it doesn't exploit negative funding (money left on the table). When shorts are paying longs, that's essentially free alpha.
The new confidence scorer applies a bounded z-score bonus:
- Negative funding on a LONG position = up to +10% confidence bonus
- High positive funding on a LONG = up to -10% penalty
This nudges the system toward trades where the funding rate tailwind supports the position.
Sprint 43: SOL & XRP Special Handling
These two assets need idiosyncratic risk management:
SOL: Network outages are real. The system will check Solana block progression before opening SOL positions. If blocks aren't advancing, no trade.
XRP: Rather than rely on brittle news APIs for regulatory monitoring, I'm implementing a relative volume spike detector. If XRP volume suddenly hits 3x its 24-hour average, something is happening—news, whale activity, regulatory rumor. The safe move is to wait.
Phase 4: Mean-Reversion & Refinements (Sprints 44-45)
Sprint 44: Complete Mean-Reversion Strategy
The original spec mentioned mean-reversion but never defined exit logic. Now it's complete:
- Entry: RSI < 30 (long) or > 70 (short)
- Exit: RSI normalizes to 50, OR time-based failsafe at 48 hours
- Sizing: 0.5x normal position (higher risk strategy)
- Stops: 2.5x ATR (wider, to accommodate counter-trend volatility)
Also updating Claude's validator prompt to recognize mean-reversion context. Currently, Claude rejects valid contrarian setups as "falling knives" because it doesn't know the trade is intentionally counter-trend.
Sprint 45: Cross-Asset Signal Confirmation
When BTC and ETH are both oversold, that's stronger confirmation than either alone. The data shows +3.7% win rate improvement from cross-asset confirmation, translating to +10.3% expected value improvement.
Simple implementation: 10% confidence bonus when both majors show aligned extreme readings.
Phase 5: Documentation (Sprint 46)
The final sprint updates architecture.md and product-description.md to reflect the v5.0 changes. Documentation debt is real debt.
The Technical Details
New Components (~440 lines of new code):
| Component | Purpose |
|---|---|
StateManager |
Trading status persistence (WAL-mode SQLite) |
RiskMonitorLoop |
5-minute safety monitoring |
CorrelationManager |
Cluster-based delta tracking |
PolicyMatrix |
Regime→Strategy→Parameters mapping |
RegimeDetector (enhanced) |
4-tier global + volatility regimes |
Infrastructure Changes:
- Second Railway cron job for Risk Loop (every 5 minutes)
- SQLite WAL mode for concurrent loop access
- No Redis or additional databases required
What's NOT Changing:
- Existing ADX regime detection (kept as local trend filter)
- InstrumentSelector (spot vs perpetual choice)
- LLM decision pipeline (DeepSeek strategist → Claude validator)
- Position tracking and reconciliation
The Critical Path
Some sprints can run in parallel, others have dependencies:
Sprint 37 (StateManager) ──┬──→ Sprint 38 (Risk Loop)
└──→ Sprint 39 (Correlation)
Sprint 40 (Regime) ──┬──→ Sprint 41 (Asset Params)
└──→ Sprint 44 (Mean-Reversion)
Sprints 42, 43, 45 are independent
Sprint 46 (Docs) comes last
If I parallelize effectively, the entire v5.0 implementation could compress to 5-6 weeks of focused work.
What I Learned Planning This
1. AI reviewing AI works
Having 6 different LLMs analyze the original spec caught edge cases I missed: the volatility double-counting bug, the Fear & Greed logic conflict, the incomplete mean-reversion exit conditions. Different models have different blind spots.
2. Historical validation is essential
The original spec recommended regime-gating SOL to bull markets only. The data showed this actually hurts performance. SOL makes money in bears too—you just need tighter risk management. Intuition != evidence.
3. Minimal infrastructure changes enable faster iteration
I could have over-engineered this with Redis for state management, a separate microservice for the Risk Loop, a time-series database for price caching. Instead: SQLite with WAL mode, a second cron job, and in-memory price buffers. Simple systems ship faster.
Next Steps
The plan is documented and approved. Implementation starts with Sprint 37 (StateManager foundation) which has no dependencies and unblocks everything else.
I'll continue paper trading on the current v4.x system while building v5.0 in parallel. Once the new architecture is complete, I'll run both versions simultaneously to validate the improvements before cutting over.
Target: v5.0 live by late January 2025.
Building an AI trading system in public. Follow along for the wins, the losses, and everything in between.
Full implementation plan: See project-plan.md in the Trader-7 repository
Source specification: Ideation/Trader7_Master_Specification_v5.0.md