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 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
generates open/high/low/close price bars according to the ancient custom of
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.
BarGen block generates only one data series for a specified
financial instrument. But a system can contain any number of
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
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.
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.
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.
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
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
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.
Copyright 1997, Structured Software Systems, Inc.