Project Overview and Business Context
The client was a fintech startup developing a systematic trading product for retail investment portfolios. Their founding team had quantitative finance backgrounds but limited engineering capacity to build the infrastructure needed to test and deploy trading strategies at speed. They needed an MVP that could ingest market data, generate trading signals from a combination of quantitative indicators and LLM-interpreted news sentiment, run backtests to evaluate strategy performance, and produce the documentation required for FCA model risk management review. The UK regulatory context shapes this project significantly. FCA PS22/9 and the model risk management expectations in SS1/23 require that firms using algorithmic or model-driven approaches to investment decisions maintain documentation covering model purpose, data inputs, validation methodology, known limitations, and ongoing monitoring. Building that documentation into the MVP build process, rather than treating it as a post-launch compliance task, was a core requirement. The MVP was scoped as a research and signal generation tool. It does not autonomously execute trades. All signals are reviewed by a human portfolio manager before execution, which is an important distinction for both FCA regulatory classification and for appropriate risk management at the MVP stage.
Technical Architecture and Stack Decisions
The system is built as a Python-native backend with a thin Next.js frontend for signal review and strategy configuration. The data ingestion layer pulls end-of-day and intraday price data from a market data vendor API, stores it in PostgreSQL, and maintains a Redis cache for the most recent rolling windows used in signal calculation. FastAPI serves the internal API between the data layer and the signal generation engine, and exposes a WebSocket endpoint for real-time signal updates to the frontend. The signal generation engine runs as an AWS Lambda function on a scheduled trigger, computing quantitative indicators (momentum, mean reversion, volatility-adjusted returns) and passing enriched market context to GPT-4o for sentiment interpretation and hypothesis generation. Signal outputs are written to PostgreSQL with full provenance: data inputs, model version, timestamp, and the GPT-4o response that contributed to the signal. The backtesting engine is a separate Python module that runs against the historical price database, applies the signal logic to historical periods, and produces performance statistics: Sharpe ratio, maximum drawdown, win rate, and comparison to a benchmark. Results are stored in PostgreSQL and displayed in the Next.js frontend. AWS Lambda handles the scheduled signal generation without requiring persistent compute, keeping infrastructure costs low for an MVP-stage deployment.
Key AI and ML Components
GPT-4o contributes to two parts of the signal generation process. First, news sentiment analysis. The system fetches headlines and short summaries from a financial news API for each instrument in the universe, passes them to GPT-4o with a structured prompt requesting a sentiment score (-1 to 1), key themes, and a confidence rating. These sentiment scores are combined with quantitative technical indicators in the signal generation formula, giving the model a language-based view of market narrative alongside price-based signals. Second, hypothesis generation. When quantitative signals exceed a threshold, GPT-4o generates a plain-English trading hypothesis: what the signal suggests, what risks could invalidate it, and what market conditions would confirm or deny the thesis. This hypothesis is presented to the portfolio manager alongside the signal, supporting informed human review rather than black-box automation. The quantitative indicator layer uses a Python implementation of standard technical analysis: RSI, MACD, Bollinger Bands, and a custom momentum factor, computed from the PostgreSQL price history. These feed into a scoring function that weights quantitative and sentiment signals based on configurable parameters. The weighting parameters are configurable by the client team and versioned in the database, so strategy variants can be A/B tested in backtesting before live deployment.
Challenges Solved and How
Three technical challenges required specific solutions. GPT-4o sentiment analysis can be inconsistent across different news article formats and writing styles. The system prompt includes explicit calibration instructions and few-shot examples of sentiment scoring for financial news, reducing variance in outputs. Post-processing validates that returned scores are numeric and within range before they enter the signal formula. Second, backtesting data integrity. Look-ahead bias, where a model inadvertently uses future data to generate historical signals, is a common error in backtesting systems. The PostgreSQL schema enforces strict temporal boundaries: signal generation queries are constrained to data with timestamps earlier than the signal date, and the backtesting engine logs each data access point for audit. Third, latency management for the scheduled signal run. Processing a universe of 50-100 instruments with quantitative indicators plus GPT-4o calls for each could take several minutes in sequence. The Lambda function processes instruments in parallel batches, with Redis locking to prevent duplicate processing, reducing the total scheduled run time to under 90 seconds for a 100-instrument universe.
Outcome and Measurable Results
The backtesting results from the initial strategy configuration showed a Sharpe ratio of 1.4 over a 24-month backtest period for the primary instrument universe, compared to 0.8 for a buy-and-hold benchmark. Maximum drawdown was reduced by 31% compared to the benchmark, attributed to the volatility filter that reduces position sizing during high-volatility regimes. The sentiment layer added approximately 0.2 to the Sharpe ratio compared to a version of the strategy using only quantitative signals, a meaningful improvement that justified the GPT-4o API cost. The client used the backtesting results and the FCA model risk documentation generated during the build to initiate conversations with two FCA-authorised investment managers interested in licensing the strategy. The hypothesis generation feature was cited by both partners as making the strategy more understandable and trustworthy for regulatory review than competitors offering black-box algorithmic signals.
Lessons for Similar Projects
Separate the decision layer from the explanation layer. The quantitative signal formula should be deterministic and auditable. GPT-4o contributes sentiment inputs and explanations but should not be the sole source of a trading signal. This separation is important both for regulatory documentation and for debugging when the strategy underperforms. Invest in backtesting infrastructure before live deployment. The temptation to go live quickly is strong in investment tech, but a poorly validated strategy can cause significant financial harm. Build the backtesting engine as part of the MVP, not as an afterthought. Build FCA model risk documentation into the sprint, not as a separate project. Every architecture decision, data source, and model parameter that is documented during the build saves weeks of reconstruction later when a compliance review is requested. Finally, configure risk controls conservatively for the MVP. Maximum position size limits, stop-loss triggers, and universe filters should be tighter than the long-term strategy requires, because MVP-stage systems have not been validated under all market conditions.