Orchimate 1.5.0 /

FIX4.0

The Heartbeat is useful for monitoring the status of the communication link and to identify when the last of a string of messages was not received.

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 is useful to verify that the Heartbeat is the result of the Test Request and not as the result of a regular timeout.

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 application requesting to initiate a FIX session.

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

Upon receipt of a Logon message the session acceptor will authenticate the party requesting connection and issue a Logon message as acknowledgment that the connection request has been accepted. The acknowledgment Logon can also be used by the initiator to validate that the connection was established with the correct party.

The session acceptor must be prepared to immediately begin processing messages after receipt of the Logon. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation Logon, however it is recommended that normal message delivery wait until after the return Logon is received to accommodate encryption key negotiation.

The confirmation Logon can be used for encryption key negotiation. If a session key is deemed to be weak, a stronger session key can be suggested by returning a Logon message with a new key. This is only valid for encryption protocols that allow for key negotiation. (See the FIX Home Page Application notes for more information on a method for encryption and key passing.)

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 communication line status. The opposite application will respond to the Test Request with a Heartbeat containing the TestReqID.

The TestReqID is used to verify that the opposite 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).

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.

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 Reset-GapFill message is used to skip messages that a sender does not wish to resend.)

Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9.

• 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 = 999999

The reject message should be issued when a message is received which cannot be passed through to the application level. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType=&) which successfully passes de-encryption, CheckSum and BodyLength checks. (As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.)

Rejected messages should be logged and the incoming sequence number incremented.

Note: When a message is received which is garbled, cannot be parsed or fails a data integrity check, the receiving application should disregard the message. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop which may be encountered in this situation.

Generation and receipt of a Reject message should be dealt with as an indication of a serious error by both parties as it may be the result of faulty logic in either the sending or receiving application.

If the sending application chooses to retransmit the rejected message it should be assigned a new sequence number.

Whenever possible, it is strongly recommeded that the cause of the failure be described in the Text field (e.g. INVALID DATA - FIELD 35).

The sequence reset message is used by the sending application to reset the incoming sequence number on the opposing side. The sequence reset message can be used in the following situations:

• During normal resend processing, the sending application may choose not to send a message (e.g. an aged order), the Sequence Reset can be used to mark the place of that message.
• During normal resend processing a number of administrative messages are not resent, the Sequence Reset message is used to fill the sequence gap created.
• In the event of an application failure it may be necessary to force synchronization of 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 next sequence number to be transmitted.

If the GapFill field is not present (or set to N), it can be 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).

If the Gap Fill field is present (and equal to Y), the MsgSeqNum should conform to standard message sequencing rules.

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 and treated as a serious error.

The logout message is to used to initiate or confirm the termination of a FIX session. Disconnection without the exchange of logout messages should be interpreted as an abnormal condition.

Before actually closing the session, the logout initiator should wait for the opposite side to respond with a confirming logout message. This gives the remote end a chance to perform any Gap Fill operations that may be necessary. The session may be terminated if the remote side does not respond in an appropriate timeframe.

The logout initiator should not send any messages after the logout.

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 a previously transmitted advertisement identified in 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 securities and forex 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, etc.) 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.

To support forex accommodation trades, two fields, ForexReq and SettlCurrency, are included in the message. To request a broker to execute a forex trade in conjunction with the securities trade, the institution would set the ForexReq = Y and SettlCurrency = “intended settlement currency”. The broker would then execute a forex trade from the execution currency to the settlement currency and report the results via the execution message in the NetMonies and SettlCurr fields.

The order message can also be used to request a straight forex trade. Conventions for identifying a forex transaction are as follows:

• The forex symbol is defined, in ISO codes, as “held-currency.new-currency” (e.g. “USD.GBP” indicates a desire to convert a held amount of USD to GPB)
• Side is defined in terms of whether the OrderQty is currency required or currency held (e.g. a forex order can be expressed as either “S 3,200,000 USD for GPB” or “B 2,000,000 GBP for USD”, at a rate of 1.6 USD/GBP, these trades are equivalent in that the broker is receiving 3,200,000 USD and delivering 2,000,000 GBP)
• OrdType = Forex

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
6. report miscellaneous fees calculations associated with a trade

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 (ExecTransType) 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 canceled 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 CumQty 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.

It is recommended that the Cancel/Replace Request message be used to partially cancel (reduce) an order.

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
• ExpireTime
• 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 or part of the remaining quantity of an existing order. The CxlType field is used to distinguish if all or part of the outstanding quantity is to be canceled.

Although the Order Cancel Request message can be used to partially cancel (reduce) an order it is recommended that the Cancel/Replace Request message be used for that 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 amongst 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 to instruct a broker on how to allocate executed shares to sub-accounts. The allocation record can also be used as a confirmation message through which third parties can communicate execution and settlement instructions between trading partners.

An allocation message can be submitted as new, cancel or replace. The AllocTransType field indicates the purpose of the message. When submitting replace or cancel AllocTransType messages the RefAllocID field is required. Replacement allocation messages must contain all data for the replacement allocation.

The allocation record contains repeating fields for each order, sub-account and individual execution; 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. If present, the total shares in the execution section must also be equal to this value.
• The number of sub-account instances 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.

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

It is possible that multiple Allocation ACK messages can be generated for a single allocation to detail the receipt and then the acceptance or rejection of the allocation.

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

In some markets it is the practice to request quotes from brokers prior to placement of an order. The quote request message is used for this purpose.

Quotes can be requested on specific securities or for forex rates.

Securities quotes can be requested as either market quotes or for a specific quantity and side. If OrderQty and Side are absent, a market-style quote (bid x offer, size x size) will be returned.

The symbol used for forex quotes is, in ISO codes, “currency1.currency2” (e.g. GBP.USD) and the quote will be returned as a rate expressed as currency1/currency2.

Forex quotes can be requested as indicative or at a specific quantity level. If an indicative quote is requested (OrderQty and Side are absent), the broker has discretion to quote at either a specific trade level and side or to provide an indicative quote at the mid-point of the spread. The broker can also choose to respond to an indicative quote by sending multiple quote messages specifying various levels and sides.

The quote message is used as the response to a quote request message and can be used to publish unsolicited quotes.

Quotes supplied as the result of a Quote Request message are tagged with the appropriate QuoteReqID, unsolicited quotes can be identified by the absence of a QuoteReqID.

The symbol used for forex quotes is, in ISO codes, “currency1.currency2” (e.g. GBP.USD) and the quote will be returned as a rate expressed as currency1/currency2. BidPx indicates the rate at which the broker is willing to buy currency1 and deliver currency2, OfferPx indicates the rate at which the broker is willing to sell currency1 and receive currency2. Indicative rates are quoted in the BidPx field and may contain a level in the BidSize field.

Orders can be generated based on Quotes, quoted orders include the QuoteID and are OrdType=Quoted Order.

The Don’t Know Trade (DK) message is used to notify a trading partner that an electronically received execution has been rejected. This message can be thought of as an execution reject message.

This message has special utility when dealing with one-way execution reporting, if the initial Order Acknowledgment message (LastShares=0 and OrdStatus=New) does not match an existing order this message can be used to notify the broker of a potential problem order.

Note that the decision to DK an execution lies with the institution; some of the mismatches listed in the DKReason field may be acceptable and will not require a DK messages to be generated.