System Rules – The Momentum Traders

# The “6/6” System — Complete Schema & Design Reference

*Written 17/9/2026, updated 19/9/2026. “6/6” = 6-month momentum lookback, 6-month fixed hold — the two defining numbers of the system.*

This document describes the trading system now live on top of The Momentum Traders’ existing cPanel infrastructure. Every rule below was arrived at through backtesting on real historical data, not assumption — the research trail is in `claude/LONG TERM PROJECT LOG.txt` in this project; this document is the distilled result, not the working notes.

—

## 1. What the system does, in one paragraph

Every weekday morning, a scanner checks a universe of ~2,900 US stocks for ones up 40%+ over the trailing 6 months and still in a confirmed uptrend. When one qualifies and a portfolio “lane” is free, the system emails Russ with the ticker, a target price and stake amount. Russ places the real trade himself on Trading 212 and confirms the actual fill price via a one-time mobile link. That trade is then held for a fixed 6 months with no active management, at which point the system emails again to prompt a manual exit, again confirmed at the real price Russ actually got. There are 25 such “lanes” running in parallel, each compounding independently, with periodic lane re-levelling agreed as part of the design (see §4). As of 18/9/2026, 24 of the 25 lanes are ACTIVE (one candidate was skipped as unavailable), all sharing the same 6-month exit date around 18/3/2027.

—

## 2. Entry rule

– **Signal:** 6-month price momentum (current price vs. price 6 months ago).
– **Threshold:** 40%+ momentum required to qualify.
– **Trend filter:** price above its 50-day moving average AND above its 200-day moving average, with the 50-day MA above the 200-day MA.
– **No other filters** — no RSI, no relative volume, no ATR, no entry-day price trigger. These were all part of the old short-hold system and were deliberately not carried over; the entry decision is pure 6-month momentum plus the trend filter.
– **Universe:** ~2,900 US-listed stocks, Alpaca-filtered (price ≥ $5, ≥ $2M average daily dollar volume), refreshed weekly. Mega-caps (~top 100 by size) are excluded — tested and found to make little performance difference either way, so left in place rather than removed.
– **No ranking/scoring when multiple candidates qualify in the same week.** Every qualifying candidate is taken as-is (subject to a lane being free); artificially favouring the “strongest” momentum names inside an already-qualified pool was tested and made the typical (median) outcome worse, even though it made the average look better — a classic case of a few huge winners flattering the average while most trades got worse. **This is one significant Opus Five review recommendation that was tested and explicitly NOT adopted** — Opus flagged the old AI-ranking layer (`claude_filter.py`) as the weakest, least testable part of the old systems, and a quantitative ranking rule was tried as the natural replacement, but backtesting showed it made real outcomes worse, not better, so no ranking of any kind — AI or quantitative — was built into the new system.
– **Data-quality protection:** any ticker whose price moved more than 3x (or less than 1/3) in a single day within the 6-month lookback window is excluded from that scan — this is the fingerprint of an unadjusted stock split, not genuine momentum, and was a real bug found and fixed during testing (a 1-for-25 reverse split had produced an apparent +1,815% “momentum” reading).

## 3. Exit rule

– **Fixed 6-month hold. No active exit rule of any kind** — no trailing stop, no moving-average trend-break exit, no AI-judgement check, no manual override for “strong winners.” Every one of these was tested against the same data and every one underperformed simply holding the full 6 months, because they end up cutting genuine pullbacks-within-an-uptrend that would have recovered, and that lost upside outweighs what’s saved on the real losers correctly avoided.
– Extending a hold manually past 6 months for a strong performer was also tested directly and rejected — there’s a small positive average edge to doing so, but it’s carried by a handful of extreme outliers; the median outcome is much smaller, and close to half of “strong winner” positions actually gave back ground rather than kept climbing.
– A wide “catastrophic floor” safety net (e.g. exit anything down 40-50% regardless of the calendar) was discussed as a future possibility but has **not** been tested or built — open item.

## 4. Position sizing — the lane system

– **25 concurrent positions (“lanes”), fixed count.** Tested against 5/10/15/20/25/30/40 alternatives on worst-case drawdown and portfolio smoothness (the only metrics that held up consistently across repeated randomised simulation — raw total-return figures for this kind of test were found to be dominated by which lane happens to catch the few huge winners, not a real property of lane count). 25 sits at the point of diminishing returns and matches independent published research on momentum-portfolio construction.
– **Lane-based compounding, not pool-percentage.** Each of the 25 lanes has its own running capital total, starting at (starting pot) ÷ 25. When a lane takes a new trade, that trade is sized at 4% of *that lane’s own current capital* — not 4% of the whole portfolio’s current value. A lane that’s had a couple of winners compounds forward with more to allocate on its next trade, independent of how the other 24 lanes have done.
– This was tested head-to-head against the alternative (every new trade sized at 4% of the total pool, regardless of which lane) using 200 paired simulations on the same historical data and same random seeds. Lane-based won convincingly on both average and median terminal wealth (roughly 65-70% more), at the cost of meaningfully higher volatility and drawdown (~2x). Given the strategy’s margin over a plain index fund is already tight, the higher-return option was chosen deliberately.
– **Stake sizing is proportional, not a fixed dollar figure.** The system was originally going to run on a fixed $400/lane against a planned $10,000 account; this was generalised to “4% of the lane’s own current capital” once the actual practice account ended up funded differently (£5,000, not $10,000) — the same logic now works correctly regardless of what currency or amount is actually in the account, with no manual conversion needed anywhere in the code.
– **Lane re-levelling (“rebalancing”) — DECIDED YES, build not yet done.** This is the other significant Opus Five recommendation (system review, section 7): periodically reset all 25 lanes back to an equal share of total capital, rather than letting winning lanes compound bigger and bigger indefinitely forever. Opus’s own research, and a separate backtest run independently on our own data (300 paired runs, 25 lanes, 8.5 years), both found this makes a genuinely significant difference — re-levelling every 6 months clearly beat never re-levelling on every measure that matters for a tight-margin system: median terminal wealth +18% (£46,376 vs £39,436), the bad-stretch (10th-percentile) outcome +36% (£29,375 vs £21,640), and worst drawdown cut by 7 percentage points (22.3% vs 29.5%). It only gives up some of the very best lucky-outlier results. **This was agreed as a firm “yes, build it” with Russ on 18/9/2026, and reconfirmed on 19/9/2026** — it is not an open question whether to do it, only how and when. What’s still outstanding is purely the implementation: because all 25 lanes entered together on 18/9/2026, they’ll also all become due to exit together around 18/3/2027, which makes a simple approach workable — average the 25 lanes’ `current_capital` figures and reset each lane to that average, once, right after that shared exit date, before the next batch of trades is assigned. Russ’s current expectation is that this will most likely be a **one-off manual SQL statement** run around 18/3/2027 rather than a fully automated script, since it only ever needs to fire once every 6 months while the lanes stay in sync — this hasn’t been locked in over a small script doing the same thing, and no code exists yet either way, but the decision to re-level is not in doubt. **Needs the mechanism finalised and (if scripted) built before 18/3/2027.**

## 5. Execution model — “notify-and-confirm”

The system never places or closes a trade itself. It only ever proposes one and waits for Russ to confirm what actually happened.

**Why:** Two things drove this. First, Trading 212’s terms of service prohibit algorithmic trading, so full automation was never viable there regardless of preference. Second — and more fundamentally — even in paper/practice testing, the goal is to know what a *real* trade would actually have returned, including the real bid-ask spread and real fill price. A price looked up on a data feed (Yahoo Finance, Alpaca) is never exactly what a person could have traded at. So the design uses the real Trading 212 price at every step, in both practice and (later) live trading, with no code difference between the two modes.

**The flow:**

1. **Entry trigger.** Scanner finds a qualifying candidate and a lane is free. System writes a row with `status = ‘AWAITING_ENTRY’`, a target price, a display-only cushion range (± around the target, for Russ’s sanity-check only — not enforced), a stake amount (that lane’s current capital), and a fresh random `confirm_token`. Emails Russ with all of the above and a link.
2. Russ places the real order in Trading 212 (practice account during testing; the live account later, unchanged code).
3. Russ opens the emailed link on his phone → `confirm.php`, a public webpage that looks up the row by `confirm_token` (no login — the token itself is the only key, and it’s a one-time-use link).
4. Russ enters the real price he was actually filled at, plus the real amount actually invested (see §6 below — this second field was added 18/9/2026 once Trading 212’s FX fee on every trade was understood properly). The page trusts these numbers completely — it does **not** block or reject a price outside the cushion range, since that range is only a visual sanity-check, not a system rule. A “Not available — skip this one” button is also available on this path, so a proposed ticker Russ can’t actually place frees its lane immediately instead of sitting until it auto-expires.
5. On submission: the row is updated to `status = ‘ACTIVE’`, `entry_price` and `invested_amount` set to the real confirmed figures, `exit_date` set to exactly 6 months from today, and `confirm_token` cleared (so the link can’t be used again).
6. **Exit trigger**, 6 months later: the tracker script sets that row to `status = ‘AWAITING_EXIT’` with a fresh `confirm_token` and emails Russ again.
7. Russ closes the position in Trading 212, opens the new link, enters the real exit price.
8. On submission: a row is written to `trade_history` with the real entry price, real exit price, and computed P&L; the row is deleted from `active_trades`; and — the lane-compounding step — that lane’s row in `wbd1_mt_lanes` is updated so `current_capital` becomes the trade’s actual return amount, ready to size that lane’s next trade.

**Status:** built, tested, and now proven live end-to-end (a real 25-candidate `radar_v2.py` run on 18/9/2026, 24 of 25 lanes successfully confirmed ACTIVE, one skipped via the “not available” button). Email sending (DKIM/SPF/DMARC all fixed) is working. The `AWAITING_EXIT` (closing) path has been tested against planted test data but not yet exercised for real — the first real exits aren’t due until around 18/3/2027.

## 6. FX fee handling

Trading 212’s GBP practice account converts currency on every individual US-stock buy/sell (not once in/out of a USD balance, as originally assumed) — roughly a 0.15% fee each way. For an entry, the figure Russ types into Trading 212’s buy box is always the real total spent (fee included); `confirm.php`’s “Amount actually invested” field (added 18/9/2026, pre-filled at the lane’s stake amount, overridable) captures this properly rather than assuming `invested_amount = stake_amount` as the system did at first. **The matching exit-side fee is not yet accounted for anywhere in the system** — not urgent, since no trade has exited yet, but needs a decision (most likely a similar real-amount field on the exit confirmation) before the first real exit around 18/3/2027.

## 7. Data sources — current split, and an agreed change for “Monday”

– **Scanning the universe** (`radar_v2.py`, finding new candidates): Yahoo Finance (yfinance), unaffected by anything below — Trading 212’s API has no price/volume data across the wider universe, only per-account holdings, so it was never usable for this and stays on yfinance.
– **Pricing currently-held positions** (`portfolio_tracker_v2.py`, day-to-day P&L on the 24 active lanes): **currently yfinance, agreed 19/9/2026 to switch to real Trading 212 per-position data**, planned for “Monday”/start of next week, not yet started. Rationale: now that a working Trading 212 API connection exists (built for the account-comparison feature below), there’s no reason to keep two different price sources for the same open positions when Trading 212 can supply the real one directly. First step will be a small disposable test script (same pattern as `t212_test.py`) to confirm the shape of Trading 212’s per-position portfolio endpoint before wiring it into the live tracker. The date-based 6-month exit trigger and lane-compounding logic are explicitly NOT to be touched by this change — only the price feed itself changes.
– **Trading 212 practice-account total-value comparison** (independent of the above): built and working, see §9. Will stay in place as an ongoing health-check even after the per-position pricing switch above, not just as a stopgap.

## 8. Database schema

### `wbd1_mt_active_trades` (existing table, extended)

### `wbd1_mt_trade_history` (existing table)

Closed trades land here: ticker, entry price, exit price, entry/activation timestamps, `pnl_pct`, `invested_amount`, `exit_amount`, `outcome` (currently always `’6-MONTH-EXIT’` since there’s only one exit path), market, sector. **Cleared of all old pre-pivot short-hold trades on 19/9/2026** (`TRUNCATE TABLE`) — this table now holds only genuine new-system exits, none of which have happened yet (first ones expected ~18/3/2027).

### `wbd1_mt_lanes` (built 17/9/2026)

Seeded at (starting pot ÷ 25) per lane — £200/lane on the £5,000 practice pot. Updated only when a trade in that lane is confirmed closed via `confirm.php`. Will also be the table lane re-levelling (§4) reads and writes, once built.

### `wbd1_mt_market_history` (new, built 19/9/2026)

Written by `market_chart.py` (the site’s existing general market-condition chart script — reused, not duplicated). Backfilled to 276 days of real history (15 Aug 2025 → present) via a one-off script. Feeds the dashboard’s market-context chart, so Russ can see how the wider market moved alongside the portfolio, not just from the 18/9/2026 launch date.

### `wbd1_mt_radar_history` (new, built 19/9/2026)

Written by `radar_v2.py`. Required removing an earlier cost-saving shortcut where the script skipped its full scan entirely on a day with zero free lanes — that shortcut made candidate flow invisible exactly when the portfolio is full (the situation as of 19/9/2026, 24/25 lanes ACTIVE), so the scan now always runs and always logs, even on a full-portfolio day.

### `wbd1_mt_ledger_history` (new, built 19/9/2026)

Written by `portfolio_tracker_v2.py`. Feeds the dashboard’s three-way “Portfolio vs S&P 500 vs Trading 212 Actual” comparison chart.

### `wbd1_mt_ledger` (existing table)

Still live — holds the current single-row snapshot of `available_cash` / `total_portfolio` that `portfolio_tracker_v2.py` updates every run (see §10 for the ledger-computation fix). No longer trusted as the *source* of the cash figure (see §10), just the table the corrected figure gets written into each run.

### `wbd1_mt_system_config` (existing table, kept)

Per-system WordPress dashboard display config (name, tagline, colour, etc.) — still live, unrelated to the 6/6 rebuild.

**Removed entirely (dropped 18/9/2026), no longer part of the schema:** `wbd1_mt_momentum_signals`, `wbd1_mt_research_scan_log`, and all seven `wbd1_mt_research_*` tables — confirmed dead/unused by the live lane-based system before being dropped. Systems B and C’s eight dedicated tables (`wbd1_mtb_*`, `wbd1_mtc_*`) were also dropped the same day.

## 9. Trading 212 practice-account comparison

Built 19/9/2026 as an independent sanity-check on the tracked portfolio figures, not something the system depends on for its own logic. `portfolio_tracker_v2.py` calls the Trading 212 practice-account API (`https://demo.trading212.com/api/v0/equity/account/summary`) once per run, using HTTP Basic auth with `base64(T212_API_KEY:T212_API_SECRET)` — confirmed as the working auth scheme via a disposable test script rather than guessed. The API key has only the “Account data” and “Portfolio” scopes enabled — nothing that could place or affect a trade. The result is written into that day’s `wbd1_mt_ledger_history` row (`t212_actual_value`); a failure to reach the API is isolated (its own try/except) and never affects live trade tracking. This comparison directly helped catch the `active_total` bug described in §10 — the tracked total showing a small loss against Trading 212’s real, visible gain was the real-world signal that something was wrong.

## 10. The active_total bug (found and fixed 19/9/2026)

`portfolio_tracker_v2.py` computed each open position’s `raw_change_pct` (the real % move from entry to current price) correctly, but then, in the step that adds each position’s value to the portfolio’s running total, was simply adding back the *original invested amount* — never actually applying `raw_change_pct` to it. In effect the tracked total only ever reflected idle cash plus what was originally staked, regardless of how those positions had actually moved — a position up 20% and a position down 20% contributed identically to the reported total. Fixed by computing each position’s real current value (`invested * (1 + pct / 100)`) and using that instead, for both `ACTIVE` and `AWAITING_EXIT` positions. This had been silently understating true portfolio performance every day since `portfolio_tracker_v2.py` first went live (18/9/2026) until it was caught and fixed the next day. Confirmed fixed against real data: the dashboard now correctly shows a genuine profit (Net Capital Value £5,048.28, +£48.28) matching the real Trading 212 balance (£5,022.45) closely, rather than a phantom loss. This is separate from, and in addition to, the earlier (also 18/9/2026) fix that made `available_cash` itself derive from `wbd1_mt_lanes` first-principles instead of a stale `wbd1_mt_ledger` field.

## 11. Dashboard

`momentum_traders_dashboard_v2.php` — a ground-up rebuild (19/9/2026) of the old short-hold-era dashboard, deployed as a preview page (`[mo**ntum_traders_dashboard_v2]` shortcode) NOW swapped in as the site’s main dashboard. Replaces every stale element the old dashboard had (a dead signals-table query, the wrong sync-button target, obsolete PENDING/trigger-price and GREEN/AMBER/RED logic, a hardcoded £10,000 base) with the current lane-based design: a 25-tile lane-status grid, an Open Positions table with real exit dates and status badges, four Chart.js charts (portfolio equity, portfolio vs S&P 500 vs Trading 212 actual — indexed to % change so the very different scales don’t need a dual-axis chart, market context, and candidate flow), and a Historical Settlement Archive table (currently empty, per §8, ready for genuine exits only). Verified via `php -l` and a local test harness executing the real render function against realistic fabricated data before being shipped, per the project’s “never deploy unverified files” rule.

## 12. Scripts — status as of 19/9/2026

| Script | Role | Status |
|—|—|—|
| `radar_v2.py` | Daily scan (Mon–Fri, 06:30 server time) for qualifying candidates, notify-and-confirm entry flow | **Live and running.** Writes `AWAITING_ENTRY` rows with lane assignment, sends the notification email, and now always writes a `wbd1_mt_radar_history` row every run (even with zero free lanes). |
| `portfolio_tracker_v2.py` | Daily (06:00 server time) check of active trades, ledger computation, AWAITING_EXIT trigger | **Live and running.** Cash/total computed first-principles from `wbd1_mt_lanes` (18/9/2026 fix); `active_total` now correctly marks open positions to market (19/9/2026 fix); writes `wbd1_mt_ledger_history` and the Trading 212 comparison every run. Per-position pricing is still yfinance-based — agreed to switch to real Trading 212 data “Monday” (§7), not yet started. Lane re-levelling (§4) is agreed but not yet coded here or anywhere else. The `AWAITING_EXIT`-triggering branch itself is untested against real data (no trade has reached 6 months yet). |
| `confirm.php` | The mobile confirmation page | **Built and fully tested**, both paths (entry and exit), including lane-capital compounding, the “skip this one” button, and the real-invested-amount field — proven end-to-end with real live trades (18/9/2026). |
| `email_utils.py` | Sends the notification email | **Working.** DKIM/SPF/DMARC/MX all fixed 18/9/2026; a real 25-candidate notification email was sent and received successfully. |
| `universe_refresh.py` | Weekly universe rebuild (replaces the old AWS-based `export_universe.py`) | Built and running. |
| `market_chart.py` | Market-condition chart + (new, 19/9/2026) daily market history | Extended to also write `wbd1_mt_market_history` daily; deprecation warning (`db=` → `database=`) fixed in passing. |
| `backfill_market_history.py` | One-off historical backfill for `wbd1_mt_market_history` | Job complete (276 rows) — safe to delete from the server. |
| `t212_test.py` | One-off Trading 212 API auth verification | Job complete (confirmed HTTP Basic auth works) — flagged safe to delete from the server. |
| `claude_filter.py` | Old AI-ranking step from the short-hold systems | Made obsolete by the “no ranking” decision (§2) — confirmed the *quantitative* replacement also underperforms, so no ranking layer of any kind is planned. **Not yet decided** whether anything about the file itself survives or is retired outright. |
| `research_archiver.py`, `daily_summary.py` | Research/reporting scripts | **Currently broken** (found 19/9/2026) — still writing to `wbd1_mt_research_*` tables dropped 18/9/2026. Not yet fixed. |

## 13. What’s proven vs. what’s still open

**Proven / decided (tested against real historical and/or live data, or explicitly agreed):**
– 6-month lookback / 6-month hold beats the academically-favoured 12-month/3-month alternative on this system’s own universe, both before and after real trading-spread costs.
– No active exit rule (trailing stop, trend-break, manual override) beats a plain fixed 6-month hold.
– 40% entry threshold is close to the point of maximum win-rate/median-trade benefit before diminishing returns set in.
– 25 lanes is close to the point of diminishing returns for drawdown/volatility smoothing, and matches independent published research.
– Lane-based compounding sizing outperforms pool-percentage sizing, at the cost of higher volatility.
– **Lane re-levelling every 6 months (an Opus Five recommendation) makes a significant, well-evidenced difference to profits** — both Opus’s own research and an independent 300-run backtest on our own data agree, and building it has been firmly agreed with Russ (18/9/2026, reconfirmed 19/9/2026). Only the implementation mechanism and the actual build are outstanding, not the decision itself (§4).
– `confirm.php`’s full logic, including lane compounding, the “skip” button and the real-invested-amount field, works correctly end-to-end — proven with real live trades, not just planted test data.
– The mega-cap exclusion makes little proven difference either way, kept as-is rather than removed.
– The full notify-and-confirm loop (scan → email → confirm → database update) works end-to-end with real data (18/9/2026, 24 of 25 lanes).
– The ledger’s cash/total figures and the portfolio’s active-position valuation both derive correctly from first principles (two separate bugs, found and fixed 18/9 and 19/9/2026 respectively).

**Still open / not yet done:**
– Lane re-levelling’s **implementation** — agreed and decided as a “yes”, but not yet built. Russ’s current expectation is a one-off manual SQL job around 18/3/2027 rather than a script, but this isn’t finalised, and no code exists either way yet (§4).
– Switching `portfolio_tracker_v2.py`’s per-position pricing from yfinance to real Trading 212 data — agreed, planned for “Monday”, not started (§7).
– Exit-side FX conversion fee is not yet captured anywhere (§6) — needed before the first real exit (~18/3/2027).
– `research_archiver.py` and `daily_summary.py` are currently broken (writing to dropped tables) — found 19/9/2026, not yet fixed.
– A “catastrophic floor” safety net (e.g. force-exit anything down 40-50%+ regardless of the 6-month calendar) has been discussed as a reasonable idea but never tested.
– A possible systematic rule for holding past 6 months with a trailing stop underneath (rather than a flat “hold longer”) was flagged as an interesting future research question, not pursued.
– Whether a news/red-flag layer for existing holdings (not new entries) is worth building was reframed but not designed — lower priority since active exits already don’t help even with clean price data.
– What (if anything) survives of `claude_filter.py`.
– Trading 212 doesn’t carry 100% of the universe (a 25-ticker spot-check found 22 available) — not treated as a live problem, since an unavailable ticker is simply skipped by Russ at confirmation time (the “skip this one” button), and candidate flow was never tight to begin with.
– `momentum_traders_dashboard_v2.php` is a preview page only — not yet decided when/whether to swap it in as the site’s main dashboard.

—

*Full research trail, including every backtest’s exact methodology, sample sizes and data-quality caveats, is in `claude/LONG TERM PROJECT LOG.txt` in this project.*
</content>
<parameter name=”if_version”>latest