AUTEX FIX 4.2 IOI AND ADVERTISED
TRADE GUIDE
REUTERS/Jorge Silva
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Contents
CHAPTER 1 INTRODUCTION.............................................3
CHAPTER 9 ADDRESSING.............................................. 16
Features and Benefits...........................................................................3
Addressing IOI Messages................................................................... 16
Service Support.....................................................................................3
Addressing Values.............................................................................. 16
CHAPTER 2 AUTEX CLIENT PORTAL................................ 4
CHAPTER 3 APPLICATION AND
NETWORKING REQUIREMENTS...................................... 6
Application Requirements....................................................................6
Networking Requirements...................................................................6
CHAPTER 4 END OF DAY PROCESSING
AND CONNECTING............................................................7
Addressing Methods: Broker Targeting One or More Recipients..... 18
Addressing Examples: Broker targeting one or more recipients
using the RoutingID tags.................................................................... 18
Addressing Examples: Broker targeting one or more recipients
using tag 128...................................................................................... 20
Addressing Methods: Recipient Identifying IOI or
Advertised Trade Originator.............................................................. 20
Service Bureau Connections............................................................... 21
On Behalf of Networks........................................................................ 21
Connecting to the Network..................................................................7
Consolidated Feed..............................................................................23
CHAPTER 5 SUBSCRIBER ID’S AND FIX COMPID’S......... 8
CHAPTER 10 FIX MESSAGE HEADER AND TRAILER..... 24
Subscriber IDs...................................................................................... 8
FIX Message Standard Header Fields.............................................. 24
FIX CompIDs........................................................................................ 8
FIX Message Standard Trailer Fields................................................ 26
FIX CompID Naming Conventions...................................................... 8
Group and Endpoint Acronyms........................................................... 8
CHAPTER 11 ADMINISTRATIVE FIX MESSAGES..............27
Possible Duplicate Messages.............................................................27
CHAPTER 6 MESSAGE REJECTS...................................... 9
Possible Resend Messages............................................................... 28
Reject Messages...................................................................................9
Logon Message.................................................................................. 28
Reject Message Types by Failure Reason............................................9
FIX 4.2 Business Reject Message....................................................... 10
CHAPTER 7 GLOBAL SYMBOLOGY..................................11
Understanding the Supported Security Identifier Methods.............. 11
Security Identification Tag Validation Process.................................... 11
CHAPTER 12 INDICATION OF INTEREST
(IOI) MESSAGES............................................................. 29
IOI Message Categories..................................................................... 29
IOI FIX Message................................................................................. 30
Actionable IOIs................................................................................... 35
Pegged IOIs........................................................................................ 35
CHAPTER 8 AUTEX BUSINESS RULES
FOR FIX MESSAGES........................................................ 13
IOI Expiration...................................................................................... 35
Supported Application Message Types............................................. 13
IOI Message Filters............................................................................. 36
FIX Protocol Documents..................................................................... 13
Security Symbol and Identifier Preferences..................................... 36
Addressing Messages......................................................................... 13
IOI Message Elections........................................................................ 36
ID Processing....................................................................................... 13
CHAPTER 13 ADVERTISED TRADE MESSAGES.............. 38
FIX Message Grid Guidelines............................................................. 13
Advertised Trade FIX Message.......................................................... 38
Tag Number Column: Repeating Groups Arrow Indicator............... 13
As of Trades......................................................................................... 41
Required Column................................................................................ 13
Advertised Trade Guidelines............................................................... 41
Data Format/Length Column............................................................ 14
Advertised Trade Message Elections................................................. 41
Description Column............................................................................ 15
Advertised Trade Message Filters..................................................... 42
Validations Column............................................................................. 15
Security Symbol and Identifier Preferences..................................... 42
Page 2
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 1 Introduction
WELCOME TO AUTEX
Autex is a network platform solution which enables high-speed messaging for both Indications of
Interest (IOI) and Advertised Trade message types that is compliant with the FIX 4.2 protocol. Autex
is partnered with the Autex Trade Route order routing network and includes a portfolio of products
allowing for complete global messaging capabilities.
FEATURES AND BENEFITS
Autex utilizes a unified global system which contains a host of features essential to your messaging needs, as follows:
Indication of Interest and Advertised Trade Supported
Autex utilizes the FIX 4.2 protocol for sending and receiving these message types. Receive FIX IOI and Advertised Trade messages directly
into your OMS blotter or view them using a provided Autex application or directly within the Thomson Reuters Eikon platform. Send FIX IOI
and Advertised Trade messages directly from your TOMS or send them using an Autex provided application to recipients via FIX. Advertised
Trade messages are then compiled into detailed trade rankings within Autex.
Actionable IOIs
Actionable IOIs are supported for venues configured accordingly to send/receive values specified in the applicable tag indicating that the
IOI is actionable.
Pegged IOIs
Send/receive IOIs pegged to the Market or Midpoint with an optional offset specified to receiving venues who have configured to handle
them accordingly.
Global Symbology
All of the following symbol types and values are supported:
CUSIP
ISIN
RIC Code
SEDOL
Symbol
Exchange Code
Message Elections
Select your own configuration for sending and/or receiving IOI and Advertised Trade messages.
Message Filters
Select only the messages that you want to see based on configurable parameters for both IOI and Advertised Trade messages.
Flexible Message Addressing
Broad support for the most popular and commonly used addressing schemes for targeting your IOIs, along with the ability to create a
Concentrator Network or Service Bureau connection with Autex. There is also the available flexibility to send out messages “on behalf of”
other members of your organization.
SERVICE SUPPORT
Should you have any questions please contact the global Autex support team. You can send an inquiry via email or you can call the regional
support phone numbers listed here.
SUPPORT PHONE NUMBERS
International
+1-801-212-9451
Tokyo
+81 3 6441 1063
Europe / UK
+44 (0) 870 1910 561
Americas
800 232 8839
GLOBAL EMAIL ADDRESS
[email protected]
Page 3
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 2 Autex Client Portal
The Thomson Reuters Autex Client Portal is available to all Autex clients. The Autex Client Portal allows you to search for clients subscribed
to the Autex network and download client directory files to support your Autex IOI and Advertised Trade messaging needs.
You can access the Autex Client Portal at the following address:
https://portal.autex.com
Access to the Autex Client Portal can be requested directly from the website by selecting “Create Account” on the login screen or by
contacting Autex support.
CLIENT DIRECTORY AND DOWNLOADS FUNCTIONAL OVERVIEW
There are two primary tools available within the Autex Client Portal that can be used by Autex subscribers needing information for IOI and
Advertised Trade messaging. Once logged into the portal they can be accessed by selecting “Navigate To” that will display a list of tools to
choose from.
Note: Other tools that can be accessed by selecting “Navigate To” such as Dashboard, Monitoring, Contacts & Escalation are tools used for
order routing clients and are not applicable to Autex IOI and Advertised Trade client sessions.
AUTEX TOOL
USE TO...
Client Directory
Search for clients in the Autex community. Narrow search results by using subcategories and indicated criteria.
Select the appropriate tab to search for:
1. C
lients based on identifier, e.g. Subscriber (client name), Acronym (FIX CompID), SubID, etc.
2. Clients based on user type and geographic Location
3. Recent Updates to the client directory based on specified timeframes.
Downloads
Page 4
The Downloads tab enables you to obtain instructions for downloading client directory files via FTP.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Navigate To: Client Directory
Navigate To: Downloads
Page 5
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 3 Application and Networking Requirements
APPLICATION REQUIREMENTS
Any proprietary or third-party application and FIX engine such as Order Management Systems (OMS) or Trade Order Management Systems
(TOMS) that is used to interface with the Autex platform must be compliant with the FIX 4.2 protocol and Autex business rules. Before
connecting to the Autex platform certification testing is performed to ensure compatibility for a seamless transition to production. Autex has
tested and certified several of the commercial Order Management Systems (OMS) and Trade Order Management Systems (TOMS) therefore
this may have already been completed depending on what system you are using.
NETWORKING REQUIREMENTS
In order to connect a FIX session to the Autex platform a physical network connection must first be established. Physical network connectivity
can be established by utilizing dedicated circuit(s) and router(s) or via the internet utilizing a virtual private network (VPN). In some instances
your OMS/TOMS or other third party vendor that may host your infrastructure that you would be connecting through may already have existing
network connectivity established to Autex. If so, then you would not need to establish network connectivity independently.
Note: Autex will work with you to assess and implement the appropriate network connectivity solution that best suits your needs.
Circuit Connectivity
Circuits and routers can be installed and managed by Thomson Reuters or certain third party vendors may also be utilized to provide network
connectivity to the Autex platform. Depending on your needs multiple circuits and routers can be installed with dynamic failover configured
between them for redundancy. You can elect to have dual circuits installed at the same location as typically done where dynamic failover can
automatically be configured between them. Alternatively, you can a circuit delivered to a primary location and a circuit delivered to a secondary
location. In this scenario you would responsible for the back-end connectivity between the sites and failover between the two sites is based
on the use of a mutually agreed upon routing protocol.
VPN Connectivity
A site-to-site or LAN-to-LAN IPSec VPN tunnel can be used as the primary method for connecting to the Autex network or as a backup
solution. VPN tunnels allow for quick setup and secure connectivity to the Autex network via your existing internet connectivity. In order to
configure a VPN tunnel you must have a device such as a firewall or router that supports certain LAN-to-LAN IKE/IPSec parameters.
Page 6
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 4 End of Day Processing and Connecting
For each client with an active session within a 24-hour period there is a resynchronization that takes place between your FIX engine and
the Autex FIX engine known as “End-of-Day (EOD) processing.” EOD processing involves resetting your outgoing sequence number and
expected inbound sequence number for each FIX connection. EOD processing occurs at a pre-defined time each day. If your FIX connection
is still established at this time, Autex automatically disconnects your FIX connection for approximately one minute in order to perform this
processing. Failure to perform EOD processing may result in sequence numbers being out of sync causing your FIX connection
to disconnect.
You must establish your EOD time with Autex prior to establishing your first FIX connection. You have the option to specify and use an EOD
time that best suits your needs and trading practices.
The following table lists EOD times recommended by Autex:
END OF DAY TIMES
Available Times
Equivalents
Comments
03:00 UTC
10:00 PM EST
11:00 AM HK
Ideal for the Americas and EMEA trading sessions.
15:00 UTC
10:00 AM EST
11:00 PM HK
Ideal for Asian trading sessions.
22:15 UTC
05:15 PM EST
06:15 AM HK
Ideal for support of global trading over one FIX session.
Custom UTC Time Value
Varies
Use if none of the above options suits your trading practices.
Note: Autex follows UTC (Universal Coordinated Time) also known as GMT (Greenwich Mean Time) 365 days a year and does not adjust
for US Daylight Savings or European Summertime changes. All EOD times are set in UTC; as such, you may need to manage your
reconnections when there are regional time adjustments in your time zone, and your servers run on local time.
CONNECTING TO THE NETWORK
It is strongly recommended that you initiate your FIX connection to Autex. This provides you with the greatest convenience and flexibility for
managing your FIX connections. You are required to disconnect your FIX connection at your specified EOD time. Once EOD processing is
complete and your sequence numbers have been reset, you can initiate a new FIX connection at will.
While not advised or recommended, you also have the option of requesting that Autex initiate the FIX connection. When this option is
selected, there is an auto-connect feature that automatically attempts to initiate a FIX connection at a designated UTC time of your choice.
The auto-reconnect feature launches under the following conditions:
• Viable network connectivity
• Seven days a week
• Starts at the designated UTC time
• Ends at the designated UTC time for EOD processing
Page 7
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 5 Subscriber ID’s and Fix CompID’s
SUBSCRIBER IDS
Every Autex subscriber or session is assigned a unique number that identifies them on the Autex network whether it is a FIX session or an
Autex GUI application session. This identifier is known as the Autex Subscriber ID or SubID value. The Subscriber ID values are used to
determine the recipient’s of a particular IOI message.
Examples:
820 = Institution ABC
821 = Institution XYZ
973 = Institution 123
Related topic: Addressing
FIX COMPIDS
Before a FIX connection can be established with Autex, both a SenderCompID (tag 49) and a TargetCompID (tag 56) must be agreed
upon. The SenderCompID is the value that identifies your FIX session to the Autex Trade Route network. In Autex the SenderCompID or FIX
CompID may also be known as the ATR Acronym or Group Acronym. The SenderCompID or FIX CompID, is an acronym that usually consists
of a form of the name of your firm, an entity within your firm, or a combination of the two. This value must be unique across the entire Autex
Trade Route network.
When Autex delivers an IOI or Advertised Trade message to your intended recipient your FIX CompID is included in the appropriate FIX tags
that identify you as the message originator.
FIX COMPID NAMING CONVENTIONS
The following table describes the rules and guidelines for creating an Autex FIX CompID value.
RULE
GUIDELINES
CORRECT EXAMPLES
INCORRECT EXAMPLES
Accepted Values
•
•
•
•
•
•
Maximum 10 characters
Minimum 1 character
First character must be alphabetic
All alphabetic characters must be uppercase
Hyphens allowed
Underscores allowed
CCO
RC123
USAMMF
CLNT-B1
BROK_PRD
J123456789BK
1A56Y
mnOPP
Non-Accepted Values
•
•
•
•
Spaces
Periods / Full Stops
Commas
Asterisks
AA550
INST29
BRK23
AA 550
FF.29
B,23
C**23
Illegal Usage
Do not begin value using
any of the following
• L – followed by a number
• S – followed by a number
• A – followed by a number
LL33F
STAR
APPMTLS
L145
S688
A2MM
GROUP AND ENDPOINT ACRONYMS
In prior legacy versions of the Autex system multiple Autex subscribers (SubID’s) that may represent a logical grouping of individuals,
locations, divisions, or desks within a firm could be associated together in a single group with an assigned group acronym. When sending
or receiving messages via FIX the group acronym acts as the FIX CompID, but other Autex GUI subscribers may also be associated with this
particular group acronym. A group acronym can be comprised of one subscriber with an assigned subscriber ID number or multiple Autex
GUI subscribers each assigned a subscriber ID and end point acronym. An endpoint acronym is a name given to an individual subscriber
within a group using the Autex GUI. It can be used to describe a specific individual, location, division, or desk within a particular group.
The endpoint acronym must be unique within its group.
Page 8
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 6 Message Rejects
REJECT MESSAGES
Reject messages are automatically generated by Autex to notify the sender when a message has not been successfully processed. A message
can be rejected when one or more tag values violate the FIX protocol or if it cannot be processed by Autex for any reason.
The reject message provides sufficient information about the original message so that it can be identified, along with the “reason for failure”
when possible. Autex sends a Business Reject message when rejecting an IOI or Advertised Trade message. If a Business Reject cannot be
generated, a session-level reject maybe used instead.
REJECT MESSAGE TYPES BY FAILURE REASON
The following table outlines common reasons for rejecting either an IOI or Advertised Trade message.
FAILURE REASON
DESCRIPTION
Addressing Error
Invalid Address or no address specified.
e.g. Target SubID(s) specified do not exist in Autex, Specified list is not
configured in Autex.
u
N/A
Unknown Security
Invalid Security Specified or No Match Found.
u
u
FIX Validation or Autex
Validation Error
If one or more tag values violate the FIX protocol or Autex FIX message
rules.e.g. tag sent with invalid format or value, required tag not sent.
u
u
Duplicate ID Error
IOIID or AdvID value was resent prior to expiration (within 7 calendar
days).
u
u
Original Message Not Found
in Database
A “no rows found” reject indicates the reference ID for the original
message could not be found in the database when sending either a
Cancel or Replace message such as if the message may have previously
been canceled or expired by Autex.
u
u
Invalid As of TradeDate
When the TradeDate (75) value is a future date or more than 7 calendar
days in the past.
N/A
u
Invalid IOI Replacement
When a “replace” message has been sent for a General IOI or if the
original is considered to be expired by Autex.
u
N/A
Invalid IOI Replacement Type
When a “replace” message is of a lower category level than the original
IOI message; for example, a Detailed IOI cannot be replaced with a
General IOI.
u
N/A
When an “on behalf of” message is received where the specified value
is not a member of the party’s OBOF Network or specified value is not
associated with a particular service bureau sending the message.
u
u
Invalid On Behalf Of
IOI
ADVERTISED
TRADE
Page 9
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
FIX 4.2 BUSINESS REJECT MESSAGE
The Business Reject message is used by Autex to reject a FIX 4.2 IOI or Advertised Trade message.
Note: The Business Reject message is not supported for client-to-client communication. Inbound message received by Autex are dropped.
Tag #
Field Name
Data Format /
Length
<Standard Header>
Req’d
Description
Y
MsgType (35) = j (lowercase).
For details see:
Standard Header
Validations
45
RefSeqNum
Int
N
MsgSeqNum (34) of rejected
message.
When possible Autex will populate
with the MsgSeqNum of the message
being rejected.
372
RefMsgType
CH
1
Y
The message type of the FIX
referenced message.
Values:
6 = IOI
7 = Advertised Trade
When possible Autex will populate
with the type of message being
rejected.
379
BusinessRejectRefID
ST
70
N
The value of the business-level ID
field on the referenced message.
When possible Autex will populate
with the IOIIID or AdvID of the
message being rejected.
380
BusinessReject
Int
2
Y
Code used to identify the reason for
reject. Common values used
by Autex:
0 = Other
1 = Unknown ID
2 = Unknown security
3 = Unsupported
message type
4 = Application not available
5 = Conditionally required field missing
58
Text
ST
N
Free format string.
Use to explain reason for reject.
354
EncodedTextLen
N
Not Sent
355
EncodedText
N
Not Sent
Y
For details see: Standard Trailer
<StandardTrailer>
Page 10
When possible Autex will populate with
the failure reason in most instances.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 7 Global Symbology
Symbol validation for specific securities around the globe is required by Autex for both IOI and Advertised Trade FIX messages. Using the
provided tags in the FIX 4.2 message, you can specify a security on any worldwide exchange. A security can be identified using a RIC Code,
SEDOL, CUSIP, ISIN, valid symbol.
Important: If a valid security is not specified in an incoming IOI or Advertised Trade message Autex will reject the message.
UNDERSTANDING THE SUPPORTED SECURITY IDENTIFIER METHODS
When sending FIX 4.2 IOI and Advertised Trade messages you have the option of using one of five different methods to specify the security.
If you do not populate tags 22/48 using one of the valid identifiers then you must specify a valid symbol in tag 55. The following chart
describes each of the five supported security identification methods.
Note: It is recommended that a SecurityID always be populated in tag 48 when possible.
TAG 22 IDSOURCE VALUE
IDENTIFIER METHOD
DESCRIPTION
N/A
Symbol
(Tag 55 - Symbol)
Identifies security within a specific exchange listing based upon symbology provided
by Datascope.
5
RIC Code
(Tag 48 - SecurityID)
Identifies security within a specific exchange listing based upon symbology used
within the Reuters platform.
2
SEDOL
(Tag 48 - SecurityID)
7-digit code that identifies a security on all exchanges within a country.
1
CUSIP
(Tag 48 - SecurityID)
9-digit code that identifies a security on North American exchanges only.
4
ISIN
(Tag 48 - SecurityID)
12-digit code that uniquely identifies a security on all exchanges worldwide.
SECURITY IDENTIFICATION TAG VALIDATION PROCESS
There are four tags in the FIX 4.2 IOI and Advertised Trade message that are used to identify a symbol and the exchange to which it is to be
applied. The tags are validated in sequential order as follows:
•
•
•
•
IDSource – tag 22
SecurityID – tag 48
Symbol – tag 55
SecurityExchange – tag 207
Primary Listing:
The Primary Listing is the home listing or exchange for the security. In many cases a security maybe listed on multiple exchanges. During
the validation process if Autex cannot determine the exchange to which the symbol should be applied, it will automatically be applied to its
Primary Listing.
Page 11
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
The following table describes the validation process for IOI and Advertised Trade messages. The tag numbers listed are validated in sequence.
Table Key:
Validation Codes
V = Valid
I = Ignore
D = Duplicate
NM = No Match
Reconciliation Codes
Accept and Apply = Validation complete; apply to the validated symbol.
Apply to Primary Listing = Validation incomplete; apply to the primary listing for the symbol
Reject = Validation incomplete; reject message back to originator.
AUTEX VALIDATION PROCESS FOR IOI AND ADVERTISED TRADE MESSAGES
CASE
22
48
55
207 207
1
V
V
I
I
EXPLANATION
When there is a valid match for the combination of tags 22 and 48, and tag 48 is not a duplicate, accept and apply to
listing. Tags 55 and 207 are ignored.
2
NM
EXPLANATION
When the combination of tags 22 and 48 do not yield a match, tag 55 is checked for a valid symbol. If there is a valid
symbol match, accept and apply to listing. Tag 207 is ignored.
3
NM
EXPLANATION
When the combination of tags 22 and 48 do not yield a match, and a there is no match for a valid symbol in tag 55
reject message. Tag 207 is ignored.
4
V
EXPLANATION
When the combination of tags 22 and 48 yield a match, but represent a duplicate, check tag 207 for unique identifier.
If unique, accept and apply to listing. Tag 55 is ignored.
5
V
EXPLANATION
When the combination of tags 22 and 48 yield a match, but represent a duplicate, check tag 207 for unique identifier.
If tag 207 is null or not unique, check tag 55 for a unique symbol. If there is no match for tag 55, accept and apply to
the primary listing.
6
V
EXPLANATION
When the combination of tags 22 and 48 yield a match, but represent a duplicate, check tag 207 for unique identifier.
If tag 207 is null or not unique, check tag 55 for a unique symbol. When there is a valid match for tag 55, accept and
apply to listing.
7
NM
EXPLANATION
When there is an invalid code in tag 22, ignore tags 48 and 207. Check tag 55 for a valid symbol. When there is a
valid symbol in tag 55, accept and apply to listing.
Page 12
NM
NM
D
D
D
I
V
NM
I
NM
V
V
I
ACCEPT AND
APPLY
APPLY TO
PRIMARY
LISTING
u
u
I
V
u
u
NM
NM
I
REJECT
u
u
u
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 8 Autex Business Rules for FIX Messages
SUPPORTED APPLICATION MESSAGE TYPES
In order to be able to send and receive messages, you must follow the Autex business rules for the FIX protocol. Those business rules are
outlined for you in the next several topics.
The following are supported:
SUPPORTED MESSAGE TYPES
Message Header and Trailer
Standard Message Header
Standard Message Trailer
Administrative Messages
Indication of Interest
IOI (35=6)
Advertised Trade
Advertised Trade (35=7)
FIX PROTOCOL DOCUMENTS
The FIX 4.2 specification documents published by The FIX Protocol Organization can be used in conjunction with this guide. These
documents can be found at the FIX Protocol Organization website which contains a wealth of information about FIX usage including the
appropriate way to address messages, the supported tags, the sequence of tags, valid and invalid field values and much more.
ADDRESSING MESSAGES
Autex supports multiple flexible addressing schemes for sending FIX 4.2 IOI messages. Addressing is required by Autex in order for IOI
messages to be delivered to the intended recipient. Advertised Trade messages do not have to be addressed since by default they broadcast
to the entire Autex community.
Related topic: Addressing
ID PROCESSING
When sending an IOI message the IOIID value sent in tag 23 must be unique for at least 7 calendar days. The same is true for the AdvID in
tag 2 when sending an Advertise Trade message.
FIX MESSAGE GRID GUIDELINES
Autex’s business rules for composing, validating, and rejecting FIX messages are defined in this section. Refer to these rules when viewing
the supported FIX message types shown in the grid format with the following columns for each field:
TAG NUMBER COLUMN: REPEATING GROUPS ARROW INDICATOR
A Tag Number preceded by an arrow indicates a repeating group. Follow rules for repeated fields and group rules for field order. If the
repeating group is not used properly (for example repeating group entries do not match the preceding No(field)), the message may be rejected.
REQUIRED COLUMN
Required is the column that identifies whether the tag is required, not required, or not supported.
IDENTIFIER
DESCRIPTION
Y
Tag is required as part of the message type.
N
Tag is not required as part of the message type.
Page 13
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
DATA FORMAT/LENGTH COLUMN
The Data Format/Length provides the accepted format for the value in the field. For each value, there can be an associated field length,
which is often static based on the data type but changes with others such as Character and String. Messages are automatically rejected
if not sent in the accepted format. Also a message will be rejected if the field length exceeds the indicated length in the table unless
otherwise noted.
DATA TYPE
CODE GUIDELINES
Boolean
B
•For tags that require a Yes or No value.
Y = Yes or True
N = No or False
Character
CH
• Multiple character values to include alphanumeric, punctuation and spaces.
• Field lengths are indicated in the FIX tables.
Datestamp
DS
• D
ate value in the following format:
YYYYMMDD
• Accepted values:
YYYY = 0000-9999
MM = 01-12
DD = 01-31
Float Datatypes: Flt
Float
Prc
Price
Qty
Quantity
• Float datatype values can be sent with at least 15 significant digits with a maximum of 17 significant digits
depending on the size of the value.
• A maximum of 12 digits to the left of the decimal can be sent. If the value has more than 12 digits to the left of
the decimal, the message is rejected.
• Float fields sent with values greater than 15 significant digits may be truncated and rounded to either 15,
16, or 17 digits. The value of truncation is dependent on the placement of the decimal. In some cases when
there are 12 digits to the left of the decimal there may be only 4 digits to the right of the decimal totaling 16
significant digits.
• All float values must be positive. Negative values are only allowed if explicitly specified that a certain field
is negative.
• Autex may add a decimal when passing a float datatype value; for example, if a value of 100 is received, the
value is passed as 100.0
• Trailing zeros are removed, so a value of 9.1000 is passed as 9.1.
• Leading zeros are removed, so a value of 0012345 is passed as 12345.
Integer
Int
• Sequence of digits without a decimal that can be either positive or negative.
• In the FIX tables, there are times when the valid values and/or the field length are indicated for a tag, e.g.
Valid values = 0-9999.
MonthYear
MY
• Month of a year with an optional day of the month or week code.
• Accepted formats and values:
YYYYMM
YYYYMMDD
YYYYMMWW
YYYY = 0000-9999
MM = 01-12
DD = 01-31
WW = W1, W2, W3, W4, W5
String
ST
• Multiple character values to include alphanumeric, punctuation and spaces.
• Field lengths are indicated in the FIX tables.
Timestamp
TS
Also known as
UTC Timestamp
Page 14
• Time and date combination in Universal Time Coordinated (UTC) also known as Greenwich Mean Time (GMT).
• Accepted formats and values:
YYYYMMDD-HH:MM:SS
YYYYMMDD-HH:MM:SS.sss
YYYY = 0000-9999
MM = 01-12
DD = 01-33
HH = 00-23
MM = 00-59
SS = 00-60
sss = 000-999
Note: Milliseconds are optional. Value may be passed with or without milliseconds.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
DESCRIPTION COLUMN
The Description column provides a general description and the accepted values of the FIX field. Any special business rules are also noted in
this column such as the following:
BUSINESS RULE
EXPLANATION
Dropped
Non-supported tags or tag values are dropped from the message and are not delivered to the message
recipient.
VALIDATIONS COLUMN
The Validations column generally provides the reason(s) that a message may be rejected from the system due to a tag-level error. In some
cases, special validation rules for the tag are provided.
Page 15
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 9 Addressing
ADDRESSING IOI MESSAGES
Autex allows you to send IOI messages to one or multiple recipients over a single FIX session into Autex as illustrated in the diagram.
Therefore, you must address each IOI to specify the intended target(s) where a single IOI can be targeted to one or many recipients.
Certain tags must be used to address each IOI message.
FIX Message Stream
BROKER
A
AUTEX
B
Explanation:
A – Message sent from Broker to Autex (intended for Recipients)
B – Message sent from Autex to Recipients on behalf of Broker
ADDRESSING VALUES
Addressing involves specifying the recipient(s) that you are targeting or blocking by including one or more of the following in an appropriate
addressing tag:
Specific Subscriber ID values(s):
Examples:
820
821
822
To find specific SubID values for each Autex subscriber or client you wish to include you can search for them in the client directory found in
the Autex Client Portal or within the Autex application.
System Lists:
There are three System Lists (L1, L2, L3) that enable you to address your messages to an entire class of Autex subscribers by client type:
Institutions, Brokers or All Brokers and Institutions available on the Autex network. These lists are automatically configured and maintained
by Autex.
L1 = All Institutions (All Institutions on the Autex network will receive the IOI message so you do not need to specify each individual recipient.
This is the most common way to reach the entire buy-side community.)
L2 = All Brokers (All Brokers on the Autex network will receive the IOI message so you do not need to specify each individual Broker
recipient. Note: Only use this option if you wish for all other brokers to be able to view your IOI message).
L3 = All Brokers and Institutions (All Brokers and all Institutions on the Autex network will receive the IOI message so you do not need to
specify each individual recipient. Note: Only use this option if you wish for all other brokers to be able to view your IOI message).
To find specific list of Autex subscriber types or client you can search for them in the Autex client directory found in the Autex Client Portal
or within the Autex application.
Page 16
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Subscriber Own Lists (SOLs):
These are lists that you can have created which contain a selected group of Autex subscribers of your choosing that you have configured for
your business needs. These lists allow you to target or block a specific set of subscribers when addressing your IOI message. Autex allows up
to 8 lists to be created and must be referenced as L100, L101, L102, L103, L104, L105, L106, L107 respectively when used to address an
IOI message.
Note: These lists are created by and stored by Autex based upon the subscribers you wish to include. Please contact Autex support to
create a new list or have an existing list edited or removed.
Examples:
L100 = subscribers 123, 456, 789, 432, 765, 543 etc.
L101 = subscribers 820, 821, 822, etc.
To find specific SubID values for each Autex subscriber or client you wish to include you can search for them in the client directory found in
the Autex Client Portal or within an Autex application.
Using “A” or “N” when addressing:
In prior legacy versions of the Autex system multiple Autex subscribers (SubID’s) that may represent a logical grouping of individuals,
locations, divisions, or desks within a firm could be associated together in a single group with an assigned group acronym. When sending
or receiving IOI’s via FIX the group acronym acts as the FIX CompID, but other Autex GUI subscribers may also be associated with this
particular group acronym. A group acronym can be comprised of one subscriber with an assigned subscriber ID number or multiple
subscribers each assigned a subscriber ID.
As such you can address an entire group by placing an “A” in front of a SubID value that you addressing to. For example, if you want to send
an IOI message to a group consisting of four (4) individual subscribers, you can address the message to the entire group by placing an “A” in
front of one of the subscriber’s ID. As a result all subscribers associated with that group will receive the message.
EXAMPLE
SUBSCRIBERS IN GROUP
MESSAGE ADDRESS
MESSAGE RECIPIENTS
820
A821
820
821
821
822
822
823
823
Note: It is not recommended that you use this method unless you know specifically what subscribers are grouped together. It is best to
target each individual subscriber instead as the grouping of multiple subscribers is legacy functionality.
You can address your own group by appending an “N” to the SubID or list for which the message is intended. For example, if you are in a
group consisting of three members including yourself, you can append an “N” to the sub ID or list, and all of the members of your group will
receive the IOI message you sent out.
EXAMPLE
SUBSCRIBERS IN YOUR GROUP
MESSAGE ADDRESS
MESSAGE RECIPIENTS
940
780N
780
945
940
950
945
955
950
955
Page 17
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
ADDRESSING METHODS: BROKER TARGETING ONE OR MORE RECIPIENTS
The following addressing options are supported when a broker sends an IOI message to one or more recipients. In the table, the tags are
listed in a very specific order. When Autex receives a message, the tags are checked in the sequential order listed in the table. This means
that if tags 215, 216 and 217 are blank, Autex will go on to check tag 128. If tag 128 is blank, then Autex will go on to check tag 57.
TAG
TAG NAME
VALUES
GUIDELINES
RoutingID Tags
• First tags in message checked for addressing.
215
NoRoutingIDs
Number of RoutingType and
RoutingID pairs.
• There can be up to 500 unique addressees targeted per message
with the Routing ID tags repeating up to 500 times. More than 500
will generate a reject.
216
RoutingType
Type of RoutingID for this pair
using the following values.
These values must appear in
the sequence shown:
1 = Target Firm
2 = Target List
3 = Block Firm
4 = Block List
• The repeating group must be used correctly. There must be one
pairing of tags 216 and 217 for the number indicated in tag 215. For
example, if 215=2, then there must be two pairs of tags 216 and 217.
217
RoutingID
Name of the SubID value,
ListID value, or Group
Acronym (CompID) for the
recipient.
128
DeliverToCompID
Name of the SubID value,
ListID value, or Group
Acronym (CompID) for the
recipient.
• A “Firm” is typically defined as a single SubID value or CompID.
• A “List” is defined as either a Subscriber Own List (SOL) or a
System List.
• You must add or “Target” Firms and Lists before subtracting or
“Blocking” Firms and Lists.
• Multiple elements using the plus (+) or subtract (-) signs are not
allowed in tag 217. Only a single SubID value, ListID value, or
CompID can be specified per RoutingID instance.
• After Routing tags (215, 216 & 217), this tag is checked next by Autex.
• Multiple addressing elements are supported so that you can target
and/or block specified ListID values, SubID, and CompID values.
• Both plus (+) and minus (-) signs are supported for including
(targeting) and excluding (blocking) elements.
• Spaces are not allowed between elements.
• A maximum length of 500 characters is allowed for this field.
57
TargetSubID
Name of the SubID value,
ListID value, or Group
Acronym (CompID) for the
recipient.
• After DeliverToCompID (128) this tag is checked next by Autex.
• Multiple addressing elements are supported so that you can target
and/or block specified ListID values, SubID, and CompID values.
• Both plus (+) and minus (-) signs are supported for including
(targeting) and excluding (blocking) elements.
• Spaces are not allowed between elements.
• A maximum length of 500 characters is allowed for this field.
ADDRESSING EXAMPLES: BROKER TARGETING ONE OR MORE RECIPIENTS USING ROUTINGID TAGS
Example 1: Broker targeting a single recipient:
215=1
Page 18
216=1
217=820
Message
Recipients:
820
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Example 2: Broker sending an IOI to all institutions on the Autex network using the L1 list:
Message
Recipients:
All Institutions
216=2
217=L1
215=1
Example 3: Broker sending an IOI to multiple recipients:
216=1
217=820
Message
Recipients:
820
821
822
216=1
217=821
215=3
216=1
217=822
Example 4: Broker sending an IOI to all institutions on the Autex network using the L1 list, but blocking 2 specific recipients.
216=1
217=L1
Message
Recipients:
All Institutions Minus
(820)
(821)
216=3
217=820
215=3
216=3
217=822
Example 5: Broker sending an IOI targeting recipients included in their L102 SOL list and additionally targeting SubID 675, but blocking
SubID 945 from receiving the IOI. Notice that the list and individual subscriber are targeted or added before the blocking or subtraction of
the subscriber.
SubIDs
in L102
801
802
803
945
955
980
216=1
217=L102
215=3
216=1
217=675
216=3
217=945
Message
Recipients:
675
801
802
803
955
980
Page 19
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
ADDRESSING EXAMPLES: BROKER TARGETING ONE OR MORE RECIPIENTS USING TAG 128
DESCRIPTION
TAG 128 VALUE
RECIPIENTS
Broker uses tag 128 to target a single recipient.
128=820
820
Broker uses tag 128 to target all institutions on the Autex network using the L1 list.
128=L1
All institutions
Broker uses tag 128 to target multiple recipients.
128=820+821+822
820
821
822
Broker sending an IOI to all institutions on the Autex network using the L1 list, but
blocking 2 specific recipients.
128=L1-820-822
All institutions
Minus
820
822
Broker sending an IOI targeting recipients included in their L102 SOL list (Contains:
801,802,803,945,955,980) and additionally targeting SubID 675, but blocking
SubID 945 from receiving the IOI. Notice that the list and individual subscriber are
targeted or added before the blocking or subtraction of the subscriber.
128=L102+675-945
675
801
802
803
955
980
Note: Tag 57 can also be used in the same manner as tag 128.
ADDRESSING METHODS: RECIPIENT IDENTIFYING IOI OR ADVERTISED TRADE ORIGINATOR
The following addressing options are supported to enable an Institution or message recipient to identify the broker or originator sending an
IOI or Advertised Trade message. Tags 115 and 50 are automatically populated by Autex with the CompID of the message originator.
Note: A recipient can be an institution receiving IOI and/or Advertised Trade messages or a broker who elects to receive their own IOI and/or
Advertised Trade messages that they sent or Advertised Trade sent by other brokers sending to the Autex community.
RECIPIENT IDENTIFYING ORIGINATOR
Tag
Tag Name
Supported For...
Guidelines
115
OnBehalfOfCompID
Broker/originator FIX CompID. Used
to identify the message originator.
Tag 115 is always populated by Autex with the Broker/originator's
CompID value.
50
SenderSubID
Broker/originator FIX CompID. Used
to identify the message originator.
Tag 50 is always populated by Autex with the Broker/originator’s
CompID value.
116
OnBehalfOfSubID
Broker/originator SenderSubID value.
Tag 116 is populated with the value contained in Tag 50 if
optionally sent from the Broker/originator or SenderSubID
endpoint value if configured in Autex.
TAGS IDENTIFYING THE TARGET INSTITUTION/RECEIVER
Tag
Tag Name
Supported For...
56
TargetCompID
Institution/Receiver FIX CompID
57
TargetSubID
Institution/Receiver TargetSubID
Guidelines
Tag 57 is populated with the value sent in tag 129 if optionally
sent by the Broker/originator.
Recipient Example: Recipient/Institution Receiving IOI from Broker
In this example a broker is sending a FIX IOI message using tag 128 to specify the target institution recipient. The message recipient receives
the IOI via their FIX session to Autex.
AUTEX SUBSCRIBERS IN EXAMPLE
Broker FIX CompID
XYZBROK
Broker SenderSubID (Optional)
BOS
Message Recipient
820 = (SubID of Institution ABCINV)
Institution FIX CompID
ABCINV
Page 20
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
SENT FROM BROKER TO AUTEX
TAG VALUES SENT
SENT FROM AUTEX TO RECIPIENT
TAG VALUES RECEIVED
SenderCompID (49)
XYZBROK
SenderCompID (49)
AUTEX
TargetCompID (56)
AUTEX
TargetCompID (56)
ABCINV
OnBehalfOfCompID (115)
XYZBROK
Message Header
OnBehalfOfCompID (115)
DeliverToCompID (128)
820
DeliverToCompID (128)
SenderSubID (50)
BOS
SenderSubID (50)
TargetSubID (57)
TargetSubID (57)
OnBehalfOfSubID (116)
OnBehalfOfSubID (116)
XYZBROK
BOS
SERVICE BUREAU CONNECTIONS
A Concentrator Network (CN) can be set up that allows for an entity such as a Service Bureau to send and receive messages on behalf of
multiple clients or destinations over a single FIX session.
The following table describes the additional FIX tags that are required when a CN is sending application messages outbound. These values
must be sent in addition to the addressing schemes listed above.
SENDING AN OUTBOUND MESSAGE
Tag
Tag Name
Supported For...
Guidelines
115
OnBehalfOfCompID
FIX CompID value used to identify the
destination originating the message.
Tag 115 is required to be sent with predefined values.
116
OnBehalfOfSubID
Optional SenderSubID value used to specify
a SubID value of the originating destination.
Tag 116 can be optionally sent with any value if a
SubID is sent by the message originator.
The following table describes the extra FIX tags you see when receiving inbound application messages. These values are received in
addition to any other values described in the addressing schemes listed above.
RECEIVING AN INBOUND MESSAGE
Tag
Tag Name
Supported For...
Guidelines
128
DeliverToCompID
FIX CompID value used to identify the
message recipient.
Tag 128 is always sent with predefined values.
129
DeliverToSubID
Optional TargetSubID value used to specify
the SubID value of the message recipient.
Tag 129 can optionally be sent with any value if a
TargetSubID is sent by the message originator.
ON BEHALF OF NETWORKS
Members within the same organization have the option of creating an On Behalf Of Network. An “On Behalf of Network” enables a
subscriber to send out messages on behalf of other subscribers within the same company. Every Autex subscriber must belong to a group
(See Group and Endpoint Acronyms for an explanation about groups). A group can consist of one or more subscribers. The On Behalf Of
Network is comprised of one or more “groups” related to the same company. Once the On Behalf Of network is established, a subscriber
may send out Indications of Interest and Advertised Trade messages “on behalf of” any other subscriber on that network allowing for the
messages to appear to the recipient with the Autex identifier values associated with that particular subscriber. This functionality could be
useful if a legacy Autex subscriber who is known to their clients with certain Autex identifier acronyms and now sends their messages via
FIX. The FIX session can send On Behalf Of the legacy Autex subscriber so that the Autex identifier acronyms appear from the original
subscriber. A FIX session could also send on behalf of another FIX session that may have previously been used and has now been replaced
by a new FIX session.
Page 21
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Notes: The On Behalf Of Network is configured and maintained by Autex.
In order to utilize this functionality the following tags are used once an On Behalf Of network has been created:
Tag 115 (OnBehalfOfCompID): Specifies the Group Acronym of the group that the message is being sent On Behalf Of.
Tag 116 (OnBehalfOfSubID): Indicates a specific subscriber (endpoint) in the group (See Group and Endpoint Acronyms for an explanation
about endpoints). This tag must be sent if the subscriber that you are sending On Behalf Of is an Autex GUI subscriber that has an endpoint
configured. If sending On Behalf Of a subscriber within a group without an endpoint such as another FIX session tag 116 does not need to be sent.
On Behalf of Network
Group
BXYZ1
Organization
Broker XYZ
Group
BXYZ2
In this example Broker XYZ has 3 groups that
make up their On Behalf of Network. BXYZ1
can send messages appearing to come from
any subscriber associated with the BXYZ2 and
BXYZ3 groups.
On Behalf of Network
Group
BXYZ3
On Behalf Of Example:
The following example shows Broker XYZ from the above diagram using a configured On Behalf Of network so that their FIX session BXYZ1
can send messages so that they appear to be originating from BXYZ3 to the recipient.
Message Originator: FIX session subscriber sending message on behalf of another subscriber
BXYZ1
Message Owner: Group acronym for whom the message is being sent on behalf of
BXYZ3
Specific Subscriber: Endpoint acronym for the subscriber for whom the message is being sent
NY
Message Recipient: Broker XYZ targets Institution ABCINV (SubID:123)
ABCINV
MESSAGE SENT ON BEHALF OF
ANOTHER SUBSCRIBER TO AUTEX
TAG VALUES SENT
MESSAGE SENT FROM AUTEX TO
MESSAGE RECIPIENT
TAG VALUES RECEIVED
SenderCompID (49)
BXYZ1
SenderCompID (49)
AUTEX
TargetCompID (56)
AUTEX
TargetCompID (56)
ABCINV
OnBehalfOfCompID (115)
BXYZ3
OnBehalfOfCompID (115)
BXYZ3
DeliverToCompID (128)
123
DeliverToCompID (128)
SenderSubID (50)
OnBehalfOfSubID (116)
Page 22
NY
SenderSubID (50)
BXYZ3
OnBehalfOfSubID (116)
NY
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
CONSOLIDATED FEED
Similar to a service bureau connection, a consolidated feed can be configured that allows for multiple individual client recipients of IOI or
Advertised Trade messages to receive them via a single FIX session. The consolidated feed uses the RoutingID tags to specify each distinct
destination that a targeted IOI or Advertised Trade message should be delivered to or excluded. A list of these destinations will need to be
configured for the feed. The destination (tag 217) can be a value of your choosing which corresponds to a specific Autex subscriber.
When receiving the FIX messages from Autex you will receive 216=1 (Target Firm) to indicate that the IOI should be delivered to a corresponding
destination value sent in tag 217. You will receive 216=3 (Block Firm) to indicate that the IOI should not be delivered to a corresponding
destination value sent in tag 217. Sometimes you may only see certain values be targeted to indicate that only those two recipients should
receive the IOI and no one else. If all destinations on the list should receive the IOI then you will receive 216=1 and “ALLINST” in tag 217.
If the majority of the clients are to receive the IOI then you may see something such as 216=1 with ALLINST in tag 217 and 216=3 with
217=INST1 to indicate that all clients should receive the IOI except for INST1.
Consolidated Feed Example:
You have 5 clients that receive IOI messages from Autex. A consolidated feed is created with those 5 Autex subscribers that you choose to
which you know them as Client1, Client2, Client3, Client4, Client5. A broker sends an IOI message targeting the Autex subscribers that you
know as Client2 and Client5. The following RoutingID tags will be populated in the FIX message sent from Autex:
215=2
216=1
217=Client2
216=1
217=Client5
Page 23
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 10 FIX Message Header and Trailer
Every FIX message contains a Standard Header at the beginning and a Standard Trailer at the end. The relevant fields are described in
detail in this section.
FIX MESSAGE STANDARD HEADER FIELDS
The following table provides details regarding the fields that are used in the Standard Header when composing a new FIX message.
Reject messages that can occur are described in the Validations column, when appropriate.
STANDARD HEADER
Tag
#
Field Name
Data Format
/ Length
8
BeginString
ST
8
9
BodyLength
35
Req’d
Description
Validations
Y
Identifies beginning of new message and
protocol version.
Must be the first field in the new message.
Always unencrypted.
Valid values: FIX 4.2
Reject if an invalid value.
Reject if not the first field in
the header.
Int
Y
Message length, in bytes, forward to the
CheckSum field.
Must be the second field in the message.
Always unencrypted.
Reject if not the second field
in the header.
MsgType
ST
2
Y
Defines the message type.
Must be the third field in the message.
Always unencrypted.
Reject if not the third
message in the header.
49
SenderCompID
ST
10
Y
Assigned value used to identify firm sending
message.
Related topics:
FIX CompIDs
Addressing
56
TargetCompID
ST
10
Y
Assigned value used to identify receiving
firm.
Related topics:
FIX CompIDs
115
OnBehalfOfCompID
ST
10
N
Assigned value used to identify firm
originating message, when a third party
delivers the message.
Related topics:
Addressing
FIX CompIDs
128
DeliverToCompID
ST
500
N
Assigned value used to identify the firm
targeted to receive the message when third
party delivers the message.
Related topics:
Addressing
FIX CompIDs
90
SecureDataLen
N
Dropped
91
SecureData
N
Dropped
34
MsgSeqNum
Int
Y
Sequence number of FIX message.
50
SenderSubID
ST
250
N
Assigned value used to identify message
originator (e.g. desk, trader, etc.).
Related topic:
Addressing
Page 24
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
STANDARD HEADER
Tag
#
Field Name
Data Format
/ Length
Req’d
142
SenderLocationID
ST
50
N
Assigned value used to identify message
originator’s location (e.g. geographic
location and/or desk).
57
TargetSubID
ST
200
N
Assigned value used to identify the specific
message recipient (e.g. desk, trader, etc.).
Related topics:
Addressing
FIX CompIDs
143
TargetLocationID
ST
50
N
Assigned value used to identify message
recipient’s location (e.g. geographic location
and/or desk).
116
OnBehalfOfSubID
ST
250
N
Assigned value used to identify the message
originator (e.g. trader) if a third party
delivers the message.
Related topic:
Addressing
144
OnBehalfOfLocationID
ST
50
N
Assigned value used to identify the message
originator’s location (e.g. geographic
location and/or desk) when a third party
delivers the message.
129
DeliverToSubID
ST
250
N
Assigned value used to identify the specific
message recipient (e.g. desk, trader, etc.)
when a third party delivers the message.
Related topic:
Addressing
145
DeliverToLocationID
ST
50
N
Assigned value used to identify message
recipient’s location (e.g. geographic location
and/or desk). when a third party delivers
the message.
43
PossDupFlag
B
N
Indicates possible retransmission of
message with this sequence number.
Required for retransmitted messages
whether prompted by the sending system,
or as the result of a resend request.
Valid values:
Y = Possible duplicate
N = Original transmission
Related topic:
Possible Duplicate Messages
97
PossResend
B
N
Indicates that the message may contain
information that was sent under another
sequence number.
Valid values:
Y = Possible resend
N = Original transmission
Related topic:
Possible Resend Messages
52
SendingTime
TS
Y
Time of message transmission.
Description
Validations
Page 25
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
STANDARD HEADER
Tag
#
Field Name
122
OrigSendingTime
212
Data Format
/ Length
TS
Req’d
Description
N
Original time of the message transmission
when transmitting messages as a result of a
Resend Request.
XmlDataLen
N
Dropped
213
XmlData
N
Dropped
347
MessageEncoding
N
Dropped
369
LastMsgSeqNum
Processed
N
The last MsgSeqNum (34) value received
by the FIX engine and processed by the
downstream application, such as trading
system or order routing system.
370
OnBehalfOfSending
Time
N
Dropped
Int
Validations
FIX MESSAGE STANDARD TRAILER FIELDS
The following table describes the fields that are used in the Standard Trailer when composing a new FIX message. Reject messages that
can occur are described in the Validations column, when appropriate.
STANDARD TRAILER
Tag
#
Field Name
89
Signature
N
Dropped
93
SignatureLength
N
Dropped
10
CheckSum
Y
Must be the last field in the message.
Three-byte simple checksum.
Always unencrypted.
Page 26
Data Format
/ Length
ST
33
Req’d
Description
Validations
Reject if not the last field in
the message.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 11 Administrative Fix Messages
Standard session-level administrative messages like Logons, Heartbeats, Test Requests, Resend Requests, Sequence Resets, and Business
Rejects messages are all supported.
Note: Details on the FIX fields and proper usages of administrative messages can be found in the FIX 4.2 specification documents
published by The FIX Protocol Organization.
The following message topics are covered in the chapter:
Possible Duplicate Messages
Possible Resend Messages
Logon Message
POSSIBLE DUPLICATE MESSAGES
When the FIX engine determines that a message was not or may not have been successfully received, a Resend Request can be issued to
request the retransmission of the unprocessed message or messages. In response to a Resend request, a Possible Duplicate message can
be used quoting the same sequence number as the original message with the PossDup flag set to “Y.” It is the responsibility of the recipient
to handle the Possible Duplicate message by either treating it as a “new” message or simply discarding it based on the receipt or nonreceipt of the original message. This function is typically automated and does not require manual intervention.
Note: Messages received with the PossDup flag set to “N” should always be treated as original messages.
POSSIBLE RESEND MESSAGES
If you sent a message that appears to be in an ambiguous state, it can be reissued with a new sequence number with the PossResend flag
set to “Y.” This indicates that all the values and identifiers are possibility the same as a previously sent message with a different sequence
number. The destination application is responsible for recognizing this flag and evaluating internal message fields to determine if this
message had been previously received, and then to process accordingly. Example: A message may be considered in an ambiguous state
when it’s suspected that a recipient’s application was not appropriately updated.
LOGON MESSAGE
LOGON MESSAGE
Tag
#
Field Name
Data Format
/ Length
<Standard Header>
Req’d
Description
Y
MsgType (35) = A (uppercase)
For details see: Standard Header
98
EncryptMethod
Int
Y
Always unencrypted.
108
HeartBtlnt
Int
Y
Same value used by both sides in seconds.
For client-initiated sessions, Autex matches
the value received.
For Autex-initiated sessions, 30 seconds is
sent by default.
95
RawDataLength
N
Dropped
96
RawData
N
Dropped
141
ResetSeqNumFlag
B
N
Indicates both side of a FIX session should
reset sequence numbers.
Valid values:
Y = Yes, reset sequence numbers
N = No
383
MaxMessageSize
Int
N
Can be used to specify the maximum
number of bytes supported for
messages received.
384
NoMsgTypes
Int
N
Specifies the number of repeating
RefMsgTypes (372).
Validations
Page 27
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
LOGON MESSAGE
Tag
#
Field Name
Data Format
/ Length
â
372
RefMsgType
ST
â
385
MsgDirection
CH
1
<StandardTrailer>
Page 28
Req’d
Description
Validations
N
Specifies a supported MsgType.
Required if NoMsgTypes (384) > 0.
Indicated from the vantage point of the
sender of the Logon message.
Note: Autex may not
authenticate or adhere to
the specified values.
N
Indicates the direction (i.e. send vs receive)
of a supported message type.
Required if NoMsgTypes (384) > 0.
Indicated from the vantage point of the
sender of the Logon message.
Valid values:
S = Send
R = Receive
Note: Autex may not
authenticate or adhere to
the specified values.
Y
For details see: Standard Header
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 12 Indication of Interest (IOI) Messages
Autex provides several powerful features allowing for flexibility when sending or receiving FIX IOI messages to best suits your needs.
The following topics and features of FIX Indications of Interest messages are described:
• IOI Message Categories
• Indication of Interest (IOI) FIX Message
• Actionable IOIs
• Pegged IOIs
• IOI Expiration
• Message Elections
• Message Categories
• Message Filters
• Security ID Preference
IOI MESSAGE CATEGORIES
Indications of Interest messages can be categorized into one of three (3) types based on the level of detail in the message. The three IOI
categories are General, Detailed and Natural. When the IOI message is composed, you can select the appropriate category by supplying
more or less detail in the Quality (25), Shares (27), and Price tags (44), or by setting the Natural flag (130).
The following table defines the appropriate level of detail for each category:
CATEGORY
QUALITY (TAG 25)
SHARES (TAG 27)
PRICE (TAG 44)
NATURAL (TAG 130)
General
Indicate one or the other
of the two valid values:
Blank
Quality of IOI indicated by:
Low (L) or
Medium (M)
Indicate one or the other
of the two valid values:
Share Quantity indicated
by:
Small (S)
Medium (M)
Large (L)
Numeric Value
Note: When using
numeric value, do not
indicate a Price (tag 44).
Indicate one of the three
valid values:
1.Blank
2.NO
3.Price
Note: When using price,
do not indicate numeric
share volume in Shares
tag (27).
Indicate one or the other
of the two valid values:
Blank
NO
Note: A General IOI cannot be replaced.
Note: If a General IOI is canceled then all other General IOI’s sent with the same Side, Shares, Symbol will also be cancelled within Autex.
GENERAL
EXAMPLES
Detailed
SYMBOL
QUALITY
SHARES
PRICE
NATURAL FLAG
IBM
L
L
Blank
Blank
IBM
Blank
5000
Blank
Blank
QUALITY (TAG 25)
SHARES (TAG 27)
PRICE (TAG 44)
NATURAL (TAG 130)
Indicate one or the other of
the two valid values:
Blank
Quality of IOI indicated by:
High (H)
Indicate one or the other of
the two valid values:
Share Quantity indicated by:
Small (S)
Medium (M)
Large (L)
Numeric Value
Note: Must use numeric
value when Quality = blank.
Indicate one of the three
valid values:
1. Blank
2.NO
3.Price
Note: Must indicate Price
when Quality = blank.
Indicate one or the other of
the two valid values:
YES
NO
Note: No value in the field
(or blank) indicates “No”
natural flag.
Page 29
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
DETAILED
EXAMPLES
SYMBOL
QUALITY
SHARES
PRICE
NATURAL FLAG
IBM
H
L
Blank
Blank
IBM
Blank
5000
75.00
Blank
CATEGORY
QUALITY
SHARES (TAG 27)
PRICE (TAG 44)
NATURAL (TAG 130)
Natural
Related
Topic: Natural
Definition
All valid values = OK
All valid values = OK
All valid values = OK
YES
Note: A General message may also be known as an “Interest” message, and a Detailed message may also be known as a “Super” message.
Natural IOI Definition
The Financial Industry Regulatory Authority (FINRA) has issued guidance in Regulatory Notice 09-28 regarding the dissemination of
IOIs and the classification of Natural IOIs. Autex expects all clients to adhere to their regulatory obligations and written procedures when
disseminating IOIs (Natural or otherwise) via Autex.
In reflecting FINRA’s guidance, Autex defines a Natural IOI as follows:
“[to] refer to interest a firm represents on an agency basis or refer not only to agency interest but also proprietary interest in certain specific
contexts (e.g. proprietary interest that was established as the result of the facilitation of a custom order or the execution of a custom order
on a riskless principal basis)” (FINRA, 2009).
Citation
Financial Industry Regulatory Authority. (May 2009). Indications of Interest: FINRA Reminds Firms of Their Obligation to Provide accurate
Information in Disseminating, or Using Services to Disseminate, Indications of Interest. (Regulatory Notice 09-28).
IOI FIX MESSAGE
The following table provides details regarding the fields that are used when composing a New, Cancel or Replace Indications of Interest
message type.
IOI MESSAGE
Tag
#
Field Name
Data Format
/ Length
Req’d
Description
Validations
<Standard Header>
Y
23
IOIID
Y
ST
30
Unique Identifier of an IOI message. Identifier must
be unique for at least 7 calendar days.
Reject if a duplicate ID
has been sent prior to
original expiring.
28
IOITransType
Y
CH
1
Identifies the IOI message transaction type.
Valid values:
N = New
C = Cancel
R = Replace
Note: A General IOI cannot be replaced.
Note: If a General IOI is canceled then all other
General IOI’s sent with the same Side, Shares,
Symbol will also be cancelled
within Autex.
Related topic:
IOI Message Categories
Reject if an invalid value.
26
IOIRefID
N
ST
30
The IOIID (23) value that identifiers a previous IOI
message that is being Cancel or Replaced.
Required when the IOITransType (28) = C or R.
Value must correspond to an active valid IOIID (23).
Reject if no value and
IOITransType (28) = C or
R. Reject if value is not
found or no longer active.
Page 30
MsgType (35) = 6
For details see: Standard Header
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
IOI MESSAGE
Tag
#
Field Name
Data Format
/ Length
Req’d
55
Symbol
Y
ST
22
Ticker symbol
Note: Either a valid Datascope symbol must be
used in this field or a valid security identifier must
be specified using tags 22/48.
Related topic:
Global Symbology
65
SymbolSfx
N
ST
8
Additional information about the security, e.g.
preferred.
Note: Autex does not validate this value.
48
SecurityID
N
ST
30
Security identifier value, e.g. CUSIP, ISIN, SEDOL,
RIC
Required if IDSource (22) is specified.
Note: Either a valid security identifier must be
specified using tags 22/48 or a valid Datascope
symbol must be used in tag 55.
Related topic:
Global Symbology
Reject if no value and
IDSource (22) is specified.
22
IDSource
N
ST
3
Identifies the security ID (48) value type.
Required if SecurityID (48) is specified.
Valid values: 1-999
Only the following are validated values:
1 = CUSIP
2 = SEDOL
4 = ISIN
5 = RIC
Note: Either a valid security identifier must be
specified using tags 22/48 or a valid Datascope
symbol must be used in tag 55.
Related topic:
Global Symbology
Reject if an in valid value.
167
SecurityType
N
ST
10
Indicates type of security.
See the FIX 4.2 specification for details
and values.
200
MaturityMonthYear
N
MY
Dropped
205
MaturityDay
N
ST
2
Dropped
201
PutOrCall
N
ST
2
Dropped
202
StrikePrice
N
Prc
Dropped
206
OptAttribute
N
CH
5
Dropped
231
ContractMultiplier
N
FIt
Dropped
223
CouponRate
N
FIt
Dropped
207
SecurityExchange
N
ST
5
Can be used to identify the security.
See the FIX 4.2 specification for valid values.
Related topic:
Global Symbology
Description
Validations
Page 31
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
IOI MESSAGE
Tag
#
Field Name
106
Issuer
N
348
EncodedIssuerLen
N
Dropped
349
EncodedIssuer
N
Dropped
107
SecurityDesc
N
350
EncodedSecurityDescLen
N
Dropped
351
EncodedSecurityDesc
N
Dropped
54
Side
Y
CH
1
Side of order
Valid values:
1 = Buy
2 = Sell
7 = Undisclosed
Reject if an invalid value.
27
IOIShares
Y
ST
13
The number of shares/quantity in numeric
form or relative size.
Valid values:
0-9999999999999
S = Small
M = Medium
L = Large
Related topic:
IOI Message Categories
Reject if an invalid value.
44
Price
N
Prc
Price per unit of quantity (e.g. per share).
Related topic:
IOI Message Categories
15
Currency
N
ST
5
Identifies the currency used for price.
Absence of this field is interpreted as the
default for the security.
See FIX 4.2 Specification for the currency
codes.
Must be uppercase alphabetic characters
only.
62
ValidUntilTime
N
TS
Indicates expiration time of message.
25
IOIQltyInd
N
Ch
1
Relative quality of indication.
Valid values:
L = Low
M = Medium
H = High
Related topic:
IOI Message Categories
Page 32
Data Format
/ Length
Req’d
ST
250
ST
250
Description
Validations
Company name of the security issuer.
Value greater than 250 characters is
truncated when passed.
Value greater than 250
characters is truncated.
Security description
Value greater than 250 characters is
truncated when passed.
Value greater than 250
characters is truncated.
Reject if not in uppercase
alphabetic characters.
Reject if an invalid value.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
IOI MESSAGE
Tag
#
Field Name
Data Format
/ Length
130
IOINaturalFlag
N
199
NoIOIQualifiers
â
104
Req’d
Description
Validations
B
Indicates that the IOI is the result of an existing
agency order or a facilitation position resulting from
an agency order, not from principal trading or order
solicitation activity.
Valid values:
Y = Natural
N = Not natural
Related topics:
Natural IOI Definition
IOI Message Categories
Reject if an invalid value.
N
ST
2
Number of repeating groups of IOIQualifiers (104).
Valid values: 1-30.
Reject if an invalid value.
IOIQualifier
N
CH
1
Code to qualify IOI use.
Required if NoIOIQualifiers (199) is greater than 0.
Values must be uppercase.
Valid values:
A = All or none
B = Market on close (MOC)
C = At the close
D = VWAP (Volume Weighted Avg Price)
E = Client Natural
F= House Natural
G = Position Wanted
H = Customer Order in Hand
I = In touch with
J = Customer Firm Commitment
L = Limit
M = More behind
N = Certified Natural
O = At the open
P = Taking a position
Q = At the Market (previously called Current Quote)
R = Ready to trade
S = Portfolio shown
T = Through the day
U = Unwind
V = Versus
W = Indication – Working away
X = Crossing opportunity
Y = At the midpoint
Z=Pre-open
Related topic:
Pegged IOIs
Reject if an invalid value.
Reject if no value and
NoIOIQualifiers (199) > 0.
Reject if the number of
repeating IOIQualifiers
does not exactly match
the number specified in
NoIOIQualifier (199) field.
58
Text
N
ST
Free format text string.
Note: Autex may populate this field to indicate
certain parameters, e.g. NAT (to indicate that the
message was sent with the Natural flag=Y.)
All contents in field are
passed.
354
EncodedTextLen
N
Dropped
355
EncodedText
N
Dropped
60
TransactTime
N
TS
Time this message was initiated.
Page 33
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
IOI MESSAGE
Tag
#
Field Name
Data Format
/ Length
149
URLLink
N
215
NoRoutingIDs
â
216
Req’d
Description
Validations
ST
250
URL link to additional information.
Value greater than 250 characters is
truncated when passed.
Value greater than 250
characters is truncated.
N
Int
Number of repeating groups of RoutingType Reject if an invalid value.
(216) and RoutingID (217) values.
Valid values: 1-500.
Related topic:
Addressing
RoutingType
N
CH
1
Indicates the type of RoutingID specified.
Required if NoRoutingIDs (215) is greater
than 0.
Valid values:
1 = Target Firm
2 = Target List
3 = Block Firm
4 = Block List
Related topic:
Addressing
Reject if an invalid value.
Reject if no value and
NoRoutingIDs (215) > 0.
If the number of
RoutingTypes does
not exactly match the
number specified in the
NoRoutingIDs (215) field.
â
217
RoutingID
N
ST
10
Assigned value used to identify a specific
routing destination.
Required if NoRoutingID (215) is greater
than 0.
Only a single SubID value, ListID value, or
CompID can be specified per RoutingID
instance.
Related topic:
Addressing
Reject if no value and
NoRoutingIDs (215) > 0.
If more than 500 values.
If the number of RoutingIDs
does not exactly match the
number specified in the
NoRoutingIDs (215) field.
218
SpreadToBenchmark
N
Dropped
219
Benchmark
N
Dropped
211
PegOffsetValue
N
FIt
Amount added to the Peg. Offset value can
be positive or negative.
Related topic:
Pegged IOIs
836
PegOffsetType
N
Int
1
Type of Peg Offset value.
Common values:
0 = Price
1 = Basis Points
2 = Ticks
3 = Price Tier / Level
N
CH
1
Indicates if the IOI is or isn’t Actionable.
Common values:
Y = Actionable
1 = Actionable
T = Actionable
F = Not Actionable
0 = Not Actionable
N = Not Actionable
Related topic:
Actionable IOIs
11001 IOIType
<Standard Header>
Page 34
Y
For details see: Standard Trailer
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Custom Tags
Custom tags are generally not passed to a message recipient when sent within an IOI message. They will usually be dropped if received
unless it has been requested that Autex pass them or in some instances may possibly be included in a FIX message by Autex to denote
certain functionality or service.
ACTIONABLE IOIS
Use the IOI Type tag 11001 to indicate if the IOI is Actionable. Venues receiving Actionable IOI’s will need to be configured to appropriately
handle and display the values received in tag 11001 indicating if the IOI is actionable or not. The proper display and subsequent orders that
maybe generated referencing an actionable IOI such as including the IOIID in tag 23 will need to be performed by the particular application
and/or OMS/EMS.
Note: Autex will pass any 1 character value received in tag 11001 to recipient FIX sessions. Typically to indicate an IOI is actionable tag 11004
values Y,1,or T specifies that it is true and typically to indicate that an IOI is not actionable tag 11004 values F,0,N, or not sent specifies that it
is false. The receiving application will need to be configured to process values received in this tag accordingly.
PEGGED IOIS
Pegged IOI’s allows you to send and/or receive IOI messages that are pegged to the Market or pegged to the Midpoint using the IOI
Qualifiers in tag 104 with an optional Peg Offset Value specified in tag 211:
Pegged to Market: IOI Qualifier Tag 104=Q
Pegged to Midpoint: IOI Qualifier Tag 104=Y
Optionally with a positive or negative offset value specified in tag 211
Note: Venues receiving pegged IOI’s will need to be configured to appropriately handle the values received for the peg reference and offset
as required. The proper display and any calculations based upon the received values will need to be performed by the particular application.
IOI EXPIRATION
At the of the end of each day Autex considers all FIX IOI messages to be expired regardless if they have not been cancelled, replaced, or
regardless if a ValidUntilTime was specified in the FIX message. Autex defines the end of the trading day based upon the business region
of the specified security being sent in the IOI message. The business region is determined during the security identification process of an IOI
message with the closest one to the identified security’s location automatically selected. See Global Symbology for details on the security
identification process.
Autex uses the following three business regions to determine the expire time of the IOI message. The expire times associated with each of
the business regions are set at a specific GMT time for each region. The GMT time is generally at or near 20:00 (8:00 PM) local time, but the
actual local time may vary depending on the specific location.
BUSINESS REGION
EXPIRE TIME
Americas
01:00 GMT
Asia Pacific
15:00 GMT
EMEA
19:00 GMT
Note: If you send a cancel for an IOI or a replacement of an IOI after it has been considered to be expired by Autex you will receive a reject.
This is also true even if a ValidUntilTime was specified in tag 62 of the FIX message for a time after the Autex expiration time. For example,
if an IOI is sent where the security is determined to be in the Asia Pacific business region at 03:00 GMT and a cancel is sent for that IOI at
16:00 GMT the cancel would be rejected because that IOI was already considered to be expired by Autex. Another example is if an IOI is sent
where the security is determined to be in the Americas business region at 14:00 GMT and a replacement for that IOI is sent at 02:00 GMT it
would be rejected since the original was sent prior to the Autex expire time.
Note: The IOIID value in tag 23 must always be unique for at least 7 calendar days regardless if a previous IOI that used the same identifier
has been considered to be expired by Autex.
Page 35
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
IOI MESSAGE ELECTIONS
Message Elections give you the ability to select whether or not you want to send or receive Indications of Interest messages. When your
session is configured it will automatically defer to the default method for your client type (Broker or Institution) unless requested otherwise.
Although receiving own IOIs by default is set to Y for Brokers, it is usually set to N unless requested to remain Y.
The following table defines the clients and their associated election types, along with the default election.
CLIENT TYPE
ELECTIONS
CHOOSE
Broker / ECN Broker
Send IOIs
Y
N
Send IOIs
Y
Receive own IOIs
Y
N
Receive own IOIs
Y
Receive other IOIs
Y
N
Receive other IOIs
N
Receive IOIs
Y
N
Receive IOIs
Y
Institution
DEFAULT
Note: Brokers can choose to receive their own IOIs that they send and/or only receive other IOIs when they are explicitly targeted in the
original IOI message.
IOI MESSAGE FILTERS
You have the option to filter Indications of Interest messages based on certain criteria. This option enables you to choose the types of
messages that you want to receive and from whom you want to receive them from.
The following table describes each of the filters in detail. When your session is configured it will automatically defer to the default method
unless requested otherwise.
FILTER TYPE
DESCRIPTION
DEFAULT
ECNs
ON = receive messages from ECNs.
OFF = do not receive any message from ECNs.
ON
Broker
Include or exclude specific brokers.
You can choose to receive all IOI messages from all brokers or you
can filter by including only a certain set of specific brokers from
whom you want to receive IOI messages from.
Receive messages from all brokers.
IOI Message Category
Indicate ON or OFF for each of the IOI category types:
Natural
Detailed
General
See IOI Message Categories for descriptions of each of the IOI
message categories.
Receive all three message
category types.
SECURITY SYMBOL AND IDENTIFIER PREFERENCES
Autex provides the flexibility for you to set a symbol and security identifier preference when receiving FIX IOI messages. Despite the values
used by the message originator, Autex can translate what was sent to conform to your chosen preferences. There are two preferences that
can be configured:
• Symbol Preference in the Symbol tag (55)
• SecurityID Preference in the SecurityID tag (48)
Symbol Preference
As the message recipient, you have the option to have the symbol value received in tag 55 as the following:
1.Datascope Symbol: Tag 55 is passed with the Datascope symbol value no matter what the message originator sent inbound to Autex.
Note: This is the default symbol preference.
2.Original Value: Tag 55 is passed without translation and is same value that was received from the message originator inbound to Autex.
Page 36
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
SecurityID Preference
As the message recipient, you also have the option to have the value received in tags 22/48 (SecurityIDSource/SecurityID) as the following:
1.No Preference: Tags 22/48 are passed without translation and is same value that was received from the message originator if populated
inbound to Autex. Note: This is the default SecurityID preference.
2. Converted to ISIN
3. Converted to CUSIP
4. Converted to SEDOL
5. Converted to RIC
Note: In the event that Autex cannot translate a value to your specified SecurityID preference, tags 22/48 may not be populated when
receiving the message.
SYMBOL/SECURITYID PREFERENCE EXAMPLES
Example 1:
Tag
Inbound Value to Autex
Recipient Symbol/SecurityID
Preference
Outbound Value from Autex to
Message Recipient
55 (Symbol)
IBM
Datascope Symbol
IBM
22 (SecurityIDSource)
N/A
4 = ISIN
4
48 (SecurityID)
N/A
ISIN
US4592001014
Tag
Inbound Value to Autex
Recipient Symbol/SecurityID
Preference
Outbound Value from Autex to
Message Recipient
55 (Symbol)
IBM.N
Original Value
IBM.N
22 (SecurityIDSource)
5 = RIC
1 = CUSIP
1
48 (SecurityID)
IBM.N
CUSIP
459200101
Example 2:
Page 37
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Chapter 13 Advertised Trade Messages
Advertised Trades are an important source of information that are broadcast to the entire Autex community which are then compiled
into detailed trade rankings within Autex. Autex provides several powerful features allowing for flexibility when sending or receiving FIX
Advertised Trade messages to best suits your needs.
The following topics and features of FIX Indications of Interest messages are described:
• Advertised Trade FIX Message
• As of Trades
• Advertised Trade Guidelines
• Message Elections
• Message Filters
• Security ID Preference
ADVERTISED TRADE FIX MESSAGE
The following table provides details regarding the fields that are used when composing a New, Cancel or Replace Advertised Trade
message type.
Note: Cancel messages will not be delivered to recipients receiving Advertised Trade messages via FIX.
ADVERTISED TRADE MESSAGE
Tag
#
Field Name
Data Format
/ Length
<Standard Header>
Req’d
Description
Y
MsgType (35) = 7
For details see: Standard Header
Validations
2
AdvID
ST
30
Y
Unique identifier of the advertisement
message.
Identifier must be unique for at least 7
calendar days.
5
AdvTransType
CH
1
Y
Identifies advertisement message
Reject if an invalid value
transaction type.
Valid values:
N = New
C = Cancel
R = Replace
Note: Cancel messages will not be delivered
to recipients receiving Advertised Trade
messages via FIX.
3
AdvRefID
ST
30
N
The AdvID (2) value that identifiers a
previous Advertised Trade message that is
being Cancel or Replaced.
Required when the AdvTransType (5) =
C or R.
Value must correspond to an active valid
AdvID (2).
55
Page 38
Symbol
ST
22
Y
Ticker symbol
Note: Either a valid Datascope symbol
must be used in this field or a valid security
identifier must be specified using tags
22/48.
Related topic:
Global Symbology
Reject if a duplicate ID has
been sent prior to original
expiring.
Reject if no value and
AdvTransType (5) = C or R.
Reject if value is not found
or no longer active.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
ADVERTISED TRADE MESSAGE
Tag
#
Field Name
Data Format
/ Length
Req’d
65
SymbolSfx
ST
8
N
Additional information about the security,
e.g. preferred.
Note: Autex does not validate this value.
48
SecurityID
ST
30
N
Security identifier value, e.g. CUSIP, ISIN,
SEDOL, RIC
Required if IDSource (22) is specified.
Note: Either a valid security identifier must
be specified using tags 22/48 or a valid
Datascope symbol must be used in tag 55
Related topic:
Global Symbology
Reject if no value and
IDSource (22) is specified.
22
IDSource
ST
3
N
Identifies the security ID (48) value type.
Required if SecurityID (48) is specified.
Valid values: 1-999
Only the following are validated values:
1 = CUSIP
2 = SEDOL
4 = ISIN
5 = RIC
Note: Either a valid security identifier must
be specified using tags 22/48 or a valid
Datascope symbol must be used in tag 55
Related topic:
Global Symbology
Reject if an in valid value.
167
SecurityType
ST
10
N
Indicates type of security.
See the FIX 4.2 specification for details and
values.
200
MaturityMonthYear
MY
N
Dropped
205
MaturityDay
ST
2
N
Dropped
201
PutOrCall
ST
2
N
Dropped
202
StrikePrice
Prc
N
Dropped
206
OptAttribute
CH
5
N
Dropped
231
ContractMultiplier
Flt
N
Dropped
223
Coupon Rate
Flt
N
Dropped
207
SecurityExchange
ST
5
N
Can be used to identify the security.
See the FIX 4.2 specification for valid values.
Related topic:
Global Symbology
106
Issuer
ST
250
N
Company name of the security issuer.
Value greater than 250 characters is
truncated when passed.
348
EncodedIssuerLen
N
Dropped
349
EncodedIssuer
N
Dropped
Description
Validations
Value greater than 250
characters is truncated.
Page 39
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
ADVERTISED TRADE MESSAGE
Tag
#
Field Name
Data Format
/ Length
107
SecurityDesc
ST
250
350
Req’d
Description
Validations
N
Security description
Value greater than 250 characters is
truncated when passed.
Value greater than 250
characters is truncated.
EncodedSecurityDescLen
N
Dropped
351
EncodedSecurity-Desc
N
Dropped
4
AdvSide
CH
1
Y
Broker’s side of advertised trade.
Valid values:
B = Buy
S = Sell
X = Cross
T = Trade
Reject if an invalid value
53
Shares
Qty
13
Y
Overall total quantity (e.g. number of
shares).
Valid values:
0-9999999999999
Reject if an invalid value
44
Price
Prc
N
Price per unit of quantity (e.g. per share).
15
Currency
ST
5
N
Identifies the currency used for price.
Absence of this field is interpreted as the
default for the security.
See FIX 4.2 Specification for the currency
codes.
Must be uppercase alphabetic characters
only.
Reject if not in uppercase
alphabetic characters.
75
TradeDate
DS
8
N
Indicates date of trade referenced in this
message.
Absence of this field indicates current date
(expressed in local time at place of trade).
Used to indicate As of Trade Date
Related topic:
As of Trades
Note: As of Trade can only be within the
previous 7 calendar days and cannot be a
future date.
Reject if the value specified
is greater than 7 previous
calendar days from the
current date.
Reject if value specified is
date set in the future.
60
TransactTime
TS
N
Time this message was initiated.
58
Text
ST
N
Free format text string.
354
EncodedTextLen
N
Dropped
355
EncodedText
N
Dropped
149
URLLink
ST
250
N
URL link to additional information.
Value greater than 250 characters is
truncated when passed.
30
LastMkt
ST
5
N
Market of execution for last fill.
See the FIX 4.2 specification for valid values.
336
TradingSessionID
ST
60
N
Identifier for Trading Session.
Can be used to represent a specific market
trading session.
Y
For details see: Standard Trailer
<Standard Trailer>
Page 40
All contents in field are
passed.
Value greater than 250
characters is truncated.
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Custom Tags
Custom tags are generally not passed to a message recipient when sent within an Advertised Trade message. They will usually be dropped
if received unless it has been requested that Autex pass them or in some instances may possibly be included in a FIX message by Autex to
denote certain functionality or service.
AS OF TRADES
Autex allows you to send As of Trades using the TradeDate (75) tag for reporting trades up to 7 calendar days in the past. This is
accomplished by sending a “new” message with the appropriate amount and backdating it to the date of the trade. This ensures that the
corrected trade amount will be available for recapping within Autex and complied into the trade rankings for the appropriate date.
Note: As Of Trades are not broadcast to the Autex community and are not sent outbound from Autex to recipients of FIX Advertised Trade
messages.
ADVERTISED TRADE GUIDELINES
The following are basic guidelines that can be used to ensure that your Trades Advertisements will be reported appropriately to Autex.
Note: For more details and specific trade reporting requirements please contact Autex support to request a copy of the Autex Trade
Reporting Guidelines.
General Trade Reporting Guidelines
• Trades executed in broker liquidity sources (including DMA, ECN, Block Desk, dark pools, algorithms, etc) are eligible for advertisement.
• A broker/dealer is never required to report a trade.
• All trade advertisements should be reported by 8PM, local time. A broker/dealer must report all non-restricted trades within 7 calendar
days (5 business days).
• To report a trade in securities past 7 calendar days (5 business days), a broker/dealer must contact an Autex representative.
• Both retail and institutional order flow are eligible for advertisement. Trade advertisements in equity securities will be accepted in any size.
• After buying or selling as an agent, a broker/dealer must only report the market side of the trade.
• After an agency cross between customers, it is suggested that a broker/dealer report a cross (X). If not, the agency cross must be
advertised as a buy (B) and a sell (S) or as traded (T).
• After trading as riskless principal, a broker/dealer must report similar to the rules for agency trading.
• There must have been a change in ownership (no internal transfers) to report a trade.
• A broker/dealer must not report dividend capture/wash or “bed and breakfast” trades.
• A broker/dealer must not report clearing-only trades.
• When “giving up” to another broker, a broker/dealer must report only the market side of the trade, the pass-through agent in the
transaction is not eligible to advertise.
• A broker/dealer must not report trading activity from a primary offering (distribution).
• A broker/dealer can report the trading activity from a secondary distribution.
• After trading as risk principal, (a purchase or sale vs ones principal account often referred to as a principal cross) a broker/dealer must
report the transaction as traded undisclosed side (T), or the principal side of the transaction (B or S).
ADVERTISED TRADE MESSAGE ELECTIONS
Message Elections give you the ability to select whether or not you want to send or receive Advertised Trade messages. When your session is
configured it will automatically defer to the default method for your client type (Broker or Institution) unless requested otherwise. Although
Send and Receive is the Broker default, it is usually set to just Send unless requested for both.
The following table defines the clients and their associated election types, along with the default election.
CLIENT TYPE
ELECTIONS
DEFAULT
Broker
Send and Receive
Receive
Do not send or receive
Send and Receive
Institution
Receive
Do not receive
Receive
Page 41
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
ADVERTISED TRADE MESSAGE FILTERS
You have the option to filter Advertised Trade messages based on share volume and from whom you want to receive them from.
The following table describes each of the filters in detail. When your session is configured it will automatically defer to the default method
unless requested otherwise.
FILTER
DESCRIPTION
DEFAULT
ECNs
ON = receive all messages from ECNs.
OFF = do not receive any message from ECNs.
ON
Broker
Include or exclude specific brokers.
You can choose to receive all IOI messages from all brokers or you can filter by
including only a certain set of specific brokers from whom you want to receive
IOI messages from.
Receive messages from all brokers,
including messages you have sent out.
Volume
Indicate a share threshold volume under which no messages will be received.
For example, if 25,000 is indicated, only messages indicating a value of
25,000 or above will be received.
Notes:
Value must be in increments of 5,000, for example 4,200 is not allowed.
Default volume is 10,000.
Minimum accepted value = 5,000 and the maximum accepted value =
100,000.
Receive all messages with a minimum
per share volume of 10,000.
SECURITY SYMBOL AND IDENTIFIER PREFERENCES
Autex provides the flexibility for you to set a symbol and security identifier preference when receiving FIX Advertised Trade messages.
Despite the values used by the message originator, Autex can translate what was sent to conform to your chosen preferences. There are two
preferences that can be configured:
• Symbol Preference in the Symbol tag (55)
• SecurityID Preference in the SecurityID tag (48)
Symbol Preference
As the message recipient, you have the option to have the symbol value received in tag 55 as the following:
• Datascope Symbol: Tag 55 is passed with the Datascope symbol value no matter what the message originator sent inbound to Autex.
Note: This is the default symbol preference.
• Original Value: Tag 55 is passed without translation and is same value that was received from the message originator inbound to Autex.
SecurityID Preference
As the message recipient, you also have the option to have the value received in tags 22/48 (SecurityIDSource/SecurityID) as the following:
• No Preference: Tags 22/48 are passed without translation and is same value that was received from the message originator if populated
inbound to Autex. Note: This is the default SecurityID preference.
• Converted to ISIN
• Converted to CUSIP
• Converted to SEDOL
• Converted to RIC
Note: In the event that Autex cannot translate a value to your specified SecurityID preference, tags 22/48 may not be populated when
receiving the message.
Page 42
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
SYMBOL/SECURITYID PREFERENCE EXAMPLES
Example 1:
Tag
Inbound Value to Autex
Recipient Symbol/SecurityID
Preference
Outbound Value from Autex to
Message Recipient
55 (Symbol)
IBM
Datascope Symbol
IBM
22 (SecurityIDSource)
N/A
4 = ISIN
4
48 (SecurityID)
N/A
ISIN
US4592001014
Tag
Inbound Value to Autex
Recipient Symbol/SecurityID
Preference
Outbound Value from Autex to
Message Recipient
55 (Symbol)
IBM.N
Original Value
IBM.N
22 (SecurityIDSource)
5 = RIC
1 = CUSIP
1
48 (SecurityID)
IBM.N
CUSIP
459200101
Example 2:
Page 43
AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE
Visit financial.tr.com
For more information, contact your representative or visit us online.
© 2016 Thomson Reuters. S034385 05/16.