Application Messages By MsgType

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 themerchandise may no longer be available due to prior trade.

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

The Execution Report (8) 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 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 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.Filled orders cannot be changed (i.e quantity reduced or price change. However, the broker/sellside may support increasing the order quantity on a currently filled order).

The Derivative Security List (y) message is used to return a list of securities that matches thecriteria specified in a Derivative Security List (y) Request.

The New Order - Multileg (AB) is provided to submit orders for securities that are made up ofmultiple securities, known as legs.

Used to modify a multileg order previously submitted using the New Order - Multileg (AB) message.See Order Cancel Replace Request for details concerning message usage.

The Trade Capture Report Request (AD) can be used to:

• Request one or more trade capture reports based upon selection criteria provided onthe trade capture report request (AD)
• Subscribe for trade capture reports based upon selection criteria provided onthe trade capture report request (AD) .

The Trade Capture Report (AE) message can be:

The order mass status request message requests the status for orders matching criteria specified within the request.

The Quote Request Reject (AG) message is used to reject Quote Request (R) messages for all quoting models.

In tradeable and restricted tradeable quoting markets Quote Requests (R) are issued bycounterparties interested in ascertaining the market for an instrument. Quote Requests (R) are thendistributed by the market to liquidity providers who make markets in the instrument. The RFQ Request (AH) isused by liquidity providers to indicate to the market for which instruments they are interested in receiving Quote Requests (R) . It can be used to register interest in receiving quote requests for a single instrumentor for multiple instruments

The quote status report message is used:

The Quote Response (AJ) message is used to respond to a IOI message or Quote (S) message.It is also used to counter a Quote (S) or end a negotiation dialog.

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

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

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

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

The Request for Positions Ack (AO) 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 (AP) 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 (AQ) message is used to:

• Provide an acknowledgement to a Trade Capture ReportRequest (AD) in the case where the Trade Capture ReportRequest (AD) is used to specify a subscription or delivery of reports via anout-of-band ResponseTransmissionMethod.
• Provide an acknowledgement to a Trade Capture ReportRequest (AD) in the case when the return of the Trade Capture Reports matching thatrequest will be delayed or delivered asynchronously. This is useful in distributedtrading system environments.
• Indicate that no trades were found that matched the selection criteria specified onthe Trade Capture Report Request (AD)
• The Trade Capture Request was invalid for some business reason, such as request isnot authorized, invalid or unknown instrument, party, trading session, etc.

The Trade Capture Report Ack (AR) 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 Allocation Report (Claim) (AS) provides account breakdown ofan order or set of orders plus any additional follow-up front-office information developedpost-trade during the trade allocation, matching and calculation phase. In versions of FIXprior to version 4.4, this functionality was provided through the Allocation (J) message. Depending on the needs of the market and thetiming of "confirmed" status, the role of AllocationReport (AS) can be taken over in whole or in part by the Confirmation (AK) message.

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

The Confirmation Ack (AU) message is used to respond to a Confirmation (AK) message.

The Settlement Instruction Request (AV) message is used to request standing settlement instructions from another party. This could be:

Assignment Reports are sent from a clearing house to counterparties, such as a clearing firm as a result of the assignmentprocess. Communication Scenarios

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 (AY) 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 (AX) message.

Used to respond to a Collateral Assignment (AY) message.

The news message is a general free format message between the broker and institution.

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

Used to inquire for collateral status.

It is envisaged these messages will be used in two scenarios:

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

These messages are provided in FIX to allow the passing of individual user information between two counterparties. The messages allow for the following function

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 (BB) in the following situations:

The Confirmation Request (BH) message is used to request a Confirmation (AK) message.

The Trading Session List Request (BI) is used to request a list of trading sessions available in a market place and the state of those trading sessions. The request can be modified to request status on a particular trading session (by specifying the TradingSessionID (336) (tag 336) and TradingSessionSubID (625) (tag 625) (if used by the market place). The request can be used to request a list of trading sessions that use a particular trading method or mode (such as electronic) by specifying the TradSesMethod (338) (tag 338) and/or TradSesMode (339) .

The Trading Session List (BJ) message is sent as a responseto a Trading Session List (BJ) Request. The Trading Session List (BJ) should containthe characteristics of the trading session and the current state of the trading session.

The Security List Update Report (BK) 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 where notification of group creation and group updates to counterparites is needed.The mssage will also carry trade information that comprised the group to the counterparites.

The Execution Report Acknowledgement (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 Contrary Intention Report (BO) 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 (460) Security Masterfile.Updates could be the result of corporate actions or other business events.Updates may include additions, modifications or deletions.

The Settlement Obligation Report message provides a central counterparty, institution, or individual counterparty with acapacity for reporting the final details of a currency settlement obligation. The settlement obligation is intended to be used forauxiliary reporting of settlement details that will be conducted over SWIFT or CLS in order to affect the instructions.The Settlement Obligation Report message is designed to allow multiple FX deals to be aggregated and netted into a singleinstruction to simplify the reporting process.

The Derivative Security List Update Report message is used to send updates to an option family or the strikes that comprise an option family.

The Trading Session List Update Report is used by marketplaces to provide intra-day updates of trading sessions when there are changes to one or more trading sessions.

The Market Definition Request message is used to request for market structure information from the Respondent that receivesthis request.Fields that are specified will act as "filters" for the request.For example, if MarketID is specified then onlymarket structure information for that specified market should be sent back if available.If MarketID is not specified then therequest is for all available market structure information.

The Market Definition message is used to respond to Market Definition Request.In a subscription, it will be used toprovide the initial snapshot of the information requested.Subsequent updates are provided by the Market Definition Update Report.

In a subscription for market structure information, this message is used once the initial snapshot of the information hasbeen sent using the Market Definition message.

This message is used to request a retransmission of a set of one or more messages generated by the application specified in RefApplID (1355) (1355) .The message can be used for five types of transmission requests:

This message is used to acknowledge an Application Message Request providing a status on the request (i.e. whether successful or not).This message does not provide the actual content of the messages to be resent.

This message is used for three difference purposes: to reset the ApplSeqNum (1181) of a specified ApplID (1180) .To indicate that the last message has been sent for a particular ApplID, or as a keep-alive mechanism for ApplIDs with infrequentmessage traffic.The purpose of the Application Message Report is indicated by ApplReportType (1426) .

The Order Mass Action Report is used to acknowledge an Order Mass Action Request.Note that each affected order that issuspended or released or canceled is acknowledged with a separate Execution Report for each order.

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 Order Mass Action Request message can be used to request the suspension or release of a group of orders that matchthe criteria specified within the request. This is equivalent to individual Order Cancel Replace Requests for each order withor without adding "S" to the ExecInst values. It can also be used for mass order cancellation.

The User Notification message is used to notify one or more users of an event or information from the sender of the message.This message is usually sent unsolicited from a marketplace (e.g. Exchange, ECN) to a market participant.

In certain markets where market data aggregators fan out to end clients the pricing streams provided by the price makers, the price maker may assign the clients to certain pricing streams that the price maker publishes via the aggregator. An example of this use is in the FX markets where clients may be assigned to different pricing streams based on volume bands and currency pairs.

The StreamAssignmentReport message is in response to the StreamAssignmentRequest message.It provides information back to the aggregator as to which clients to assign to receive which price stream based on requested CCY pair.This message can be sent unsolicited to the Aggregator from the Price Maker.

This message is used to respond to the Stream Assignment Report, to either accept or reject an unsolicited assingment.

The Party Details List Request message is used to request party reference information from a central master reference system or another party that stores and maintains party reference information.The central master reference system can be an exchange that provides such information to trading applications that connect to it.Reference information may include relationships between parties, and details such as risk limits.The response to this message is the PartyDetailsListReport.

The Party Details List Report message is used by a central master file systerm or another party that stores and maintains party reference information to disseminate party reference information.Reference information may include relationships between parties, and details such as risk limits.

The purpose of this message is to initiate a margin requirement inquiry for a margin account. The inquiry may be submitted at the detail level or the summary level. It can also be used to inquire margin excess/deficit or net position information. Margin excess/deficit will provide information about the surplus or shortfall compared to the previous trading day or a more recent margin calculation. An inquiry for net position information will trigger one or more PositionReport messages instead of one or more MarginRequirementReport messages.

Used to respond to a Margin Requirement Inquiry.

The Margin Requirement Report returns information about margin requirement either as on overview across all margin accounts or on a detailed level due to the inquiry making use of the optional Instrument component block. Application sequencing can be used to re-request a range of reports.

The PartyDetailsListUpdateReport(35=CK) is used to disseminate updates to party detail information.

The PartyRiskLimitsRequest message is used to request for risk information for specific parties, specific party roles or specific instruments.

The PartyRiskLimitsReport message is used to communicate party risk limits. The message can either be sent as a response to the PartyRiskLimitsRequest message or can be published unsolicited.

The AccountSummaryReport is provided by the clearinghouse to its clearing members on a daily basis. It contains margin, settlement, collateral and pay/collect data for each clearing member level account type. Clearing member account types will be described through use of the Parties component and PtysSubGrp sub-component.

The PartyRiskLimitsUpdateReport(35=CR) is used to convey incremental changes to risk limits. It is similar to the regular report but uses the PartyRiskLimitsUpdateGrp component instead of the PartyRiskLimitsGrp component to include an update action.

PartyRiskLimitDefinitionRequest is used for defining new risk limits.

PartyRiskLimitDefinitionRequestAck is used for accepting (with or without changes) or rejecting the definition of risk limits.

The PartyEntitlementsRequest message is used to request for entitlement information for one or more party(-ies), specific party role(s), or specific instruments(s).

The PartyEntitlementsReport is used to report entitlements for one or more parties, party role(s), or specific instrument(s).

The QuoteAck(35=CW) message is used to acknowledge a Quote(35=S) submittal or request to cancel an individual quote using the QuoteCancel(35=Z) message during a Quote/Negotiation dialog.

The PartyDetailsDefinitionRequest(35=CX) is used for defining new parties and modifying or deleting existing parties information, including the relationships between parties.

The PartyDetailsDefinitionRequestAck(35=CY) is used as a response to the PartyDetailsDefinitionRequest(35=CX) message. The request can be accepted (with or without changes) or rejected.

The PartyEntitlementsUpdateReport(35=CZ) is used to convey incremental changes to party entitlements. It is similar to the PartyEntitlementsReport(35=CV). This message uses the PartyEntitlementsUpdateGrp component which includes the ability to specify an update action using ListUpdateAction(1324).

The New Order (D) message type is used by institutions wishing toelectronically submit securities and forex orders to a broker for execution.

The PartyEntitlementsDefinitionRequest(35=DA) is used for defining new entitlements, and modifying or deleting existing entitlements for the specified party(-ies).

The PartyEntitlementsDefinitionRequestAck(35=DB) is used as a response to the PartyEntitlemensDefinitionRequest(35=DA) to accept (with or without changes) or reject the definition of party entitlements.

The TradeMatchReport(35=DC) message is used by exchanges and ECN’s to report matched trades to central counterparties (CCPs) as an atomic event. The message is used to express the one-to-one, one-to-many and many-to-many matches as well as implied matches in which more complex instruments can match with simpler instruments.

The TradeMatchReportAck(35=DD) is used to respond to theTradeMatchReport(35=DC) message. It may be used to report on the status of the request (e.g. accepting the request or rejecting the request).

PartyRiskLimitsReportAck is an optional message used as a response to the PartyRiskLimitReport(35=CM) or PartyRiskLimitUpdateReport(35=CR) messages to acknowledge or reject those messages.

PartyRiskLimitCheckRequest is used to request for approval of credit or risk limit amount intended to be used by a party in a transaction from another party that holds the information.

PartyRiskLimitCheckRequestAck is used to acknowledge a PartyRiskLimitCheckRequest(35=DF) message and to respond whether the limit check request was approved or not. When used to accept the PartyRiskLimitCheckRequest(35=DF) message the Respondent may also include the limit amount that was approved.

The PartyActionRequest message is used suspend or halt the specified party from further trading activities at the Respondent. The Respondent must respond with a PartyActionReport(35=DI) message.

Used to respond to the PartyActionRequest(35=DH) message, indicating whether the request has been received, accepted or rejected. Can also be used in an unsolicited manner to report party actions, e.g. reinstatements after a manual intervention out of band.

The MassOrder(35=DJ) message can be used to add, modify or delete multiple unrelated orders with a single message. Apart from clearing related attributes, only the key order attributes for high performance trading are available.

The mass order acknowledgement message is used to acknowledge the receipt of and the status for a MassOrder(35=DJ) message.

The PositionTransferInstruction(35=DL) is sent by clearing firms to CCPs to initiate position transfers, or to accept or decline position transfers.

The PositionTransferInstructionAck(35=DM) is sent by CCPs to clearing firms to acknowledge position transfer instructions, and to report errors processing position transfer instructions.

The PositionTransferReport(35=DN) is sent by CCPs to clearing firms indicating of positions that are to be transferred to the clearing firm, or to report on status of the transfer to the clearing firms involved in the transfer process.

The MarketDataStatisticsRequest(35=DO) is used to request for statistical data. The simple form is to use an identifier (MDStatisticID(2475)) assigned by the market place which would denote a pre-defined statistical report. Alternatively, or also in addition, the request can define a number of parameters for the desired statistical information.

The MarketDataStatisticsReport(35=DP) is used to provide unsolicited statistical information or in response to a specific request. Each report contains a set of statistics for a single entity which could be a market, a market segment, a security list or an instrument.

CollateralReportAck(35=DQ) is used as a response to the CollateralReport(35=BA). It can be used to reject a CollateralReport(35=BA) when the content of the report is invalid based on the business rules of the receiver. The message may also be used to acknowledge receipt of a valid CollateralReport(35=BA).

The MarketDataReport(35=DR) message is used to provide delimiting references (e.g. start and end markers in a continuous broadcast) and details about the number of market data messages sent in a given distribution cycle.

The CrossRequest(35=DS) message is used to indicate the submission of orders or quotes that may result in a crossed trade.

The CrossRequestAck(35=DT) message is used to confirm the receipt of a CrossRequest(35=DS) message.

This message is used in a clearinghouse 3-party allocation model to request for AllocationInstructionAlert(35=BM) from the clearinghouse. The request may be used to obtain a one-time notification of the status of an allocation group.

This message is used in a clearinghouse 3-party allocation model to acknowledge a AllocationInstructionAlertRequest(35=DU) message for an AllocationInstructionAlert(35=BM) message from the clearinghouse.

TradeAggregationRequest(35=DW) is used to request that the identified trades between the initiator and respondent be aggregated together for further processing.

TradeAggregationReport(35=DX) is used to respond to the TradeAggregationRequest(35=DW) message. It provides the status of the request (e.g. accepted or rejected) and may also provide additional information supplied by the respondent.

PayManagementRequest(35=DY) message is used to communicate a future or expected payment to be made or received related to a trade or contract after its settlement.

PayManagementRequestAck(35=DZ) is used to acknowledge the receipt of the PayManagementRequest(35=DY) message (i.e. a technical acknowledgement of receipt). Acceptance or rejection of the request is reported in the corresponding PayManagementReport(35=EA).

The NewOrderList Message can be used in one of two ways depending on which market conventions are being followed.

PayManagementReport(35=EA) may be used to respond to the PayManagementRequest(35=DY) message. It provides the status of the request (e.g. accepted, disputed) and may provide additional information related to the request.

PayManagementReportAck(35=EB) is used as a response to the PayManagementReport(35=EA) message. It may be used to accept, reject or dispute the details of the PayManagementReport(35=EA) depending on the business rules of the receiver. This message may also be used to acknowledge the receipt of a PayManagementReport(35=EA) message.

SettlementStatusRequest(35=EC) is used to request for the settlement status of a trade.

SettlementStatusRequestAck(35=ED) is used to respond to the SettlementStatusRequest(35=EC) to acknowledge the request and provide status for the request message.

SettlementStatusReport(35=EE) is a response to the SettlementStatusRequest(35=EC) to provide settlement status for the requested trade. It may also be sent unsolicited without an explicit request message by the party able to provide the settlement status for the trade identified in the report message.

SettlementStatusReportAck(35=EF) is used to respond to the SettlementStatusReport(35=EE) to acknowledge or reject the report.

SecurityRiskMetricsReport(35=EG) is used for publishing the risk metrics, valuation metrics or analytics of one or more securities, or for an option series.

AlgoCertificateRequest(35=EH) is used to request algo testing certificate information for one or more algorithms.

AlgoCertificateRequestAck(35=EI) is used to respond to the AlgoCertificateRequest(35=EH) to acknowledge the request and provide status for the request message.

AlgoCertificateReport(35=EJ) is a response to the AlgoCertificateRequest(35=EH) to certify an algo. It may also be sent unsolicited without an explicit request message by the party able to provide certificate information for the algo identified in the report message.

AlgoCertificateReportAck(35=EK) is used to respond to the AlgoCertificateReport(35=EJ) to acknowledge or reject the report message.

TestSuiteDefinitionRequest(35=EL) is used to convey to the test system the suite of test scenarios to perform.

TestSuiteDefinitionRequestAck(35=EM) is used to respond to the TestSuiteDefinitionRequest(35= EL) to acknowledge the request and provide status for the request message.

TestActionRequest(35=EN) is used to manage test executions or request for testing activity state of the identified test suite.

TestActionRequestAck(35=EO) is used to respond to the TestActionRequest(35=EN) to acknowledge the request and provide status for the request message.

TestActionReport(35=EP) is used to report the testing results of the identified test suite that has been executed with TestActionRequest(35=EN). In the context of algorithmic trading, the results may be used to create a certificate for the algorithm upon meeting the success criteria.

This message may be used as a response to the MarketDataSnapshotFullRefresh(35=W) and MarketDataIncrementalRefresh(35=X) messages.

This message may be used as a response to the SecurityStatus(35=f) message.

This message may be used as a response to the TradingSessionStatus(35=h) message.

The order cancel request message requests the cancelation of all of the remaining quantity of an existing order.Note that the Order Cancel/Replace Request should be used to partially cancel (reduce) an order).

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

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

The Allocation Instruction (J) message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts. In versions of FIX prior to version 4.4, this same message was known as the Allocation message. Note in versions of FIX prior to version 4.4, the allocation message was also used to communicate fee and expense details from the Sellside to the Buyside.This role has now been removed from the Allocation Instruction (J) and is now performed by the new (to version 4.4) Allocation Report and Confirmation (AK) messages.,TheAllocation Report message should be used for the Sell-side Initiated Allocation role as defined in previous versions of the protocol.

The List Cancel Request (K) message type is used by institutions wishing to cancel previously submitted lists either before or during execution.

The List Execute (L) message type is used by institutions to instruct the broker 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 list status request message type is used by institutions to instruct the broker to generate status messages for a list.

The list status message is issued as the response to a List Status Request (M) message sent in an unsolicited fashion by the sell-side. It indicates the current state of the orders within the list as they exist at the broker's site. This message may also be used to respond to the List Cancel Request.

In versions of FIX prior to version 4.4, this message was known as the Allocation ACK message.

The Don't Know Trade (DK) (Q) 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 (S) (RFQ)

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

The Settlement Instructions (T) message provides the brokers, the institutions, or the intermediarys 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 Market Data Request (V) is a general request for market data on specific securities or forex quotes.

The Market Data messages are used as the response to a Market Data Request (V) 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 second Market Data message format is used for incremental updates.Market Data Entries may have an MDEntryID (278) unique among all currently active Market Data Entries so they can be referenced for the purposes of deleting and changing them later.When changing a Market Data Entry, it may keep the same MDEntryID, in which case only MDEntryID (278) would be populated, or the MDEntryID (278) may change, in which case MDEntryID (278) will contain the new ID, and MDEntryRefID (280) will contain the ID of the Market Data Entry being changed.An MDEntryID (278) can be reused within a day only if it has first been deleted.

The Market Data Request Reject (Y) 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 (Z) message is used by an originator of quotes to cancel quotes.

The quote status request message is used for the following purposes in markets that employ tradeable or restricted tradeable quotes:

Mass Quote (S) Acknowledgement is used as the application levelresponse to a Mass Quote (S) message. The Mass Quote (S) Acknowledgement contains a field for reporting the reason in the event that the entire quote is rejected (QuoteRejectReason[300]). The Mass Quote (S) Acknowledgement also contains a field for each quote that is used in the event that the quote entry is rejected (QuoteEntryRejectReason[368]). The ability to reject an individual quote entry is important so that the majority of quotes can be successfully applied to the market instead of having to reject the entire Mass Quote (S) for a minority of rejected quotes.

The Security Definition Request (c) message is used for the following:

The Security Definition (d) message is used for the following:

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

The Security Status (f) message provides for the ability to report changes in status to a security. The Security Status (f) message contains fields to indicate trading status, corporate actions, financial status of the company. The Security Status (f) 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 (g) 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 (h) provides 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 Mass Quote (S) 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 (j) 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 Bid Request (k) Message can be used in one of two ways depending on which market conventions are being followed.

The Bid Response (l) message can be used in one of two ways depending on which market conventions are being followed.

The strike price 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 (o) 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 (p) message type may be used by broker or fund manager (for CIV) in response to a Registration Instructions (o) message submitted by an institution or retail intermediary for an order or for an allocation.

The order mass cancel request message requests the cancelation of all of the remaining quantity of a group of orders matching criteria specified within the request. NOTE: This message can only be used to cancel order messages (reduce the full quantity).

The Order Mass Cancel Report (r) is used to acknowledge an Order Mass Cancel Request. Note that each affected order that is canceled is acknowledged with a separate Execution Report or Order Cancel Reject (9) message.

Used to submit a cross order into a market. The cross order contains two order sides (a buy and a sell). The cross order is identified by its CrossID.

Used to modify a cross order previously submitted using the New Order - Cross (s) message. See Order Cancel Replace Request for details concerning message usage.

Used to fully cancel the remaining open quantity of a cross order.

The Security Type Request (v) message is used to return a list of security types available from a counterparty or market,

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

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

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

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