Real-Data Trading Bot Optimization & Validation

Options Trading Bot — Real-Data Validation & Fix.

Why this bot is currently shut down — stated plainly
This is a real-money automated options trading bot (Schwab broker). It is currently fully halted by two independent safety locks (a hard kill switch and a max-drawdown gate), both enforced in code and verified directly against live server logs. It stays off until someone proves — with real data, not guesses — that it can make money without blowing up the account.
The real trading record, from the account’s own ledger:
• 25 real trades: 6 wins, 19 losses
• Realized P&L: -$1,527.85 on a $1,885.57 starting account (81% drawdown)
• The losing streak that did the real damage: six straight losing trades in August with zero wins in between, cutting the account from ~$1,315 to ~$358
Every backtest run on this strategy since has come back negative:
• A full redesign of entry/exit/sizing logic was tested on 5 years of real S&P price data (~13,800 trades). Every configuration tested had a profit factor under 1 and negative expectancy — even with transaction costs set to zero. Simply buying and holding the underlying stock beat every version of the bot.
• A separate exit-timing redesign (adaptive stagnant-window + adverse-cut) was independently re-verified: the negative result is real, not a bug. A look-ahead-bias audit passed 47 out of 47 checks (including a random-walk control test that would have shown a fake positive if the backtest had a data leak). Removing the exit-timing mechanism entirely still comes back negative — pointing to the actual problem being poor entry selection, not exit timing.
• The core, unresolved limitation in every backtest so far: there is no real historical options-chain data. All prices were estimated using a Black-Scholes model, not actual market quotes. Nobody has yet tested this strategy against what option prices actually did in the real market.
Additional real code defects found and fixed in review (not the reason for the shutdown, but real bugs that existed in the live code): hardcoded credentials in source, a stop-loss that could fail to arm at all on a bad price tick, a duplicate-entry bug, a phantom-loss accounting bug, and several NaN-handling bugs that could silently disable a live stop-loss or force-close a position incorrectly. These have been fixed and tested; they are not why the strategy is unprofitable.
What must actually be fixed before this can go live again
1. Real historical options-chain data, not model-estimated prices — at least the last 3-5 years, validated against what the live Schwab account actually shows for spot-checked contracts.
2. A rigorous, pre-registered backtest on that real data — defined hypothesis before looking at results, train/test split, real transaction costs, real position sizing at the account’s actual equity, statistically honest (no cherry-picked date ranges or after-the-fact rule changes).
3. A demonstrated positive expectancy (profit factor meaningfully above 1, positive average R, holds up out-of-sample) before any code touches the live server again.
4. Proof of no look-ahead bias in whatever backtest is delivered — this project already has a working look-ahead audit script; any new work must pass it.
Standing rules — non-negotiable
• No changes to live-trading files without a separate review.
• No live orders under any circumstances during this engagement.
• Nothing gets deployed to the live server without a separately reviewed backtest proving positive expectancy on real data.
• A negative result is an acceptable, fully paid outcome if the methodology is honest — a false positive from sloppy or overfit analysis is not.
Important — read before applying
We are paying for a rigorous, honest answer, not a promised outcome. Nobody — including us — knows in advance whether this strategy has a real edge; that is exactly what this engagement is meant to find out, using real data and sound methodology. Do not bid on this job if your plan is to guarantee profitability or to tune a backtest until it looks good. A clean negative result, delivered honestly, is a full success and will be paid in full. A dressed-up false positive will be caught (we have working look-ahead-bias and overfitting checks from prior review work) and will not be paid.
What we’re looking for in a contractor
We previously worked with a contractor on this codebase; that engagement is ending. We are hiring someone new and expect a higher standard: rigorous, honest, real-data-backed work, delivered on time, with no shortcuts and no dressing up a bad result as a good one. If the honest answer is “this doesn’t work,” say so clearly — that is a valid and fully paid outcome. If it does work, prove it with numbers that hold up to scrutiny.
Strong Python, quantitative finance / options pricing background, and experience with real market microstructure data (bid-ask, fills, slippage) required. Please describe your approach to avoiding overfitting and look-ahead bias in your application.