Orchimate 1.4.6 /

FIX.LatestFIX.Latest_EP307

Orchestra Hub

The Heartbeat monitors the status of the communication link and identifies when the last of a string of messages was not received.

The test request message forces a heartbeat from the opposing application. The test request message checks sequence numbers or verifies communication line status. The opposite application responds to the Test Request with a Heartbeat containing the TestReqID.

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 reject message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data which successfully passes de-encryption, CheckSum and BodyLength checks.

The sequence reset message is used by the sending application to reset the incoming sequence number on the opposing side.

The logout message initiates or confirms the termination of a FIX session. Disconnection without the exchange of logout messages should be interpreted as an abnormal condition.

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.

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.

The ExecutionReport(35=8) message is used to:

1. confirm the receipt of an order (i.e. acknowledge)
2. confirm changes to an existing order (i.e. accept cancel and replace requests)
3. relay order status information
4. relay fill information on working orders
5. relay fill information on tradeable or restricted tradeable quotes
6. reject orders
7. report post-trade fees calculations associated with a trade

The OrderCancelReject(35=9) message is issued by the recipient upon receipt of a OrderCancelRequest(35=F) or OrderCancelReplaceRequest(35=G) message which cannot be honored. Requests to change price or decrease quantity are executed only when an outstanding quantity exists. Filled orders cannot be changed (i.e. quantity reduced or price change, however, the recipient may support increasing the order quantity on a currently filled order).

The logon message authenticates a user establishing 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 news message is 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 message can be originated at either the broker or institution side, or exchanges and other marketplace venues.

The email message is similar to the format and purpose of the News message, however, it is intended for private use between two parties.

The NewOrderSingle(35=D) message type is used by the order submitter wishing to electronically place orders for execution with their counterparty. The message supports a variety of security types.

The NewOrderList(35=E) message may be used in one of two ways depending on which market conventions are being followed.

In the "Non disclosed" convention the NewOrderList(35=E) message is sent after the bidding process has been completed, by telephone or electronically. The NewOrderList(35=E) message enumerates the stocks, quantities, direction for the trade and may contain pre-allocation information.

In the "Disclosed" convention the NewOrderList(35=E) message is sent before the bidding process is started, by telephone or electronically. The NewOrderList(35=E) message enumerates the stocks and quantities from the bidding process, and may contain pre-allocation information. The direction of the trade is disclosed after the bidding process is completed.

The OrderCancelRequest(35=F) message requests the cancellation of all of the remaining quantity of an existing order.

The OrderCancelReplaceRequest(35=G) message (a.k.a. Order Modification Request) is used to change the parameters of an existing order. The OrderCancelReplaceRequest(35=G) message may be used to change any valid attribute of an open order (e.g. reduce/increase quantity, change limit price, change instructions, etc.). Subject to agreement between counterparties, it may be used to re-open a filled order by increasing OrderQty(38).

The OrderStatusRequest(35=H) message is used by the order submitter to generate an ExecutionReport(35=8) message with ExecType(150)=I (Order Status) back from the recipient.

The AllocationInstruction(35=J) message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts.

The ListCancelRequest(35=K) message is used to cancel previously submitted lists either before or during execution.

The ListStatus(35=N) message is used by the recipient of the ListCancelRequest(35=K) message to communicate the status of the ListCancelRequest(35=K) message.

The ListExecute(35=L) message is used to begin execution of a previously submitted list. This message may or may not be used, as it may be mirroring a phone conversation.

The ListStatusRequest(35=M) message is used to generate status messages for a list of orders.

The ListStatus(35=N) message is issued as the response to a ListStatusRequest(35=M) message or sent in an unsolicited fashion by the recipient of the NewOrderList(35=E). It indicates the current state of the orders within the list as they exist at the recipient. This message may also be used to respond to the ListCancelRequest(35=K) message.

In versions of FIX prior to version 4.4, this message was known as the Allocation ACK message.
The Allocation Instruction Ack message is used to acknowledge the receipt of and provide status for an Allocation Instruction message.

The DontKnowTrade(35=Q) message (a.k.a. DK message) notifies a trading partner that an electronically received execution has been rejected. This message can be thought of as an execution reject message.

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. This message is commonly referred to as an Request For Quote (RFQ)

The Quote message is used as the response to a Quote Request or a Quote Response message in both indicative, tradeable, and restricted tradeable quoting markets.

The Settlement Instructions message provides the broker’s, the institution’s, or the intermediary’s instructions for trade settlement. This message has been designed so that it can be sent from the broker to the institution, from the institution to the broker, or from either to an independent "standing instructions" database or matching system or, for CIV, from an intermediary to a fund manager.

Some systems allow the transmission of real-time quote, order, trade, trade volume, open interest, and/or other price information on a subscription basis. A MarketDataRequest(35=V) is a general request for market data on specific securities or forex quotes. The values in the fields provided within the request will serve as further filter criteria for the result set.

The Market Data messages are used as the response to a Market Data Request message. In all cases, one Market Data message refers only to one Market Data Request. It can be used to transmit a 2-sided book of orders or list of quotes, a list of trades, index values, opening, closing, settlement, high, low, or VWAP prices, the trade volume or open interest for a security, or any combination of these.

The Market Data message for incremental updates may contain any combination of new, changed, or deleted Market Data Entries, for any combination of instruments, with any combination of trades, imbalances, quotes, index values, open, close, settlement, high, low, and VWAP prices, trade volume and open interest so long as the maximum FIX message size is not exceeded. All of these types of Market Data Entries can be changed and deleted.

The Market Data Request Reject is used when the broker cannot honor the Market Data Request, due to business or technical reasons. Brokers may choose to limit various parameters, such as the size of requests, whether just the top of book or the entire book may be displayed, and whether Full or Incremental updates must be used.

The Quote Cancel message is used by an originator of quotes to cancel quotes.
The Quote Cancel message supports cancellation of:
• All quotes
• Quotes for a specific symbol or security ID
• All quotes for a security type
• All quotes for an underlying

The quote status request message is used for the following purposes in markets that employ tradeable or restricted tradeable quotes:
• For the issuer of a quote in a market to query the status of that quote (using the QuoteID to specify the target quote).
• To subscribe and unsubscribe for Quote Status Report messages for one or more securities.

Mass Quote Acknowledgement is used as the application level response to a Mass Quote message.

The SecurityDefinitionRequest(35=c) message is used for the following:
1. Request a specific security to be traded with the second party. The requested security can be defined as a multileg security made up of one or more instrument legs.
2. Request a set of individual securities for a single market segment.
3. Request all securities, independent of market segment.

The SecurityDefinition(35=d) message is used for the following:
1. Accept the security defined in a SecurityDefinition(35=d) message.
2. Accept the security defined in a SecurityDefinition(35=d) message with changes to the definition and/or identity of the security.
3. Reject the security requested in a SecurityDefinition(35=d) message.
4. Respond to a request for securities within a specified market segment.
5. Convey comprehensive security definition for all market segments that the security participates in.
6. Convey the security's trading rules that differ from default rules for the market segment.

The Security Status Request message provides for the ability to request the status of a security. One or more Security Status messages are returned as a result of a Security Status Request message.

The Security Status message provides for the ability to report changes in status to a security. The Security Status message contains fields to indicate trading status, corporate actions, financial status of the company. The Security Status message is used by one trading entity (for instance an exchange) to report changes in the state of a security.

The Trading Session Status Request is used to request information on the status of a market. With the move to multiple sessions occurring for a given trading party (morning and evening sessions for instance) there is a need to be able to provide information on what product is trading on what market.

The Trading Session Status provides information on the status of a market. For markets multiple trading sessions on multiple-markets occurring (morning and evening sessions for instance), this message is able to provide information on what products are trading on what market during what trading session.

The Mass Quote message can contain quotes for multiple securities to support applications that allow for the mass quoting of an option series. Two levels of repeating groups have been provided to minimize the amount of data required to submit a set of quotes for a class of options (e.g. all option series for IBM).

The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.

The BidRequest(35=K) message can be used in one of two ways depending on market conventions being followed.
In the "Non disclosed" convention (e.g. US/European model) the BidRequest(35=k) message may be used to request a bid based on the sector, country, index and liquidity information contained within the message itself. In the "Non disclosed" convention the BidDescReqGrp repeating group is used to define liquidity of the program.

In the "Disclosed" convention (e.g. Japanese model) the BidRequest(35=k) message may be used to request bids based on the NewOrderList(35=E) messages sent in advance of BidRequest(35=k) message. In the "Disclosed" convention the BidCompReqGrp repeating group is used to define which NewOrderList(35=E) messages a bid is being sought for and the directions of the required bids.

The BidResponse(35=l, lowercase "L") message may be used in one of two ways depending on which market conventions are being followed.

In the "Non disclosed" convention the BidResponse(35=l) message may be used to supply a bid based on the sector, country, index and liquidity information contained within the corresponding BidRequest(35=k) message.

In the "Disclosed" convention the BidResponse(35=l) message may be used to supply bids based on the NewOrderList(35=E) messages sent in advance of the corresponding BidRequest(35=k) message.

The ListStrikePrice(35=m) message is used to exchange strike price information for principal trades. It can also be used to exchange reference prices for agency trades.

The Registration Instructions message type may be used by institutions or retail intermediaries wishing to electronically submit registration information to a broker or fund manager (for CIV) for an order or for an allocation.

The Registration Instructions Response message type may be used by broker or fund manager (for CIV) in response to a Registration Instructions message submitted by an institution or retail intermediary for an order or for an allocation.

The OrderMassCancelRequest(35=q) message is used to request the cancellation of all of the remaining quantity of a group of orders matching criteria specified within the request using MassCancelRequestType(530). Some of the criteria require the specification of another FIX field. This message can only be used to cancel orders.

The OrderMassCancelReport(35=r) message is used to acknowledge an OrderMassCancelRequest(35=q) message. Each affected order that is canceled is responded to with a separate ExecutionReport(35=8) or OrderCancelReject(9) message.

The NewOrderCross(35=s) message is used to submit a cross order into a market. The cross order contains two orders, a buy and a sell. The cross order is identified by its CrossID(548).

The CrossOrderCancelReplaceRequest(35=t) message (a.k.a. Cross Order Modification Request) is used to modify a cross order previously submitted using the NewOrderCross(35=s) message. Refer to the OrderCancelReplaceRequest(35=G) (a.k.a. Order Modification Request) message for restrictions on what fields can be changed during a cancel/replace.

The CrossOrderCancelRequest(35=u) message is used to fully cancel the remaining open quantity of a cross order.

The Security Type Request message is used to return a list of security types available from a counterparty or market.

The Security Type Request message is used to return a list of security types available from a counterparty or market.

The Security List Request message is used to return a list of securities from the counterparty that match criteria provided on the request

The Security List message is used to return a list of securities that matches the criteria specified in a Security List Request.

The Derivative Security List Request message is used to return a list of securities from the counterparty that match criteria provided on the request

The Derivative Security List message is used to return a list of securities that matches the criteria specified in a Derivative Security List Request.

The NewOrderMultileg(35=AB) message is used to submit orders for securities that are made up of multiple securities, known as legs.

The MultilegOrderCancelReplace(35=AC) message (a.k.a. Multileg Order Modification Request) is used to modify a multileg order previously submitted using the NewOrderMultileg(35=AB) message. See OrderCancelReplaceRequest(35=G) for details concerning message usage.

The Trade Capture Report Request can be used to:
• Request one or more trade capture reports based upon selection criteria provided on the trade capture report request
• Subscribe for trade capture reports based upon selection criteria provided on the trade capture report request.

The Trade Capture Report message can be:
- Used to report trades between counterparties.
- Used to report trades to a trade matching system.
- Sent unsolicited between counterparties.
- Sent as a reply to a Trade Capture Report Request.
- Used to report unmatched and matched trades.

The OrderMassStatusRequest(35=AF) message requests the status for orders matching criteria specified within the request using MassStatusReqType(585). Some of the criteria require the specification of another FIX field. The request is assigned its own unique ClOrdID(11) and is treated as a separate entity. Individual ExecutionReport(35=8) messages with ExecType(150)=I (Order Status) are returned for each order matching the criteria provided on the request with the order's status.

The Quote Request Reject message is used to reject Quote Request messages for all quoting models.

In tradeable and restricted tradeable quoting markets – Quote Requests are issued by counterparties interested in ascertaining the market for an instrument. Quote Requests are then distributed by the market to liquidity providers who make markets in the instrument. The RFQ Request is used by liquidity providers to indicate to the market for which instruments they are interested in receiving Quote Requests. It can be used to register interest in receiving quote requests for a single instrument or for multiple instruments

The quote status report message is used:
• as the response to a Quote Status Request message
• as a response to a Quote Cancel message
• as a response to a Quote Response message in a negotiation dialog (see Volume 7 – PRODUCT: FIXED INCOME and USER GROUP: EXCHANGES AND MARKETS)

The QuoteResponse(35=AJ) message is used for the following purposes:
1. Respond to an IOI(35=6) message
2. Respond to a Quote(35=S) message
3. Counter a Quote
4. End a negotiation dialog
5. Follow-up or end a QuoteRequest(35=R) dialog that did not receive a response.

The Confirmation messages are used to provide individual trade level confirmations from the sell side to the buy side. In versions of FIX prior to version 4.4, this role was performed by the allocation message. Unlike the allocation message, the confirmation message operates at an allocation account (trade) level rather than block level, allowing for the affirmation or rejection of individual confirmations.

The Position Maintenance Request message allows the position owner to submit requests to the holder of a position which will result in a specific action being taken which will affect the position. Generally, the holder of the position is a central counter party or clearing organization but can also be a party providing investment services.

The Position Maintenance Report message is sent by the holder of a position in response to a Position Maintenance Request and is used to confirm that a request has been successfully processed or rejected.

The Request For Positions message is used by the owner of a position to request a Position Report from the holder of the position, usually the central counter party or clearing organization. The request can be made at several levels of granularity.

The Request for Positions Ack message is returned by the holder of the position in response to a Request for Positions message. The purpose of the message is to acknowledge that a request has been received and is being processed.

The Position Report message is returned by the holder of a position in response to a Request for Position message. The purpose of the message is to report all aspects of a position and may be provided on a standing basis to report end of day positions to an owner.

The Trade Capture Request Ack message is used to:
- Provide an acknowledgement to a Trade Capture Report Request in the case where the Trade Capture Report Request is used to specify a subscription or delivery of reports via an out-of-band ResponseTransmissionMethod.
- Provide an acknowledgement to a Trade Capture Report Request in the case when the return of the Trade Capture Reports matching that request will be delayed or delivered asynchronously. This is useful in distributed trading system environments.
- Indicate that no trades were found that matched the selection criteria specified on the Trade Capture Report Request or the Trade Capture Request was invalid for some business reason, such as request is not authorized, invalid or unknown instrument, party, trading session, etc.

The Trade Capture Report Ack message can be:
- Used to acknowledge trade capture reports received from a counterparty.
- Used to reject a trade capture report received from a counterparty.

Sent from sell-side to buy-side, sell-side to 3rd-party or 3rd-party to buy-side, the AllocationReport(35=AS) message (Claim) provides account breakdown of an order or set of orders plus any additional follow-up front-office information developed post-trade during the trade allocation, matching and calculation phase.

The Allocation Report Ack message is used to acknowledge the receipt of and provide status for an Allocation Report message.

The Confirmation Ack (aka Affirmation) message is used to respond to a Confirmation message.

The Settlement Instruction Request message is used to request standing settlement instructions from another party.

Assignment Reports are sent from a clearing house to counterparties, such as a clearing firm as a result of the assignment process.

An initiator that requires collateral from a respondent sends a Collateral Request. The initiator can be either counterparty to a trade in a two party model or an intermediary such as an ATS or clearinghouse in a three party model. A Collateral Assignment is expected as a response to a request for collateral.

Used to assign collateral to cover a trading position. This message can be sent unsolicited or in reply to a Collateral Request message.

Used to respond to a Collateral Assignment message.

Used to report collateral status when responding to a Collateral Inquiry message.

Used to inquire for collateral status.

This message is send either immediately after logging on to inform a network (counterparty system) of the type of updates required or to at any other time in the FIX conversation to change the nature of the types of status updates required. It can also be used with a NetworkRequestType of Snapshot to request a one-off report of the status of a network (or counterparty) system. Finally this message can also be used to cancel a request to receive updates into the status of the counterparties on a network by sending a NetworkRequestStatusMessage with a NetworkRequestType of StopSubscribing.

This message is sent in response to a Network (Counterparty System) Status Request Message.

This message is used to initiate a user action, logon, logout or password change. It can also be used to request a report on a user's status.

This message is used to respond to a user request message, it reports the status of the user after the completion of any action requested in the user request message.

Used to respond to a Collateral Inquiry in the following situations:
• When the CollateralInquiry will result in an out of band response (such as a file transfer).
• When the inquiry is otherwise valid but no collateral is found to match the criteria specified on the Collateral Inquiry message.
• When the Collateral Inquiry is invalid based upon the business rules of the counterparty.

The Confirmation Request message is used to request a Confirmation message.

The Contrary Intention Report is used for reporting of contrary expiration quantities for Saturday expiring options. This information is required by options exchanges for regulatory purposes.

This message is used for reporting updates to a product security master file. Updates could be the result of corporate actions or other business events. Updates may include additions, modifications or deletions.

The Security List Update Report is used for reporting updates to a Contract Security Masterfile. Updates could be due to Corporate Actions or other business events. Update may include additions, modifications and deletions.

Used to report changes in position, primarily in equity options, due to modifications to the underlying due to corporate actions

This message is used in a 3-party allocation model (buy-side and sell-side using a central clearing entity) where notification of group creation and group updates to counterparties is needed. The message will also carry trade information that comprised the group to the counterparties.

The ExecutionAck(35=BN) message is an optional message that provides dual functionality to notify a trading partner that an electronically received execution has either been accepted or rejected (DK'd).

The Trading Session List message is sent as a response to a Trading Session List Request. The Trading Session List should contain the characteristics of the trading session and the current state of the trading session.