FIXATDL

Algorithmic Trading Definition Language

Introduction and Tutorial

January 9, 2008

Table of Contents

TABLE OF CONTENTS..................................................................................................................1

DOCUMENT HISTORY..................................................................................................................2

1 INTRODUCTION......................................................................................................................... 2

1.1 PURPOSE................................................................................................................................ 2

1.2 AUDIENCE............................................................................................................................... 2

1.3 BACKGROUND........................................................................................................................ 2

1.4 METHODOLOGY...................................................................................................................... 3

1.5 CAPABILITIES.......................................................................................................................... 3

2 SCHEMA DESIGN....................................................................................................................... 4

Core Schema...........................................................................................................................................4UI Sub-schema........................................................................................................................................4Validation Sub-schema...........................................................................................................................4

3 DEFINITION OVERVIEW............................................................................................................5

3.1 PARAMETERS........................................................................................................................................53.2 LAYOUT.................................................................................................................................................73.3 VALIDATION RULES...............................................................................................................................9

4 SAMPLE DEFINITION FILE......................................................................................................11

5 IMPLEMENTATION AND CODING GUIDE...............................................................................14

5.1 TIMESTAMP PARAMETERS.................................................................................................................145.2 TIME CONVERSION CONSIDERATIONS................................................................................................145.3 RELATIVE PRICES...............................................................................................................................155.4 RELATIVE TIMES.................................................................................................................................175.5 MULTIPLE SELECTIONS FROM A LIST................................................................................................175.7 DEFAULT VALUES VS. INITIAL VALUES..............................................................................................18

6. Appendices............................................................................................................................... 18

FIXADTL 1

Document History

Revison Date Author Comments1.0 August 15, 2007 Greg Malatestinic Original draft1.1 September 4, 2007 Zoltan Feledy Review and minor edits.1.2 November 26, 2007 Greg Malatestinic Addition of flow control description

and additional edits.1.3 January 9, 2008 Greg Malatestinic More additions.

1 Introduction

1.1 Purpose

This guide introduces the FIX Algorithmic Trading Definition Language (FIXATDL), a markup language that works in conjunction with the FIX protocol. It is used to define parameters of algorithmic order types; dependencies between the parameters; and rules for validating the values entered into an order form by a user.

Our central motivation in creating this language is to ease the integration of strategies from multiple vendors, and provide a standard way of describing these strategies. It is envisioned that applications supporting this standard would be able to receive XML documents conforming to FIXATDL and be able to dynamically display an order entry ticket containing the particular algorithmic order parameters.

1.2 Audience

This guide is intended for those interested in an overview of FIXATDL and its capabilities. It also serves as a users guide to those who wish to describe interfaces to an algorithmic order types conforming to the FIXATDL schema.

1.3 Background

The FIX protocol provides the specification of some two-dozen standard order types. These order types are enumerated in tag 40 (OrdType) of the protocol. Since these order types are well known and have been with us for some time, OMS or EMS implementations commonly treat the requirements of these order types as static, i.e. they are built once and the vendors have no means to rapidly integrate new order types into their systems.

We have recently experienced rapid growth in the use of algorithmic order types. The number of providers offering algorithms continues to rise as well as the number of algorithms they offer. This growth has exposed several problems with the way these products are currently developed and deployed. Mainly:

Each algorithm requires custom programming, testing and certification. This needs to be done for every OMS provider.

OMS vendors have limited resources and are not able to test in a timely manner. Subsequently a broker’s algorithm is queued for testing and may wait several weeks for a slot to open.

In order to get the latest algorithms, clients must upgrade their OMS. Clients must often wait several months for the next release.

FIXADTL 2

Clearly the static implementation of an order type is not an adequate model when dealing with such rapid changes. So to enable vendors to move to a dynamic implementation we are proposing the use of a markup language, FIXATDL, which will greatly reduce the time of deployment of algorithmic order types.

With FIXATDL brokers describe the inputs to their algorithms in a conforming XML document. An OMS that supports FIXATDL will be able to receive these XML documents and use them to render the appropriate GUI controls and input fields on their order entry screens. As the user toggles among the order types, different order entry screens can be rendered on-the-fly. When it comes time to generate an order, data entered by the user is packaged into the appropriate FIX tags as described in the broker’s XML document and is routed to that broker.

For this to be realized, an OMS must be re-architected to support the schema. This may be a considerable effort for some vendors, but it is a one-time cost that is outweighed by the benefit of algorithm integration without the need of additional programming and without the need to perform a product upgrade. Some vendors have been in the process of implementing such a solution, each with their own XML Schema language. FPL believes that it would be beneficial to the industry as a whole if we were to standardize to one schema.

1.4 Methodology

During 2006, the Algorithmic Trading Working Group conducted interviews with several OMS vendors and algorithmic trading providers. From these sessions we were able to gather a list of capabilities that would be necessary for a definition language. We then leveraged the experiences of several of our members who had been involved in algorithmic order integration and had detailed knowledge of numerous broker-dealer algorithmic trading specifications. This information formed a set of requirements from which we developed the schema of the language.

1.5 Capabilities

FIXATDL makes it possible to describe the FIX tags and ancillary data necessary to support trading using a variety of algorithmic order types. Great care has been taken to accommodate most of the dependencies, workflows and behaviors of the parameters that are required of any particular algorithm. Among these capabilities are:

Ability to assign a FIX tag number to a parameter - Considering that most FIX capable systems (OMSs, EMSs, FIX Hubs) do not yet support the algorithmic trading extension defined in FIX 5.0 (tags 957 – 960), most algorithmic parameters are transported within user defined tags.

Ability to declare the type of a parameter - Algorithm providers place type constraints on the parameters they receive. With FIXATDL, a parameter’s type can be defined by selecting from the list of FIX predefined types.

Ability to constrain the values entered by the user by specifying minimum and maximum values, or restricting the values to a particular enumerated range.

Ability to validate parameter values entered by the user via simple bounds checking.

Ability to validate parameter values by the user via complex and conditional rules - FIXATDL provides a rule language that enables the creation of complex and conditional validation rules.

Ability to enable or disable a parameter via complex flow-control rules.

FIXADTL 3

Ability to perform validation either at the time an order is sent or at the time a trading engine receives an order.

Ability to initialize the value of GUI control object - When a GUI control is initially rendered on the screen there may be a text value or selection that is used as the initial value. Algorithm providers may set this value in the parameter definition.

Ability to declare statically set tag values - Some Algo engines require certain tags to be set with constant values. Specifically, in cases where a value must be populated in the FIX order message without the user having to enter this information. For example, an algorithm provider may require that tag 57, TargetSubID, is populated with the same particular value regardless of the strategy being used.

Ability to define a preferred GUI control - FIXATDL provides a list of platform neutral controls from which to choose.

Ability to define a preferred layout of the controls in a manner that is independent of user interface platform.

2 Schema Design

Before we began defining the schema we took a look at what had been done by the FIXML Schema Working Group and adopted one of their basic guidelines: to use XML Schema attributes over XML Schema elements whenever possible. Favoring attributes in this manner produces XML that is a bit more compact and easier to read. This was important because we realize that it may be business analysts or product managers that may be authoring the XML and not necessarily programmers.

Using the information gathered from the vendors during the interview phase, we decided to partition the schema along the functional lines of data interface, presentation, validation and workflow. These 4 individual components of the schema (or sub-schemas) are described as follows:

Core Schema

The core schema contains attributes and elements that are used to describe the data content of the algorithm and the parameters. A minimal implementation of a dynamically rendered order entry screen would need to support XML documents that adhere to this schema.

UI Sub-schema

The UI sub-schema (layout schema) contains attributes and elements to describe how a parameter should be rendered within a user interface – this includes recommendations about GUI components and their relative location within the interface. Our intent was to provide the algorithm provider some visual control of their trading screens without overriding the overall look-and-feel of the hosting system.

Validation Sub-schema

The validation sub-schema contains attributes and elements that can be used to author rules that are applied to the parameters. These rules can be simple where boundary conditions checked, or complex where compound boolean expressions involving several parameters are evaluated.

Flow Sub-schema

FIXADTL 4

The flow sub-schema provides the ability to dynamically affect the behavior of a GUI control. Rules can be created to enable or disable parameters based on values entered by the user in other parameters.

Four namespaces have been created to encapsulate the elements of the schema: core, layout, valid and flow. These namespaces are defined in separate XML Schema files: FIXATDL-core.xsd, FIXATDL-layout.xsd, FIXATDL-valid.xsd and FIXATDL-flow.xsd.

Please note that while support of the core schema is required, it is not necessary for the validation, layout and flow-control sub-schemas to be supported by an OMS/EMS in order for it to process FIXATDL code. We expect that vendors will provide varying degrees of support for the capabilities offered by this standard based on the technical constraints imposed by the design and architecture of their existing systems. We do, though, highly encourage broker-dealers to write algorithm definitions that contain these features.

3 Definition Overview

To describe an algorithmic order type (or strategy) a few basic bits of information are needed: The strategy definition must provide a unique identifier of the strategy and indicate which tag is to be used to identify the strategy (FIX 4.4 has designated tag 847 for this purpose); it must provide a list of detailed parameter definitions; and it must indicate which Algo Extension models are supported (these models describe how algorithmic parameters are transported. Details of these models can be found in http://www.fixprotocol.org/documents/1428/Extensions%20for%20Algorithmic%20Trading%20050405.doc)

Optionally, a strategy definition may include other attributes such as: applicable message types, supported asset classes; algorithm provider IDs; version number; trading desk location; a list of applicable markets; and several others. A strategy definition may also include validation rules, flow control rules (to enabled or disabled a GUI control), choices for GUI controls and screen layout preferences.

Give that the most complex characteristics of a strategy are the parameter list, validation and flow control rules, and UI preferences; we will focus on these topics in the sections to follow.

3.1 Parameters

Parameters received by an algorithmic order processor must have a type known to the processor. FIXATDL requires that any parameter to an algorithm must be of a type defined by the FIX protocol. These types are defined in the description of tag 958 in the FIX 5.0 specification. The types listed in that description should be easily recognized by anyone familiar with FIX.

To define a parameter one should use the <parameter> element of FIXATDL along with its required attributes (see appendix B for a complete list of attributes):

name (a unique identifier) type (values taken from tag 959) fixTag (required if using custom tags) uiRep (not required but useful for the vendor) use (defaults to “optional” if not defined)

For example:

<parameter name=”MktOnCloseFlag” uiRep=”Mkt on Close” type=”13” fixTag=”8001” use=”required” lay:controlType=”CheckBox”/>

FIXADTL 5

Here we have defined a Boolean parameter, “MktOnClose”. The parameter is required and the value chosen by the user will be populated in tag 8001 of the FIX order message that is sent to the broker. The attribute “uiRep” is used to define what the algo provider wishes the user to see on the screen.

Since parameters may be of any valid FIX type, their attributes may differ from each other. This may lead to some confusion and cause errors should a parameter be defined with an invalid attribute. For instance, it would make little sense to assign a minimum value to a String parameter. To alleviate these situations and to promote type-safety, FIXATDL has defined a set of elements that are derived from the base element, <parameter>.

So if we were to redefine the previous parameter using the type-safe elements it would be written as:

<parameter name=”MktOnCloseFlag” uiRep=”Mkt on Close” xsi:type=”Boolean_t” type=”13” fixTag=”8001” use=”required” lay:controlType=”CheckBox” initValue=”false”/>

Notice that by setting xsi:type of this parameter to “Boolean_t” we can now use an attribute, “initValue”, which is a member of the derived element and takes on standard XML Boolean values “true” or “false”. (The namespace, xsi can be declared by the statement:xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance)

The following table lists the parameter types derived either directly or indirectly from <parameter>.

Parameter Type xsi:type type Additional attributesAmt Amt_t 10 initValue, maxValue, minValueBoolean Boolean_t 13 initValueChar Char_t 12 initValueCurrency Currency_t 16 initValueData Data_t 23 initValue, minLength, maxLengthExchange Exchange_t 17 initValueFloat Float_t 6 initValue, minValue, maxValueInt Int_t 1 initValue, minValue, maxValueLength Length_t 2 initValueLocalMktTime LocalMktTime_t 21 initValue, minValue, maxValue, localMktTzMonth-Year MonthYear_t 18 initValue, minValue, maxValueMultipleCharValue MultipleCharValue_t 15 minLength, maxLengthMultipleStringValue MultipleStringValue_t 24 minLength, maxLengthNumInGroup NumInGroup_t 3 initValuePercentage Percentage_t 11 initValue, maxValue, minValuePrice Price_t 8 initValue, minValue, maxValuePriceOffset PriceOffset_t 9 initValue, minValue, maxValueQty Qty_t 7 initValue, minValue, maxValueSeqNum SeqNum_t 4 initValueString String_t 14 initValue, minLength, maxLengthTagNum TagNum_t 5 initValueUTCDate UTCDate_t 22 initValue, minValue, maxValueUTCTimeOnly UTCTimeOnly_t 20 initValue, minValue, maxValueUTCTimeStamp UTCTimeStamp_t 11 initValue, minValue, maxValue, localMktTz

FIXADTL 6

3.2 Layout

In order to render a parameter within an order entry screen, an OMS must be able to pick an appropriate GUI control to display. For instance, a parameter representing a price would best be rendered as a number spinner control and a parameter representing a choice between limited numbers of values, such as “High”, “Medium” and “Low”, would best be rendered as a comboBox. Once the GUI controls have been selected, the OMS must appropriately arrange them on the screen. By using the elements and attributes of the Layout Schema, an algorithm provider can describe the GUI controls to use and describe how they should be arranged on the screen.

Note that the Layout Schema is not intended to be a complete specification for building user interfaces. It provides only basic functionality.

In recent years there have been many efforts to create a graphical user interface markup language. Most have these have attracted limited attention and acceptance. Among those with the most potential for wide acceptance have been XUL and XAML. (XUL is the markup language developed by the Mozilla Foundation and is used by the Firefox browser application. XAML was developed by Microsoft and is an integral part of their Windows Presentation Foundation (WPF).) Our initial notion was to leverage one of the standards. However, in our view, XML-based creation of a user interface is an emerging technology. So a conscious decision was made on our part not to adopt any one of these languages. Instead we have developed our own with the understanding that a vendor may extend or transform it to be aligned with their architecture and internal data structures.

Many parts of the UI sub-schema are optional; it is not a tight specification and does not attempt to dictate user-interface style or look-and-feel. We designed it to be platform neutral. The components that are provided are those typically found in both .Net and Java environments.

The layout schema allows GUI controls to be arranged by adding them to a container define by the <strategyPanel> element. Controls within a panel may be arranged either vertically or horizontally. Panel themselves may be nested and arranged either vertically or horizontally as well. The attributes of the <strategyPanel> element include

Title – a string representing the panel title which may or may not be displayed Collapsible – a Boolean value indicating whether the panel can be collapsed. Collapsed – a Boolean value indicating the panel’s initial state. Color – the background color of the panel. Orientation – defines whether the panels components should vertically or horizontally

aligned.

An important detail in the user-interface portion is the controls themselves – they are also platform neutral. For platforms that might not support more complex components (i.e.; Sliders on web-platforms) you could choose to implement an alternative component (such as a combo-box).

The following basic controls supported are:

CheckBox Standard check box – set to checked or unchecked ComboBox Drop down list that displays one item at a time RadioButton Standard radio button that is typically part of a group Label Non editable text TextField Standard text field Slider Draggable slider with labels that map to values MultiCheckBox Group of two or more checkboxes that logically map to one field Clock Clock with hours, minutes and AM/PM

FIXADTL 7

SingleSpinner A numeric field that has arrows to increment and decrement DualSpinner A numeric field that has two sets of arrows to increment and

decrement by different values (say for pennies and dollars)

The list of controls is expected to expand and evolve as FIXATDL gets more participants and feedback.

The following example defines four parameters. If we examine the code we’ll notice that each of them have been given preferred GUI control object by the author of the XML. The arrangement on the screen of the parameters has also been provided.

<stategyPanel orientation=”horizontal”> <strategyPanel title=”Time Parameters” collapsible=”false” orientation=”vertical”> <parameter name=”Start Time” type=”19” fixTag=”168” use=”optional” controlType=”Clock”/>

<parameter name=”End Time” type=”19” fixTag=”126” use=”optional” controlType=”Clock”/> </strategyPanel> <strategyPanel title=”Advanced” collapsible=”false” orientation=”vertical”>

<parameter name=”Participation Rate” type=”11” fixTag=”7022” use=”optional” controlType=”SingleSpinner”/>

<parameter name=”Aggression” type=”1” fixTag=”7023” use=”optional” controlType=”ComboBox”><enumPair uiRep=”High” wireValue=”3”/><enumPair uiRep=”Medium” wireValue=”2”/><enumPair uiRep=”Low” wireValue=”1”/>

</parameter> </strategyPanel></strategyPanel>

If an application were to render this information on an order ticket it would have to decide which GUI controls to instantiate and find a way to insert them into panels and lay the panels out according to the instructions of the XML. Different platforms will have different controls and panels available for this purpose and the application built on these platforms will have different appearances. A rendering of these parameters may look similar to the following image:

An important point to remember is that the UI control is just a recommended component. The decision to support a given type is up to the vendor. For example, if you choose not to support spinners, than just use standard a textbox. The way a component is rendered is entirely up to the vendor as well – and it is in this area where we would expect vendors to leverage any custom controls they may have developed in order to differentiate their offerings.

FIXADTL 8

3.3 Validation Rules

We’ll need to be able to validate what a user has entered into the control of the GUI. It would be simple enough to let the user enter any value into a parameter and let the recipient broker system reject the order if any of the values were invalid. However, this is not the common practice – most order originating systems will provide basic validation of the order before it is transmitted.

By performing validation on the client application, useful information can be given to the user when an invalid value has been entered and the user can edit the order ticket based on that information. If it were left to the recipient system to validate then the user would have to examine the order reject message to determine the reason for the rejection. You would even expect the user to make a few errors before getting it right which would result in a trade blotter littered with rejected orders.

With this in mind, we have proposed a validation schema that enables the creation of complex and conditional validation rules which can be applied to the orders generated by an OMS. The validation schema is intended to be used by the client application (GUI) but may also be applicable to server-side validation.

Validation rules are defined by use of the <strategyEdit> element. Each rule must include a boolean expression, defined by the use of multiple <edit> elements, and an error message which can be displayed by the OMS in the case where the boolean expression evaluates to true. To form the boolean expression several <edit> elements may be listed with an expected left-to-right evaluation order.

For example:

<strategyEdit errorMessage="Start Time must precede End Time."> <edit field="StartTime" logicOperator="LT"/> <edit field="EndTime" logicOperator="End"/> </strategyEdit>

Here we have defined a rule predicated on the fact that StartTime and EndTime are two Datetime parameters defined in the parameter list of this strategy. At validation time, this rule instructs the OMS to perform an evaluation of the boolean expression provided by the <edit> elements. In this case a comparison of StartTime and EndTime will be made. If StartTime is not less than EndTime then the OMS can inform the user of this fact by displaying the error message in a dialog box.

As another example, consider a compound expression where a parameter value is compared not to another parameter but to a constant value.

<strategyEdit errorMessage="If Participation Rate is entered it must be between 1 and 50"> <val:edit field="ParticipationRate" operator="EQ" value="" logicOperator="OR"/> <val:edit field="ParticipationRate" operator="GE" value="1" logicOperator="AND"/> <val:edit field="ParticipationRate" operator="LE" value="50" logicOperator="End"/> </strategyEdit>

Here we see a strategy parameter being compared to two constant values. This rule is also illustrative on how the <edit> elements can be listed in a particular order to build the desired boolean expression.

FIXADTL 9

The field attribute of an <edit> element is not restricted to strategy parameters. Standard order tags may also be used to create boolean expressions. For example

<strategyEdit errorMessage="For IOC orders Participation Rate must be between 1 and 25"> <val:edit field="TimeInForce" operator="EQ" value="3" logicOperator="OR"/> <val:edit field="ParticipationRate" operator="GE" value="1" logicOperator="AND"/> <val:edit field="ParticipationRate" operator="LE" value="25" logicOperator="End"/> </strategyEdit>

This rule evaluates the value of TimeInForce which is a standard tag found in most order messages. The values associated with standard tags are those that are sent over the wire, so you should use similar values when making a comparison. Support for these types of expressions is highly dependent on a vendor’s implementation of FIXATDL. Not all standard tags may be available. In cases where the field attribute is not recognized or not supported, the rule containing the offending <edit> element should be ignored.

Bear in mind that we are considering batch-mode validation only, i.e. validation takes place after the user gives values to all the parameters and is ready to send the order. If you want to provide an iterative validation method, one where each parameter is checked just after the users enters a value; you should consider flow control rules instead.

3.4 Flow Control Rules Definition

Interdependencies among standard FIX tags affecting their applicability are quite common. For example, Price (44) is not applicable when OrdType (40) is set to Market. The same can be said for algorithmic order types and their parameters. Many algorithmic order types will have parameters whose applicability is dependent on one or more other parameters. These rules are often listed in algorithmic order specifications in the comments column of tables that describe the parameters of the algorithm. In order to standardize the way these rules are described we have provided a sub-schema which contains elements and attributes used to define rules. These rules control the applicability of a parameter and can cause them to be enabled, disabled, hidden, and shown.

We consider this capability as a means to control the user’s workflow and this is why we have called the sub-schema the flow sub-schema. When creating such rules the expectation is that they are evaluated every time a parameter’s value has changed and based on the outcome of the evaluations certain parameters may become grey-out or hidden as the user enters values into an order entry screen.

The rules that change the behavior of a parameter consist of a boolean expression that when true causes the parameter to change its visual state. When creating this functionality we were able to leverage the work that had been done in creating the validation schema and you will notice in the following example that the element <edit> provides the boolean expression of a <stateRule>.

<parameter name=”AlphaMode” uiRep=”Alpha Mode” type=”1” xsi”type=”Int_t” initValue=”Annual” fixTag=”8300”>

<enumPair uiRep=”Annual” wireValue=”1”/> <enumPair uiRep=”Daily” wireValue=”2”/> <enumPair uiRep=”Continuous” wireValue=”3”/> </parameter>

FIXADTL 10

<parameter name=”Alpha” uiRep=”Alpha” type=”6” xsi:type=”Float_t” fixTag=”8301”> <stateRule behavior=”enable”> <edit field=”AlphaMode” operator=”EQ” value=”Annual” logicOperator=”OR”/> <edit field=”AlphaMode” operator=”EQ” value=”Daily” logicOperator=”End”/> </stateRule> </parameter>

In this example there are two parameters defined: AlphaMode and Alpha. A rule has been supplied which governs the behavior of Alpha. It should be interpreted as: “The parameter Alpha is enabled only when AlphaMode is Annual or Daily. When AlphaMode is Continuous, Alpha should be disabled.”

This example shows the rules defined within a parameter definition. Another way to define flow rules is to group them together in a containing element, <stateGroup>, which is declared after all parameter declarations. Flow rules of all the parameters would be defined within this element. So if we were to use this method then the previous example becomes:

<parameter name=”AlphaMode” uiRep=”Alpha Mode” type=”1” xsi”type=”Int_t” initValue=”Annual” fixTag=”8300”> <enumPair uiRep=”Annual” wireValue=”1”/> <enumPair uiRep=”Daily” wireValue=”2”/> <enumPair uiRep=”Continuous” wireValue=”3”/> </parameter> <parameter name=”Alpha” uiRep=”Alpha” type=”6” xsi:type=”Float_t” fixTag=”8301”> </parameter>

<stateGroup> <field name=”Alpha” behavior=”enable”> <edit field=”AlphaMode” operator=”EQ” value=”Annual” logicOperator=”OR”/> <edit field=”AlphaMode” operator=”EQ” value=”Daily” logicOperator=”End”/> </field> </stateGroup>

As with validations rules provided by the validation sub-schema, flow rules may use the values of standard FIX tags to determine whether or not to change the visual state of a parameter.

4 Sample Definition File

So now that you have been provided with same basic understanding of what FIXATDL is about, we’ll proceed with an example. Let’s consider a fictional algorithm called “Heuristic Mining”. It is not important to know how the algorithm goes about its business of executing an order, we just need to know how to render the proper screen and send the necessary FIX tags.

The algorithm has 5 parameters: Start Time, End Time, Benchmark Type, Benchmark Price, and Dampening Rate. It also requires that tag 57 (TargetSubID) be set to “MBA” and tag 18 (ExecInst) includes the value “1” (not held).

FIXADTL 11

The definition of this algorithm will also include some rules to disable of the parameters and some other rules for validation. The constraints and dependencies from which these rules will be derived are summarized in the following table.

Parameter FIX Tag Req’d Range RuleStart Time 6100 Yes Must precede End Time.End Time 6101 No Must precede Start

Time.Benchmark Type 6102 Yes “Last Price”, “Mid

Point”, “Open”, “Specific Price”

Corresponding values for transmit are: L, M, O or S.

Benchmark Price 6103 Conditional > 0 Required when Benchmark Type is “Specific Price”.

Dampening Rate 6104 No 0 – 50 Default is 10

We’ll start off by describing this algorithm using the elements and attributes of the core, flow and layout schema. Following that we’ll include the code defining the validation rules that may be processed when the order is ready for transmission or upon receipt. For convenience we have grouped the controls into one panel in a vertical orientation.

The following listing shows the entire definition of the Heuristic Mining algorithm.

<strategy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"name="HeuristicMining" version="1.0"providerID="XYZ Trading" fixTag="847"uiRep="Heuristic Mining" wireValue="1"locations="NA EMEA" applicableMsgTypes="D E"supportsCxlRpl="false" algoExtModel="Custom">

<strategyLayout> <strategyPanel collapsible="false" orientation="VERTICAL">

<parameter name="StartTime" uiRep=”Start Time” xsi:type="UTCTimeStamp_t" type="19" fixTag="6100" use="required"

initValue="09:30:00" localMktTz=”Americas/New_York” lay:controlType=”Clock”/>

<parameter name="EndTime" uiRep=”End Time” xsi:type="UTCTimeStamp_t" type="19" fixTag="6100" use="required"

initValue="16:00:00" localMktTz=”Americas/NewYork” lay:controlType=”Clock”/>

<parameter name="BenchmarkType" uiRep=”Benchmark” xsi:type="String_t" type="14"

fixTag="6102" use="optional" lay:controlType=”ComboBox”>

<enumPair uiRep="Last Price" wireValue="L"/> <enumPair uiRep="Mid Point" wireValue="M"/> <enumPair uiRep="Open" wireValue="O"/>

<enumPair uiRep="Specific Price" wireValue="S"/> </parameter>

FIXADTL 12

<parameter name="BenchmarkPrice" uiRep=”Benchmark Prc” xsi:type="Price_t" type="8"

fixTag="6103" use="optional"precision="2" increment="0.01"

lay:controlType=”SingleSpinner”/>

<parameter name="DampeningRate" uiRep=”Dampening Rate”xsi:type=”Int_t” type="1"fixTag="6104" use="optional"

increment=”1” lay:controlType=”SingleSpinner”/>

</strategyPanel> </strategyLayout>

<!-- all our algos need tag 57 set to "MBA" --> <constTag fixTag="57"

wireValue="MBA"overrideUserInput="true"/>

<!-- all orders must be "not held" --> <constTag fixTag="18"

wireValue="1"appendToUserInput="true"/>

<strategyEdit errorMessage="Start time must be less than end time."> <edit

field="EndTime" type="UTCTimeStamp" logicOperator="GT"/>

<edit field="StartTime" type="UTCTimeStamp" logicOperator=""/>

</strategyEdit>

<strategyEdit errorMessage="BenchmarkPrice required if BenchmarkType is Specific”> <edit

field="BenchmarkPrice" operator="EQ" value="" type="String" logicOperator="OR"/>

<edit field="BenchmarkPrice" operator="NE" value="" type="String" logicOperator="AND"/>

<edit field="BenchmarkType" operator="EQ" value="Specific Price" type="String" logicOperator=""/>

</strategyEdit>

FIXADTL 13

<strategyEdit errorMessage="Dampening Rate must be between 0 and 50"> <edit

field="DampeningRate" type="Int" operator="GT"

value=”0” logicOperator=”AND”/> <edit

field="DampeningRate" type="Int"

operator=”LT” value=”50”

logicOperator=""/> </strategyEdit>

</strategy>

5 Implementation and Coding Guide

You now know the basics of how to describe the data interface of a parameter, how to group them into panels and create a validation rule. We’ll now examine some common parameters and present some solutions and guidelines on how to define them with the schema.

5.1 TimeStamp Parameters

Most strategies employ a start and end time for when they are in effect. This information is often transferred in tags 168 (EffectiveTime) and 126 (ExpireTime) which are both UTCTimestamps. FIXATDL schema defines several timestamp elements that are derived from the base Parameter_t element.

UTCTimeStamp LocalMktTime Month-Year UTCDate UTCTimeOnly

When defining UTCTimeStamps and UTCTimeOnly parameters the initValue, minValue and maxValue attributes are available for use. Note that these attributes are LocalMktTime types, so when defining them keep in mind that they refer to the time zone of the target broker or exchange.

5.2 Time conversion considerations

The underlying premise in the design of the timestamp elements is that the rendering engine (OMS, EMS, etc.) will know the locality of its users and will have the ability to display and receive time parameters in local time. It will also know whether daylight savings is in effect. With this information it is be able to convert any time parameter from local time to UTC and easily comply with FIX timestamp conventions.

We leave it to the OMS to know how to do this and also how to compensate for daylight savings adjustments. However, when it comes to the attribute “initValue” the OMS will need more information than just a UTCTimestamp in order to display the initial value correctly.

FIXADTL 14

Here’s why:

Suppose it is January and initValue=”14:30:00”. This is equivalent to 9:30am in New York. Now suppose it is May and initValue is still =”14:30:00”, but this is now equivalent to 10:30 am in New York.

The proposed solution is to add an attribute “LocalMktTz” where we would place the time zone of the target broker or market. If the OMS knew this information then it could properly convert initial, maximum and minimum values. It would be done this way: if the local mkt tz is currently in standard time then convert as usual, if the local_mkt_tz is currently in daylight time then add/subtract an extra hour when doing the conversion. An example of LocalMktTime is “est5edt”.

For example, consider the following XML:

<parameter name=”StartTime” uiRep=”Start Time” type=”19” xsi:type=”UTCTimeStamp_t” fixTag=”7500” use=”required” initValue=”09:30” minValue=”09:30” maxValue=”16:00” localMktTz=”Americas/New_York” lay:controlType=”Clock”/>

This defines a parameter, StartTime, with a minimum value of 09:30 and a maximum value of 16:00. The broker receiving this order operates in the east cost of the United States which has a time zone code of Americas/New_York. These values are defined just once and do not need to be changed during the course of a year.

5.3 Relative Prices

In some cases a price may be required that is not absolute but rather relative to a specific benchmark. There are several ways in which to describe a relative price and the choice depends on how the algorithmic engine expects to receive them.

The simplest way would be to declare the parameter as a String and let the user type in values such as “Bid+0.05” indicating the bid price plus five cents. This would require that the receiving engine be capable of parsing and properly interpreting this string. Users would also be required to enter values using the proper format.

Another method of describing a relative price is to use several tags and the set of standard FIX types and FIXATDL controls. From a standards perspective this is preferable to the previous free-format method and is less susceptible to user error. These tags would indicate data items:

Benchmark type – an enumeration of quote attributes such as BID, ASK and MID. Offset – the offset value from the benchmark. Operator – a value indicating whether to add or subtract the offset. Absolute price – a specific price entered by the user.

The following code snippet gives an example of how to describe a relative price.

<parameter name=”Price1” type=”4” xsi:type=”Price_t” fixTag=”6001”/> <parameter name=”Price1Benchmark” type=”1” xsi:type=”Int_t fixTag=”6002”/>

<enumPair uiRep=”NBBid” wireValue=”1”/><enumPair uiRep=”NBOffer” wireValue=”2”/><enumPair uiRep=”NBMid” wireValue=”3”/>

</parameter> <parameter name=”Price1Op” type=”12” xsi:type=”Char_t” fixTag=”6003”/>

FIXADTL 15

<enumPair uiRep=”+” wireValue=”+”/><enumPair uiRep=”-“ wireValue=”-“/>

</parameter> <parameter name=”Price1Offset” type=”3” xsi_type=”Price_t” fixTag=”6004”/>

The four tags 6001, 6002, 6003 and 6004 give all the necessary information to derive a relative price. Note that we could have easily declared PriceOp1 to be a String_t and required that the user enter either a “+” or a “-“, but the way it is described is less prone to user error.

The only question about interpretation has to do with how we let the user enter an absolute price. The simplest way would be to check whether there is a valid price value in tag 6001 and ignore tags 6002, 6003 and 6004 if there is such a value. Another way would be to have another parameter that acts as an indicator. This parameter could be a boolean or one of a string, char or integer limited to the values “Relative” and “Absolute”. A rule could be written that check that the user has not entered a price in the wrong field. This could be defined as:

<parameter name=”Price1Type” type=”12” xsi:type=”Char_t” fixTag=”6000”/><enumPair uiRep=”Absolute” wireValue=”a”/><enumPair uiRep=”Relative“ wireValue=”r“/>

</parameter><strategyEdit>

<val:edit field="Price1Type" operator="EQ" value="Absolute" logicOperator="OR"/> <val:edit field="Price1Offset" operator="EX" logicOperator="AND"/> <val:edit field="Price1Benchmark" operator="EX" logicOperator="AND"/><val:edit field="Price1Op" operator="EX" logicOperator=”End”/></strategyEdit><strategyEdit>

<val:edit field="Price1Type" operator="EQ" value="Relative" logicOperator="OR"/> <val:edit field="Price1" operator="EX" logicOperator="End"/></strategyEdit>

If we want the user to be able to enter offsets in units other than prices, then we can declare our Offset parameter, “Price1Offset”, to be a String type and declare another parameter that will deliver the meta-data needed to describe the units of the Offset.

<parameter name=”Price1Offset” type=”3” xsi_type=”String_t” fixTag=”6004”/><parameter name=”Price1OffsetUnits” type=”1” xsi_type=”Int_t” fixTag=”6005”>

<enumPair uiRep=”Ticks” wireValue=”1”/><enumPair uiRep=”Percent” wireValue=”2”/>

</parameter>

It would then be up to the algorithmic engine to properly interpret Price1Offset as directed by tag 6005, Price1OffsetUnits.

5.4 Relative Times

As with prices, there may be the need to express Timestamp parameters relative to some benchmark. Methods for describing relative time parameters are very similar to methods used to describe relative prices. Again, the choice depends on how the algorithmic engine expects to receive them.

FIXADTL 16

One method of describing a relative time is to use several tags and the set of standard FIX types and FIXATDL controls. These tags would indicate data items:

Benchmark type – an enumeration of timestamp attributes such as MktOpen and MktClose.

Offset – the offset value from the benchmark. Operator – a value indicating whether to add or subtract the offset. Absolute time – a specific time entered by the user.

The following code snippet gives an example of how to describe a relative time.

<parameter name=”EndTime” type=”19” xsi:type=”UTCTimeStamp_t” fixTag=”6001”/> <parameter name=”EndTimeBenchmark” type=”1” xsi:type=”Int_t fixTag=”6002”/>

<enumPair uiRep=”MktOpen” wireValue=”1”/><enumPair uiRep=”MktClose” wireValue=”2”/>

</parameter> <parameter name=”EndTimeOp” type=”12” xsi:type=”Char_t” fixTag=”6003”/>

<enumPair uiRep=”+” wireValue=”+”/><enumPair uiRep=”-“ wireValue=”-“/>

</parameter> <parameter name=”EndTimeOffset” type=”3” xsi_type=”Price_t” fixTag=”6004”/>

The four tags 6001, 6002, 6003 and 6004 give all the necessary information to derive a relative time. Note that we could have easily declared EndTimeOp to be a String_t and required that the user enter either a “+” or a “-“, but the way it is described is less prone to user error.

5.5 Multiple Selections from a List

There are times when a parameter needs to contain multiple values. The standard FIX tag ExecInst (18) exhibits this behavior. It can hold multiple values delimited by a space. It is recommended that algorithmic parameters that can hold multiple values be described in the same fashion.

When describing a mutli-value parameter choose one of the types, MultipleStringValue or MultipleCharValue, as the type attribute. To provide a range of values from which the user can choose, use multiple <enumPair> elements. In each <enumPair> describe the list items as you would the items of a combo box. For the UI control, use the MultiCheckBox control. For example,

<parameter name=”SplitHandling” uiRep=”Split Handling” type=”15” xsi:type=”MultipleCharValue_t” fixTag=”5503” use=”optional” controlType=”MultiCheckBox”>

<enumPair uiRep=”Allow Add-Ons” wireValue=”A”/><enumPair uiRep=”Disallow ISOs” wireValue=”B”/><enumPair uiRep=”Aggregate Fills” wireValue=”C”/>

</parameter>

On some platforms this is the equivalent of a CheckedListBox and may be rendered as in the following graphic.

FIXADTL 17

Based on this information, the OMS should know how to properly gather the selections from the control and properly format the data into the desired tag. In this example if each item in the CheckedListBox were checked then the value in the FIX message for tag 5503 would be “A B C”.

5.7 Default Values vs. Initial Values

Most algorithm providers define default values for particular parameters. These values are used by the recipient system in cases where they are not supplied by the originating system. A parameter that has a default value will typically be defined as optional - the intention being that if the user does not enter the information the broker will use the default value. This calls for the user to be educated about how the recipient system will process an order message when these fields are not populated.

Since it is not the responsibility of the originating system to manage default values, we have not given the schema any capabilities to do so. However, we have given the algorithm providers the ability to suggest an initial value for certain parameters. This is why most of the parameter types have an “initValue” attribute. When this information is defined in an XML instance it lets the originating system pre-populate a GUI with control with the given value.

6. Appendices

Appendix A – Element Data Dictionary

Element Name Parent Element Occurs DescriptionconstTag strategy 0 – unbounded Definition for non-viewable parameters.description strategy 0 - 1 Basic description of a strategy.edit strategyEdit or

stateRule1 - unbounded Boolean expression to be evaluated.

enumPair parameter 0 – unbounded Defines a legal value of a parameter a corresponding wire value.

field stateGroup 0 - unbounded Reference to a parameterhelpText parameter 0 – 1item stateGroup 1 - unbounded Reference to an enumPair item.parameter strategy 0 - unboundedstateGroup strategy 0 – 1 Container for flow rulesstateRule parameter 0 – 1 Defines workflow rule for a parameter.strategies 1 Container for all strategy elements.strategy strategies 1 - unbounded Root level of a strategy definition.strategyEdit strategy 0 - unbounded Definition of a validation rule.strategyLayout strategy 0 - 1 Container for strategyPanelsstrategyPanel strategyLayout 0 - unbounded

Appendix B – Attribute Data Dictionary

Attribute Element Type Req’d

Description

algoExtModel strategy MVS Y List of the extension models supported as described by Algorithmic Trading Proposed Extensions v1.0

FIXADTL 18

appendUserInput constTag boolean Y If true, this value is appended to the value of the tag. The primary motivation for this attribute is to allow values to be added to tags of type mutilpleValueString such as tag 18. Cannot be true if overrideUserInput is also true. Used only for MultipleValueString tags.

applicableMsgTypes strategy MVS_t N List of values from FIX tag 35 with <space> delimiter.

assetClasses strategy MVS_t N List of asset classes supported by the algorithm. Values are obtained from FIX tag 167 (SecurityType).

behavior field string Y Can be one of Enable Disable Hide Unhide

behavior stateRule string Y Can be one of Enable Disable Hide Unhide

collapsed strategyPanel boolean Ncollapsible strategyPanel boolean N Indicates whether panel can be collapsed.color strategyPanel string NcontrolType parameter string N Can be one of

Clock TextField MultiCheckBox Slider CheckBox ComboBox RadioButton ClockPanel SingleSpinner DualSpinner Label EditableComboBox

disclosureDoc strategy anyURI N URL of a disclosure document supplied by the algorithm provider.

embededFixTag strategy posInt N FIX tag where all parameter names and values are to be stored when sending an algorithmic order. Applicable only to the Embedded extension model.Required when algoExtModel is Embedded.

errorMessage strategyEdit string Y The error message to be displayed if validation fails for this field.

field edit string Y Field name for comparison. Must exist in the strategy XML.

fixTag constTag posInt Y The tag that will hold the value of a non-viewable or constant parameter.

fixTag parameter posInt N The tag that will hold the value of the parameter. Required when algoExtModel is Custom.

FIXADTL 19

fixTag strategy posInt Y The tag used to identify the algorithm. FIX 4.4 provides tag 847 (TargetStrategy) for this purpose.

version strategy string N Information to facilitate version control.increment parameter decimal N Limits the granularity of numeric

parameters. Useful in spinner objects to enforce odd-lot and sub-penny restrictions. Applicable for the types Amt, Float, Percentage, Price, PriceOffset, Qty.

index enumPair integer N Provides an ordering for the enumPairs.initValue parameter N The value used to pre-populate the GUI

component when the order entry screen is initially rendered.

localMktTz parameter string N For use when parameter is derived from UTCTimeStamp or LocalMktTime.

locations strategy MVS_t N List of locations as defined by the provider. Used to declare the regions or trading desks where the algorithm is supported.

logicOperator edit string Y One of the following enumerated types: AND OR End EQ NE LE LT GE GT

markets strategy MVS_t N List of values from FIX tag 100 (ExDestination). Used to declare the markets where the algorithm is applicable.

maxValue parameter N The maximum value of the data of the parameter. Applicable for the types Int, Amt, LocalMktTime,Month-Year, Percentage, Price, PriceOffset, Qty, UTCDate, UTCTimeOnly, UTCTimeStamp

minValue parameter N The minimum value of the data of the parameter. Applicable for the types Int, Amt, LocalMktTime,Month-Year, Percentage, Price, PriceOffset, Qty, UTCDate, UTCTimeOnly, UTCTimeStamp

mutableOnCxlRpl parameter boolean N Indication of whether the parameter’s value can be modified by a Cancel-Replace message.

name field string Y Reference to a parameter.name parameter string Y The name of the parameter. No two

parameters may have the same name. The name may be used as a unique key when referenced from the other sub-schemas. This is also the value rendered on the UI when the user is presented with a choice of algorithms.

FIXADTL 20

name strategy string Y Unique identifier of a strategy.operator edit string N One of the following enumerated types:

EX (Exists) NX (Not exists) EQ (Equal) LT (Less than) GT (Greater than) NE (Not equal) LE (Less than equal) GE (Greater than equal).

orientation strategyPanel string N Must be “HORIZONTAL” or “VERTICAL”.overrideUserInput constTag boolean Y If true, the tag is set to this value

regardless of what is entered by the user. Cannot be true if appendToUserInput is also true

precision parameter int N The number of digits to the right of the decimal point in which to round.Applicable for numeric types.

providerID strategy string N Identifies the firm providing the algorithm.providerSubID strategy string N A further level of firm identification.supportsCxlRpl strategy boolean N Indicates whether or not the strategy

accepts Cancel-Replace messages.title strategyPanel string N Optional panel title.tooltip parameter string N Tool tip text for rendered GUI objects

rendered for the parameter.type edit string Y Data type of the field’s value (must be a

value in the paramaterType enumeration).type parameter SPT Y Values are taken from the Algorithmic

Trading Extensions Proposal tag 959.uiRep enumPair string Y The value that is shown in a drop-down

menu or combo-box within the UI.uiRep parameter string N The name of the parameter that is

displayed to the user. Values from the UI sub-schema should take precedence.

uiRep strategy string N The name of the strategy as rendered in the UI. If not provided then the “name” attribute should be used.

use parameter use_t N Valid values are “required” or “optional”.value edit string N Value for comparison when using an

operator.wireValue constTag string Y The value with which to set the tag.wireValue enumPair string Y The corresponding value that is used to

populate the FIX message.wireValue strategy String N The value used to identify the algorithm.

The tag referred to by fixTag will be set to this value.

FIXADTL 21