This content is for educational and informational purposes only and should not be construed as investment advice, a recommendation, or an offer to buy or sell any securities. The strategy concepts, workflows, models, and examples discussed are illustrative only and are based in part on hypothetical backtesting and paper trading. Hypothetical and simulated results have significant limitations, do not reflect actual trading, and should not be interpreted as indicative of future performance or actual customer experience.
The views and opinions expressed are those of the author and do not reflect or represent the views and opinions of Alpaca. Alpaca does not endorse or recommend any specific securities, strategies, or trading methodologies.The author was not compensated for this content but did receive nominal promotional items from Alpaca.
I came to quantitative trading not through traditional finance channels, but through intellectual curiosity and a deep interest in data science. By day, I'm an MSc student at Imperial College London studying geotechnical engineering and data science.
Most people who ask that question read a few blog posts and move on. I couldn't. I kept reading threads and academic papers at midnight, backtesting frameworks at weekends, and debugging execution logic instead of watching TV. The idea that markets, which look so chaotic on the surface, might contain measurable patterns underneath felt like a puzzle I absolutely had to solve.
After several years of experimentation, I developed a research hypothesis that certain sector relationships may exhibit measurable persistence over short time horizons.
The Insight: Slow Money and Sector Rotation
The idea came from watching how institutional money moves. When big funds rotate capital between sectors, from technology into energy or from growth into defense, they don't do it all at once. They can't. The positions are too large. The moves unfold over days, sometimes weeks, in waves of gradual accumulation.
That slowness was something I wanted to explore more. If capital rotation leaves a detectable trail in the price data, a short-term persistence in relative sector performance, then maybe a model could pick it up before it fully plays out. Not predicting the market. Just predicting which sectors would outperform which other sectors over the next five trading days.
I built the universe around seven sector ETFs: XLY (consumer discretionary), XLU (utilities), VGT (technology), VDE (energy), VHT (healthcare), VAW (materials), and IYW (information technology). Liquid, transparent, and between them covering most of the US economy.
Every day, the system computes a handful of features for each ETF: momentum over several horizons, three, five, twenty, and sixty days, and realised volatility. A ridge regression model, trained on the most recent 500 trading days, then ranks all seven ETFs by predicted five-day forward return. The top two get bought. The bottom two get shorted. The resulting portfolio is dollar-neutral, which means I'm not betting on the market going up or down, only on relative sector dynamics.
To reduce timing risk, I stagger the positions. Each day's signal opens a fresh five-day slice, so at full deployment the portfolio carries five overlapping layers. It's a rolling, self-refreshing book that never goes fully in or out at once.
Reviewing the Backtest Outputs
Disclaimer: The hypothetical results detailed below are derived from backtesting a model over the period of 2005-01-01 through 2024-01-01, but they do not represent actual trading and this strategy was not traded with live capital. Hypothetical results do not reflect the deduction of brokerage commissions, transaction fees, or any advisory fees, which would reduce the depicted returns. No inference should be made that past hypothetical results are indicative of future performance, and any language suggesting consistency or a forecast of future results is strictly unwarranted.
I remember the first time I ran the full backtest end-to-end. It was past midnight. I'd been fighting a bug in the position expiry logic for three hours. When I finally fixed it and re-ran the simulation, I sat back and stared at the equity curve for a long time.
The backtest outputs suggested that the model behaved differently across market environments and warranted additional review and stress testing. Because the analysis was hypothetical and highly sensitive to assumptions, I focused more on understanding the model’s behavior and limitations than on any individual return metric.
I ran it again to make sure I hadn't made a mistake. Then I ran it with different transaction cost assumptions, different training windows, different feature sets. Some observations persisted across multiple test configurations, although the results remained highly sensitive to modeling assumptions.
The backtesting process highlighted how sensitive the model was to changing assumptions and market environments.
Research Hypothesis and Model Interpretation
The most important thing I learned from building this is that you have to understand why a signal works before you trust it. A backtest that produces great numbers but has no economic rationale may be overfit to historical noise. This research approach was built around a hypothesis I wanted to explore further.
When energy prices spike, energy sector ETFs tend to outperform, but the full repricing may take several days as earnings estimates are revised, analyst coverage catches up, and institutional allocators adjust. When interest rate expectations shift, utilities and rate-sensitive sectors often respond over days, not minutes. One possible interpretation is that sector rotation may occur gradually enough for certain relationships to appear in historical data.
The decomposition analysis suggested the long and short components behaved differently under varying market conditions.
The hypothetical outputs changed meaningfully under different transaction cost assumptions. Historical relationships observed in backtests may not persist in future market environments
Building the Live System: Where It Gets Really Hard
Here's what nobody tells you about backtesting: it's the easy part.
A backtest is a loop over a list of dates. A live trading system is something else entirely. It has to run reliably every morning, remember what it did yesterday, reconcile with a broker that sees the real world differently than your model does, handle partial fills and missing data and network timeouts, and never, under any circumstances, send a duplicate order.
Building the live execution layer took longer than building the strategy itself. I had to write a persistent state system: a JSON file that records every active position, its entry price, and its scheduled expiry date. Each morning, before anything else, the system loads that file, checks what has expired, and reconciles the expected positions against what the broker actually holds. Only then does it run the model and generate new trades.
I also had to think carefully about execution quality. The backtest assumes I trade at the daily close price. In practice, sending a large market order at the open can move the price against me. The live system slices each target order into smaller pieces and executes them gradually through the session, watching a VWAP benchmark to determine whether conditions are favourable before each slice.
And I had to handle shortability. Not every ETF can always be borrowed for shorting. The system queries the broker each morning to check which tickers are available, and adjusts the short book dynamically if any positions are unavailable.
Every one of these details feels small until it breaks at 9:31am on a live trading day. Engineering discipline matters in systematic trading in a way that most research-oriented people underestimate.
A backtest is a loop over dates. A live system has to survive contact with the real world every single morning.
Discovering Alpaca
When I started looking for a brokerage to connect my system to, I had a very specific wish list. I needed clean Python integration. I needed paper trading that actually behaves like live trading. And I needed an API that was honest about its limitations and didn't make simple things complicated.
I discovered Alpaca through a conversation with ChatGPT. I'd been asking about developer-friendly brokerage APIs and it kept coming up. After an afternoon with the documentation, I understood why. The Alpaca Python SDK reads like someone who actually uses it wrote it. Checking shortability, pulling intraday bars for VWAP, submitting orders with specific time-in-force constraints. It's all there, documented clearly.
The paper trading environment was the real revelation. I could run my full system, live market data, order submission, position tracking, reconciliation, all without putting any capital at risk. The edge cases I hadn't anticipated in the backtest showed up in paper trading first: timing quirks around market open, occasional gaps in bar data, subtle differences between historical close prices and the prices available at execution time.
For a solo researcher trying to build something serious without institutional support, that kind of sandbox is invaluable. It provided a useful environment for testing operational workflows and execution assumptions in a simulated setting.
What Building This Taught Me
The single most important thing I learned is that simplicity is a virtue, not a compromise. Five features and one model: Ridge regression. I experimented with more sophisticated approaches like gradient boosted trees and LSTM architectures which feature engineering pipelines that would make a PhD student proud. None materially improved the hypothetical outputs observed during testing.The discipline of asking "can I explain economically why this feature should predict returns?" before including it made the final model easier for me to interpret and evaluate during testing.
The second thing I learned is that passion and rigor aren't opposites. I care deeply about this project. More than I probably should for a side endeavour during a demanding postgraduate degree. But that passion is what drove me to stress-test the results properly, to validate the signal on out-of-sample data, to spend three hours debugging a position expiry bug instead of just shipping the version that mostly worked. The best research I've done has always been on the things I couldn't stop thinking about.
And the third thing: the gap between a strategy that works on paper and one that works in production is almost entirely an engineering problem. The quant finance literature is full of ideas. The rare and valuable skill is turning one of those ideas into a system that runs reliably, handles failure gracefully, and makes it easy to understand what it's doing and why.
Where This Goes Next
A paper trading implementation is currently being used to evaluate operational workflows, execution assumptions, and reconciliation processes in a simulated environment before considering any live deployment.
The questions I'm most excited about are the ones I haven't answered yet. How does the signal scale with capital? At what AUM does the market impact start to eat into the edge? Are there other instruments, international sector ETFs, perhaps, or single-stock factors that carry similar signals and could diversify the book? Can the holding period be adapted dynamically based on estimated signal decay, rather than fixed at five days?
But honestly, the strategy is secondary to what this project represents for me. I started it because I couldn't stop thinking about a question. I kept working on it because every answer I discovered revealed three more questions. That process, the cycle of hypothesis, experiment, failure, refinement, and occasional genuine discovery is the thing I love most about this field.
If you're reading this because you're thinking about building something similar, the tools are accessible. Alpaca makes the execution layer tractable for individual researchers. The compute is cheap. The data is available. The only thing you need is a question you can't stop thinking about and the willingness to take it seriously.
For individuals interested in quantitative research, modern APIs and paper trading tools can provide accessible ways to explore systematic workflows and learn about market structure in a simulated environment.
About the Author
Steven Wong is pursuing an MSc in Geotechnical Engineering with Data Science at Imperial College London. Outside of geotechnics, he spends his time building systematic trading strategies, thinking about signal decay, and occasionally sleeping.
Past hypothetical backtest results do not guarantee future returns, and actual results may vary from the analysis.
*The Paper Trading API is offered by AlpacaDB, Inc. and does not require real money or permit a user to transact in real securities in the market. Providing use of the Paper Trading API is not an offer or solicitation to buy or sell securities, securities derivative or futures products of any kind, or any type of trading or investment advice, recommendation or strategy, given or in any manner endorsed by AlpacaDB, Inc. or any AlpacaDB, Inc. affiliate and the information made available through the Paper Trading API is not an offer or solicitation of any kind in any jurisdiction where AlpacaDB, Inc. or any AlpacaDB, Inc. affiliate (collectively, “Alpaca”) is not authorized to do business.
**Commission free trading is available to Alpaca's retail customers. Commission free trading means that there are no commission charges for Alpaca self-directed individual cash brokerage accounts that trade U.S.-listed securities and options through an API. However, certain arrangements with authorized business partners or the use of the Elite Smart Router as part of the Alpaca Elite offering may preclude commission free trades by Alpaca Securities. Please refer to the Brokerage Fee Schedule for more information. Relevant regulatory fees may apply. Alpaca reserves the right to charge additional fees if it is determined that order flow is non-retail in nature.
Please note that this article is for educational and general informational purposes only. The examples above are for illustrative purposes only. The views and opinions expressed are those of the author and do not reflect or represent the views and opinions of Alpaca. Alpaca does not recommend any specific securities or investment strategies. Testimonials and examples used are for illustrative purposes only and are not indicative of future performance or success.
Alpaca and the entities referenced in this article are not affiliated and are not responsible for the liabilities of the others.
Alpaca does not prepare, edit, or endorse Third Party Content. Alpaca does not guarantee the accuracy, timeliness, completeness or usefulness of Third Party Content, and is not responsible or liable for any content, advertising, products, or other materials on or available from third party sites.
All investments involve risk, and the past performance of a security, or financial product does not guarantee future results or returns. There is no guarantee that any investment strategy will achieve its objectives. Please note that diversification does not ensure a profit, or protect against loss. There is always the potential of losing money when you invest in securities, or other financial products. Investors should consider their investment objectives and risks carefully before investing.
Securities brokerage services are provided by Alpaca Securities LLC (dba "Alpaca Clearing"), member FINRA/SIPC, a wholly-owned subsidiary of AlpacaDB, Inc. Technology and services are offered by AlpacaDB, Inc.
This is not an offer, solicitation of an offer, or advice to buy or sell securities or open a brokerage account in any jurisdiction where Alpaca Securities is not registered or licensed, as applicable.