Previous Next Table of Contents

3. Typical structure of a TREE trading system

In this section we sketch the typical structure of a trading system built in TREE's TS domain, and introduce some of the standard block types available in TS.

A complete TS trading system ( Figure 1) can be divided into five functional parts:

Data sources.

Data source blocks obtain data from outside the system (either a historical database or a live data feed) and introduce it into the TS world with the appropriate timestamps. The prototypical source block is BarGen, which generates open/high/low/close price bars according to the ancient custom of traders. BarGen is capable of creating a variety of types of bars: daily, multiday, intraday with any desired width in minutes, or tick based (constant number of ticks per bar). Adjusting BarGen's parameters thus allows viewing market activity on many different timescales.

A single BarGen block generates only one data series for a specified financial instrument. But a system can contain any number of BarGen blocks that are producing data for one or many instruments on one or many timescales. Dealing with multiple instruments or multiple timescales is thus simple and natural.

Currently, the only data source blocks in TREE are variants of BarGen, so only market price data is available to a trading system. Thus the current version of TREE is suited for ``technical trading'' approaches, which follow the dictum that the pattern of price movements is all that one needs to know about the market. But there is no inherent reason that other data source block types could not be created. A trader following a ``fundamentalist'' philosophy would probably like to have source blocks that emit quarterly earnings reports, for example. This is a straightforward feature to add, given access to a suitable database.

Signal processing network.

A trading system designer will usually want to perform some amount of numerical processing on the time series produced by his data sources. Typical calculations include moving averages, differences of related prices, and so forth. TREE includes an extensive library of signal-processing blocks that cover many of the published analytic methods used by technical traders.

The term ``signal processing'' is not intended to restrict the kind of calculation done --- for example, a bar pattern recognizer would fit naturally into this area of the system. We use the term to indicate that the purpose of this part of a trading system is to transform the raw data series into some more useful form.

The outputs of this part of the system are typically numeric data series. Each event in such a series will be timestamped with the time at which it can be calculated, normally the time of the latest data source event needed to compute the value.

Trading strategy subsystem.

This section of the schematic makes the actual buy-or-sell decisions, using signal processing results and/or raw data source outputs as input data. Its output is a timestamped series of trade orders, for example ``buy 100 IBM at market'', ``sell 1 SPU7 953.5 stop'', etc.

The trading strategy subsystem typically needs to keep track of its current market position and the results of ongoing and past trades. To do this it receives feedback reports from the trade executor, described next.

We have found that trading strategies are usually most compactly expressed by scripted logic, rather than networks of independent processing blocks. Therefore this section of the schematic is usually a single block whose actions are controlled by a Tcl script. (Again, this illustrates the design principle of using an appropriate notation for each part of the problem.) But this approach is not a fundamental part of TREE --- any kind of block or group of blocks could be used, as long as they emit valid trade order events. We continue to work on developing better representations of trading strategies.

Trade executor/record keeper.

Given a timestamped series of trade orders, the TradeExec block is responsible for executing them and reporting the results.

During historical testing, TradeExec examines prices from the historical database to determine when and at what price trades would have occurred. This simulation is deliberately somewhat conservative. For example, when a market order is issued, TradeExec assumes that it will be filled at the least favorable price that traded within the next couple of minutes after the order's timestamp. The real results of trading would not always be so pessimistic; but it's better to be favorably surprised than unfavorably surprised. TradeExec is also responsible for determining whether and when stop-type orders would be triggered.

In live trading, the TradeExec block will report each received order to the user for submission to his broker. (Someday it might cause the order to be transmitted directly to the brokerage house's computer...) The actual execution price can subsequently be entered into the system. However, this is not absolutely necessary, because TradeExec also watches the live data feed and can estimate the fill price from received ticks, using the same rules it applies during historical simulation.

In either case, TradeExec maintains a history of completed trades, open positions, and pending orders, which it makes available to interested blocks via status-report events. This record-keeping could be done in a separate block, but to avoid clutter in trading schematics it seems best to integrate it into TradeExec. TradeExec can also be made to display net profit and other useful statistics at the end of a run.

In simple cases, only one TradeExec block is needed per trading schematic. However, more can be used if there is some reason to keep separate statistics for separate groups of trades. One important application of multiple TradeExecs is described in Order filtering, below.


For development and testing of trading strategies, it's very useful to have interactive displays that can plot the raw price data, the results of signal processing, trade orders, and trade occurrences. Standard Ptolemy contains numerous sorts of display blocks, but none are quite optimal for trading purposes, so TREE provides its own display block types. The user determines which data series need to be displayed and wires the schematic accordingly.

The TREE display blocks can be disabled when noninteractive use of a trading schematic is wanted. For example, during automatic parameter optimization, it would be a waste of time to put up an interactive display of the progress of each individual run; so we make it possible for the controlling script to turn off display blocks within the schematic that it is repeatedly executing.

Figure 3, Figure 4, and Figure 5 demonstrate some of the display capabilities of TREE.

Thus, a TREE trading system schematic represents all of the calculations needed to execute a trade strategy and do basic evaluation and display of its results. But for more sophisticated applications, we might want to place this schematic within some larger context that does more processing. That is the topic of the next section.

Previous Next Table of Contents

Copyright 1997, Structured Software Systems, Inc.