Implementation Guide

Contents | Previous | Next | Terms of Use

10. The FIX process for fixed income

Introduction

• US Treasury Bonds
• US Corporate Bonds
• Municipal Securities
• Agency Securities
• To-Be-Announced (TBA) Mortgage Backed Securities
• Euro Sovereign Bonds
• Euro Corporate Bonds
• US and European Commercial Paper

The usage models are described as between two counterparties, an Initiator and a Respondent.

Note that this section should be used as a starting point and serves merely to provide guidance in the reader's FIX implementation. Full details can be found in the FIX Protocol Specification Documents.

Message Dialog

• One party sending out offerings to their clients and their clients responding to the offerings.
• An interested party initiating an inquiry or a bid/offer request. Once the dialog is initiated a trade could be consummated. The allocation of the trade could be conducted "pre-trade" or "post-trade" directly with the trading counterparty.

The diagrams below attempt to illustrate the various dialogs that can happen to facilitate a FI trade and the message flows to use depending on the initiation point of the dialog.

Note that the diagrams will also show, via the green colored circles, the next step in the message dialog and do not show error conditions (i.e. one party receiving an unknown CUSIP) that can occur during the dialog.

Indication of Interest (Offerings)

Offerings can be sent by the Respondent to an Initiator on a continuous basis as long as the Initiator wants to receive them. The Initiator has the option to ignore the messages sent by not responding or to respond to an offering of interest by sending a Quote Response message back to the Respondent to either "hit" or "lift" the offering. Figure 1 below illustrates the message flow. The Respondent will pickup on the message dialog flow at "B" in the Negotiated Trade diagram (see next section).

Figure 1: Indication of Interest/Offerings

Negotiated Trade /Inquiry/Bid or Offer Request

An inquiry, bid or offer request/wanted begins with a Quote Request from the Initiator. It is possible for the Respondent to send an unsolicited Quote message to their counterparty to initiate the negotiated trade dialog, however, this arrangement should be bilaterally agreed upon by the counterparties involved.

In the negotiation dialog, the Initiator would send a Quote Request message to the Respondent to inquire about a certain security, inquire for a list of securities that meet certain stipulations and parameters, request a bid or offer or request a quote on a certain security. Should the Respondent choose not to provide a quote a Quote Request Reject can be sent with the appropriate reject reason code set. At this point the current dialog would terminate. Alternatively the Respondent can respond to the Quote Request with a Quote message. The Quote message would provide the pricing levels for the securities requested by the Initiator.

The Initiator will respond to the Quote from the Respondent via the use of the Quote Response message type. The Quote Response message type can be used to end the dialog, "hit/lift" the Quote, or counter the Quote. A "hit/lift" response from the Initiator indicates to the Respondent that the Initiator agrees with the price level and the quantity, and want to complete a trade. On the other hand, if the Initiator responded with a counter offer then the negotiation can continue until one party decides to terminate the dialog or a trade is completed.

To a "hit/lift" or counter message from the Initiator, the Respondent can respond with another "counter" message using the Quote message type, end the negotiation dialog with a Quote Status Report, or give the Initiator an Execution Report message indicating that the trade has been completed. This Execution Report message may or may not include calculations for information such as accrued interest, gross trade amount, etc.

Lastly, if the Initiator deems that there are discrepancies in the Execution Report message received from the Respondent, the Initiator may use the Don't Know Trade (a.k.a. DK Trade) message type to "reject" the trade information. Resolving the error or discrepancies would be done manually and is currently out of scope for the suggested use of the Protocol.

The diagram, Negotiated Trade, on the following page illustrates this flow with some additional details of what values within certain fields can be used.

Figure 2: My Bid/Offer

Figure 3: Negotiated Trade/Bid or Offer Request

Out-of-Band Negotiated Order

When an order is placed by the Initiator using the New Order message type the Respondent could either accept the order or reject the other using the Execution Report message type. If the order is rejected the dialog ends. If the order is accepted the negotiation can begin out-of-band or "offline". When the negotiation is completed and the terms of the trade are agreed upon the Respondent would send the Initiator an Execution Report message to confirm that the trade has been completed. The terms of the trade are reiterated in the Execution Report message.

In the event that the Initiator deems that there are discrepancies in the Execution Report message received from the Respondent, the Initiator may use the Don't Know Trade (a.k.a. DK Trade) message type to "reject" the trade information. Resolving the error or discrepancies would be done manually and is currently out of scope for the suggested use of the Protocol.

Figure 4: Out-of-Band Negotiated Trade

Allocation Instructions

1. Pre-allocated Order - in this option the Initiator would communicate the allocation instructions within the New Order message when the order is placed with the Respondent.
2. Pre-trade allocation - in this option the Initiator would communicate the allocation instructions to the Respondent in a separate message using the Allocation message. The Allocation message is sent after the order is placed with the Respondent but before the trade is completed by the Respondent.
3. Post-trade allocation - in this option the Initiator would communicate the allocation instructions to the Respondent in a separate message using the Allocation message after the trade has been completed by the Respondent.

For the Initiator options 2 and 3 represents the same message flow. The main difference is when the Allocation message is sent - in option 2 it is sent prior to the trade being completed and in option 3 it is sent after the trade has been completed.

Once the trade is completed and the Respondent is ready to act on the allocation instructions, assuming no errors in the allocation instructions from the Initiator, the message flow for the Respondent is the same regardless of which option is used by the Initiator to communicate those allocation instructions.

Note that these options work for fixed income because of FI's simple trading practices - there is no concept of "done for day", one set of allocations is applied to a single order usually filled in a single execution.

In the Pre-allocated Order scenario the Initiator would send a New Order message that includes the allocation information needed by the Respondent to allocate the trade once the trade is completed. Note, however, that if even one account cannot be identified, or the quantity of one allocation instance does not meet minimum quantity/minimum increment rules for the instrument, or the sum of allocated quantities does not equal the block trade quantity, the entire request must be rejected. If erroneous allocations are sent via the New Order message, the entire New Order message is rejected using the Execution Report message with the appropriate reject code.

If the pre-allocated Order is accepted and filled, the Respondent communicates that information to the Initiator using the Execution Report message type, setting all the appropriate status values per standard Protocol usage.

At this point in the message flow the Respondent would begin to allocate the trade according to the allocation instructions already provided in the New Order message and communicating that information back to the Respondent according to the message flow shown in Figure 5, starting with the AllocationReport.

Figure 5: Allocations

In the Pre-trade allocation scenario the Initiator would send the allocation instructions, after placing the order but before the Execution Report message indicated that the trade is completed, to the Respondent using the AllocationInstruction message type. On the other hand, in the Post-trade allocation scenario the Initiator would send the allocation instructions to the Respondent after receiving the Execution Report message indicated that the trade is completed - again using the AllocationInstruction message type.

Before accepting the request the Respondent should determine that all accounts are known, the quantity of each allocation instance meets minimum quantity/minimum increment rules for the instrument and the sum of allocated quantities equals the block trade quantity. If any error is found the Respondent must reject the entire Allocation using the AllocationInstructionAck message with the appropriate reject reason code. In this event, whether the trade that has been completed or is pending completion, the order is a still a live order. A rejection of the AllocationInstruction message does not equate to a reject of the order placed in this case. The Initiator can send a new AllocationInstruction message with the correct instructions and information to the Respondent.

If the Respondent accepts the AllocationInstruction, the message flow would continue as shown in Figure 5 with the Respondent sending the AllocationReport message to communicate the sub-account level calculations for net monies and accrued interest if appropriate. At this stage the Initiator still has the option to reject the validated/calculated allocation message due to differences in calculations of net money, gross amounts, etc., for each of the allocated sub-accounts. Alternatively the Initiator can acknowledge back to the Respondent that the validated/calculated message is accepted. Both the Initiator's response is communicated via the use of the AllocationReportAck message type.

Figure 6: Confirmation and Affirmation

Figure 6 illustrates the message flow of the confirmation process for each of the allocated account instance (the sub-accounts in the AllocationInstruction message) the Respondent would use once the allocation calculations have been confirmed by the Initiator.

The Confirmation message is an optional message that the Respondent can use to report back, confirms or raise an exception of the booking/confirm status of each of the allocation instances in the trade. When the "confirmed" status is reported to the Initiator it indicates that that piece of the allocated trade is ready to settle. Each Confirmation message will report the details of a single "ticket", therefore the account names, fees, net money and settlement information are reported using fields designated for single account trades.

Once the "confirmed" is received from the Respondent the Initiator has the final say by sending the ConfirmationAck message with the "affirmed" status. However, should the Initiator disagree with the Respondent's "confirm" the Initiator can send a reject using the ConfirmationAck message with a status of "rejected" and provide a reason for rejection.

Post Trade Reporting to a Third Party or Virtual Matching Utility ("VMU")

Figure 7: Post Trade 3rd Party or VMU Trade Reporting

The Allocation Instruction message type is used by the Initiator to report one or more orders and block trades along with associated allocations to a 3rd party or VMU for trade matching.

The Respondent will use the Trade Capture Report, or an Execution Report depending on the 3rd party's requirements, message type to report trades to a 3rd party. This notice of execution will be for block level trades.

Message Usage Details

General Usage Rules

1. PriceType field must be present when the following price fields are used in any message: Price, BidPx, OfferPx, MktBidPx, MktOfferPx, MidPx.
2. AvgPx field is usually expressed as "percent of par". Where it is not, such as in certain Confirmation scenarios, AvgParPx and LastParPx have been added for communicating the percent-of-par price that will drive settlement calculated from the negotiated price.
3. LegPriceType must be present when LegBidPx or LegOfferPx is used in the NoLegs repeating block of any message that contains this repeating block.
4. In all trade and post-trade messages where price information is being communicated, a limit or execution price is always conveyed in Price or LastPx, respectively, with PriceType set appropriately. Depending on market convention for a particular asset class other fields may be used to supplement the quote or execution price such as YieldData component block and/or SpreadOrBenchmark component block. Yield and Spread should communicate only derived information, never the negotiated price.
5. All FIX messages identified for use in FI trading except New Order Single support both single instrument trades "outrights" and trades of two instruments - one to be sold and the other to be bought as a replacement. In the US the latter are often called "swaps", in other regions they are "switches", and two-instrument trades involving the sale and purchase of futures contracts with different contract settlement months are called "rolls". The NoLegs repeating block is used to identify and link the two sides of the trade. LegSwapType can be used instead of LegQty on one side of the trade to instruct the Respondent to calculate the LegQty based on the opposite leg's quantity. To submit a new order for a swap or roll use New Order Multileg instead of New Order Single.
6. LastPxPar conditionally required in the Execution Report, Allocation, and TradeCaptureReport messages when LastPx is expressed with a PriceType other than "percent of par" (i.e. when LastPx is expressed as "discount" or "yield" PriceType then LastPxPar must be used to express the price in "percent of par" equivalent.)
7. When SettlType is not "regular" then SettlType must to be specified. SettlType "future" requires a value for SettlDate.

Indication Of Interest

Either the IOIQty or the NoLegs repeating block is required. If the NoLegs repeating block is used, put "0" (zero) in the IOIQty field. IOIQty is required and used for offerings of single instruments. The NoLegs repeating block is used for multilegs (swaps/switches/rolls). In fixed incomes use there would only be two legs - a buy leg and a sell leg.

ValidUntilTime is where the IOI sender can specify the "firm time" of the offering.

Quote Request

The ClOrdID field has been added to this message allowing the Initiator to assign a ClOrdID when requesting for quotes that are of QuoteType "Tradable" and OrdType of "Limit".

To submit a "my bid/offer" quote request the Initiator will need to specify QuoteType of "Tradable" and OrdType of "Limit". Pricing information must be specified using either one of the set of price information fields (see General Usage Rules section)

ValidUntilTime - used by the Initiator to indicate the period of time the resulting Quote must be valid for.

ExpireTime - used by the Initiator to indicate the period of time when this quote request expires

OrderQtyData component block - required when QuoteType is "Tradeable"

Quote Response

Initiator will use the QuoteRespType field to indicate what type of response this is, i.e. "hit/lift", "counter", etc.

IOIid is required if the Quote Response is used to respond to an IOI (offering) message, the field would contain the ID of the IOI message.

Fields required when QuoteRespType is "hit/lift" or "counter quote": OrderQtyData component block, Side, ValidUntilTime, ClOrdID (see paragraph below), and either one of the set of price information fields (see General Usage Rules section).

In the initial use of the "hit/lift" QuoteRespType, the Initiator is required to assign a ClOrdID. This ClOrdID will be reused throughout the negotiation process, including in the "counter", until the negotiation ends in either a fill or the negotiation dialog is terminated by either party.

In a "counter quote" to a Quote, only a limited set of data elements can change depending on the security type. Price can be expected to change, but also Instrument being quoted can change in some markets as well as Stipulations and ClearingCode within the Parties component block.

In a "counter quote" with a "my price" set, OrdType must be "Limit" and either one of the set of price information fields (see General Usage Rules section).

Quote

New Order - Single

For OrdType of "limit" either one of the set of price information fields (see General Usage Rules section) is required.

TradeDate is required and is set by the Initiator.

HandlInst is required by the Protocol but is not a required field for FI. However, for the purposes of being compliant to the Protocol the counterparties should bilaterally agree on the value to use.

New Order - Multileg

TradeDate is required and is specified by Initiator.

For the Multileg Order, if the following fields are not applicable to all legs of the trade then the NestedParties component block associated with each leg within the NoLegs repeating block will be used: Account, AccountType, NoAllocs repeating block, SettlType, and SettlDate.

Execution Report

For multilegs only use the NoLegs blocks of the Execution Report message for swaps/switches/rolls when OrdStatus is "new". The partial fill or fill (OrdStatus) Execution Report for each of the legs will be reported separated and execution price for each leg is conveyed in LastPx, AvgPx and LastPxPar, if applicable.

The following fields are required when OrdStatus is "partial", "filled" or "calculated": PriceType, Price

The following fields are required when ExecType is "trade" or "trade correct": LastQty, LastPx, AvgPx, LastPxPar (when conditionally applicable)

The following fields are required when OrdStatus is "filled" or "calculated" AND if NumDaysInterest is populated and not zero: AccruedInterestRate, AccruedInterestAmt

GrossTradeAmt and NetMoney is required when OrdStatus is "filled" or "calculated".

NumDaysInterest is required where applicable based on security type and when OrdStatus is "filled" or "calculated".

InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.

Allocation Instruction

This message should always use SettlType "future" with a value for SettlDate.

GrossTradeAmt - Initiators are required to send this information when sending Allocation post-trade.

For Financing Trades Use QtyType and ContractMultiplier if necessary to identify how quantities are to be expressed and specify in OrderQty the block cash amount to be allocated and in AllocQty the cash amount to be assigned to each fund.

Allocation Report

NetMoney is required from Respondents when reporting the Allocation back with calculations.

NumDaysInterest, AccruedInterestAmt and AccruedInterestRate is required from Respondents when reporting the Allocation back with calculations for security types where this information can be derived or is available.

InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.

AllocNetMoney is required from Respondents when reporting the Allocation back with calculations.

AllocAccruedInterestAmt is required, if the value is not zero, from Respondents when reporting the Allocation back with calculations. AllocAccruedInterestAmt should be calculated and rounded appropriately for each allocation instance. This means that the sum of AllocAccruedInterestAmt will not always match AccruedInterestAmt.

AllocInterestAtMaturity is required, if value is not zero, from Respondents when reporting the Allocation back with calculations. AllocInterestAtMaturity is required in lieu of AllocAccruedInterestAmt for security types that pay lump-sum at maturity. Similar to AccruedInterestAmt, the sum of AllocInterestAtMaturity will not always match InterestAtMaturity.

For Financing Trades use the same quantity rules as given for the Allocation Instruction above.

Trade Capture Report

Parties component block is required.

GrossTradeAmt and NetMoney are required.

NumDaysInterest is required where information is applicable.

AccruedInterestRate is required if NumDaysInterest is used and is not zero.

AccruedInterestAmt is required is required for security types that trade with accrued interest.

InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.

Instrument component block

SecurityID and SecurityIDSource are both required.

SecurityType is required.

Factor is conditionally required when it is not equal to one (1) for MBA, TIPS, ABS.

OrderQtyData component block

Contents | Previous | Next | Terms of Use