Orchimate 1.5.0 /

FIX4.2

The Heartbeat monitors the status of the communication link and identifies 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 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 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 Web Site’s Application notes for more information on a method for encryption and key passing.)

The Logon message can be used to specify the MaxMessageSize supported (e.g. can be used to control fragmentation rules for very large messages which support fragmentation). It can also be used to specify the MsgTypes supported for both sending and receiving.

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 TestReqID verifies that the opposite application is generating the heartbeat as the result of Test Request and not a normal timeout. The opposite application includes 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, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.

• 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 = 0 (represents infinity) .

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 (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: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. 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 indicates a serious error that 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 recommended that the cause of the failure be described in the Text field (e.g. INVALID DATA - FIELD 35).

If an application-level message received fulfills session-level rules, it should then be processed at a business message-level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific “reject” messages, which should be used. All others can be rejected at a business-level via the Business Message Reject message. See the Business Message Reject message

Note that in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system, a Business Message Reject with BusinessRejectReason = “Application not available at this time” should be issued.

Scenarios for session-level Reject:

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 in all situations specifies NewSeqNo to reset as the value of the next sequence number to be transmitted.

If the GapFillFlag 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. 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 GapFillFlag field is present (and equal to Y), the MsgSeqNum should conform to standard message sequencing rules (i.e. the MsgSeqNum of the SequenceReset-GapFill message should represent the beginning MsgSeqNum in the GapFill range because the remote side is expecting that next message).

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. It is possible to have multiple ResendRequests issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend Request may appear as SeqReset-GapFill with NewSeqNo of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, and message 10. This could then followed by SeqReset-GapFill with NewSeqNo of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, message 10, and message 11. One must be careful to ignore the duplicate SeqReset-GapFill which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum is less than expected. If so, the SeqReset-GapFill is a duplicate and should be discarded.

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.

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

The email message is similar to the format and purpose of to the News message, however, it is 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 HandlInst 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.

The value specified in the TransactTime field should allow the receiver of the order to apply business rules to determine if the order is potentially "stale" (e.g. in the event that there have been communication problems). 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 SettlCurrAmt and SettlCurrency 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 "EBS" (Electronic Banking System) format: "CCY1/CCY2".
• Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
• (e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
• CCY1 and CCY2 are ISO currency codes
• The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
• In the case of a Forex - Swap (buying (or selling) a currency at one value date and selling (or buying) the same currency at a different value date), Side should represent the side of the FutSettDate2 transaction.
• OrdType = Forex - Market, Forex - Limit, Forex- Swap, or Forex - Previously Quoted
• Netting can be specified via the ExecInst field.
• See Appendix O – Foreign Exchange Trading

Orders involving or requiring Pre-Trade Allocation consist of the following steps:

• Buyside sends a New Order request message specifying one or more AllocAccount and AllocShares values within the repeating group designated by NoAllocs.
• Sellside sends Execution Report messages for the “New” and resulting fills.
• Post-Trade Allocation messaging takes place

To “take” an IOI (or Quote) from an ECN or exchange and not display the order on the book, the New Order message should contain the TimeInForce field with ImmediateOrCancel and an OrdType field with Previously Indicated ( or Previously Quoted).

The presence of DiscretionInst on an order indicates that the trader wishes to display one price but will accept trades at another price. For example a sell order with OrdType = Limit, Price=50.00, DiscretionInst = Related to displayed price and DiscretionOffset = -0.25 means that the order should be displayed as an offer for 50.00, but will match any bid >= 49.75 Discretionary pricing can also be used when pegging an order - for example to indicate that a buy order is to be displayed as pegged to the bid minus 0.25, but can be matched by anything <= the offer, set OrdType=Pegged, ExecInst = Primary Peg, PegDifference = -0.25, DiscretionInst = Related to market price and DiscretionOffset = 0.

See Appendix D: Order State Change Matrices

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 on working orders
5. reject orders
6. report post-trade 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 report contains three fields which are used to communicate both the current state of the order as understood by the broker and the purpose of the message: OrdStatus, ExecType and ExecTransType.

In an execution report the OrdStatus is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in the OrdStatus field. The order statuses are as follows (in highest to lowest precedence):

The ExecType is used to identify the purpose of the execution report message. To transmit a change in OrdStatus for an order, the broker(sell side) should send an Execution Report with the new OrdStatus value in both the ExecType AND the OrdStatus fields to signify this message is changing the state of the order. The only exception to this rule is that when rejecting a cancel or cancel/replace request the CancelReject message is used both to reject the request and to communicate the current OrdStatus. An ExecType of Pending Cancel or Pending Replace is used to indicate that a cancel or cancel/replace request is being processed. An ExecType of Canceled or Replace is used to indicate that the cancel or cancel/replace request has been successfully processed.

Execution information (e.g. new partial fill or complete fill) should not be communicated in the same report as one which communicates other state changes (such as pending cancel, pending replace, canceled, replaced, accepted, done for day etc).

Any fills which occur and need to be communicated to the customer while an order is “pending” and waiting to achieve a new state (i.e. via a Order Cancel Replace (aka Order Modification) Request) must contain the “original” (current order prior to state change request) order parameters (i.e. ClOrdID, OrderQty, Price, etc). These fills will cause the CumQty and AvgPx to be updated. An order cannot be considered replaced until it has been explicitly accepted and confirmed to have reached the replaced status via an execution report with ExecType = ‘Replace’, at which time the effect of the replacement (ClOrdID, new quantity or limit price etc) will be seen. Note that due to the precedence rules above, in reports where ExecType=Replace, OrdStatus may not = Replaced.

Requests to cancel or cancel/replace an order are only acted upon when there is an outstanding order quantity. Requests to replace the OrderQty to a level less than the CumQty will be interpreted by the broker as requests to stop executing the order. Requests to change price on a filled order will be rejected (see Order Cancel Reject message type). The OrderQty, CumQty, LeavesQty, and AvgPx fields should be calculated to reflect the cumulative result of all versions of an order. For example, if partially filled order A were replaced by order B, the OrderQty, CumQty, LeavesQty, and AvgPx on order B’s fills should represent the cumulative result of order A plus those on order B.

The general rule is: OrderQty = CumQty + LeavesQty.

There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay (e.g. on a day order), Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0.

Execution report messages are transmitted with a transaction type (ExecTransType) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID, and are used to cancel or correct a previously reported execution. 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, ExecType, 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. Note: ExecTransType of Cancel should not be used to cancel a previous ExecutionRpt with ExecTransType of Cancel (e.g. cannot cancel a cancel).

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. If a single execution is corrected more than once, ExecRefID should refer to the ExecID of the last corrected ExecutionRpt (same convention as ClOrdID and OrigClOrdID). To correct an ExecutionRpt which was previously canceled, an ExecutionRpt with ExecTransType=New should be sent (e.g. cannot send ExecTransType=Correct for an ExecutionRpt with ExecTransType=Cancel). Note: Data reported in the CumQty, LeavesQty, 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.

See Appendix D: Order State Change Matrices for examples of key state changes, processing of cancel and cancel/replace requests, and for execution cancel/corrects.

An ExecutionRpt with ExecType = Restated represents an ExecutionRpt sent by the sellside communicating a change in the order or a restatement of the order’s parameters without an electronic request from the customer. ExecRestatementReason must be set. This is used for GT orders and corporate actions (see below), changes communicated verbally to the sellside either due to normal business practices or as an emergency measure when electronic systems are not available, repricing of orders by the sellside (such as making Sell Short orders compliant with uptick / downtick rules), or other reasons (Broker option). ExecRestatementReason can also be used to communicate unsolicited cancels.

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. Unlike ClOrdID/OrigClOrdID which requires a chaining through Cancel/Replaces and Cancels, OrderID and SecondaryOrderID are not required to change through changes to an order.

The underlying business assumption of orders that can trade over multiple days, such as GTC and Good Till Date orders expiring on a future trading date (henceforth referred to as GT orders) is that a GT order that is not fully executed and has not been canceled and has not expired on a given day remains good for the broker to execute the following day. Note that the concept of day is determined by the market convention, which will be security specific. At the end of each trading day, once the order is no longer subject to execution, the broker may optionally send an Execution Report with ExecType=Done for Day(3). When the ExpireDate or ExpireTime of a Good Till Date order is reached, or a GTC order reaches a maximum age, the order is considered expired and the broker may optionally send an Execution Report with ExecType and OrdStatus=Expired(C).

In handling GT orders, the OrderQty, CumQty and AvgPx fields will represent the entirety of the order over all days. The fields DayOrderQty, DayCumQty, and DayAvgPx can be used on days following the day of the first trade on a GT order. Prior to the start of business each day, for all GT orders that have partial fills on previous days, DayCumQty and DayAvgPx are set to zero, and DayOrderQty becomes the LeavesQty. The following relationship holds: DayOrderQty = OrderQty – (CumQty – DayCumQty). Since (CumQty – DayCumQty) represents the volume traded on all previous days, DayOrderQty = OrderQty – Volume traded on all previous days. Note that when changing the quantity of an order, both OrderQty and DayOrderQty will change. Requests to change or cancel an order will be made in terms of the total quantity for the order, not the quantity open today. For example, on an order where OrderQty=10000 and 2000 shares trade during the previous days, a request to change OrderQty to 15000 will mean that 13000 shares will be open. See Appendix D – Order State Change Matrices for examples of canceling and changing GT orders partially filled on previous days.

A Cancel on an execution (trade bust) happening the same day of the trade will result in CumQty and DayCumQty each decreasing by the quantity busted, and LeavesQty increasing by the quantity busted. OrderQty and DayOrderQty will remain unchanged. If the business rules allow for a trade bust to be reported on a later date than the trade being busted, the OrderQty and DayCumQty will remain unchanged, the LeavesQty and DayOrderQty will increase by the quantity busted, and the CumQty will decrease by the quantity busted.

If bilaterally agreed between counterparties, a broker may wish to transmit a list of all open GT orders, permitting reconciliation of the open orders. Typically this transmission may occur at the end of the trading day or at the start of the following trading day. There is no expected response to such retransmission; in the event of a reconciliation problem this should be resolved manually or via the DK message. Assuming no corporate actions have occurred, the broker will send an Execution Report with ExecType = Restated (D) and ExecRestatementReason = GT renewal / restatement (no corporate action) (1) for each open GT order. These Execution Reports may have DayCumQty and DayAvgPx restated to zero, and DayOrderQty restated to LeavesQty if the transmission occurs at the start of the following business day. The broker has the option of changing the OrderID and SecondaryOrderID fields, or leaving them unchanged. If they are changed, then the buy-side should use these new ID fields when sending Order Cancel Request, Order Cancel/Replace Request, and Order Status Request messages.

In the case of a corporate action resulting in the adjustment of an open GT order, the broker will send an Execution Report with ExecType = Restated (D) and ExecRestatementReason = GT Corporate action (0) with the order’s state after the corporate action adjustment. In the case of stock splits, OrderQty, CumQty, AvgPx, and LeavesQty will be adjusted to reflect the order’s state in terms of current shares, not pre-split shares. See Appendix D – Order State Change Matrices for examples of GT order restatement with and without a corporate action.

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.

Cancel/Replace will be used to change any valid attribute of an open order (i.e. reduce/increase quantity, change limit price, change instructions, etc.) It can be used to re-open a filled order by increasing OrderQty.

An immediate response to this message is required. It is recommended that an ExecutionRpt with ExecType=Pending Replace be sent unless the Order Cancel/Replace Request can be immediately accepted (ExecutionRpt with ExecType=Replaced) or rejected (Order Cancel Reject message).

The Cancel/Replace request will only be accepted if the order can successfully be pulled back from the exchange floor without executing. Requests which cannot be processed will be rejected using the Cancel Reject message. The Cancel Reject message should provide the ClOrdID and OrigClOrdID values which were specified on the Cancel/Replace Request message for identification.

Note that while it is necessary for the ClOrdID to change and be unique, the broker’s OrderID field does not necessarily have to change as a result of the Cancel/Replace request.

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. The fields which can be changed via this message are:

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

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 request will only be accepted if the order can successfully be pulled back from the exchange floor without executing.

A cancel request is assigned a ClOrdID and is treated as a separate entity. If rejected, the ClOrdID of the cancel request will be sent in the Cancel Reject message, as well as the ClOrdID of the actual order in the OrigClOrdID field. The ClOrdID assigned to the cancel request must be unique amongst the ClOrdID assigned to regular orders and replacement orders.

An immediate response to this message is required. It is recommended that an ExecutionRpt with ExecType=Pending Cancel be sent unless the Order Cancel Request can be immediately accepted (ExecutionRpt with ExecType=Canceled) or rejected (Order Cancel Reject message).

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

When rejecting a Cancel/Replace Request, the Cancel Reject message should provide the ClOrdID and OrigClOrdID values which were specified on the Cancel/Replace Request message for identification

The execution message responds 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 message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts. It can also be used as a confirmation message through which third parties can communicate execution and settlement details between trading partners. In addition, the allocation message can be sent by the broker to communicate fees and other details that can only be computed once the sub-account breakdowns are known.

Allocation is typically communicated Post-Trade (after fills have been received and processed). It can, however, also be communicated Pre-Trade (at the time the order is being placed) to specify the account(s) and their respective order quantities which make up the order. This is a regulatory requirement in certain markets and for certain types of securities.

An allocation message can be submitted as preliminary, calculated, calculated without preliminary, new, cancel or replace. The AllocTransType field indicates the purpose of the message. When submitting calculated, replace, or cancel AllocTransType messages the RefAllocID field is required. Replacement allocation messages must contain all data for the replacement allocation. Calculated allocations should have a unique AllocID and use RefAllocID to specify the AllocID from the preliminary. Calculated without preliminary are sent unsolicited from the sellside and do not require RefAllocID.

The allocation message contains repeating fields for each order, sub-account and individual execution. The repeating fields are shown below in typeface Bold-Italic and indented with the 🡪 symbol. The field’s relative position in the message is important. For example, 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.

Pre-Trade Allocation consists of the following steps:

• Buyside sends a New Order request message specifying one or more AllocAccount and AllocShares values within the repeating group designated by NoAllocs.
• Sellside sends Execution Report messages for the “New” and resulting fills.
• Post-Trade Allocation messaging takes place

Post-Trade Allocation can be computed via one of two methods:

1. Using Average Price: Each AllocAccount has a single AllocAvgPx
2. Using Executed Price: Combination of each AllocAccount and AllocPrice (unique LastPx) (e.g. Japan)

Post-Trade Allocation supports three different message flows:

1. Buyside initiated without Misc Fees
2. Buyside-initiated with Misc Fee computation
3. Sellside-initiated

See Appendix K: Example Usage of Allocations for more examples and details.

The allocation ACK message is used to acknowledge the receipt and status of an allocation message 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 NewOrderList Message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention the New Order - List message is sent after the bidding process has been completed, by telephone or electronically. The New Order - List message enumerates the stocks, quantities, direction for the trade and may contain pre-allocation information.

This message may also be used as the first message for the transmission of a program trade where the bidding process has been done by means other than FIX. In this scenario the messages may either be used as a staging process, in which case the broker will start execution once either a ListExecute is received or for immediate execution, in which case the orders will be executed on receipt.

In the “Disclosed” convention the New Order - List message is sent before the bidding process is started, by telephone or electronically. The New Order - List 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.

See Appendix N – Program/Basket/List Trading for an example.

The list status message is issued as the response to a List Status Request message sent in an unsolicited fashion by the sell-side. It 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. The relative position of the repeating fields is important in this message, i.e. each instance of ClOrdID, CumQty, LeavesQty, CxlQty and AvgPx must be in the order shown below.

Description of ListOrderStatus field values:

• “InBiddingProcess”: indicates that a list has been received and is being evalutated for pricing. It is envisaged that this status will only be used with the "Disclosed" List Order Trading model.
• “ReceivedForExecution”: indicates that a list has been received and the sell side is awaiting the instruction to start working the trade. It is envisaged that this status will be used under both models.
• “Executing”: indicates that a list has been received and the sell side is working it.
• “Canceling”: indicates that a List Cancel Message has been received and the sell side is in the process of pulling any orders that were being worked. The status of individual order can be found out from the detail repeating group.
• “AllDone”: indicates that a list has been executed as far as possible for the day.
• “Alert”: used whenever any of the individual orders have a status that requires something to be done. For instance alert would be used when a buy-side firm has submitted a list that has individual stock reject that have not been addressed.
• “Rejected” used when a response cannot be generated. For example when the ListID is not recognised. The text field should include an explanation of why the Request s been rejected.

The list execute 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 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 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.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

• The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
  • Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
  • e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
  • CCY1 and CCY2 are ISO currency codes
• The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
• See Appendix O – Foreign Exchange Trading
• 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.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

• The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
  • Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
  • e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
  • CCY1 and CCY2 are ISO currency codes
• The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
• See Appendix O – Foreign Exchange Trading

Orders can be generated based on Quotes. Quoted orders include the QuoteID and are OrdType=Previously Quoted or Forex - Previously Quoted.

Example: Quote for Single Security
QuoteID=XXX
QuoteReqID=YYY
Symbol=AA
MaturyMonthYear=199901
StrikePrice=25.00
PutOrCall=1
BixPx=5.00
OfferPx=5.25
BidSize=10
OfferSize=10

The Don’t Know Trade (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.

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.

The Settlement Instructions message provides either the broker’s or the institution’s instructions for trade settlement. The SettlInstSource field indicates if the settlement instructions are the broker’s or the institution’s. 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.

The Settlement Instructions message can be used in one of two modes (SettlInstMode):

1. To provide “standing instructions” for the settlement of trades occurring in the future, messages should include some combination of.

• AllocAccount
• LastMkt
• Side
• SecurityType
• SettlLocation
• SettlDeliveryType
• EffectiveTime

2. To provide settlement instructions for a specific Allocation Account either as overriding or standing instructions to support matching. The following key should be used to tie the settlement instructions to the corresponding Allocation message.

   (TradeDate + AllocID + AllocAccount)

The Settlement Instruction detail can be either explicitly specified (via SecuritySettl* and CashSettl* fields) or can exist on within an independent standing instructions database and can be referenced via the StandInstDbType, StandInstDbName, and StandInstDbID fields.

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

A QuoteSet specifies the first level of repeating tags for the Mass Quote message. It represents a group of related quotes and can, for example, represent an option class.

Each QuoteSet contains an optional repeating group of QuoteEntries which can represent an option series.

It is possible the number of Quote Entries for a Quote Set (option class) could exceed one’s physical or practical message size. It may be necessary to fragment a message across multiple quote messages. Message size limits must be mutually agreed to with one’s counterparties.

The grouping of quotes is as follows:

• NoQuoteSets – specifies the number of sets of quotes contained in the message
  • QuoteSetID – Is a unique ID given to the quote set
  • Information regarding the security to which all of the quotes belong
  • TotQuoteEntries – defines the number of quotes for the quote set across all messages
  • NoQuoteEntries – defines the number of quotes contained within this message for this quote set
    • QuoteEntryID – Is a unique ID given to a specific quote entry
    • Information regarding the specific quote (bid/ask size and price)

If there are too many Quote Entries for a Quote Set to fit into one physical message, then the quotes can be continued in another Mass Quote message by repeating all of the QuoteSet information and then specifying the number of Quote Entries (related symbols) in the continued message. The TotQuoteEntries is provided to optionally indicate to the counterparty the total number of Quote Entries for a Quote Set in multiple quote messages. This permits, but does not require, a receiving application to react in a stateful manner where it can determine if it has received all quotes for a Quote Set before carrying out some action. However, the overall approach to fragmentation is to permit each mass quote message to be processed in a stateless manner as it is received. Each mass quote message should contain enough information to have the Quote Entries applied to a market without requiring the next message if fragmentation has occurred. Also, a continued message should not require any information from the previous message.

Maximum message size for fragmentation purposes can be determined by using the optional MaxMessageSize field in the Logon message or by mutual agreement between counterparties.

Requesting Acknowledgement for Mass Quotes

Applications can optionally support acknowledgement of quotes using the QuoteResponseLevel tag. The QuoteResponseLevel is used to specify the level of acknowledgement requested from the counterparty. A QuoteResponseLevel of 0 indicates that no acknowledgement is requested. A ResponseLevel of 1 requests acknowledgement of invalid or erroneous quotes. A QuoteResponseLevel of 2 requests acknowledgement of each Mass Quote message.

See Appendix H: Mass Quote Message Scenarios

Notes on usage for Options Markets:

It is assumed that for many options markets, the Mass Quote message will be used to generate quotes in high volumes in an unsolicited manner. This means that multiple quotes will be sent to the counterparty (an exchange) without acknowledgement. The Mass Quote message can be used to send quotes for multiple classes, each with multiple series.

Example: Multiple Option Series for a single Option Class (No Fragmentation)

• QuoteID=XXX
• QuoteReqID=YYY
• NoQuoteSets=1
  • QuoteSetID=1
  • Symbol=AA
  • TotQuoteEntries=2
  • NoQuoteEntries=2
  • Other quote set fields
  • QuoteEntryID=1
    • MaturyMonthYear=199901
    • StrikePrice=25.00
    • PutOrCall=1
    • BixPx=5.00
    • OfferPx=5.25
    • BidSize=10
    • OfferSize=10
  • QuoteEntryID=2
    • MaturyMonthYear=199901
    • StrikePrice=30.00
    • PutOrCall=1
    • BixPx=3.00
    • OfferPx=3.25
    • BidSize=10
    • OfferSize=10

Example: Multiple Option Series for a single Option Class (Fragmentation)

First Message:

• QuoteID=XXX
• QuoteReqID=YYY
• NoQuoteSets=1
  • QuoteSetID=1
  • Symbol=AA
  • TotQuoteEntries=3
  • NoQuoteEntries=2
  • Other quote set fields
  • QuoteEntryID=1
    • MaturyMonthYear=199901
    • StrikePrice=25.00
    • PutOrCall=1
    • BixPx=5.00
    • OfferPx=5.25
    • BidSize=10
    • OfferSize=10
  • QuoteEntryID=2
    • MaturyMonthYear=199901
    • StrikePrice=30.00
    • PutOrCall=1
    • BixPx=3.00
    • OfferPx=3.25
    • BidSize=10
    • OfferSize=10

Second Message:

• QuoteID=XXX
• QuoteReqID=YYY
• NoQuoteSets=1
  • QuoteSetID=1
  • Symbol=AA
  • Other quote set fields
  • TotQuoteEntries=3
  • NoQuoteEntries=1
  • QuoteEntryID=3
    • MaturyMonthYear=199901
    • StrikePrice=35.00
    • PutOrCall=1
    • BixPx=2.00
    • OfferPx=2.25
    • BidSize=10
    • OfferSize=10

The Quote Cancel message is used by an originator of quotes to cancel quotes.

The Quote Cancel message supports cancelation of:

• All quotes
• Quotes for a specific symbol or security ID
• All quotes for a security type
• All quotes for an underlying

Canceling a Quote is acccomplished by indicating the type of cancelation in the QuoteCancelType field.

The Quote Cancelation only applies to quotes made by the current FIX user.

Options usage notes:

Normal usage would be to cancel the quotes for a symbol. This is the reason that the use of further nesting similar to the quote is not used in this message. You are able to cancel quotes for specific series by specifying each option series in the repeating group.

It is recommended that all Cancel messages be acknowledged using the Quote Acknowledgement message

The quote status request message is used by the institution to generate an execution report that contains the quote status message back from the counterparty. It is used to retrieve the status of the originating party’s quotes and not to obtain market data information.

An optional response to Quote, Mass Quote, Quote Cancel, and Quote Request message is the Quote Acknowledgement message. The use of the Quote Acknowledgement message is optional per Quote, Mass Quote, or Quote Request message. It is intended to provide application level acknowledgement of quotes. The level of response requested from a receiver of the Quote Acknowledgement message is specified in the QuoteResponseLevel tag.

Some systems allow the transmission of real-time quote, order, trade and/or other price information on a subscription basis. A Market Data Request is a general request for market data on specific securities or forex quotes.

A successful Market Data Request returns one or more Market Data messages containing one or more Market Data Entries. Each Market Data Entry is a Bid, an Offer, a Trade associated with a security, the opening, closing, or settlement price of a security, the value of an index, or the trading session high price, low price, or VWAP. Market Data Entries have a price and usually a quantity associated with them. For example, in an order book environment, requesting just the top of book will result in only two active Market Data Entries at a time – one for the best Bid and one for the best Offer. For a full book, the Bid and Offer side may each have several Market Data Entries. Each Market Data Entry might represent an aggregate for each price tier, and only one Market Data Entry per side per price would be active at a time. This is referred to as an Aggregated book. Or several Market Data Entries at one price tier could each represent a broker, Market Maker, ECN or Exchange’s quote in a security, or individual orders in a book. This is a Non-Aggregated book. Alternately, a Market Data Entry could represent a completed trade in a security, the value of an index, the opening, closing, or settlement price of an instrument, or the trading session high price, low price, or VWAP.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

• The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
• Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
• e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
• CCY1 and CCY2 are ISO currency codes
• The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
• See Appendix O – Foreign Exchange Trading

A Snapshot causes the current state of the market to be sent. A Snapshot + Updates causes the current state of the market to be sent, and any updates as they occur, until the client requests that the Snapshot + Updates be disabled.

When just a Snapshot is requested, the complete data for only one security or forex quote will be returned per FIX Market Data message.

When Snapshot + Updates is requested, updates may be full or incremental:

• Full Refresh. This mode is optimized to trade off increased bandwidth for simplicity in processing and is intended for requests on only a few instruments. Each FIX Market Data message in response to the request will contain the complete data requested for one instrument. If more than just the top of book is requested, this means that both sides, and all price tiers, must be reported in that Market Data message.
• Incremental Refresh. This mode is optimized for handling requests for many instruments while conserving bandwidth. Each Market Data Entry is assigned an MDEntryID unique among all other active entries, and several incremental updates of entries for different instruments can be included in one FIX Market Data message.

One specifies whether a list of trades, a 1-sided or 2-sided book, index, opening, closing, settlement, high, low and VWAP prices should be returned by using the NoMDEntryTypes field and MDEntryType repeating group to list all MDEntryType values that should be returned.

While this document specifies many parameters and modes in a request, the recipient of the request is not required to support all of them. A Market Data Request Reject may be sent in response to a request indicating that it cannot be honored.

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, or any combination of these.

Market Data messages sent as the result of a Market Data Request message are tagged with the appropriate MDReqID. Unsolicited Market Data messages can be sent; in such cases, MDReqID will not be present.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

• The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
• Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
• e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
• CCY1 and CCY2 are ISO currency codes
• The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
• See Appendix O – Foreign Exchange Trading

Market Data messages include many fields, and not all are required to be used. A firm may, at its option, choose to send the minimum fields required, or may choose to send more information, such as tick direction, tagging of best quotes, etc.

Market Data messages can take two forms. The first Market Data message format used for a Snapshot, or a Snapshot + Updates where MDUpdateType = Full Refresh (0) is as follows:

• For Market Data Requests where a Bid or Offer is added, changed, or deleted, every update to a Market Data Entry results in a new Market Data message that contains the entirety of the data requested for that instrument, not just the changed Market Data Entry. In other words, both sides of the market, or just one side in the case of a request of only bids or offers, for the depth requested, must be sent in one FIX Market Data message.
• A Market Data message may contain several trades, an index value, opening, closing, settlement, high, low, and/or VWAP price for one instrument, but only one instrument per message.
• Messages containing bids and/or offers cannot contain trades, index value, opening, closing, settlement, high, low, and/or VWAP prices.

The second Market Data message format is used for incremental updates. Market Data Entries may have an MDEntryID 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 would be populated, or the MDEntryID may change, in which case MDEntryID will contain the new ID, and MDEntryRefID will contain the ID of the Market Data Entry being changed. An MDEntryID can be reused within a day only if it has first been deleted.

Alternately, in the case of displaying the best quotes of Market Makers or Exchanges, and not orders in an order book, MDEntryID can be omitted for simplification. In this case, a New Market Data Entry will replace the previous best quote for that side and symbol for the specified Market Maker or Exchange. Deletion of a Market Data Entry would not specify an MDEntryID or MDRefID, and would remove the most recent Market Data Entry for the specified symbol, side, and Market Maker or Exchange. A Change of a Market Data Entry would not specify an MDEntryID or MDRefID, and would replace the most recent Market Data Entry for the specified symbol, side, and Market Maker or Exchange.

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, quotes, index values, open, close, settlement, high, low, and VWAP prices, so long as the maximum FIX message size is not exceeded. All of these types of Market Data Entries can be changed and deleted.

Adding, Changing, or Deleting Market Data Entries requires special consideration of the MDEntryPositionNo field, if the sender wishes to specify it and the receiver wishes to process it. For example, assume ten bids for a security. Adding a bid with MDEntryPositionNo = 4 requires the receiver to shift down other Market Data Entries, i.e. the Market Data Entry in the 4th display position will shift to the 5th, the 5th shifts to the 6th, etc. until the 10th shifts to the 11th. The sender must NOT send a modification of all MDEntries in the 4th through 10th positions just to update the MDEntryPositionNo field; the recipient must infer the change. Similarly, deleting a Market Data Entry in the 7th position causes the 8th Market Data Entry to move into the 7th position, the 9th to shift into the 8th position, etc. A Change of the MDEntryPositionNo field of a Market Data Entry causes the Market Data Entries lying between the old and new positions to shift. For instance, a Market Data Entry that occupied the 5th position is changed to the 8th position. This means that the Market Data Entry in the 6th position shifts up to the 5th position, the 7th position shifts to the 6th, and what was in the 8th position shifts into the 7th to make room for the changed Market Data Entry that is being moved into the 8th position.

Several techniques are employed to conserve bandwidth:

• An instrument only needs to be identified when a Market Data Entry is first created.
• In cases where the identification of an instrument is long, the sender has the option of referring to a previous active Market Data Entry of the same instrument instead of duplicating the information.
• A new Market Data Entry will default to the same instrument of the previous Market Data Entry in the same Market Data message if neither Symbol nor MDEntryRefID are specified.
• In the case of a change in a Market Data Entry, only the fields changing need to be sent as part of the change to the Market Data Entry; for example, a change of the MDEntrySize but not the MDEntryPx or other attributes of the Market Data Entry only requires listing the MDEntrySize field, in addition to MDUpdateAction and MDEntryID if used in the original Market Data Entry
• When creating a new Market Data Entry with a future or option instrument similar to the instrument in the previous Market Data Entry in the same FIX message, one may send just symbol identification fields that have changed, such as MaturityMonthYear, MaturityDay, PutOrCall, StrikePrice, OptAttribute, and SecurityExchange.
• MDEntryID can be reused within the same day after it is deleted. This is helpful for distributing order books because an order that is suspended and then reinstated can have its MDEntryID deleted upon suspension and later reused, with MDUpdateAction = New(0) upon reinstatement, thus avoiding having to re-map the MDEntryID.

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 Security Definition Request message is used for the following:

1. Request a specific Security to be traded with the second party. The request security can be defined as a complex security made up of one or more underlying securities.
2. Request a list of the Security Types that can be traded with the second party.
3. Request a list of Securities that can be traded with the second party. This request can optionally be qualified with Symbol, TradingSessionID, SecurityExchange, and Security Type.

See Appendix I: Security Definition, Security Status, and Trading Session Message Scenarios

The Security Definition message is used for the following:

1. Accept the security defined in a Security Definition message.
2. Accept the security defined in a Security Definition message with changes to the definition and/or identity of the security.
3. Reject the security requested in a Security Definition message
4. Return a list of Security Types
5. Return a list of Securities

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 Request message contains a SubscriptionRequestType field. This tells the counter party what type of request is being made:

• 0 – indicates that the requestor only wants a snapshot or the current status.
• 1 – indicates that the requestor wants a snapshot (the current status) plus updates as the status changes. This is similar to subscribing for information and can be implemented in applications as a subscription mechanism.
• 2 – indicates that the requestor wishes to cancel any pending snapshots or updates – in essence making this an unsubscribe operation.

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.

It is expected that the Security Status message that is sent as a response should indicate what type of request is being provided. If the message is being generated as a result of a RequestType =1, then the response should have a RequestType=1 to permit the requestor to determine why the message was sent.

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 Request message can be used to inquire the trading status of a trading party. The Trading Session Status message can be used to subscribe to updates to the status of a trading session by setting the RequestType field to 1.

To list the securities available during a particular trading session, see the SecurityDefinitionRequest message.

The Trading Session Status 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 Trading Session Status can provide an optional repeating group of securities that are available for trading during that session.

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

In the “Non disclosed” convention (e.g. US/European model) the BidRequest message can 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 entry repeating group is used to define liquidity of the program. See Appendix N – Program/Basket/List Trading for an example.

In the “Disclosed” convention (e.g. Japanese model) the BidRequest message can be used to request bids based on the ListOrderDetail messages sent in advance of BidRequest message. In the “Disclosed” convention the list repeating group is used to define which ListOrderDetail messages a bid is being sort for and the directions of the required bids.

The pair of fields SideValue1 and SideValue2 are used to show the monetary total value in either direction (buy or sell) of the transaction without revealing whether it is the buy-side institution intention to buy or sell.

The two repeating groups, NoEntries and NoBidComponents are mutually exclusive and a function of which bidding model is being used. If the “Non Disclosure” method is being used the portfolio of stocks being traded is described by a number of “bid desciptors” entries. If the “Disclosure” Method is being used the portfolio is fully disclosed, except for side, by a number of “list” entries enumerating the lists that list the stocks to be traded.

A BidRequest message with BidRequestTransType cancel may be used to indicate to sell side firms that they no longer need to store details of the BidRequest as they have either lost the bid or the List has been canceled.

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

In the “Non disclosed” convention the Bid Response message can be used to supply a bid based on the sector, country, index and liquidity information contained within the corresponding bid request message. See Appendix N – Program/Basket/List Trading for an example.

In the “Disclosed” convention the Bid Response message can be used to supply bids based on the List Order Detail messages sent in advance of the corresponding Bid Request message.

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

See the session-level Reject message

It should NOT be used in the following situations:

Note the only exception to this rule is in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system. In this situation a Business Message Reject with BusinessRejectReason = “Application not available at this time” can be issued if the the system is unable to send the specific “reject” message listed above due to this condition.

Messages which can be referenced via the Business Message Reject message are:

Scenarios for Business Message Reject:

Whenever possible, it is strongly recommended that the cause of the failure be described in the Text field (e.g. “UNKNOWN SYBMOL: XYZ”).