CASE STUDY / 02
MULTI-TIMEFRAME TRADING & EXECUTION ARCHITECTURE
AUTOMATED TRADING OS
Multi-timeframe quantitative trading and execution architecture.
An operating-system-style architecture for systematic trading: higher-timeframe context flows down through mid- and lower-timeframe analysis into risk, trade management and execution — every stage bounded by structural controls: 1% per-trade risk cap, minimum 1:4 reward-to-risk, fee and slippage modelling, cost-budget filtering, profit lock and giveback limit.
EVIDENCE INSTRUMENT / PROJECT-SPECIFIC
INSTRUMENT / EXECUTION PIPELINE
ARCHITECTURE DIAGRAM — NOT A PERFORMANCE MEASUREMENT
One-way information flow: no lower timeframe can override a higher timeframe constraint. The risk firewall sits before order construction, so a setup that fails the 1% cap, the 1:4 R:R floor or the cost budget never becomes an order.
PROBLEM
Most trading systems are built as a single indicator that prints buy/sell signals. That model collapses context, risk and execution into one fragile decision.
Real systematic trading is layered: what the higher timeframe permits, the mid timeframe structures, the lower timeframe triggers — and none of it matters if position size, costs and exit management are not governed explicitly.
MOTIVATION
I wanted an architecture where the layers are honest about their role — where a lower-timeframe entry can never override higher-timeframe context, and where risk rules are structural rather than advisory.
The operating-system framing is deliberate: kernels schedule, enforce and isolate. A trading architecture should do the same for decisions.
RESEARCH QUESTION
Does explicit multi-timeframe separation, with hard risk controls at every layer boundary, improve trade quality enough to survive modeled costs?
OBJECTIVE
- Separate HTF / MTF / LTF analysis into distinct pipeline stages with defined contracts
- Enforce risk controls as structural invariants: 1% per-trade risk cap, minimum 1:4 R:R
- Model fees and slippage at execution, and filter trades whose cost budget cannot support the setup
- Manage open trades with profit lock and giveback limits instead of static stops only
ARCHITECTURE
VISUAL METAPHOR — LAYERED EXECUTION PIPELINE
ARCHITECTURE — DATA PATH
ARCHITECTURE DIAGRAM — THE DOCUMENTED LAYERS, NOT A MEASUREMENT
- 01
HTF — HIGHER TIMEFRAME
Directional context and regime
- Establishes the permitted directional bias
- Lower layers may not contradict it
- 02
MTF — MID TIMEFRAME
Structure and setup identification
- Maps the structure the entry will live inside
- Defines setup zones and invalidation
- 03
LTF — LOWER TIMEFRAME
Entry trigger
- Times the execution within MTF structure
- Emits trigger only when HTF and MTF agree
- 04
RISK
Position sizing and trade admission
- 1% per-trade risk cap on capital
- Minimum 1:4 reward-to-risk required
- Cost-budget filter rejects setups that cannot pay for themselves
- 05
TRADE MANAGEMENT
Open-position governance
- Profit lock secures gains as trade progresses
- Giveback limit caps how much open profit may be surrendered
- 06
EXECUTION
Order construction and fills
- Fee and slippage modelling applied to every fill
- Orders constructed only after all gates pass
DATA FLOW
PIPELINE — 7 STAGES, IN ORDER
- 01HTF analysis establishes directional context and regime classification
- 02MTF analysis maps structure and defines the setup and its invalidation
- 03LTF timing emits a trigger only inside MTF structure and HTF direction
- 04Risk stage sizes the position from stop distance under the 1% cap and rejects sub-1:4 setups
- 05Cost-budget filtering removes trades whose fees and slippage cannot be supported by target
- 06Trade management governs the open position: profit lock and giveback limits
- 07Execution constructs and simulates the order with explicit fee and slippage models
METHODS
- Layered pipeline architecture with one-way information flow — downstream cannot override upstream
- Structural risk invariants enforced at layer boundaries
- Explicit cost modelling: fees and slippage priced into every admission decision
- Before/after experimentation comparing trades with and without each control
RISK / VALIDATION
- 1% maximum account risk per trade — position size derives from stop distance
- Minimum 1:4 reward-to-risk — setups below the threshold are never admitted
- Cost budget filter — if modeled costs exceed what the setup can carry, the trade is rejected
- Profit lock and giveback limit — open profit is protected by rule, not discretion
EXPERIMENTS
Control ablation
ONGOINGWhat does each risk control individually contribute to trade quality?
Before/after comparisons isolating the effect of each gate on admitted trade sets.
R:R threshold sweep
ONGOINGHow does the admitted-trade population change as the minimum R:R threshold moves?
Strategy matrix across R:R thresholds under fixed 1% risk.
Timeframe alignment study
ONGOINGHow often do HTF, MTF and LTF agree, and what is the character of those windows?
Timeframe explorer mapping agreement windows across instrument history.
RESULTS
1%
MAX RISK PER TRADE
STRUCTURAL CAP
1:4
MINIMUM R:R
ADMISSION THRESHOLD
6
PIPELINE STAGES
HTF → EXECUTION
100%
FILLS COST-MODELED
FEES + SLIPPAGE
The results here are architectural: the controls exist, are enforced structurally, and are experiment-ready. Performance figures from this architecture will be published only as labeled backtests when runs complete.
LIMITATIONS
- Execution architecture is in development — forward results are not yet published
- Control ablation experiments are ongoing; per-control contribution figures are not yet final
- Cost models approximate fills and do not capture all extreme-liquidity scenarios
CURRENT STATUS
DEVELOPMENT
Execution architecture under active development.
EVIDENCE
CONTROLS IN CODE
Risk cap, R:R floor, cost filter, profit lock, giveback limit - enforced structurally and exercised by local tests; no CI runs yet
PIPELINE MODEL
HTF → MTF → LTF → RISK → TRADE MANAGEMENT → EXECUTION
INTERACTIVE LAB
TRADE DISTRIBUTION — SEEDED ILLUSTRATION UNDER THE 1:4 R:R FLOOR
EQUITY SHAPE — SEEDED ILLUSTRATION OF A RISK-CAPPED PIPELINE