94 CHAPTER ◆ 8 Describe Trading/Investment Idea
logic that will lead to entering into and exiting from positions in the markets. For exam-
ple, the description will include all the indicators and what actions will be taken based
upon their differing values. Also, we will want to understand what, if any, dynamic inputs
will be part of the system. That is, will the user be able to change any parameters, say
stop limits, or optimization constraints. Of course, the nature of the trading rules will be
different for different kinds of systems, for example, market making versus market taking
systems. Nonetheless, common to all systems will be an explanation of why a particular
instrument will be bought or sold, or rather why a bid or offer will be entered on a par-
ticular instrument.
Successful product teams approach quantitative research, the search for best practices,
in a methodical manner. The goal over the course of the following research step, K|V
1.2.2, may be to assemble, say, 20–50 references. A research survey of this size requires
planning. In the end, though, the team may only select and prototype a small subset of the
total research found; the full complement of references become part of the firm ’ s library.8.5. STEP 1, LOOP 3: Consolidate Trading System
Details (All Equations and Logic Rules)
The final loop consolidates all component descriptions into a single document with all of
the trading rules. A consolidation loop will prevent endless looping. Never-ending loop-
ing through the design stage is a serious issue in trading/investment system development;
researchers almost always aspire to optimal solutions. Very often, however, the perfect
solution takes too long. The goal must be to deliver profitable, working strategies in the
short term, with the goal to continuously improve working systems over the longer term.
Consolidation should not occur without planning. Stitching together disparate proto-
types requires forethought on data formats and conversions and merging graphical user
interfaces. Furthermore, problems during consolidation may corrupt component proto-
types. We recommend backing up all prototypes beforehand and documenting graphically
the architecture of the final prototype before any work begins. The final prototype will
form the basis for the software requirements documents in Stage 3.
After consolidation, our methodology assumes that all quantitative methods and busi-
ness rules are fixed, except for optimization of parameters, which can occur over the
course of Stage 2.8.6. Summary
In summary, documenting reveals aspects of the process trading strategy research that
may not be apparent from general communication. The ways in which product teams
organize discussions of quantitative, qualitative, and technological issues may reveal gaps
in logic or unchallenged assumptions. Product team members should follow a standard
model for organizing discussions of trading system design and development. A standard
way of presenting financial research, such as certain topics first followed by solutions, is
to present the pieces of the analysis in an expected order, then use inductive reasoning to
structure discussions. Revising the organization of a discussion clarifies thinking and pro-
motes clear writing; and clear writing in turn promotes clear thinking.
The necessity of documenting, and documenting well, with accountability to team
leaders and top management, forces product teams to do better research.