Patent Application
20100325032
The securities industry is continuing to experience an increasing degree of automation. One area of especially rapid growth is in automated execution of security orders by software programs. These programs are known popularly as “trading algorithms.”
Such programs take as inputs order information (e.g., security identifier and quantity) and user-specified preferences (e.g., maximum or minimum allowable execution price and target amount of time over which to operate). Collectively, these inputs are called parameters, and their primary functions are to: (a) specify desired execution objectives; and (b) govern the behavior of the program, within designer-specified boundaries, in pursuit of the objectives. These programs also process both real-time and historical data as a typical part of their operation.
In order for users to successfully access trading algorithms, they usually must package the inputs into a message (effectively a data structure) of moderate to high complexity. This message typically is comprised primarily of a collection of parameters.
Today, much security order information (and most trading algorithm order information) is transmitted from sender to receiver via an industry protocol known as Financial Information Exchange (“FIX”). FIX was originally designed to transmit order parameters for orders in a single security, with a limited, pre-defined set of parameters. When the usage of FIX expanded to include the transmission of orders to trading algorithms (as well as other applications, such as transmitting multiple orders to be executed in coordination with one another), the protocol was expanded somewhat to accommodate basic trading algorithm types.
Today, so-called “next generation” trading algorithms are starting to emerge that require much more extensive and complex parameter sets. Generally speaking, vendors of such trading algorithms cannot offer them to prospective users (or third party vendors who supply order entry software to prospective users) without defining proprietary extensions to the FIX protocol or other specialized solutions. Prospective users, who are typically employing trading algorithms offered by multiple vendors, are understandably reluctant to support multiple proprietary protocol extensions. Even vendors prefer not to extend the protocol because such extensions give rise to a costly cycle of promulgation and certification. Such extensions also increase the probability of service failure due to improperly formed messages.
At the same time, users of next-generation trading algorithms want to take advantage of the expanded capabilities of those algorithms, but usually prefer to specify (upon initial setup of the interface) only a subset of their choosing (i.e., customized) of the total parameter set to be supplied at the time of order submission (dynamic parameters), while setting other parameters to pre-defined (static) values of their choosing and allowing still other parameters to remain unspecified or to take on vendor-established default values. Submission-time (dynamic) values may be optional or mandatory, and may or may not have default values. A user also may wish to specify upon initial setup a range of allowable values for submission-time parameters.
Users also want to be able to easily invoke previously-saved, customized parameter sets and employ them to direct security orders to the underlying trading algorithms.
In one aspect, the present invention permits users of trading algorithms to jointly achieve the objectives described above, namely: (a) permit access to trading algorithms of (arbitrary) complexity without requiring proprietary protocol extensions; (b) allow users to easily identify and store one or more sets of dynamic vs. static parameters (and related details, including user interface layout); and (c) allow any given pre-defined set of parameters to be easily invoked and used to submit orders.
In another aspect, the invention comprises a computer system comprising: (a) authoring tool operable to enable a user to design custom trading strategies and create interface definitions; and (b) a pre-processor operable to receive a custom strategy order message delivered via a standard protocol, load an definition for a corresponding custom strategy, enrich the order message based on the definition, and pass the enriched message to a trading strategy destination.
In various embodiments: (1) the definition is encoded using a protocol for encoding the custom trading strategies and interface definitions for transmission and storage; (2) the standard protocol is a FIX protocol; (3) the authoring tool is operable to enable a user to designate one or more input parameters as either a static parameter or a dynamic parameter; and (4) the dynamic parameter may further be designated as a required input or an optional input.
In another aspect, the invention comprises a computer-implemented method comprising: (a) receiving a definition for an advanced approach strategy; (b) storing the definition for the advanced approach strategy in a database; and (c) based on the definition, integrating and deploying the advanced approach strategy.
In various embodiments: (1) the definition for an advanced approach strategy comprises: (a) a strategy name; (b) data identifying a parent algorithm; (c) a manifest; (d) a custom parameters definition; and (e) a custom interface definition; (2) the manifest enumerates a list of parameters of the parent algorithm and identifies which of the parameters are static and which are dynamic; (3) the parent algorithm is operable to receive FIX messages; (4) the manifest comprises one or more static parameter values and one or more dynamic parameter values; (5) the static parameter values are transcribed in a manner essentially identical to a manner in which the static parameter values would be defined in a FIX message; and (6) a placeholder is used to identify a location where a passed-in value for a dynamic parameter should be inserted.
In another aspect, the invention comprises software stored on a computer readable medium and operable to enable a user to author a custom trading strategy via a graphical user interface, wherein the graphical user interface is configured to allow the user to: (a) assign static parameter values to be fixed; (b) identify dynamic parameters to be exposed; and (c) set default values for the dynamic parameters.
In various embodiments: (1) the software is further operable to store a custom strategy comprising: a parent algorithm name; and a manifest; (2) the manifest comprises data identifying pre-defined static parameter values and dynamic parameters; (3) the manifest further comprises data identifying default parameter values for the dynamic parameters; (4) the graphical user interface is further configured to allow the user to identify one or more base actions, one or more conditional actions, and one or more conditions; (5) the manifest is stored as an XML string or a FIX string; and (6) the software is further operable to store a custom strategy comprising at least one of: a custom parameters definition and a custom interface definition.
In another aspect, the invention comprises a computer system comprising: (a) an authoring tool operable to enable a user to design custom trading strategies and interfaces; (b) an order entry object interpreter operable to receive parameter values and form the values into a message transmitted via a standard protocol; and (c) a data structure packager operable to receive the message from the order entry object interpreter, form the message into a data structure, and transmit the data structure to a trading strategy destination.
In another aspect, the invention comprises a computer-implemented method comprising: (a) displaying a graphical user interface operable to allow a user to enter a definition for an advanced approach strategy; (b) receiving data entered by the user defining an advanced approach strategy; and (c) transmitting the definition for the advanced approach strategy to a parent algorithm.
The above-described aspects and embodiments are not intended to be limiting. Those skilled in the art will perceive other aspects and embodiments after reviewing the drawings and the detailed description.
A preferred embodiment of this invention comprises three closely integrated software applications, each of which is described below.
The first software application (“authoring tool”) allows a strategy designer (who may or may not be an end user) to:
The object that is stored in the database will, in turn, be readable and interpretable at the time of order entry by a second software application (“custom order entry object interpreter”) whose job is to:
The function of the third software application (“FIX packager”) (or, more generally, a “data structure packager”) is to receive the enhanced FIX message (possibly combining it with other information read from an associated database), form it into a valid data structure, and transmit this structure to the ultimate trading strategy destination.
Aspects of components of this invention have been previously used on a stand-alone basis in this area. For example, the idea of enriching a security order that is destined for a trading algorithm by looking up static information (stored in a database) and attaching it to that order has been used before. Similarly, static, non-customizable interfaces have been used to set parameter values that are ultimately passed along to the target trading algorithm. However, such schemes are static and furthermore do not solve the joint problems of: (a) being able to create and deploy complex new trading algorithms dynamically; (b) having the interfaces to such algorithms be easily tailored to individual needs (including risk management) and preferences of end users; and (c) not requiring frequent, proprietary extensions of the industry standard protocol, namely FIX.
Collectively, the benefits created by this invention dramatically extend the capabilities of trading algorithms, and substantially reduce the time it takes to bring new trading algorithm concepts to market.
A trading algorithm is an engine that executes orders automatically according to a pre-defined set of instructions. Examples of trading algorithms are those used by Lehman Brothers, which include VWAP, Target Strike, CAT, and TactEx, among others. Each of these algorithms has a specific purpose and trading style, but each also allows a user to specify certain input parameters to further define how the algorithm should trade a specific order. Examples of such input parameters include start and end times, volume constraints, urgency levels, etc. These parameters allow a single trading algorithm to be used flexibly to cover a variety of different applications.
In some cases, trading algorithms present users with such a wide variety of parameter choices that it is desirable to allow users or developers to create and store streamlined variants based on the full algorithm. This process essentially consists of two steps: (1) “nailing down” (i.e., pre-determining and storing) a subset of the available parameters; and then (2) presenting an end user with a simplified interface that allows the user to enter the remaining parameters that were not fixed in step (1). A custom strategy is associated with a “parent” trading algorithm (which serves as its foundation) and consists of a subset of predefined parameter settings for the parent algorithm, and a set of placeholders to identify any further parameters that will later need to be specified.
A simple example will illustrate this.
The point is to define these parameter settings once (the custom strategy) and then allow end users to access the strategy without retyping parameter settings or even seeing the full TactEx interface. Instead, users can be presented with a simplified interface that exposes only a subset of the TactEx parameters to the end user. Or, if there are no missing parameter values required by the TactEx algorithm, the end user can bypass the interface altogether and submit orders to the custom strategy directly.
It is important to distinguish between two types of custom strategies, with the critical distinction being whether the strategy allows an end user to specify additional parameters when submitting orders. The advanced approach is used when the end user is to be presented with a customized interface allowing the user to specify additional parameters. The basic approach is used when all required parameters are pre-specified and the user can send orders to the custom strategy directly without using an interface.
Static parameters are parameters that are pre-defined and cannot be modified when sending an order. Dynamic parameters are parameters that can be specified by the end-user when submitting an order to the custom strategy.
In the basic approach, all required parameters are static and there are no dynamic parameters. A designer simply names the new custom strategy (say “Passive”), stores the strategy in a database, and systems are configured so that any incoming orders with strategy name set to “Passive” are handled by automatically loading the stored (predefined) parameter settings and passing those settings on to the parent algorithm. The end user is not provided with any interface. The user simply sends in orders tagged with the name of the custom strategy. Typically, the custom strategy is presented as a destination within a menu of routing options on the user's trading workstation.
In the advanced approach, some but not all required parameters are static and the end user is able to set a short list of dynamic parameters using a custom interface or through some electronic protocol. Returning to the example in
Note that advanced approach custom strategies can be implemented either by providing a custom graphical interface that integrates with the end user's trading workstation, or by simply providing a specification to the end user and allowing the user to create his own interface or even set the required parameters programmatically.
Defining an advanced approach strategy involves not only pre-defining static parameters (as with the basic approach) but also defining a graphical interface and/or electronic protocol through which the user can set the dynamic parameters. Each dynamic parameter must be defined and mapped to order fields so that the parameter may be passed electronically. If the end user is to be presented with a custom interface, the layout, field labels, field types, and default values also must be defined.
Regardless of approach, there is some behind-the-scenes work to process an incoming custom strategy order, load the appropriate parameter settings, and forward the order on to the parent trading algorithm. The pre-processor is the module that performs this task, converting simplified custom strategy orders into complex, fully-specified parent algorithm orders. This conversion process can occur upstream of the parent algorithm (which need not have any awareness of custom strategy definitions, or of any distinction between regular and custom strategy orders). For advanced approach strategies, the pre-processor must be capable of parsing incoming dynamic parameter values and incorporating these values into the parent algorithm order.
The remainder of this section explains the steps and components required to implement a new custom strategy, following the format depicted in
Step 1: Use Authoring Tool to Build Strategy
An Authoring Tool is an interactive, graphical environment used to design custom strategies and the interfaces used to control them. A user preferably is presented with a graphical interface displaying a full superset of input parameters for a “parent” trading algorithm. More details regarding functionality and structure of a preferred Authoring Tool are provided below in the Authoring Tool Overview section.
For each parameter, the Authoring Tool presents the strategy designer with three options:
For basic approach strategies, only option (1) is available: all parent algorithm parameters must be static.
When an advanced approach strategy is created, the Authoring Tool is not only used to pre-define static parameters, but also to define the protocol through which dynamic parameters are to be passed into the pre-processor, and (optionally) to build a custom interface that exposes any required or optional dynamic parameters to the user. For each dynamic variable, the advanced approach designer defines field type (integer, string, date, time, percent, real, or enumerated) and a unique parameter tag that allows the interface to pass the variable into the pre-processor. If the designer is building a custom interface, the designer also needs to define parameter labels, default values, validation instructions, and screen layout.
Step 2: Store New Strategy with Custom Interface
A custom strategy definition preferably comprises the following components:
For basic approach custom strategies, only strategy name, parent algorithm name, and manifest need to be defined. For advanced approach strategies, the custom parameters definition must be defined. The custom interface definition only needs to be defined if the strategy requires a custom interface. Generally, the authoring tool can produce all of these components.
Manifest
The manifest can be defined in any protocol, typically in an XML or FIX (Financial Information eXchange) format. Preferably the manifest is represented in a FIX message format with embedded XML. FIX, a trademark of FIX Protocol Limited, is the industry standard communications format for electronic equity trading (see www.fixprotocol.org). Here is a simple illustrative example:
This message has four lines, each prefixed with a numeric FIX tag that identifies the type of data contained on the line. The first line identifies the algorithm (1012 is the unique numeric ID for the Sitter algorithm). The second and third lines show the start and end times for the order. 168 and 126 are standard FIX tags for controlling the time horizon.
The fourth line (which is broken into five rows in the statement above) is an XML string that contains a collection of additional parameters. The four parameters in the bottom section of the interface in
If one were to develop a custom strategy using Sitter as the parent algorithm, the manifest would look similar to the FIX message above. In fact, if the custom strategy were a basic approach strategy with no dynamic parameters, then the manifest would be identical to this message, except that the first line (TargetStrategy) would be omitted, since both the base algorithm name and the new custom strategy name already are included in the custom strategy definition.
Advanced approach custom strategies need to additionally describe how dynamic parameters are to be handled. This is accomplished through placeholders in the message. All dynamic parameters are represented in the manifest by placeholder strings that occupy the place of where the parameter value would appear in the message. Each placeholder string is the parameter's unique ID code surrounded by pipe (|) characters, like so: |DisplaySz|.
For example, if the display size and end time parameters were designated as dynamic parameters and all others were designated as static, the manifest would look like this:
In this example, EndTime and DisplaySz have been chosen as unique identifiers for those two parameters, as will be explained in the next section.
Custom Parameters Definition
The custom parameters definition is used to define each of the dynamic parameters to be exposed to the end-user. For the custom parameters definition, a FIX message format with a “repeating group” data structure is used as follows:
Each dynamic parameter must be included in the definition with all three definition rows, tagged with 958, 959, and 960.
At a minimum, available parameter types should include:
Beyond this minimal set, the FIX protocol identifies a number of other parameter types such as quantity and currency that would be useful to support as well. For the purposes of this implementation, these are omitted.
The exact order in which the parameters are listed is unimportant for incoming orders. The pre-processor will sort out any discrepancies as long as the correct parameter IDs are supplied.
Note that the custom parameter format has two purposes. The primary purpose is for passing parameters electronically to a trading system. This is done by including the custom parameters definition in the above FIX format to the FIX message representing the order. The second purpose is to serve as a reference point to the pre-processor so that incoming orders can be placed in the correct context. In this second case, the StrategyParameterValue field is ignored.
Custom Interface Definition
The custom interface definition is used as a set of instructions for creating a custom interface to the custom strategy. This interface exposes the various dynamic parameters to the end-user, validates entries, and attaches the parameter values to the order. Preferably, there is an engine that reads the custom interface definition and automatically produces an interface that is consistent with the instructions. Alternatively, a computerized script may read the custom interface definition and automatically produce an interface spec that can be handed to an interface developer to build the interface accordingly. This spec may describe screen layout, field definitions and labels, validation, and the mapping from interface fields to the dynamic parameter fields associated with the order. Finally, of course, the custom interface definition may just be handed to a developer as is, forming a crude set of requirements that can be used to build the interface.
The custom interface definition protocol is quite similar to that of the custom parameters definition, but it adds three additional fields in the format:
StrategyParameterLabel (the graphical user interface [GUI] label for the parameter); StrategyParameterControl (the control element type for the GUI); and StrategyParameterValidation (validation instructions for the parameter). Numeric FIX tags are omitted from the definition since this definition is not designed to be passed electronically through FIX lines.
For any custom strategy, there preferably is an exact correspondence between the parameters defined in the custom parameters definition and those in the custom interface definition. The number of parameters in each definition is identical, and the StrategyParameterName and StrategyParameterType settings exactly matches. However, the order of parameters need not be identical.
The legal parameter types are the same as listed above in the Custom Parameters Definition section. StrategyParameterLabel defines the label that will be displayed next to the field on the GUI, and it can take on any string value up to 40 characters. StrategyParameterValue defines default values to be displayed on the interface. If the end user does not change the default value, the interface needs to automatically pass the default value along with the other order parameters. Leaving StrategyParameterValue blank will instruct the interface not to display any default value.
StrategyParameterControl gives the designer options for what type of interface control is used to represent the parameter on the interface. For example, for a parameter with Time type, one could have multiple possible controls on the interface, as shown in
For simplicity, the control types may be defined as shown in
Extensions of this format may include additional control types (for example, sliders, more time controls, etc.) and additional control over interface layout (parameter groups, side-by-side parameters, spacing, etc.).
It is important to note that when a custom interface definition is created and stored, only an interface definition has been built, not a fully-functional user interface. To deploy the interface, one either hands the definition as a spec to an interface developer, or creates a general tool that automatically generates fully-functioning interfaces based on the interface definitions.
The StrategyParameterValidation field provides validation instructions for each dynamic parameter. These instructions are to be included in the interface design. A string format is used. The method for specifying validation depends on the parameter type (i.e., StrategyParameterType):
All Parameter Types
String Type Parameters
Integer/Real/Percent/Price Type Parameters
Time Type Parameters
Boolean Type Parameters
There is no validation performed on Boolean type variables.
Step 3: Deploy Strategy and Interface
The stored custom strategy definition (strategy name, manifest, and custom parameters definition) is placed in a database where it can later be referenced by the pre-processor.
If desired, the custom strategy definition can be stored at the client or end user level so that the same custom strategy name can be associated with different strategy definitions depending on the specific end user. This also allows the designer to provide the same custom strategy to multiple clients but store and load different sets of default parameter values for each.
Once stored, the strategy name must be deployed on the end-user's trading system or workstation. Deploying a basic approach strategy is simpler, as it requires no interface integration or translation of parameters into the desired protocol. Generally, one can add the custom strategy to the workstation as a new electronic destination identified by its strategy name.
Deploying an advanced approach strategy is more complex, as it involves integrating an interface or otherwise providing a mechanism through which clients can specify parameter settings. And these parameter settings also must be passed to a trading system in the correct format, as per the parameter definition.
If an interface is integrated, it must be fully compliant with the definition specified by the Authoring Tool: format and layout, parameter availability, default values, parameter validation, and parameter passing.
When integrated properly, the end user will have the option to route orders to the new custom strategy from their workstation with the relevant interface (if any) appearing automatically to allow the user to set additional parameters, and with strategy name and any additional parameters passed to the pre-processor in the correct format.
Step 4: Process Incoming Client Orders
Once the strategy definitions have been created and stored, and the strategy has been fully deployed to the end user's workstation, the user is able to send custom strategy orders. To accommodate these orders, a pre-processor component may be used that converts simplified custom strategy orders into complex, fully-specified parent algorithm orders.
Incoming orders are routed through the pre-processor, which reads the incoming strategy name and then loads the appropriate custom strategy definition from the database, possibly contingent on the end user name. The pre-processor loads the strategy definition, incorporates passed-in parameters (if any), and passes the fully-specified order on to the parent trading algorithm. Note that since the manifest format is chosen to appear very similar to the FIX format used to control the parent algorithm, the pre-processor simply needs to splice in any passed-in values for dynamic parameters directly into the manifest in the appropriate places (as defined by the placeholders), append the resulting FIX message to the order, and then pass the order on to the parent algorithm.
Note that strictly speaking, Step 4 is not really a part of creating a new custom strategy. In other words, once the strategy is built, stored, and deployed, there are no additional steps to prepare the pre-processor to handle incoming orders for the new strategy.
Custom Strategy Example
To illustrate the framework in action, a sample custom strategy based on the TactEx algorithm is used.
The strategy definition consists of five pieces:
The manifest enumerates the full list of TactEx algorithm parameters and identifies which have been nailed down vs. which can be set by the end user:
In FIX message format (omitting numeric FIX tags for readability), the manifest would look like this:
The custom parameters definition looks like this (again, omitting FIX tags):
The custom interface definition for this particular interface is as follows:
Authoring Tool Overview
This section describes a preferred authoring tool that may be used to create custom strategies based on the Conditional AutoTrader (“CAT”) parent algorithm. Conditional AutoTrader (CAT) is a flexible toolkit that enables designers to build custom execution algorithms on the fly. Every CAT strategy is made up of four components:
For more details on CAT, see co-pending U.S. patent application Ser. No. 11/387,994, entitled “Methods and Systems for Conditional Auto Trading,” filed Mar. 22, 2006, the entire contents of which are incorporated herein by reference. Although this description is focused on CAT as the parent algorithm, those skilled in the art will recognize that the description also applies, with appropriate modifications, to other trading algorithms (e.g., TactEx).
The authoring tool is an interactive, graphical environment used to design custom strategies and the interfaces used to control them. The authoring tool interface at first glance looks quite similar to the user interface for the CAT algorithm (see
The CAT algorithm interface is organized around four tabs (Time Config, Base Action, Condition, and Conditional Action), each tab corresponding to various parameters. The parameters visible on the Base Action and Conditional Action tabs further depend on an action choice specified at the top of the tab using a drop-down menu. Similarly, the parameters available on the Condition tab depend on a condition type choice, available from a drop-down menu at the top of the tab. The CAT authoring tool preferably has the same four-tab organizational structure.
The CAT algorithm interface allows the user (a trader) to set parameter values and then click “OK” button to send an order to CAT (or another trading algorithm) with all parameter value settings. The CAT authoring tool also allows parameter values to be set, but additionally allows the user (a designer) to categorize parameters into two groups: static and dynamic. Static parameters have pre-defined and fixed values for all orders processed by the custom strategy. Dynamic parameters are exposed to the end user and can be modified on an order-by-order basis. As described in the Custom Strategy Concept section herein, for each available CAT algorithm parameter, the authoring tool preferably gives the designer three options:
Within the authoring tool, all parameters can be defined and fixed (option (1) above), but only certain parameters can be exposed to the trader (options (2) or (3)). For example, the choice of base action, conditional action, or condition must be fixed in the custom strategy; those choices cannot be exposed to the trader. Fields that can be exposed are identified using a small checkbox (□) icon (see
There are buttons on the authoring tool interface that are not found on the algorithm interface:
The designer has chosen to designate only the first (Size Threshold) parameter as dynamic by clicking the checkbox 1310 for this field. When selected, the box changes color and gets marked with an X. The user has specified a default value of 1000 for this parameter. Other parameters on the screen are static: Size Threshold Type=Shares, Range Threshold=1, Range Threshold Type=Cents, Range Anchor=Midpoint, One Shot=False, and Min Cycle Time=1 min 30 sec. In the designer's final custom strategy, all of these parameters will be fixed and hidden from the trader, with the exception of Trigger Size, which will be modifiable by the trader (either from a custom interface or by programmatically passing a parameter value along with an incoming order) with a default value of 1000 shares.
The application distinguishes between required and optional parameters. Parameters that are required by the parent algorithm (e.g., CAT) must be either fixed in advance by the designer or else filled in by the user when submitting an order. For required parameters, blank values are not allowed. Therefore, if a required variable is exposed to the trader on a custom interface, validation must be performed to prevent the user from attempting to execute the order with the required parameter left blank. Following the conventions described herein in the Custom Strategy Concept section, the \# sequence is used in the StrategyParameterValidation field for any required parameter which identifies the parameter as required.
List of Required Parameters for CAT Algorithm
Note that if the designer switches the choice of base action, conditional action, or condition, any parameter choices made relating to the previous choice are cleared.
For example, in
Steps to Author a Custom CAT Strategy
Using the Authoring Tool to Define a Custom CAT Strategy and Interface
This section will proceed screen by screen through the interface, identifying which fields can be exposed to the client as dynamic parameters. For each exposable field, the required elements of the custom parameters definition and custom interface definition are defined: parameter ID, parameter type (int, real, string, etc.), label to identify parameter on the GUI (graphical user interface), the GUI element type (edit box, checkbox, etc.), and any validation instructions for the parameter. Refer to the Custom Strategy Concept section for more information on these definitions.
Time Configuration Tab
See
Note that the two banks of radio buttons represent another parameter choice that is not exposable to the customer. For example, for start time, the designer must make a radio button selection between “Start of Day/Now” and an exact time. If the user selects “Start of Day/Now” then start time is fixed and the exact time parameter cannot be exposed to the trader. If, on the other hand, the designer selects the exact time radio button, then the designer has the option of fixing a time (leaving the shaded checkbox unchecked) or exposing the exact time control to the trader (with or without a default value). The end time works the same way. This means, for example, that the designer cannot expose both the exact end time parameter and the duration parameter to the trader simultaneously.
MaxDuration is defined as Mkt Close Time−MAX(Mkt Open Time, Time Now) (in integer minutes).
Base Action and Conditional Action Tabs
There are five possible base actions and six possible conditional actions, each listed below. Each choice is discussed separately, defining the exposable parameters for the chosen action.
Strategy choice is not exposed to the trader. In other words, a canned strategy is not created that allows users to choose between VWAP and With Volume as the base strategy. This choice must be made up front when the strategy is designed. Also, while each action has its own set of exposable elements, only selections pertaining to the chosen base and conditional actions will apply. For example, if the Target Strike base action is selected and the choice is made to expose the urgency slider, and then one subsequently changes to a With Volume base strategy, the checkmark for the Target Strike urgency slider element will be cleared automatically.
The Idle base action and conditional action choices have no parameters.
Note on Relative Limit Prices
Two types of limit prices are supported by all base and conditional actions except Idle: absolute and relative. If relative price limit is selected (in other words, if any selection other than “absolute price” is chosen from the drop-down menu on the base/conditional action screen), then the following relative limit price options are available: [cents/bps] [better/worse than] [Arrival Price/VWAP/Open/Prey Close/Arrival Opp Side/Arrival Same Side/Strike Price]. (For example, possible relative limit price options would include “cents better than VWAP” or “bps worse than Arrival Opp Side”.)
If a relative price limit is used and the designer chooses to expose the Limit Price field to the trader, then the GUI label for limit price should be appended with the relative limit price type selected. For example, if the designer fixes the limit price type as relative with “bps worse than Arrival Price”, then the GUI label for the limit price should be “Limit Price (bps worse than Arrival Price)”.
The parameter type, GUI Element type, and validation string for the Limit Price parameter field depend on the price limit type, as shown in the table below:
Base Action Tab:
See
In addition to the 2 exposable fields, the designer can fix two other parameter settings from this screen: the “Aggressive Completion” checkbox, and the limit price type. (See discussion above on limit price type and appending the GUI label for relative limit price types.) Note that the “Apply to Full Order” box is not part of the CAT algorithm interface. If this box is checked, the specified limit price will be applied to both the base and conditional action (as long as conditional action is not Idle).
Base Action Tab: TWAP
See
In addition to the 2 exposable fields, the designer can fix two other parameter settings from this screen: the “Aggressive Completion” checkbox, and the limit price type.
Base Action Tab: With Volume
See
In addition to the 2 exposable fields, the designer can limit price type.
Base Action Tab: Target Strike
See
In addition to the 3 exposable fields, the designer can fix the limit price type.
If there is a valid GUI element type to represent a slider, then that should be used instead. Here, an editbox with a positive integer input is used.
Conditional Action Tab: VWAP
See
In addition to the 3 exposable fields, the designer can fix three other parameter settings from this screen: time configuration radio box (“Until the End of the Order” or “Minutes”), the “Aggressive Completion” checkbox, and the limit price type. If the “Until the End of the Order” radio box is selected, then the duration (minutes) parameter is not exposable to the trader.
If the base action “Apply to Full Order” box is checked, then the Limit Price edit box on the conditional action tab (and the related drop-down menus and shaded checkbox) should be disabled; the base action limit price will then be applied to the conditional action as well.
Conditional Action Tab: TWAP
See
In addition to the 3 exposable fields, the designer can fix three other parameter settings from this screen: time configuration radio box (“Until the End of the Order” or “Minutes”), the “Aggressive Completion” checkbox, and the limit price type.
If the base action “Apply to Full Order” box is checked, then the Limit Price edit box on the conditional action tab (and the related drop-down menus and shaded checkbox) should be disabled; the base action limit price will then be applied to the conditional action as well.
Conditional Action Tab: with Volume
See
In addition to the 2 exposable fields, the designer can fix the limit price type.
If the base action “Apply to Full Order” box is checked, then the Limit Price edit box on the conditional action tab (and the related drop-down menus and shaded checkbox) should be disabled; the base action limit price will then be applied to the conditional action as well.
Conditional Action Tab: Target Strike
See
In addition to the 3 exposable fields, the designer can fix the limit price type.
If there is a valid GUI element type to represent a slider, then that should be used instead. Here, an editbox with a positive integer input is used.
If the base action “Apply to Full Order” box is checked, then the Limit Price edit box on the conditional action tab (and the related drop-down menus and shaded checkbox) should be disabled; the base action limit price will then be applied to the conditional action as well.
Conditional Action Tab: Fast Exec
See
In addition to the 5 exposable fields, the designer can fix the limit price type, the sweep price type (see below), the aggressiveness choice (“Limit Sweep” or “2 minutes VWAP”), and the Randomize Time/Size choice.
The sweep price type preferably takes the following format: [Cents/BPS/%/% Av Sprd] from [Midpoint/Opp Side/Same Side]. The default option (shown in
If either of the “Link to Condition” checkboxes is checked, that parameter's edit controls will be disabled (along with any associated drop-down menu and shaded checkbox) and the associated parameter will mirror the parameter value from the Size on Opposite Side condition. The “Number of Shares” parameter is linked to the first edit box (“Size Threshold”) on the Size on Opposite Side condition screen. The “Sweep Price” parameter (and all associated drop-down menus) are linked to the “within” edit box on the Size on Opposite Side condition screen. Note that the parameter values entered on the Size on Opposite Side condition screen need not be displayed on the Fast Exec screen for linked parameters; edit controls for linked parameters should simply be disabled.
If any condition type other than Size on Opposite Side is currently selected, both “Link to Condition” checkboxes will be disabled. Furthermore, if the “Size Threshold” on the Size on Opposite Side condition screen is currently denominated in anything other than shares (based on the drop-down menu), the “Link to Condition” checkbox next to the “Number of Shares” parameter on the Fast Exec screen should be disabled. Similarly, once either “Link to Condition” checkbox has been checked, the designer will not be able to switch to a different condition type without first unchecking the “Link to Condition” checkboxes. Finally, if the “Link to Condition” checkbox next to the “Number of Shares” parameter is checked, the designer will not be able to change the denomination of the “Size Threshold” on the Size on Opposite Side condition screen.
If the base action “Apply to Full Order” box is checked, then the Limit Price edit box on the conditional action tab (and the related drop-down menus and shaded checkbox) should be disabled; the base action limit price will then be applied to the conditional action as well.
Condition Tab
The Condition Tab provides six choices, each of which has its own set of associated parameter fields:
Conditions
The choice of condition must be fixed by the designer and cannot be exposed to the trader when submitting an order for the canned strategy. And like the base/conditional action tabs, when the designer chooses a particular condition, any parameters fixed or exposed on any other condition screens are automatically erased. So, for example, if a designer were to choose the time condition and expose the duration tab to the trader and then choose a new condition tab, the time condition duration parameter would not be exposed to the trader.
Condition Tab: Price Condition
See
In addition to these parameters, the designer can fix a number of other parameters:
Note that the designer cannot expose anything related to the second price trigger condition. All of the parameter choices associated with the second condition can be fixed but not exposed.
As is the case with limit prices for base/conditional actions, the trigger price for the price condition can be specified as an absolute price (e.g. “$38.50”) or a relative price (e.g. “75 bps above arrival price”).
Refer to the section herein entitled Note on Relative Limit Prices for details on parameter type, GUI element type, GUI label, and validation for this parameter. One additional detail: if the symbol for the first price condition has been entered (rather than left blank), the GUI label for the trigger price should be prefixed with this symbol (e.g., “SPY Trigger Price”). Also, the Price Trigger parameter is required, so the validation field should start with the \# character sequence.
Condition Tab: Time Condition
See
Additionally, the designer needs to pin down three additional variables: radio button choice between exact time and relative time, exact time (if selected), and relative time type. Relative time type has three options: minutes after order start time, minutes before order end time, or minutes before market close. This relative time type should be appended to the GUI label for Duration (e.g., “Time Trigger (minutes before end time)”).
Condition Tab: Size on Opposite Side Condition
See
In addition, the designer can define five other parameters (all static):
If the Size Threshold Type is “Shares”, the Size Threshold parameter type and GUI element type are Integer, and the validation string is “\#(0,)”. For all other Size Threshold Types, the Size Threshold parameter type and GUI type are Real, and the validation string is “\#(0.0,)”. In either case, GUI label is “Size Threshold (<Size Threshold Type>)”
If Range Threshold Units is set to “Cents” then the Range Threshold parameter type and GUI element type are Integer, and validation string is “\#[0,)”. Otherwise, Range Threshold parameter type and GUI element type are Real and validation string is “\#[0.0,)”. In either case, the GUI label should read “Range (<Units>from <Anchor>)”.
For example: “Range (BPS from Same Side of Quote)”.
On the Fast Exec screen (see
Condition Tab: Bid/Ask Spread Condition
See
In addition, the designer can define four other parameters (all static):
If Spread Threshold Units is set to “Cents” then the Spread Threshold parameter type and GUI element type are Integer, and validation string is “\#[0,)”. Otherwise, Spread Threshold parameter type and GUI element type are Real and validation string is “\#[0.0,)”. In either case, the GUI label should read “Spread Threshold (<Units>)”. For example: “Spread Threshold (Cents)”.
Condition Tab: Relative Return Condition
See
In addition, the designer can define four other parameters (all static):
Condition Tab: Filled Size Condition
See
In addition, the designer can define one other static parameter: Filled Threshold Type (Shares or % of Original Order).
If Filled Threshold Type is Shares, then for Filled Threshold the following definitions apply: parameter type and GUI element type are Integer, GUI label is “Filled Size Threshold (Shares)”, and validation string is “(0,)”.
If Filled Threshold Type is % of Original Order, then for Filled Threshold the following definitions apply: parameter type and GUI element type are Real, GUI label is “Filled Size Threshold (% Order)”, and validation string is “(0.0,1.0)”,
The Preview Button
When the user clicks on the “Preview” button (see, e.g.,
As shown in
The top section of the interface is divided into frames to section off parameters associated with the various parts of the CAT strategy:
Only frames containing at least one dynamic variable are shown; empty frames are hidden (in this case, the conditional action frame is hidden). The Limit Price frame only applies if either (a) the base action is Idle, (b) the conditional action is Idle, or (c) the base action is exposed and the designer has checked the “Apply to Full Order” checkbox.
If any of these apply, then there is at most one limit price that applies to the full order; this limit price parameter field is moved from the Base or Conditional Action section where it would normally be located and placed in its own section. All other sections correspond exactly to a tab of the CAT interface (and authoring tool). Any dynamic parameters exposed from one of the tabs are positioned on the interface in the section associated with the tab. In the case of Fast Exec parameters marked as “Link to Condition”, these parameters are placed in the Condition section and are displayed only once.
Parameter fields preferably are stacked vertically, never side by side. Each parameter field on the interface consists of the parameter GUI label (from the custom interface definition) followed by a “:” character and then the GUI element specified in the custom interface definition (checkbox, Integer edit box, etc.). For parameters with defined default values in the custom interface definition, the specified value is displayed in the GUI element as a default. If GUI labels are too long to display on one line, they can be broken up over several lines.
At the bottom of the preview interface are two buttons: “OK” and “Cancel”. If the preview interface is interactive, then clicking either of these buttons will close the preview pane.
If the preview interface is interactive, the validation instructions in the custom interface definition preferably are implemented for each parameter. In addition, basic type-related validation preferably is performed (the user is prevented from typing a character in an integer parameter field, and so on).
Note that in this CAT authoring tool example, the strategy designer has little direct control over the interface layout; the layout of the interface is generated automatically by the authoring tool. However, the general authoring tool functionality described herein extends to cover the case where the tool provides more control over interface layout. As those skilled in the art will recognize, a designer may be allowed to control anything from the ordering and labeling of fields to color schemes and even definitions of custom interface controls such as sliders and buttons.
The Compile Button
Pressing the Compile Button (see, e.g.,
Assuming this test is passed, the authoring tool will prompt the designer to specify a strategy name for the new custom strategy.
Then the authoring tool will write out the five portions of the custom strategy:
As described in the Custom Strategy Concept section herein, the manifest format is closely modeled after the FIX message format used to specify parameter settings for a normal CAT order. All parameters that have been identified as static variables and pre-defined in the authoring tool can be transcribed into the manifest in exactly the way they would be defined in a FIX message representing a regular CAT order with the same parameter settings. Parameters that have been identified as dynamic variables will be transcribed into the manifest by positioning the Parameter ID (found in the table entry for the parameter in this description) nestled between two pipe (I) characters into the spot where the parameter setting would typically go. Effectively a placeholder is put into the spot in the FIX message normally reserved for the parameter setting, identifying the location where the pre-processor should splice a passed-in parameter value tagged with the unique ID identified by the placeholder. This is covered extensively in the Custom Strategy Concept section.
The FIX message representing the custom parameters definition will only be created if the strategy has at least one dynamic parameter exposed to the end user.
Each dynamic parameter exposed by the designer in the authoring tool (using the checkboxes provided) preferably has a repeating group entry in the format defined in the Custom Strategy Concept section. The parameter entry is built as follows:
The top of the repeating list records the strategy name entered by the designer and the total number of dynamic parameters.
(5) Custom Interface Definition
The custom interface definition starts with a replica of the custom parameters definition. The blank StrategyParameterValue fields are overwritten with the default settings entered for each dynamic parameter by the designer. These default values may be blank, provided that the parameter in question is not identified as a required parameter. Each parameter's repeating group entry is then expanded by adding three new rows:
These five components are stored, and the authoring process is complete.
For additional background; the following information regarding recommended algorithmic trading extensions is provided.
Algorithmic Trading Extensions
Background:
The current FIX 4.4 version supports algorithmic trading through a combination of three strategy-related tags: TargetStrategy (tag 847), TargetStrategyParameters (tag 848) and ParticipationRate (tag 849). For most firms, there are a growing number of strategies that need additional parameters. Several firms have come up with a variety of implementations and have been adding custom tags to support their requirements.
Recommendations:
In order to standardize the passing of additional parameters for strategies and create a more flexible implementation to support algorithmic trading, the following are proposed:
Valid Values for StrategyParameterType (Tag 959)
Embodiments of the present invention comprise computer components and computer-implemented steps that will be apparent to those skilled in the art. For ease of exposition, not every step or element of the present invention is described herein as part of a computer system, but those skilled in the art will recognize that each step or element may have a corresponding computer system or software component. Such computer system and/or software components are therefore enabled by describing their corresponding steps or elements (that is, their functionality), and are within the scope of the present invention.
For example, all calculations preferably are performed by one or more computers. Moreover, all notifications and other communications, as well as all data transfers, to the extent allowed by law, preferably are transmitted electronically over a computer network. Further, all data preferably is stored in one or more electronic databases.
This application claims the benefit of U.S. Provisional Application No. 60/698,219, filed Jul. 11, 2005. The entire contents of that provisional application are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60698219 | Jul 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11485030 | Jul 2006 | US |
| Child | 12851986 | US |
