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
Live · Operational console
Quick read
The through-line of the work.
Open
The starting question
The starting point was simple. Before asking whether a strategy was right, I had to be able to switch it on and off safely and watch it.
Build
What I checked
In Fleet I tied the broker interface, bot state, settings, order history, and logs into one flow, controlled through FastAPI and a dashboard.
Turn
What changed my view
The next question was whether the strategy had any edge at all. In tqt I redesigned the backtest so that results are reported only from walk-forward out-of-sample runs, never in-sample.
Close
Where I draw the line
That meant the first thing I wrote down was that even the best strategy trailed buy-and-hold on CAGR. Bots now run on small real-money accounts as well as paper ones, with each account labelled on /lab, but no return is claimed.
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, on paper, then with real money
Reported performance only from a five-year train, two-year test walk-forward, validated operations first with paper trading that fills against the live order book, then added small real-money accounts alongside the paper ones.
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. Results from the small real-money accounts are not presented as a track record.
- Does not claim the strategy has an edge. The best variant still trailed buy-and-hold on CAGR.
- Does not claim a production service. It is a personal project running bots on small real-money accounts and on paper and mock accounts.
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
- •Real-money operation runs on small accounts alongside paper and mock accounts; this portfolio does not treat those live results as evidence of performance.
- •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 returns, win rate, or profitability.
Source · Current FastAPI/React architecture and portfolio codebase
Paper and real-money operating scope
Verified source- Live-server paper tradingPaper
- Small real-money accounts · labelled on /labReal
- Bot state and setting controlsImplemented
- Execution history and logsImplemented
- Human stop-and-control flowImplemented
- Paper and small real-money accounts · no return, win-rate, or capital-growth claim.
The table summarizes implemented operating controls only. Small real-money accounts are running, but the table does not report or imply their 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