Orchimate 1.5.0 /

FIX3.0

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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

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.

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