The IP process is the core research cycle for every QR member — from concept to deployment.
An Investment Proposal is the formal research deliverable every QR analyst produces. It documents a complete quantitative strategy from economic rationale to backtest results. It is not code — QR writes the IP, QD implements it. The IP is the source of truth that QD builds from and QT evaluates for portfolio fit.
The document has four sections, each with specific required content. You cannot skip ahead: Section 2b (the QD approval gate) must be completed and signed off before any backtest work begins.
These are not suggestions. An IP fails at submission if either gate was not cleared.
Before any backtest, the analyst must have written confirmation from the Head of Data Engineering that the required data is available, ingestible into TimescaleDB, and (if alternative data) properly licensed. No sign-off = no backtest. No exceptions.
What the sign-off must confirm: exact asset/frequency/date range available, ingest pipeline feasibility, and any licensing cleared.
The completed IP is reviewed by QR leadership and QT. Evaluated on economic rationale, rigor, portfolio fit, and creativity. Approved strategies move to incubation. Rejected IPs may be resubmitted with substantial changes only.
No IP reaches this stage without Section 2b signed off. Both gates must be cleared.
The hypothesis must explain why the edge exists — behavioral bias, structural constraint, or risk premium — not just that it appeared in the data. The mechanism must explain why it will persist, not just that it did historically.
Proper out-of-sample or walk-forward validation. Realistic slippage and commission assumptions. No look-ahead bias anywhere in the data pipeline. Results must hold under parameter perturbation — sensitivity analysis required.
Correlation analysis against existing live strategies is required. A lower-Sharpe strategy can still be approved if it provides genuine diversification. A high-Sharpe strategy that doubles existing exposure may be rejected.
Novel data sources, unconventional signal construction, and rigorous data cleaning are valued. Incremental tweaks to existing strategies require strong justification. Alternative data must have confirmed licensing and sufficient lookback history (5+ years, ideally 10+).
Use this when reviewing an analyst's workshop readiness. All items must be checked before a workshop clears to submission.
Section 2b not completed or not signed by Head of Data Engineering. Look-ahead bias present in signal construction. Results reported gross of transaction costs. Strategy re-submitted without substantial changes after prior rejection. Backtest window cherry-picked to hide underperformance.
These are the templates analysts are given in the training program. Use them to calibrate what you expect to see.
Economic mechanism: Market participants systematically _____ because _____, which causes prices to _____. Predicted relationship: When [signal] is [high/low/rising/falling], [asset] returns are expected to be [positive/negative] over [horizon], because [mechanism above]. Falsifiability: This hypothesis would be rejected if [specific quantitative condition — e.g., IC < 0.02, Sharpe < 0.5 on hold-out, directional accuracy < 55% OOS].
Data sourcing: [Asset] [frequency] from [start] to [end] is available via [source]. Historical archive confirmed via [link/reference]. Ingestibility: [Frequency] data can be ingested into TimescaleDB within [timeframe] of [daily close / event]. [Pipeline status: existing / new work required]. Alternative data: [None required / Licensed via ___ / Confirmed free and public]. Head of Data Engineering approval (Name, email): "[Confirmation that data is available, ingestible, covers requested date range. Any caveats. Signed off.] — [Initials]"