Financial Information Exchange Protocol

Version: 3.0
Date: September 27, 1995

Table of Contents

• Financial Information Exchange Protocol
  • Table of Contents
  • DISCLAIMER
  • Preface
  • Release Notes
  • Introduction
  • Session Protocol
    • 1. Connection, Authentication and Initialization
    • 2. Message Exchange
      • General Message Format and Content
      • Data Types
        • int
        • float
        • char
        • data
      • Sequence Numbers
      • Heartbeats
      • Possible Duplicates
      • Possible Resends
      • Data Integrity
      • Required Fields
      • Encryption
      • User Defined Fields
    • 3. Logout
    • Message Header
    • Message Trailer
  • Administrative Messages
    • Heartbeat
    • Logon
    • Test Request
    • Resend Request
    • Reject
    • Sequence Reset
    • Logout
  • Application Messages
    • Advertisements
    • Indications of Interest
    • News
    • Email
    • New Order - Single
    • Execution Reports
    • Order Cancel/Replace Request
    • Order Cancel Request
    • Order Cancel Reject
    • Order Status Request
    • Allocation
    • Allocation ACK
    • New Order - List
    • List Status
    • List Execute
    • List Cancel Request
    • List Status Request
  • Appendix A
    • Valid Currency Codes
      • Codes A–F
      • Codes G–L
      • Codes M–R
      • Codes S–Z
  • Appendix B
    • CheckSum Calculation
  • Appendix C
    • Reuters Exchange Mnemonics
      • Exchanges A–L
      • Exchanges M–Z
  • Appendix D
    • Order State Change Matrices
      • Filled Order
      • Partially Filled Order
      • Cancelled Order
      • Replaced Order

Back to top ↑

DISCLAIMER

THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER.

NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES.

No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein).

Back to top ↑

Preface

In mid-1992 Fidelity Management and Research Company and Salomon Brothers Inc began work on a project to link the two firms' trading systems for the purpose of automating the exchange equity-related indication and execution messages. Fidelity had determined that it could help its traders become more effective by automating portions of their broker communication and thus reduce the time spent on the phone placing routine orders and recording fills. Salomon's motivation was the desire to leverage its investment in technology into increased service for its clients. The initial system link was brought up in early 1993 and has been in production each trading day since.

At the onset of the effort it was recognized that the success of the linkage would be determined by the two firms' ability to develop a workable set of messages and protocols to be used for the information exchange. The firms decided that the effort would be most successful if other buy- and sell-side representatives were involved in the specification discussions. Throughout 1993 a group of large financial firms met regularly to refine the specification and to share their experiences in its implementation. The group felt it necessary to limit participation in the effort until the concept had been proven in production and the rate of requests for modification to the protocol had slowed to the point which indicated it had stabilized. By early 1994 the majority of the committee members had implemented the protocol and felt that the stabilization requirement for general release had been satisfied.

The Financial Information Exchange Protocol is the result of these efforts. It is offered to the financial community as a starting point towards the establishment of a standard for broker/institution communication.

Feedback on this protocol, including comments on existing content and suggestions for additional message types, is requested. Feedback should directed to me at Salomon. My phone number in New Jersey is (201) 896-7789.

Christopher Morstatt
Vice President
Salomon Brothers Inc
July, 1994

Back to top ↑

Release Notes

Attached is the latest FIX Protocol specification (Version 3.0) which addresses the changes requested since the publication of Version 2.7 on July 15, 1994.

Changes in this release include:

1. Corrected Checksum calculation in Appendix B (reflected in interim release 2.7a).

2. BodyLength(9) field description modified to remove the words “and including” (reflected in interim release 2.7a).

3. Various typographic and grammar error corrections (reflected in interim release 2.7a).

4. Defined new field, IOIQualifier(104), and included in IOI message as optional.

5. Revised Execution message removing ‘OrdStat = New’ conditional requirement from the LastShares(32), LastPx(31), CumQty(14) and AvgPx(6) fields.

6. New field, WaveNo(105), defined and added to Order-List, List Cancel Request, List Execute, List Status Request, List Status and Allocation messages as optional.

7. Description of User Defined Fields added to Message Exchange section of the Session Protocol.

8. Removed range restrictions from all price fields and updated float data type description.

9. Added additional enumerations to the IDSource(22) field.

10. Defined new fields Issuer(106) and SecurityDesc(107) and added, as optional, to all messages containing the Symbol(55) field to aid in security identification.

11. Defined new field ClientID(109) and added it and ExecBroker(76) to the Order-Single, Execution, Cancel Request, Cancel/Replace Request, Cancel Reject, Status Request, Allocation and Allocation Ack messages to aid in firm identification in third-party transactions.

12. Defined new field HeartBtInv(108) and added to the Logon message as mandatory.

13. ExecInst(18) field use changed from repeating tag-value occurances to space delimited strings.

14. Removed DOT/manual only restrictions from ExecInst(18).

15. Clarified need to redeclare all ExecInst(18) when issuing Cancel/Replace requests.

16. Added new enumeration P (pegged) to OrdType(40) field. Pegged orders require and ExecInst(18) = L, R, M, P or O.

17. Enumerations for the ExecInst(18) expanded to include:

    • L = Last peg
    • R = Primary peg
    • M = Mid-price peg
    • P = Market peg
    • O = Opening peg
    • I = Institutions only
    • N = Non-negotiable
    • S = Suspend

18. OrdStatus(39) enumerations expanded to include 9 = Suspended and A= Pending New. Descriptions of the use of these values were added to the Execution description section.

19. Defined new fields, MinQty(110) and MaxFloor(111), which were added to the Order-Single, Cancel/Replace Request and Order-List messages as optional.

20. Clarified the use of the delimiter character in the General Message Format section.

21. The date and time field descriptions were updated to indicate that all values should be expressed in GMT.

22. The Side(54) field description was modified to remove the Traded and Crossed enumerations.

23. The ExDestination(100) and LastMkt(30) field descriptions were modified to correspond to the Reuters exchange mnemonics. (Appendix C was added which lists the valid values.) removed Instinet as an eligible ExDestination.

24. The HandlInst(21) field description was modified to change the “DOT” reference to “Automated Execution”.

25. Order identification in the Cancel Request, Cancel/Replace Request and Cancel Reject messages was modified for clarity. Specifically the CxlReqOrdId(101) field was removed from the Cancel Request and Cancel Reject messages and the OrigClOrdID(41) field added. The use of the OrigClOrdID(41) and ClOrdID(11) fields in the Cancel Request and Cancel Reject messages was modified for consistency with the Cancel/Replace message.

26. Removed any restriction on which party should initiate and accept connections in the Session Protocol section.

27. Expanded the number of fields eligible for modification through the Cancel/Replace Request message.

28. Modified the message header to allow encryption of the SenderSubID(50) and TargetSubID(57) fields.

29. Various typographic and grammar error corrections.

Back to top ↑

Introduction

The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic exchange of information related to securities transactions. It is intended for use between brokers and institutions wishing to automate communications.

The message protocol, as defined, will support the following electronic conversations:

• Equity order submissions, cancellations and replacements
• Equity execution reporting
• Equity order statusing
• Equity trade allocation
• Indication of interest communication
• Completed trade advertisements
• Directed email and news messaging

The FIX protocol is defined at two levels; session and application. The session level is concerned with the delivery of data while the application level defines business related data content. This protocol is independent of the telecommunications protocol (X.25, asynch, internet, etc.) and medium chosen for electronic data delivery.

Back to top ↑

Session Protocol

Each connection between an institution and broker will be defined as a session. The Financial Information Exchange session consists of three parts:

• Connection, authentication and initialization
• Message exchange
• Logout

The following section describes each of these parts.

1. Connection, Authentication and Initialization

Establishing a communication session involves three distinct operations: creation of a telecommunications level link, authentication of the originating party by the accepting party and message synchronization (initialization). The connection sequence should contain the following steps:

• Authenticate as a valid user by submitting the Logon message which contains the login name and password as agreed upon between the parties.

• After validation, the broker's system will start the initialization process which will:

  • forward all queued outgoing messages awaiting transmission,
  • issue a test request message, and,
  • if the response to the test request is other than expected, issue a resend request for any untransmitted incoming messages.

2. Message Exchange

After completion of the initialization process, normal message exchange begins. The formats for all valid messages are detailed in the sections 'Administrative Messages' and 'Application Messages'.

General Message Format and Content

The general format of a message is a standard message header followed by message body data and a standard trailer.

The Financial Information Exchange session protocol is based on an optimistic model; normal delivery of data is assumed (i.e. no acknowledgment of individual messages) with errors in delivery identified by message sequence number gaps. Each message (except certain of the administrative messages) is identified by a unique sequence number. It is the receiving application's responsibility to monitor incoming sequence numbers to identify gaps for response with resend request messages.

Each message is defined in a <tag>=<value> format. Except where noted, fields within a message can be defined in any sequence (i.e. relative position of a field within a record is inconsequential except where explicitly defined otherwise).

All fields in a FIX message are terminated by a delimiter character; the non-printing, ASCII "SOH" (#001), is used for this purpose. Note that records are delimited by the “SOH” character following the CheckSum field. All records begin with the “8=FIX.x.y” string and terminate with “10=nnn<SOH>“.

There shall be no imbedded delimiter characters within fields except for type data.

Data Types

Data types are mapped to ASCII strings as follows:

int

Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999").

Examples:

• 723 in field 21 would be mapped int as |21=723|.
• -723 in field 12 would be mapped int as |12=-723|

float

Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits.

char

Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. morstatt ≠ Morstatt).

data

Raw data with no format or content restrictions. Data fields are always preceded by a length field. Caution: may contain the delimiter (SOH) character.

Sequence Numbers

All messages are identified by unique sequence number, except certain administrative messages. Sequence numbers are re-initialized each day starting at 1 (one) and increment throughout the day. In the event of a connection failure, the sequence numbers are used to resynchronize the applications. Each connection will establish an independent incoming and outgoing sequence series; participants will maintain a sequence series to assign to outgoing messages and a series to monitor for sequence gaps on incoming messages.

Heartbeats

When message traffic is light the sending application will generate heartbeat messages at regular time intervals. The heartbeat will contain the next sequence number to be transmitted. The heartbeat is useful for identifying when the last of a string of messages are lost and for monitoring the status of the communication link.

When message traffic is light the sending application will generate heartbeat messages at regular time intervals. The heartbeat will contain the next sequence number to be transmitted. The heartbeat is useful for identifying when the last of a string of messages are lost and for monitoring the status of the communication link. The heartbeat interval is declared by the session originator using the HeartBtInt field in the Logon message. The heartbeat interval timer should be reset after every message is transmitted (not just heartbeats).

Possible Duplicates

In certain circumstances the sending application may be unsure if a message was successfully transmitted to its destination. In such cases a poss dupe message will be generated. The poss dupe will be a resend (with the same sequence number) of the data in question with the PossDupFlag included and set to "Y" in the header. It is the receiving application's responsibility to handle the poss dupe message (i.e. treat as a new message or discard as appropriate). All messages created as the result of a resend request will contain the PossDupFlag field, messages lacking the PossDupFlag field are original transmissions. The PossDup flag is used only to identify the resend of messages with a previously recorded sequence number.

Possible Resends

Application level messages which appear to the end-user to be in an ambiguous state may be resent with the PossResend flag set. An example of when this is useful is the case where an order remains unacknowledged for an inordinate length of time and the end-user suspects it had never been sent. The receiving application must recognize this flag and interrogate internal fields (order number, etc.) to determine if this order has been previously received.

Data Integrity

Integrity of message data content can be verified in two ways; verification of record length and a simple checksum of characters. The record length is indicated in the BodyLength field and can be verified by counting the number of characters in the message following the BodyLength field up to, and including, the delimiter immediately preceding the CheckSum tag (“10=”). An additional integrity check is to sum the binary value of each character from the “8” of “8=“ up to and included the <SOH> character immediately preceding the CheckSum tag field and comparing the least significant eight bits of the calculated value to the CheckSum value (see Appendix B for a complete description).

Required Fields

Each message within the protocol is comprised of required, non-required and conditionally required (fields which are required only when other fields are present) fields. Systems should be written to operate when only the required and conditionally required fields are present.

Encryption

The exchange of sensitive data across public carrier networks may make it advisable to employ data encryption techniques to mask the application messages.

The choice of encryption method will be determined by mutual agreement between the broker and institution.

Except where explicitly stated any field within a message can be encrypted and included in the SecureData field.

Imbedded in the protocol are fields which enable the implementation of a public key signature and encryption methodology, straight DES encryption and clear text. The choice of encryption methodology will be defined in the LOGON message.

User Defined Fields

In order to provide maximum flexibility for its users, the FIX protocol accommodates User Defined Fields. These fields are intended to be implemented between consenting trading partners and should be used with caution to avoid conflicts which will arise as multiple parties begin implementation of the protocol. It is suggested that if trading partners find that particular User Defined Fields add value, they should be recommended to the FIX Protocol Committee for inclusion in a future FIX version.

The tag numbers 9000 to 9999 have been reserved for use with user defined fields.

3. Logout

Normal termination of the message exchange session will be initiated by the customer via the submission of the LOGOUT message. Termination by other means will be considered an abnormal condition. Note that the process of logging out does not affect the state of any orders placed on the broker’s system, all active orders will continue to execute.

Message Header

Each message, administrative or application, is preceded by a standard header. The header is used to identify the message type, length, destination, sequence number, origination point and time.

Two fields are provided for use when resending messages. The PossDupFlag is set when resending a message as the result of a session level event (i.e. the retransmission of a message using reusing a sequence number). The PossResend is set when reissuing a message with a new sequence number (e.g. resending an order). The receiving application should process these messages as follows:

• PossDup—if a message with this sequence number has been previously received, ignore message, if not, process normally.
• PossResend—forward message to application and determine if previously received (i.e. verify order id and parameters)

Message Trailer

Each message, administrative or application, is terminated by a standard trailer. The trailer is used to segregate messages and contains the three digit character representation of the Checksum value.

Back to top ↑

Administrative Messages

The administrative class of messages are intended to address the utility needs of the protocol. The following section describes the use of each message and provides the message layout.

Administrative messages will be generated from both the broker and institution side of the connection.

Heartbeat

The Heartbeat is useful for identifying when the last of a string of messages are lost and for monitoring the status of the communication link. The Heartbeat will contain the next sequence number to be transmitted.

When either end of a FIX connection has not sent any data for (HeartBtInt) seconds, it will transmit a Heartbeat message. When either end of the connection has not received any data for (HeartBtInt + “some reasonable transmission time”) seconds, it will transmit a Test Request message. If there is still no Heartbeat message received after (HeartBtInt + “some reasonable transmission time”) seconds then the connection should be considered lost and corrective action be initiated. If HeartBtInt is set to zero then no regular heartbeat messages will be generated. Note that a test request message can still be sent independent of the value of the HeartBtInt which will force a Heartbeat message.

Heartbeats issued as the result of Test Request must contain the TestReqID transmitted in the Test Request message. This useful to verify that the Heartbeat is the result of the Test Request and not as the result of a regular timeout.

The standard message header is utilized for heartbeats with following provisions:

• The sequence number field contains the next message sequence number to be transmitted
• The sequence number is NOT incremented for heartbeats

Logon

The logon message is utilized to authenticate a user attempting to establish a connection to a remote system. The logon message must be the first message sent by the connecting application.

The HeartBtInt (108) field is used to declare the timeout interval for generating heartbeats.

The sequence number field is not incremented for a Logon message, thus the sequence number contained in the message should be used for resynchronization purposes on restarts. It is always necessary to complete the Test Request - Heartbeat initialization sequence to guarantee proper resynchronization.

Logon messages are NEVER retransmitted as the result of a resend request.

Test Request

The test request message is utilized to force a heartbeat from the opposing application. The test request message is useful for checking sequence numbers or verifying the communication line status. The opposite application will respond to the Test Request with a Heartbeat.

The TestReqID is used to verify that the oppposite application is generating the heartbeat as the result of Test Request and not a normal timeout. The opposite application will include the TestReqID in the resulting Heartbeat. Any string can be used as the TestReqID (one suggestion is to use a timestamp string).

Sequence numbers are not incremented for test request messages.

Resend Request

The resend request is sent by the receiving application to initiate the retransmission of messages. This function is utilized if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process. Sequence numbers are not incremented for resend request messages.

The resend request can be used to request a single message, a range of messages or all messages subsequent to a particular message.

Note: the sending application may wish to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has elapsed since its original inception, the sender may not wish to retransmit the order given the potential for changed market conditions. (The Sequence Resend message is used to skip messages that a sender does not wish to resend.)

• To request a single message: BeginSeqNo = EndSeqNo
• To request a range of messages: BeginSeqNo = first message of range, EndSeqNo = last message of range
• To request all messages subsequent to a particular message: BeginSeqNo = first message of range, EndSeqNo = 99999

Reject

The reject message will be issued when a message is received which cannot be parsed or contains invalid information (i.e. fails one of the validation tests). Where possible the cause of the failure will be described in the Text field.

Sequence Reset

The sequence reset message is used to reestablish the incoming sequence number on the opposing side. In the event of an application failure it may be necessary to resync sequence numbers on the sending and receiving sides.

The sending application will initiate the sequence reset. The message is used to reset the value of the last sequence number sent (which on the receiving side will reset the value of the next expected sequence number).

It is assumed that the purpose of the sequence reset message is to recover from an out-of-sequence condition, therefore, the MsgSeqNum in the header should be ignored (i.e. the receipt of a sequence reset message with an out of sequence MsgSeqNum should not generate resend requests).

The sequence reset can only increase the sequence number; if a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected.

Logout

The logout message is to used to terminate the session. Disconnection without the sending of a logout message should be interpreted as an abnormal condition.

Back to top ↑

Application Messages

The exchange of business information is accomplished through the passing of application messages. The application message is composed of the standard header followed by the message body and trailer.

Descriptions and formats of the specific messages follow.

Advertisements

Advertisement messages are used to announce completed transactions. The advertisement message can be transmitted in various transaction types; NEW, CANCEL and REPLACE. All message types other than NEW modify the state of the message AdvRefID.

Indications of Interest

Indication of interest messages are used to market merchandise which the broker is buying or selling in either a proprietary or agency capacity. The indications can be time bound with a specific expiration value. Indications are distributed with the understanding that other firms may react to the message first and that the merchandise may no longer be available due to prior trade.

Indication messages can be transmitted in various transaction types; NEW, CANCEL, and REPLACE. All message types other than NEW modify the state of the message identified in IOIRefID.

News

The news message is intended for use as a general free format message between the broker and institution. The message contains flags to identify the news item's urgency and to allow sorting by subject company (symbol). The News record can be originated at either the broker or institution side.

Email

Format and purpose similar to News message, however, intended for private use between two parties.

New Order - Single

The new order message type is used by institutions wishing to electronically submit orders to a broker for execution.

Orders can be submitted with special handling instructions and execution instructions. Handling instructions refer to how the broker should handle the order on its trading floor (see HandInst field). Execution instructions contain explicit directions as to how the order should be executed (see ExecInst field).

New Order messages received with the PossResend flag set in the header should be validated by ClOrdID and order parameters (side, symbol, quantity) to determine if the order had been previously submitted. PossResends previously received should be acknowledged back to the client via an Execution - Status message. PossResends not previously received should be processed as a new order and acknowledged via an Execution - New message.

Execution Reports

The execution report message is used to:

1. confirm the receipt of an order
2. confirm changes to an existing order (i.e. accept cancel and replace requests)
3. relay order status information
4. relay fill information as orders are worked
5. reject orders

NOTE: Execution reports do not replace the end-of-day confirm. Execution reports are to be regarded only as replacements for the existing fill messages currently communicated via telephone.

Each execution message will contain information that will describe the current state of the order and execution status as understood by the broker.

Execution report messages can be transmitted as transaction types (ExecTranType) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID. Transaction type STATUS indicates that the execution message contains no new information, only summary information regarding order status.

• The NEW transaction type indicates that this message represents a new order, a change in status of the order, or a new fill against an existing order. The combination of the ExecTransType and OrdStatus fields will indicate how the message is to be applied to an order.
• The CANCEL transaction type applies at the execution level. The Cancel transaction will be used to cancel an execution which has been reported in error. The cancelled execution will be identified in the ExecRefID field.
• The CORRECT transaction type applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in the ExecRefID field. Note: Data reported in the CumQty and AvgPx fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.

The OrdStatus field is used to identify the status of the current order. The order statuses are as follows:

NOTE: The canceled and replaced order status is set in response to accepted cancel and replace requests. These requests are only acted upon when there is an outstanding order quantity. Requests to replace OrderQty to a level less than the LeavesQty will be rejected (OrderQty = CumQty + LeavesQty). Requests to change price on a filled order will be rejected (see Order Cancel Reject message type).

The CumQty and AvgPx fields should be calculated to reflect the fills on all versions of an order. For example, if partially filled order A were replaced by order B, the CumQty and AvgPx on order B’s fills should represent the fills on order A plus those on order B.

The field ClOrdID is provided for institutions to affix an identification number to an order to coincide with internal systems. The OrderId field is populated with the broker-generated order number.

Order Cancel/Replace Request

The order cancel/replace request is used to change the parameters of an existing order.

Do not use this message to cancel the remaining quantity of an outstanding order, use the Cancel Request message for this purpose.

The request will only be accepted if the order can successfully be pulled back from the exchange floor without executing. Cancel/Replace requests which cannot be processed will be rejected using the Cancel Reject message; the ClOrdId of the replacement order is inserted in the ClOrdId field of the Cancel Reject message for identification.

Only a limited number of fields can be changed via the cancel/replace request message. All other fields should be retransmitted as sent in the original order. These fields are:

• ExecInst
• OrderQty
• OrdType
• Price
• HandlInst
• TimeInForce
• MinQty
• MaxFloor

When modifying ExecInst fields in a replacement order, it is necessary to redeclare all ExecInst in the replacement order. ExecInst’s will not be carried forward from the original order to the replacement unless redeclared.

Order Cancel Request

The order cancel request message is used to request the cancellation of all remaining quantity of an existing order.

Do not use this message to reduce the quantity of (i.e. partially cancel) an outstanding order, use the Cancel/Replace Request for this purpose.

The request will only be accepted if the order can successfully be pulled back from the exchange floor without executing.

Note that a cancel request is assigned an order id and is treated as a separate entity. If rejected, the order id of the cancel request will be sent in the Cancel Reject message. The OrderID assigned to the cancel request must be unique from the OrderID’s assigned to regular orders and replacement orders.

Order Cancel Reject

The order cancel reject message is issued by the broker upon receipt of a cancel request or cancel/replace request message which cannot be honored. Requests to change price or decrease quantity are executed only when an outstanding quantity exists; orders which are filled cannot be changed.

When rejecting a Cancel/Replace Request, the ClOrdID of the replacement order in the request message is inserted in the ClOrdID field of the Cancel Reject message for identification.

The execution message will be used to respond to accepted cancel request and cancel/replace request messages.

Order Status Request

The order status request message is used by the institution to generate an order status message back from the broker.

Allocation

The allocation record is used by the institution to instruct the broker on how to allocate executed shares to sub-accounts.

The allocation record contains repeating fields for each sub-account; the repeating fields are shown below in typeface Bold-Italic. The relative position of the repeating fields is important in this record, i.e. each instance of allocation must be in the order shown below.

• The total shares allocated must equal the Shares value which must equal the total executed quantity of the original order.
• The number of instances of allocations is indicated in NoAllocs.
• Multiple orders can be combined for allocation by identifying the number of orders in the NoOrders field and each individual order in the OrderID fields. Combined orders must have the same ticker, trade date, settlement date and side.
• Single orders cannot be combined with list orders for allocation.

Allocation ACK

The allocation ACK record is used by the broker to acknowledge the receipt and status of an allocation record received from the institution.

New Order - List

The new order list message type is used by institutions wishing to electronically submit lists of related orders to a broker for execution.

The New Order List is intended for use in staging lists to be executed by the broker. If the institution wishes to work a list using the broker's execution services the orders should be submitted as individual New Order - Single's.

After staging, the list can be operated on in the following ways:

Executions against orders within the list will not normally be reported as they occur. (If this feature is desired the institution and broker should arrange for this reporting as a custom feature using the Execution message.) Executions against the list will be reported within the List-Status message.

List Status

The list status message is issued as the response to a List Status Request message and indicates the current state of the orders within the list as they exists at the broker's site.

Orders within the list are statused at the summary level. Individual executions are not reported, rather, the current state of the order is reported.

The message contains repeating fields for each order; the repeating fields are shown below in typeface Bold-Italic. The relative position of the repeating fields is important in this record, i.e. each instance of ClOrdID, CumQty, CxlQty and AvgPx must be in the order shown below.

Each list status message will report on only a maximum of 50 orders; if the list contains more than 50 orders multiple status messages will be required.

List Execute

The list execute message type is used by institutions to instruct the broker to begin execution of a previously submitted list.

List Cancel Request

The list cancel request message type is used by institutions wishing to cancel previously submitted lists either before or during execution.

After the list has been staged with the broker, it can be cancelled via the submission of the List Cancel message. If the list has not yet been submitted for execution, the List Cancel message will instruct the broker not to execute it, if the list is being executed, the List Cancel message should trigger the broker's system to generate cancel requests for the remaining quantities of each order within the list. Individual orders within the list can be cancelled via the Order Cancel Request message.

List Status Request

The list status request message type is used by institutions to instruct the broker to generate status messages for a list.

Back to top ↑

Appendix A

Valid Currency Codes

Codes A–F

Codes G–L

Codes M–R

Codes S–Z

Back to top ↑

Appendix B

CheckSum Calculation

The checksum of a FIX message is calculated by summing every byte of the message up to but not including the checksum field itself. This checksum is then transformed into a modulo 256 number for transmission and comparison. The checksum is calculated after all encryption is completed, i.e. the message as transmitted between parties is processed.

For transmission, the checksum must be sent as printable characters, so the checksum is transformed into three ASCII digits.

For example, if the checksum has been calculated to be 274 then the modulo 256 value is 22. This value would be transmitted a |10=022| where "10=" is the tag for the checksum field.

A sample code fragment to generate the checksum field is as follows:

  char *cksum( char *buf, long bufLen )
  
  GenerateCheckSum (int checksum)
  {
    static char tmpBuf[ 4 ];
    long idx;
    unsigned int cks;
  
    for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );
    sprintf( tmpBuf, "%03d", (unsigned int)( cks % 256 ) );
    return( tmpBuf );
  }

Back to top ↑

Appendix C

Reuters Exchange Mnemonics

Exchanges A–L

Exchanges M–Z

Back to top ↑

Appendix D

Order State Change Matrices

The following matrices are included to clarify the sequence of messages and the status of orders involved in the submission and processing of new orders, executions, cancel requests and cancel/replace requests. These state diagrams are presented from the broker’s view. (Note: x refers to the original order, y refers to the cancel/replacing order)

Filled Order

Partially Filled Order

Cancelled Order

¹ information only transmitted as the result of an Order Status Request on this order

Replaced Order

¹ information only transmitted as the result of an Order Status Request on this order

Back to top ↑