88 lines
2.8 KiB
Markdown
88 lines
2.8 KiB
Markdown
# Project Notes
|
|
|
|
## Objective
|
|
|
|
Build a Python-based trading bot that uses machine learning to determine which assets should be held, then uses the IBKR API to facilitate trades. The first supported trading mode should be paper trading.
|
|
|
|
## Planned Modules
|
|
|
|
### Training Data Collection
|
|
|
|
Responsible for acquiring and storing market, asset, and any future feature data needed for model training and evaluation.
|
|
|
|
The first planned tool is an IBKR daily candle fetcher. It should fetch open, high, low, close, and volume data for a ticker and date range, then eventually persist that data to a ticker-named Parquet file. See [data-fetcher.md](data-fetcher.md).
|
|
|
|
The initial supervised training dataset is documented in [training-dataset.md](training-dataset.md). It derives market-regime features from `SPY`, `VIX`, `TLT`, and `USO`, then labels whether `SPY` closes higher five trading days later.
|
|
|
|
Parquet files are partitioned by ticker, not by date.
|
|
|
|
Open decisions:
|
|
|
|
- asset universe;
|
|
- data vendors and data licensing;
|
|
- historical time range;
|
|
- data storage format;
|
|
- feature update cadence;
|
|
- handling missing data, delistings, corporate actions, and survivorship bias.
|
|
|
|
### Model Generation And Training
|
|
|
|
Responsible for building datasets, training models, evaluating candidates, and writing versioned model artifacts.
|
|
|
|
Open decisions:
|
|
|
|
- prediction target;
|
|
- model family;
|
|
- validation strategy;
|
|
- evaluation metrics;
|
|
- retraining schedule;
|
|
- model artifact format;
|
|
- reproducibility requirements.
|
|
|
|
### Trading Bot
|
|
|
|
Responsible for loading a model, generating portfolio signals, deciding target holdings, and using the IBKR API to place or simulate orders.
|
|
|
|
Initial expectations:
|
|
|
|
- paper trading first;
|
|
- real trading later only behind explicit configuration;
|
|
- clear logging of model version, signals, target holdings, generated orders, and broker responses;
|
|
- separation between signal generation, portfolio construction, and broker execution.
|
|
|
|
Open decisions:
|
|
|
|
- rebalance cadence;
|
|
- position sizing;
|
|
- risk limits;
|
|
- cash handling;
|
|
- order types;
|
|
- failed order handling;
|
|
- market hours behavior;
|
|
- manual override behavior.
|
|
|
|
### Read-Only Web UI
|
|
|
|
Optional future module for checking status without controlling trading behavior.
|
|
|
|
Possible scope:
|
|
|
|
- current holdings;
|
|
- latest signals;
|
|
- recent orders;
|
|
- account summary;
|
|
- model version;
|
|
- bot health and logs.
|
|
|
|
## Near-Term Priorities
|
|
|
|
1. Decide the initial project package structure.
|
|
2. Keep Python packaging and dependency management current with `uv`.
|
|
3. Add a minimal configuration system.
|
|
4. Define interfaces for data collection, model artifacts, and broker execution.
|
|
5. Add tests for the core trading decision boundaries before connecting real broker behavior.
|
|
|
|
## Decisions Deferred
|
|
|
|
The model, features, labels, asset selection rules, risk management rules, and trading cadence are intentionally deferred for later discussion.
|