Quant Trading Automation
Spent less time inventing strategies than on checking whether a strategy has an edge and on being able to start, stop, and record it safely. tqt handles validation and execution; Fleet is the operating dashboard.
Period · 2025–present
Role · Individual project · tqt (Toss Open API) · Quant Trading Fleet
Source · GitHub repository
Quick read
The through-line of the work.
Open
The starting question
What does running trading rules as a service require beyond strategy code, and how do you confirm the rules actually have an edge?
Build
What I checked
I started with Daily-bar backtest over eight domestically listed global ETFs and two government-bond ETFs, 2011–2026 and moved through Separate strategy from broker logic -> Make state and history visible -> Backtest on measured costs -> Validate out-of-sample, then on paper.
Turn
What changed my view
Out-of-sample, the Faber moving-average sleeve returned 7.36% CAGR with a 1.01 Sharpe, a −14.1% maximum drawdown, and decay of ×1.28, so there is no sign of overfitting.
Close
Where I draw the line
Paper-trading validation only. Backtest figures are simulations on historical data and claim no real-money operation, return, win rate, or capital growth.
01 · Start
The question I began with
What does running trading rules as a service require beyond strategy code, and how do you confirm the rules actually have an edge?
02 · Material
The data and evidence
03 · Work
How I worked through it
- 01
Separate strategy from broker logic
Designed a broker abstraction layer to isolate per-exchange differences in market data and order handling.
- 02
Make state and history visible
Persisted bot state, settings, execution history, and operating logs, controlled through a FastAPI service and a React dashboard.
- 03
Backtest on measured costs
Replaced assumed fees with the account's actual rates from the API and applied slippage and next-open fills so cost assumptions match reality.
- 04
Validate out-of-sample, then on paper
Reported performance only from a five-year train, two-year test walk-forward, then validated operations with paper trading that fills against the live order book.
04 · Takeaway
What the numbers suggested
Out-of-sample, the Faber moving-average sleeve returned 7.36% CAGR with a 1.01 Sharpe, a −14.1% maximum drawdown, and decay of ×1.28, so there is no sign of overfitting.
Buy-and-hold still wins on CAGR at 8.94%. What tactical allocation buys is not return but drawdown, cutting the maximum from −20.1% to −14.5%.
The Toss Open API serves only about four days of one-minute bars, which makes intraday backtesting impossible. Choosing low-frequency daily strategies was a constraint, not a preference.
Automated trading is an operations problem as much as a modelling one: state checks, logs, parameter management, a kill switch, and recovery procedures are what make it safe to leave running.
Not claimed
- Does not claim returns or win rate. There is no real-money track record.
- Does not claim the strategy has an edge. The best variant still trailed buy-and-hold on CAGR.
- Does not claim production operation. It remains at paper trading.
05 · Use
Where this helps
Instead of claiming returns, set out in numbers and operating controls the conditions under which a strategy may run and the signals that should switch it off.
06 · Boundary
What still needs checking
- •Both projects are at paper-trading validation with no real-money operating history.
- •The backtest universe consists of currently listed instruments, so some survivorship bias remains.
- •Most validated strategies lost money in 2022; this design does not defend a period where equities and long bonds fall together.
- •Long-running uptime, order-failure handling, and restart scenarios remain separate operating concerns.
07 · Figures
Tables and figures
Operating-system architecture
Verified sourceThe diagram shows the connection among strategies, broker abstraction, execution data, controls, and monitoring. It supports the implemented architecture; it does not evidence real-money operation, returns, win rate, or profitability.
Source · Current FastAPI/React architecture and portfolio codebase
Paper-trading operating scope
Verified source- Live-server paper tradingPaper
- Bot state and setting controlsImplemented
- Execution history and logsImplemented
- Human stop-and-control flowImplemented
- Paper-trading validation only · no real-money operation or return claim.
The table summarizes implemented operating controls only. It does not report or imply real-money performance.
Source · Implemented controls in the current FastAPI/React project
Walk-forward out-of-sample results
Reported evidence| Strategy | In-sample CAGR | OOS CAGR | Sharpe | Max drawdown | Decay |
|---|---|---|---|---|---|
| Faber | 5.73% | 7.36% | 1.01 | -14.1% | ×1.28 |
| Dual momentum | 7.60% | 7.57% | 0.49 | -30.5% | ×1.00 |
| Buy and hold | 8.94% | 11.10% | 0.97 | -20.1% | ×1.24 |
The table reports out-of-sample results only. A decay at or above 1.0 means performance did not collapse in the test window; it does not promise future return. Buy-and-hold's higher CAGR is left in place.
Source · tqt project · five-year train, two-year test · 2011–2026 daily bars