autex fix 4.2 ioi and advertised trade guide - reuters€¦ · data format/length column ... them...

AUTEX FIX 4.2 IOI AND ADVERTISED TRADE GUIDE

REUTERS/Jorge Silva


Page 2

ContentsCHAPTER 1 INTRODUCTION ............................................3Features and Benefits ..........................................................................3

Service Support ....................................................................................3

CHAPTER 2 AUTEX CLIENT PORTAL ............................... 4

CHAPTER 3 APPLICATION AND NETWORKING REQUIREMENTS ..................................... 6Application Requirements ...................................................................6

Networking Requirements ..................................................................6

CHAPTER 4 END OF DAY PROCESSING AND CONNECTING ...........................................................7Connecting to the Network .................................................................7

CHAPTER 5 SUBSCRIBER ID’S AND FIX COMPID’S ........ 8Subscriber IDs ..................................................................................... 8

FIX CompIDs........................................................................................ 8

FIX CompID Naming Conventions ..................................................... 8

Group and Endpoint Acronyms .......................................................... 8

CHAPTER 6 MESSAGE REJECTS ..................................... 9Reject Messages...................................................................................9

Reject Message Types by Failure Reason ...........................................9

FIX 4.2 Business Reject Message ...................................................... 10

CHAPTER 7 GLOBAL SYMBOLOGY..................................11Understanding the Supported Security Identifier Methods ............. 11

Security Identification Tag Validation Process ................................... 11

CHAPTER 8 AUTEX BUSINESS RULES FOR FIX MESSAGES ....................................................... 13Supported Application Message Types ............................................ 13

FIX Protocol Documents .................................................................... 13

Addressing Messages ........................................................................ 13

ID Processing ...................................................................................... 13

FIX Message Grid Guidelines ............................................................ 13

Tag Number Column: Repeating Groups Arrow Indicator .............. 13

Required Column ............................................................................... 13

Data Format/Length Column ........................................................... 14

Description Column ........................................................................... 15

Validations Column ............................................................................ 15

CHAPTER 9 ADDRESSING ............................................. 16Addressing IOI Messages .................................................................. 16

Addressing Values.............................................................................. 16

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

Consolidated Feed .............................................................................23

CHAPTER 10 FIX MESSAGE HEADER AND TRAILER .... 24FIX Message Standard Header Fields ............................................. 24

FIX Message Standard Trailer Fields ............................................... 26

CHAPTER 11 ADMINISTRATIVE FIX MESSAGES .............27Possible Duplicate Messages ............................................................27

Possible Resend Messages............................................................... 28

Logon Message ................................................................................. 28

CHAPTER 12 INDICATION OF INTEREST (IOI) MESSAGES ............................................................ 29IOI Message Categories .................................................................... 29

IOI FIX Message ................................................................................ 30

Actionable IOIs .................................................................................. 35

Pegged IOIs ....................................................................................... 35

IOI Expiration ..................................................................................... 35

IOI Message Elections ....................................................................... 36

IOI Message Filters ............................................................................ 36

Security Symbol and Identifier Preferences..................................... 36

CHAPTER 13 ADVERTISED TRADE MESSAGES ............. 38Advertised Trade FIX Message ......................................................... 38

As of Trades ........................................................................................ 41

Advertised Trade Guidelines .............................................................. 41

Advertised Trade Message Elections ................................................ 41

Advertised Trade Message Filters .................................................... 42

Security Symbol and Identifier Preferences..................................... 42


Chapter 1 IntroductionWELCOME 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 BENEFITSAutex utilizes a unified global system which contains a host of features essential to your messaging needs, as follows:

Indication of Interest and Advertised Trade SupportedAutex 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 IOIsActionable IOIs are supported for venues configured accordingly to send/receive values specified in the applicable tag indicating that the IOI is actionable.

Pegged IOIsSend/receive IOIs pegged to the Market or Midpoint with an optional offset specified to receiving venues who have configured to handle them accordingly.

Global SymbologyAll of the following symbol types and values are supported: CUSIP ISIN RIC Code SEDOL Symbol Exchange Code

Message ElectionsSelect your own configuration for sending and/or receiving IOI and Advertised Trade messages.

Message FiltersSelect only the messages that you want to see based on configurable parameters for both IOI and Advertised Trade messages.

Flexible Message AddressingBroad 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 SUPPORTShould 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 GLOBAL EMAIL ADDRESS

International +1-801-212-9451

[email protected] +81 3 6441 1063

Europe / UK +44 (0) 870 1910 561

Americas 800 232 8839

mailto:autexsupport%40thomsonreuters.com?subject=


Page 4

Chapter 2 Autex Client PortalThe 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 OVERVIEWThere 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. Clients based on identifier, e.g. Subscriber (client name), Acronym (FIX CompID), SubID, etc.2. Clients based on user type and geographic Location3. Recent Updates to the client directory based on specified timeframes.

Downloads The Downloads tab enables you to obtain instructions for downloading client directory files via FTP.

https://portal.autex.com


Navigate To: Downloads

Navigate To: Client Directory


Page 6

Chapter 3 Application and Networking RequirementsAPPLICATION REQUIREMENTSAny 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 REQUIREMENTSIn 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 ConnectivityA 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.


Chapter 4 End of Day Processing and ConnectingFor 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 NETWORKIt 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 8

Chapter 5 Subscriber ID’s and Fix CompID’sSUBSCRIBER IDSEvery 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 COMPIDSBefore 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 CONVENTIONSThe 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 ACRONYMSIn 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.


Chapter 6 Message RejectsREJECT MESSAGESReject 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 REASONThe following table outlines common reasons for rejecting either an IOI or Advertised Trade message.

FAILURE REASON DESCRIPTION IOI ADVERTISED TRADE

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

Invalid On Behalf Of 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


Page 10

FIX 4.2 BUSINESS REJECT MESSAGEThe 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

Req’d Description Validations

<Standard Header> Y MsgType (35) = j (lowercase). For details see: Standard Header

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 ID2 = Unknown security3 = Unsupported

message type4 = Application not available5 = Conditionally required field

missing

58 Text ST N Free format string. Use to explain reason for reject.

When possible Autex will populate with the failure reason in most instances.

354 EncodedTextLen N Not Sent

355 EncodedText N Not Sent

<StandardTrailer> Y For details see: Standard Trailer


Chapter 7 Global SymbologySymbol 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 METHODSWhen 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 PROCESSThere 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 12

AUTEX VALIDATION PROCESS FOR IOI AND ADVERTISED TRADE MESSAGES

CASE 22 48 55 207 207 ACCEPT AND APPLY

APPLY TO PRIMARY LISTING

REJECT

1 V V I I u

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 NM V I u

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 NM NM I u

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 D I V u

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 D NM NM u

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 D V NM u

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 I V I u

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.

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


Chapter 8 Autex Business Rules for FIX MessagesSUPPORTED APPLICATION MESSAGE TYPESIn 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 DOCUMENTSThe 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 MESSAGESAutex 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 PROCESSINGWhen 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 GUIDELINESAutex’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 INDICATORA 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 COLUMNRequired 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 14

DATA FORMAT/LENGTH COLUMNThe 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 • Date value in the following format: YYYYMMDD

• Accepted values: YYYY = 0000-9999 MM = 01-12 DD = 01-31

Float Datatypes:FloatPriceQuantity

Flt Prc Qty

• 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 Also known as UTC Timestamp

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


DESCRIPTION COLUMNThe 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 COLUMNThe 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 16

Chapter 9 AddressingADDRESSING IOI MESSAGESAutex 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 AUTEXA B

Explanation: A – Message sent from Broker to Autex (intended for Recipients) B – Message sent from Autex to Recipients on behalf of Broker

ADDRESSING VALUESAddressing 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.


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 18

ADDRESSING METHODS: BROKER TARGETING ONE OR MORE RECIPIENTSThe 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.

ADDRESSING EXAMPLES: BROKER TARGETING ONE OR MORE RECIPIENTS USING ROUTINGID TAGSExample 1: Broker targeting a single recipient:

TAG TAG NAME VALUES GUIDELINES

RoutingID Tags • First tags in message checked for addressing.

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

215 NoRoutingIDs Number of RoutingType and RoutingID pairs.

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.

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

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.

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

215=1216=1

217=820

Message Recipients:

820


Example 2: Broker sending an IOI to all institutions on the Autex network using the L1 list:

Example 3: Broker sending an IOI to multiple recipients:

Example 4: Broker sending an IOI to all institutions on the Autex network using the L1 list, but blocking 2 specific recipients.

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.

215=1216=2 217=L1

Message Recipients:

All Institutions

215=3216=1

217=821

216=1 217=822

216=1 217=820

Message Recipients:

820 821 822

215=3216=3

217=820

216=3 217=822

216=1 217=L1

Message Recipients:

All Institutions Minus (820) (821)

215=3216=1

217=675

216=3 217=945

216=1 217=L102

Message Recipients:

675 801 802 803 955 980

SubIDs in L102

801 802 803 945 955 980


Page 20

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

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


56 TargetCompID Institution/Receiver FIX CompID

57 TargetSubID Institution/Receiver TargetSubID Tag 57 is populated with the value sent in tag 129 if optionally sent by the Broker/originator.

AUTEX SUBSCRIBERS IN EXAMPLE

Broker FIX CompID XYZBROK

Broker SenderSubID (Optional) BOS

Message Recipient 820 = (SubID of Institution ABCINV)

Institution FIX CompID ABCINV

Note: Tag 57 can also be used in the same manner as tag 128.

ADDRESSING METHODS: RECIPIENT IDENTIFYING IOI OR ADVERTISED TRADE ORIGINATORThe 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 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.


SENT FROM BROKER TO AUTEX TAG VALUES SENT SENT FROM AUTEX TO RECIPIENT TAG VALUES RECEIVED

Message Header

SenderCompID (49) XYZBROK SenderCompID (49) AUTEX

TargetCompID (56) AUTEX TargetCompID (56) ABCINV

OnBehalfOfCompID (115) OnBehalfOfCompID (115) XYZBROK

DeliverToCompID (128) 820 DeliverToCompID (128)

SenderSubID (50) BOS SenderSubID (50) XYZBROK

TargetSubID (57) TargetSubID (57)

OnBehalfOfSubID (116) OnBehalfOfSubID (116) BOS

SENDING AN OUTBOUND MESSAGE


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.

RECEIVING AN INBOUND MESSAGE


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.

SERVICE BUREAU CONNECTIONSA 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.

ON BEHALF OF NETWORKSMembers 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.

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.


Page 22

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

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.

Organization Broker XYZ

On Behalf of Network

Group BXYZ1

Group BXYZ2

Group BXYZ3

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.

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) SenderSubID (50) BXYZ3

OnBehalfOfSubID (116) NY OnBehalfOfSubID (116) NY


CONSOLIDATED FEEDSimilar 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 24

Chapter 10 FIX Message Header and TrailerEvery 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 FIELDSThe 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

Req’dDescription Validations

8 BeginString ST 8

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.

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

35 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


STANDARD HEADER

Tag #



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.


Page 26

STANDARD HEADER

Tag #



122 OrigSendingTime TS N Original time of the message transmission when transmitting messages as a result of a Resend Request.

212 XmlDataLen N Dropped

213 XmlData N Dropped

347 MessageEncoding N Dropped

369 LastMsgSeqNum Processed

Int 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

STANDARD TRAILER

Tag #



89 Signature N Dropped

93 SignatureLength N Dropped

10 CheckSum ST 33

Y Must be the last field in the message. Three-byte simple checksum. Always unencrypted.

Reject if not the last field in the message.

FIX MESSAGE STANDARD TRAILER FIELDSThe 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.


Chapter 11 Administrative Fix MessagesStandard 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 MESSAGESWhen 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 non-receipt 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 MESSAGESIf 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 #



<Standard Header> 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).


Page 28

LOGON MESSAGE

Tag #



â 372

RefMsgType ST 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.

â 385

MsgDirection CH 1

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.

<StandardTrailer> Y For details see: Standard Header


Chapter 12 Indication of Interest (IOI) MessagesAutex 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 CATEGORIESIndications 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

GENERAL EXAMPLES

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)

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

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.


Page 30

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 DefinitionThe 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).

CitationFinancial 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 MESSAGEThe 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 #



<Standard Header> Y MsgType (35) = 6 For details see: Standard Header

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.


IOI MESSAGE

Tag #



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


Page 32

IOI MESSAGE

Tag #



106 Issuer N ST 250

Company name of the security issuer. Value greater than 250 characters is truncated when passed.

Value greater than 250 characters is truncated.

348 EncodedIssuerLen N Dropped

349 EncodedIssuer N Dropped

107 SecurityDesc N ST 250

Security description Value greater than 250 characters is truncated when passed.


350 EncodedSecurity-DescLen

N Dropped

351 EncodedSecurityDesc N Dropped

54 Side Y CH 1

Side of order Valid values: 1 = Buy 2 = Sell 7 = Undisclosed


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


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.

Reject if not in uppercase alphabetic characters.

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



IOI MESSAGE

Tag #



130 IOINaturalFlag N 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


199 NoIOIQualifiers N ST 2

Number of repeating groups of IOIQualifiers (104). Valid values: 1-30.


â 104

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 noneB = Market on close (MOC) C = At the closeD = VWAP (Volume Weighted Avg Price)E = Client NaturalF= House NaturalG = Position Wanted H = Customer Order in HandI = In touch with J = Customer Firm CommitmentL = LimitM = More behind N = Certified NaturalO = At the openP = Taking a positionQ = At the Market (previously called Current Quote)R = Ready to trade S = Portfolio shown T = Through the day U = UnwindV = VersusW = Indication – Working away X = Crossing opportunityY = 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 34

IOI MESSAGE

Tag #



149 URLLink N ST 250

URL link to additional information. Value greater than 250 characters is truncated when passed.


215 NoRoutingIDs N Int Number of repeating groups of RoutingType (216) and RoutingID (217) values. Valid values: 1-500. Related topic: Addressing


â 216

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

11001 IOIType 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

<Standard Header> Y For details see: Standard Trailer


Custom TagsCustom 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 IOISUse 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 IOISPegged 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 EXPIRATIONAt 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.

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.

BUSINESS REGION EXPIRE TIME

Americas 01:00 GMT

Asia Pacific 15:00 GMT

EMEA 19:00 GMT


Page 36

IOI MESSAGE ELECTIONSMessage 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.

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

CLIENT TYPE ELECTIONS CHOOSE DEFAULTBroker / 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

Institution Receive IOIs Y N Receive IOIs Y

FILTER TYPE DESCRIPTION DEFAULTECNs 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 PREFERENCESAutex 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 PreferenceAs 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.


SecurityID PreferenceAs 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 EXAMPLESExample 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

Example 2:



55 (Symbol) IBM.N Original Value IBM.N

22 (SecurityIDSource) 5 = RIC 1 = CUSIP 1

48 (SecurityID) IBM.N CUSIP 459200101


Page 38

Chapter 13 Advertised Trade MessagesAdvertised 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 MESSAGEThe 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 #



<Standard Header> Y MsgType (35) = 7 For details see: Standard Header

2 AdvID ST 30

Y Unique identifier of the advertisement message. Identifier must be unique for at least 7 calendar days.

Reject if a duplicate ID has been sent prior to original expiring.

5 AdvTransType CH 1

Y Identifies advertisement message 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.

Reject if an invalid value

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

Reject if no value and AdvTransType (5) = C or R.

Reject if value is not found or no longer active.

55 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



Tag #



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


Page 40


Tag #



107 SecurityDesc ST 250

N Security description Value greater than 250 characters is truncated when passed.


350 EncodedSecurity-DescLen

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


53 Shares Qty 13

Y Overall total quantity (e.g. number of shares). Valid values: 0-9999999999999


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. All contents in field are passed.

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.

<Standard Trailer> Y For details see: Standard Trailer


Custom TagsCustom 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 TRADESAutex 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 GUIDELINESThe 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 ELECTIONSMessage 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 DEFAULTBroker Send and Receive

Receive Do not send or receive

Send and Receive

Institution Receive Do not receive

Receive


Page 42

ADVERTISED TRADE MESSAGE FILTERSYou 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.

SECURITY SYMBOL AND IDENTIFIER PREFERENCESAutex 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 PreferenceAs 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 PreferenceAs 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.

FILTER DESCRIPTION DEFAULTECNs 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.


SYMBOL/SECURITYID PREFERENCE EXAMPLESExample 1:



55 (Symbol) IBM Datascope Symbol IBM

22 (SecurityIDSource) N/A 4 = ISIN 4

48 (SecurityID) N/A ISIN US4592001014

Example 2:



55 (Symbol) IBM.N Original Value IBM.N

22 (SecurityIDSource) 5 = RIC 1 = CUSIP 1

48 (SecurityID) IBM.N CUSIP 459200101


Visit financial.tr.com

For more information, contact your representative or visit us online.

© 2016 Thomson Reuters. S034385 05/16.