FIXATDL

Algorithmic Trading Definition Language

Introduction and Tutorial

January 9, 2008
Table of Contents
TABLE OF CONTENTS..................................................................................................................2
DOCUMENT HISTORY..................................................................................................................3
1 INTRODUCTION.........................................................................................................................3
1.1 PURPOSE................................................................................................................................3
1.2 AUDIENCE...............................................................................................................................3
1.3 BACKGROUND........................................................................................................................3
1.4 METHODOLOGY......................................................................................................................4
1.5 CAPABILITIES..........................................................................................................................4
2 SCHEMA DESIGN.......................................................................................................................5
Core Schema ..........................................................................................................................................5
UI Sub-schema........................................................................................................................................5
Validation Sub-schema...........................................................................................................................5
3 DEFINITION OVERVIEW............................................................................................................6
3.1 PARAMETERS.............................................................................................................................................6
3.2 LAYOUT....................................................................................................................................................8
3.3 VALIDATION RULES..................................................................................................................................10
4 SAMPLE DEFINITION FILE.......................................................................................................12
5 IMPLEMENTATION AND CODING GUIDE...............................................................................15
5.1 TIMESTAMP PARAMETERS.........................................................................................................................15
5.2 TIME CONVERSION CONSIDERATIONS............................................................................................................15
5.3 RELATIVE PRICES.....................................................................................................................................16
5.4 RELATIVE TIMES......................................................................................................................................18
5.5 MULTIPLE SELECTIONS FROM A LIST...........................................................................................................18
5.7 DEFAULT VALUES VS. INITIAL VALUES.......................................................................................................19
6. APPENDICES...........................................................................................................................19

FIXADTL 2
Document History

Revison Date Author Comments

1.0 August 15, 2007 Greg Malatestinic Original draft
1.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 3
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.

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

• 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.

FIXADTL 5
 Flow Sub-schema
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:

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

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 attributes

Amt Amt_t 10 initValue, maxValue, minValue
Boolean Boolean_t 13 initValue
Char Char_t 12 initValue
Currency Currency_t 16 initValue
Data Data_t 23 initValue, minLength, maxLength
Exchange Exchange_t 17 initValue
Float Float_t 6 initValue, minValue, maxValue
Int Int_t 1 initValue, minValue, maxValue
Length Length_t 2 initValue
LocalMktTime LocalMktTime_t 21 initValue, minValue, maxValue, localMktTz
Month-Year MonthYear_t 18 initValue, minValue, maxValue
MultipleCharValue MultipleCharValue_t 15 minLength, maxLength
MultipleStringValue MultipleStringValue_t 24 minLength, maxLength
NumInGroup NumInGroup_t 3 initValue
Percentage Percentage_t 11 initValue, maxValue, minValue
Price Price_t 8 initValue, minValue, maxValue
PriceOffset PriceOffset_t 9 initValue, minValue, maxValue
Qty Qty_t 7 initValue, minValue, maxValue
SeqNum SeqNum_t 4 initValue
String String_t 14 initValue, minLength, maxLength
TagNum TagNum_t 5 initValue

FIXADTL 7
UTCDate UTCDate_t 22 initValue, minValue, maxValue
UTCTimeOnly UTCTimeOnly_t 20 initValue, minValue, maxValue
UTCTimeStamp UTCTimeStamp_t 11 initValue, minValue, maxValue, localMktTz

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

FIXADTL 8
 • 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
• 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:

FIXADTL 9
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.

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>

FIXADTL 10
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.

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”>

FIXADTL 11
 <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”>
<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.

FIXADTL 12
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).

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 Rule

Start Time 6100 Yes Must precede End Time.
End Time 6101 No Must precede Start
Time.
Benchmark Type 6102 Yes “Last Price”, “Mid Corresponding values for
Point”, “Open”, transmit are: L, M, O or
“Specific Price” 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”>

FIXADTL 13
 <enumPair uiRep="Last Price" wireValue="L"/>
<enumPair uiRep="Mid Point" wireValue="M"/>
<enumPair uiRep="Open" wireValue="O"/>
<enumPair uiRep="Specific Price" wireValue="S"/> </parameter>

<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"

FIXADTL 14
 operator="EQ"
value="Specific Price"
type="String"
logicOperator=""/>
</strategyEdit>

<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

FIXADTL 15
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.

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.

FIXADTL 16
 <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”/>
<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.

FIXADTL 17
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.

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”/>

FIXADTL 18
 </parameter>

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

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 Description

constTag strategy 0 – unbounded Definition for non-viewable parameters.
description strategy 0-1 Basic description of a strategy.
edit strategyEdit or 1 - unbounded Boolean expression to be evaluated.
stateRule
enumPair parameter 0 – unbounded Defines a legal value of a parameter a
corresponding wire value.
field stateGroup 0 - unbounded Reference to a parameter
helpText parameter 0–1
item stateGroup 1 - unbounded Reference to an enumPair item.
parameter strategy 0 - unbounded
stateGroup strategy 0–1 Container for flow rules
stateRule 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 strategyPanels
strategyPanel strategyLayout 0 - unbounded

FIXADTL 19
Appendix B – Attribute Data Dictionary

Attribute Element Type Req’ Description

d
algoExtModel strategy MVS Y List of the extension models supported as
described by Algorithmic Trading
Proposed Extensions v1.0
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 N
collapsible strategyPanel boolean N Indicates whether panel can be collapsed.
color strategyPanel string N
controlType 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

FIXADTL 20
 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.
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-

FIXADTL 21
 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.
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

FIXADTL 22
 this value.

FIXADTL 23