Automated Multi-Timeframe Equities Trading System
A day trader wanted his strategy to run without him. Trading real money, unattended, on 2001-era infrastructure that failed constantly. The hard problem was never the strategy logic.
Role: Co-Architect, Designer and coder
Period: 2001–2006
Team: Two developers — myself as co-architect and designer, and another co-architect and one primary implementer
Stack: Java (pre-Spring), Hibernate, XML configuration, Eclipse, relational database, Interactive Brokers API
Executive Summary
A day trader wanted his strategy executed without him watching it. I co-architected a system that tracked roughly 2,000 symbols across four intraday timeframes and traded through Interactive Brokers, unattended, every trading day. Built in 2001, before the infrastructure this needs existed, so the real engineering was surviving market data feeds and broker connections that failed constantly with nobody there to restart anything. It traded live, and outlasted the trader who inspired it.
Origin
The project started with a day trader in California. He had a strategy he worked by hand: he would trade it until he hit a monthly number, then stop and surf for the rest of the month. It worked, but it required him to sit in front of a screen to run it.
The question he brought was whether the method could run without him. That framing set the design goal for the whole system — not to invent a strategy, but to take a discretionary process that already worked and make it operate continuously, unattended, across a universe far larger than one person could watch.
The strategy itself was the client's proprietary intellectual property and is not described here.
What the System Did
The system tracked roughly 2,000 symbols — the Nasdaq composite, the S&P 500, and the Dow Jones constituents — and evaluated the client's strategy against all of them on an ongoing basis.
Four responsibilities:
Market data ingestion. Harvested market data daily and stored it in databases structured for fast historical access, building an accumulating corpus of price history rather than depending on a vendor's historical API at query time.
Strategy evaluation on multiple timeframes. The strategy operated on four intraday cycles — 4-hour, 1-hour, 15-minute, and 5-minute. Each symbol was evaluated on each cycle, so the system continuously maintained a view of the same universe at four different resolutions.
Historical evaluation. A backtesting facility replayed stored historical data through the strategy so new variations could be tested against past markets before being trusted with capital.
Broker connectivity. Integrated with Interactive Brokers for account and order connectivity.
The system was built to run unattended through the trading day, every trading day.
Architecture
One strategy implementation, two data sources
The most consequential decision was that the same strategy code ran against both historical and live data.
The strategy was written against an abstract source of market data. The backtester fed it stored historical bars; the live path fed it current market data. The strategy could not tell the difference, because nothing in it knew where its input came from.
The alternative — and the common shortcut — is to write the strategy twice: once inside the backtester and once in the live path. That approach fails quietly. The two implementations drift, and a backtest stops predicting live behavior in ways nobody notices until real money is involved. Every strategy variation validated against history was validated against the code that would actually trade it.
This is standard practice in trading infrastructure today. In 2001 it was a decision we had to arrive at ourselves, and it shaped everything else in the design.
Nightly harvest into replay-optimized storage
Market data was captured on a nightly cycle and written to databases designed for the access pattern backtesting requires: read large spans of history for a given symbol and timeframe, quickly, repeatedly.
Under the storage and hardware constraints of the period, accumulating multi-timeframe history across 2,000 symbols was a genuine engineering problem rather than a configuration detail. Owning the pipeline meant the backtester ran against data we controlled, in a shape built for the job.
Multi-timeframe state
Maintaining an evaluated view of 2,000 symbols across four cycles meant the system's core state was substantial and constantly moving. The design problem was keeping per-symbol, per-timeframe state coherent as new data arrived on four independent cadences — and doing it continuously, without a person watching.
Interactive Brokers integration
The IB API of that era was a socket protocol with a fat client, asynchronous callbacks, connections that dropped, and order state the client application was responsible for tracking. Integration meant handling reconnection and state reconciliation as normal operating conditions rather than exceptional ones.
The Hard Part: Nothing Underneath Was Reliable
The genuine difficulty of this project was not the strategy logic or the system design. It was that the infrastructure everything depended on did not really exist yet.
Market data was fragile. Commodity market data feeds were not available the way they are now. There was no menu of vendors with documented APIs, uptime guarantees, and client libraries in every language. Getting continuous, trustworthy price data for 2,000 symbols meant working with what was available and accepting that it would fail — gaps, stalls, bad values, and outright outages during market hours. Every one of those failures reaches a system that is making trading decisions on a five-minute cycle.
Live broker connectivity was harder still. Holding a valid, authenticated, real-time connection capable of placing orders was a real engineering problem in itself. The connection dropped. State drifted between what the system believed and what the broker believed. Reconciling those two views — and knowing which one to trust — was not a solved problem with a library to import.
The consequence is that a large share of the engineering went into operating correctly on top of unreliable foundations. A system that runs unattended through the trading day cannot treat a feed outage or a dropped broker connection as an exceptional case to be escalated to a human — there was no human watching. Failure had to be an expected state with a defined response.
This is the part of the work that is easiest to underestimate in hindsight, because the problem has largely been solved by the industry since. At the time, the reliability layer was the project.
Context: Building This in 2001
Much of what this system did is now well-served by off-the-shelf components. At the time, essentially none of it was.
No Spring — dependency wiring and lifecycle management were hand-rolled or driven through XML. Hibernate was young. There were no managed time-series databases, no cloud infrastructure, no containers, and no mature open-source backtesting frameworks to borrow patterns from. Market data infrastructure, the historical store, the evaluation loop, the broker integration, and the operational scaffolding to keep it running were all built directly.
The architectural ideas that matter here — separating strategy from data source, validating against replay before committing capital, owning the data pipeline — were arrived at from the problem rather than adopted from prevailing practice.
My Role
I was the architect and designer. I owned the system design: the separation between strategy and data source, the data model and storage design, the multi-timeframe evaluation structure, and the integration boundaries with the market data feed and Interactive Brokers. My collaborator was the primary implementer and contributed to design decisions throughout.
Outcome
I worked on the system from 2001 through 2006. It went on to trade live after my involvement ended, and to my knowledge it may still be running. I have no visibility into its development after my departure and make no claims about what it became.
The original client — the surfer whose strategy started the project — went through a divorce and left trading. The system outlasted the trader who inspired it.
What I'd Do Differently
Make the data source boundary an explicit contract. The abstraction that let one strategy implementation serve both backtest and live paths was the right call, but it was a convention we maintained rather than an interface the system enforced. A stricter boundary would have made it impossible to accidentally introduce a dependency on live-only data.
Design for point-in-time correctness from the start. The subtlest failure in any backtest is letting the strategy see information that would not have been available at the moment being simulated. Building the historical store so that a query is always scoped to what was knowable at a given timestamp closes off an entire category of silently optimistic results.
Treat the evaluation loop as an observable system. The system ran unattended, which makes visibility into what it is doing and why a first-class requirement rather than an operational afterthought. I would instrument decision paths from the beginning — not just logging errors, but recording why each symbol was or was not acted upon.
Separate the execution layer more sharply. Broker connectivity was integrated fairly directly. Isolating order management behind its own boundary would have made the broker replaceable and, more importantly, made execution independently testable without a live account.