Orchestra2025-04-10T20:56:54.926104611ZOrchestra schemaSequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. "00023" = "23"). Examples: 723 in field 21 would be mapped int as |21=723|. -723 in field 12 would be mapped int as |12=-723| The following data types are based on int.int field representing the length in bytes. Value must be positive.int field representing the number of entries in a repeating group. Value must be positive.int field representing a message sequence number. Value must be positive.int field representing a field's tag number when using FIX "Tag=Value" syntax. Value must be positive and may not contain leading zeros.int field representing a day during a particular month (values 1 to 31).Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. "00023.23" = "23.23") and may contain or omit trailing zeros after the decimal point (e.g. "23.0" = "23.0000" = "23" = "23."). Note that fields which are derived from float may contain negative values unless explicitly specified otherwise.float field capable of storing either a whole number (no decimal places) of "shares" (securities denominated in whole units) or a decimal value containing decimal places for non-share quantity asset classes (securities denominated in fractional units).float field representing a price. Note the number of decimal places may vary. For certain asset classes prices may be negative values. For example, prices for options strategies can be negative under certain market conditions. Refer to Volume 7: FIX Usage by Product for asset classes that support negative price values.float field representing a price offset, which can be mathematically added to a "Price". Note the number of decimal places may vary and some fields such as LastForwardPoints may be negative.float field typically representing a Price times a Qtyfloat field representing a percentage (e.g. 0.05 represents 5% and 0.9525 represents 95.25%). Note the number of decimal places may vary.Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case-sensitive (i.e. m != M).char field containing one of two values: 'Y' = True/Yes 'N' = False/NoAlpha-numeric free format strings, can include any character or punctuation except the delimiter. All String fields are case-sensitive (i.e. test != Test).string field containing one or more space delimited single character values.string field representing a country using ISO 3166 Country code (2 character) values.string field representing a currency type using ISO 4217 Currency code (3 character) values.string field representing a market or exchange using ISO 10383 Market Identifier Code (MIC) values.string field representing month of a year. An optional day of the month can be appended or an optional week code. Valid formats: YYYYMM YYYYMMDD YYYYMMWW Valid values: YYYY = 0000-9999; MM = 01-12; DD = 01-31; WW = w1, w2, w3, w4, w5.string field representing Time/date combination represented in UTC (Universal Time Coordinated, also known as "GMT") in either YYYY-MM-DDTHH:MM:SS (whole seconds) or YYYY-MM-DDTHH:MM:SS.sss (milliseconds) format, colons, dash, and period required. Valid values: * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second) (without milliseconds). * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating milliseconds). Leap Seconds: Note that UTC includes corrections for leap seconds, which are inserted to account for slowing of the rotation of the earth. Leap second insertion is declared by the International Earth Rotation Service (IERS) and has, since 1972, only occurred on the night of Dec. 31 or Jun 30. The IERS considers March 31 and September 30 as secondary dates for leap second insertion, but has never utilized these dates. During a leap second insertion, a UTCTimestamp field may read "1998-12-31T23:59:59", "1998-12-31T23:59:60", "1999-01-01T00:00:00".string field representing Time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss (milliseconds) format, colons, and period required. This special-purpose field is paired with UTCDateOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: HH = 00-23, MM = 00-60 (60 only if UTC leap second), SS = 00-59. (without milliseconds) HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating milliseconds).string field representing Date represented in UTC (Universal Time Coordinated, also known as "GMT") in YYYYMMDD format. This special-purpose field is paired with UTCTimeOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31.string field representing a Date of Local Market (as opposed to UTC) in YYYYMMDD format. This is the "normal" date field used by the FIX Protocol. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31. Raw data with no format or content restrictions. Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH). Caution: the value of one of these fields may contain the delimiter (SOH) character. Note that the value specified for this field should be followed by the delimiter (SOH) character as all fields are terminated with an "SOH". Account mnemonic as agreed between broker and institution.Unique identifier of [Advertisement &lt;35=7&gt;](msg:7) message. Prior to FIX 4.1 this field was of type int.Reference identifier used with CANCEL and REPLACE transaction types. Prior to FIX 4.1 this field was of type int.Broker's side of advertised tradeIdentifies [Advertisement &lt;35=7&gt;](msg:7) message transaction typeCalculated average price of all fills on this order.Message sequence number of first message in range to be resentIdentifies beginning of new message and protocol version. ALWAYS FIRST FIELD IN MESSAGE. (Always unencrypted)Message length, in bytes, forward to the [CheckSum (10)](tag:10) field. ALWAYS SECOND FIELD IN MESSAGE. (Always unencrypted)Three byte, simple checksum (see [Appendix B: CheckSum Calculation](app_b.html) for description). ALWAYS LAST FIELD IN MESSAGE; i.e. serves, with the trailing <SOH>, as the end-of-message delimiter. Always defined as three characters. (Always unencrypted)Unique identifier for Order as assigned by institution (identified by [SenderCompID (49)](tag:49) or [OnBehalfOfCompID (115)](tag:115) as appropriate). Uniqueness must be guaranteed within a single trading day. Firms, particularly those which electronically submit multi-day orders, trade globally or throughout market close periods,should ensure uniqueness across days, for example by embedding a date within the [ClOrdID (11)](tag:11) field.Commission. Note if [CommType (13)](tag:13) is percentage, [Commission (12)](tag:12) of 5% should be represented as .05.[Commission (12)](tag:12) typeTotal number of shares filled. Prior to FIX 4.2 this field was of type int.Identifies currency used for price. Absence of this field is interpreted as the default for the security. It is recommended that systems provide the currency value whenever possible. See [Appendix A: Valid Currency Codes](app_a.html) for information on obtaining valid values.Message sequence number of last message in range to be resent. If request is for a single message [BeginSeqNo (7)](tag:7) = [EndSeqNo (16)](tag:16). If request is for all messages subsequent to a particular message, [EndSeqNo (16)](tag:16) = 0 (representing infinity).Unique identifier of execution message as assigned by broker (will be 0 (zero) for [ExecTransType (20)](tag:20)='3' (Status)). Uniqueness must be guaranteed within a single trading day or the life of a multi-day order. Firms which accept multi-day orders should consider embedding a date within the [ExecID (17)](tag:17) field to assure uniqueness across days. Prior to FIX 4.1 this field was of type int.Instructions for order handling on exchange trading floor. If more than one instruction is applicable to an order, this field can contain multiple instructions separated by space.Reference identifier used with Cancel and Correct transaction types. Prior to FIX 4.1 this field was of type int.Identifies transaction typeInstructions for order handling on Broker trading floorIdentifies class of alternative [SecurityID (48)](tag:48)Unique identifier of [Indication of Interest &lt;35=6&gt;](msg:6) message. Prior to FIX 4.1 this field was of type int.No longer used as of FIX 4.2. Included here for reference to prior versions.Relative quality of indicationReference identifier used with CANCEL and REPLACE, transaction types. Prior to FIX 4.1 this field was of type int.Number of shares in numeric or relative size.Identifies IOI message transaction typeBroker capacity in order executionMarket of execution for last fillPrice of this (last) fill. Field not required for [ExecTransType (20)](tag:20) ='3' (Status)Quantity of shares bought/sold on this (last) fill. Field not required for [ExecTransType (20)](tag:20) ='3' (Status) Prior to FIX 4.2 this field was of type int.Identifies number of lines of text bodyInteger message sequence number.Defines message type. Always third field in message. Always unencrypted. The value is case-sensitive. "U" as the first character of the value (e.g. U1, U2) indicates that the message format is privately defined between the sender and receiver.New sequence numberUnique identifier for Order as assigned by broker. Uniqueness must be guaranteed within a single trading day. Firms which accept multi-day orders should consider embedding a date within the [OrderID (37)](tag:37) field to assure uniqueness across days.Number of shares ordered. This represents the number of shares for equities or based on normal convention the number of contracts for options, futures, convertible bonds, etc. Prior to FIX 4.2 this field was of type int.Identifies current status of order.Order type.[ClOrdID (11)](tag:11) of the previous order (NOT the initial order of the day) as assigned by the institution, used to identify the previous order in cancel and cancel/replace requests.Time of message origination (always expressed in UTC (Universal Time Coordinated, also known as 'GMT'))Indicates possible retransmission of message with this sequence numberPrice per shareReference message sequence numberSymbol of issue related to story. Can be repeated within message to identify multiple companies.Note that the name of this field is changing to 'OrderCapacity' as Rule80A is a very US market-specific term. Other world markets need to convey similar information, however, often a subset of the US values. See the [Rule80A (aka OrderCapacity) Usage by Market](app_g.html) appendix for market-specific usage of this field.CUSIP or other alternate security identifierAssigned value used to identify firm sending message.Assigned value used to identify specific message originator (desk, trader, etc.)No longer used. Included here for reference to prior versions.Time of message transmission (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')Number of shares Prior to FIX 4.2 this field was of type int.Side of orderTicker symbolAssigned value used to identify receiving firm.Assigned value used to identify specific individual or unit intended to receive message. 'ADMIN' reserved for administrative messages not intended for a specific user.Free format text string (Note: this field does not have a specified maximum length)Specifies how long the order remains in effect. Absence of this field is interpreted as DAY.Time of execution/order creation (expressed in UTC (Universal Time Coordinated, also known as 'GMT')Urgency flagIndicates expiration time of indication message (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')Indicates order settlement period. Absence of this field is interpreted as Regular. Regular is defined as the default settlement period for the particular security on the exchange of execution.Specific date of trade settlement (SettlementDate) in YYYYMMDD format. Required when [SettlmntTyp (63)](tag:63) = '6' (Future) or [SettlmntTyp (63)](tag:63) = '8' (Sellers Option). (expressed in local time at place of settlement)Additional information about the security (e.g. preferred, warrants, etc.). Note also see [SecurityType (167)](tag:167).Unique identifier for list as assigned by institution, used to associate multiple individual orders. Uniqueness must be guaranteed within a single trading day. Firms which generate multi-day orders should consider embedding a date within the [ListID (66)](tag:66) field to assure uniqueness across days.Sequence of individual order within list (i.e. [ListSeqNo (67)](tag:67) of [TotNoOrders (68)](tag:68), 2 of 25, 3 of 25, . . . )Total number of list order entries across all messages. Should be the sum of all [NoOrders (73)](tag:73) in each message that has repeating list order entries related to the same [ListID (66)](tag:66). Used to support fragmentation. Prior to FIX 4.2 this field was named "ListNoOrds".Free format text message containing list handling and execution instructions.Unique identifier for [Allocation &lt;35=J&gt;](msg:J) message. Prior to FIX 4.1 this field was of type int.Identifies allocation transaction typeReference identifier to be used with Replace, Cancel, and Calculated [AllocTransType (71)](tag:71) messages. Prior to FIX 4.1 this field was of type int.Indicates number of orders to be combined for average pricing and allocation.Indicates number of decimal places to be used for average pricing. Absence of this field indicates that default precision arranged by the broker/institution is to be used.Indicates date of trade referenced in this message in YYYYMMDD format. Absence of this field indicates current day (expressed in local time at place of trade).Identifies executing / give-up broker. Standard NASD market-maker mnemonic is preferred.Indicates whether the resulting position after a trade should be an opening position or closing position. Used for omnibus accounting - where accounts are held on a gross basis instead of being netted together. Valid Values: O=Open C=CloseNumber of repeating [AllocAccount (79)](tag:79)/[AllocPrice (366)](tag:366) entries.Sub-account mnemonicNumber of shares to be allocated to specific sub-account Prior to FIX 4.2 this field was of type int.Processing code for sub-account. Absence of this field in [AllocAccount (79)](tag:79) / [AllocPrice (366)](tag:366)/[AllocShares (80)](tag:80) / [ProcessCode (81)](tag:81) instance indicates regular trade.Total number of reports within series.Sequence number of message within report series.Total number of shares canceled for this order. Prior to FIX 4.2 this field was of type int.Number of delivery instruction fields to follow No longer used. Included here for reference to prior versions.Free format text field to indicate delivery instructions No longer used. Included here for reference to prior versions.Identifies status of allocation.Identifies reason for rejection.Electronic signatureLength of encrypted messageActual encrypted data streamBroker to receive trade credit.Number of bytes in [Signature (89)](tag:89) field.[Email &lt;35=C&gt;](msg:C) message type.Number of bytes in raw data field.Unformatted raw data, can include bitmaps, word processor documents, etc.Indicates that message may contain information that has been sent under another sequence number. Valid Values: Y=Possible resend N=Original transmissionMethod of encryption.Price per shareExecution destination as defined by institution when order is entered.Code to identify reason for cancel rejection.Code to identify reason for order rejection.Code to qualify IOI use.Identifier to aid in the management of multiple lists derived from a single, master list.Company name of security issuer (e.g. International Business Machines)Security description.[Heartbeat &lt;35=0&gt;](msg:0) interval (seconds)Firm identifier used in third party-transactions (should not be a substitute for [OnBehalfOfCompID (115)](tag:115)/[DeliverToCompID (128)](tag:128)).Minimum quantity of an order to be executed. Prior to FIX 4.2 this field was of type int.Maximum number of shares within an order to be shown on the exchange floor at any given time. Prior to FIX 4.2 this field was of type int.Identifier included in [Test Request &lt;35=1&gt;](msg:1) message to be returned in resulting [Heartbeat &lt;35=0&gt;](msg:0)Identifies party of trade responsible for exchange reporting.Indicates whether the broker is to locate the stock in conjunction with a short sell order.Assigned value used to identify firm originating message if the message was delivered by a third party i.e. the third party firm identifier would be delivered in the [SenderCompID (49)](tag:49) field and the firm originating the message in this field.Assigned value used to identify specific message originator (i.e. trader) if the message was delivered by a third partyUnique identifier for quoteTotal amount due as the result of the transaction (e.g. for Buy order - principal + commission + fees) reported in currency of execution.Total amount due expressed in settlement currency (includes the effect of the forex transaction)Currency code of settlement denomination. See [Appendix A: Valid Currency Codes](app_a.html) for information on obtaining valid values.Indicates request for forex accommodation trade to be executed along with security transaction.Original time of message transmission (always expressed in UTC (Universal Time Coordinated, also known as 'GMT') when transmitting orders as the result of a resend request.Indicates that the [Sequence Reset &lt;35=4&gt;](msg:4) message is replacing administrative or application messages which will not be resent.No of execution repeating group entries to follow.No longer used. Included here for reference to prior versions.Time/Date of order expiration (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')Reason for execution rejection.Assigned value used to identify the firm targeted to receive the message if the message is delivered by a third party i.e. the third party firm identifier would be delivered in the [TargetCompID (56)](tag:56) field and the ultimate receiver firm ID in this field.Assigned value used to identify specific message recipient (i.e. trader) if the message is delivered by a third partyIndicates that IOI is the result of an existing agency order or a facilitation position resulting from an agency order, not from principal trading or order solicitation activity.Unique identifier for quote requestBid price/rateOffer price/rateQuantity of bid Prior to FIX 4.2 this field was of type int.Quantity of offer Prior to FIX 4.2 this field was of type int.Number of repeating groups of miscellaneous feesMiscellaneous fee value[Currency (15)](tag:15) of miscellaneous feeIndicates type of miscellaneous fee.Previous closing price of security.Indicates that the both sides of the FIX session should reset sequence numbers.Assigned value used to identify specific message originator's location (i.e. geographic location and/or desk, trader)Assigned value used to identify specific message destination's location (i.e. geographic location and/or desk, trader)Assigned value used to identify specific message originator's location (i.e. geographic location and/or desk, trader) if the message was delivered by a third partyAssigned value used to identify specific message recipient's location (i.e. geographic location and/or desk, trader) if the message was delivered by a third partySpecifies the number of repeating symbols specified.The subject of an [Email &lt;35=C&gt;](msg:C) messageThe headline of a [News &lt;35=B&gt;](msg:B) messageA URL (Uniform Resource Locator) link to additional information (i.e. https://en.wikipedia.org/wiki/URL)Describes the specific [Execution Report &lt;35=8&gt;](msg:8) (i.e. Pending Cancel) while [OrdStatus (39)](tag:39) will always identify the current order status (i.e. Partially Filled)Amount of shares open for further execution. If the [OrdStatus (39)](tag:39) is Canceled, DoneForTheDay, Expired, Calculated, or Rejected (in which case the order is no longer active) then [LeavesQty (151)](tag:151) could be 0, otherwise [LeavesQty (151)](tag:151) = [OrderQty (38)](tag:38) - [CumQty (14)](tag:14). Prior to FIX 4.2 this field was of type int.Specifies the approximate order quantity desired in total monetary units vs. as a number of shares. The broker would be responsible for converting and calculating a share quantity ([OrderQty (38)](tag:38)) based upon this amount to be used for the actual order and subsequent messages.[AvgPx (6)](tag:6) for a specific [AllocAccount (79)](tag:79)[NetMoney (118)](tag:118) for a specific [AllocAccount (79)](tag:79)Foreign exchange rate used to compute [SettlCurrAmt (119)](tag:119) from [Currency (15)](tag:15) to [SettlCurrency (120)](tag:120)Specifies whether or not [SettlCurrFxRate (155)](tag:155) should be multiplied or divided. M=Multiply D=DivideNumber of Days of Interest for convertible bonds and fixed incomeAccrued Interest Rate for convertible bonds and fixed incomeAmount of Accrued Interest for convertible bonds and fixed incomeIndicates mode used for [Settlement Instructions &lt;35=T&gt;](msg:T)Free format text related to a specific [AllocAccount (79)](tag:79).Unique identifier for [Settlement Instructions &lt;35=T&gt;](msg:T) message.[Settlement Instructions &lt;35=T&gt;](msg:T) message transaction typeUnique identifier for an email thread (new and chain of replies)Indicates source of [Settlement Instructions &lt;35=T&gt;](msg:T)Identifies Settlement Depository or [Country (421)](tag:421) Code (ISITC spec)Indicates type of security (ISITC spec)Time the details within the message should take effect (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')Identifies the Standing Instruction database usedName of the Standing Instruction database represented with [StandInstDbType (169)](tag:169) (i.e. the Global Custodian's name).Unique identifier used on the Standing Instructions database for the Standing Instructions to be referenced.Identifies type of settlement 0 = 'Versus. Payment': Deliver (if Sell) or Receive (if Buy) vs. (Against) Payment 1 = 'Free': Deliver (if Sell) or Receive (if Buy) FreeBroker's account code at the depository (i.e. CEDEL ID for CEDEL, FINS for DTC, or Euroclear ID for Euroclear) if [SettlLocation (166)](tag:166) is a depositoryBIC (Bank Identification Code-Swift managed) code of the broker involved (i.e. for multi-company brokerage firms)BIC (Bank Identification Code-Swift managed) code of the institution involved (i.e. for multi-company institution firms)Name of [SettlInstSource (165)](tag:165)'s local agent bank if [SettlLocation (166)](tag:166) is not a depositoryBIC (Bank Identification Code-Swift managed) code of the [SettlInstSource (165)](tag:165)'s local agent bank if [SettlLocation (166)](tag:166) is not a depository[SettlInstSource (165)](tag:165)'s account number at local agent bank if [SettlLocation (166)](tag:166) is not a depositoryName of [SettlInstSource (165)](tag:165)'s account at local agent bank if [SettlLocation (166)](tag:166) is not a depositoryName of contact at local agent bank for [SettlInstSource (165)](tag:165)'s account if [SettlLocation (166)](tag:166) is not a depositoryPhone number for contact at local agent bank if [SettlLocation (166)](tag:166) is not a depositoryName of [SettlInstSource (165)](tag:165)'s local agent bank if [SettlDeliveryType (172)](tag:172)=FreeBIC (Bank Identification Code-Swift managed) code of the [SettlInstSource (165)](tag:165)'s local agent bank if [SettlDeliveryType (172)](tag:172)=Free[SettlInstSource (165)](tag:165)'s account number at local agent bank if [SettlDeliveryType (172)](tag:172)=FreeName of [SettlInstSource (165)](tag:165)'s account at local agent bank if [SettlDeliveryType (172)](tag:172)=FreeName of contact at local agent bank for [SettlInstSource (165)](tag:165)'s account if [SettlDeliveryType (172)](tag:172)=FreePhone number for contact at local agent bank for [SettlInstSource (165)](tag:165)'s account if [SettlDeliveryType (172)](tag:172)=FreeBid F/X spot rate.Bid F/X forward points added to spot rate. May be a negative value.Offer F/X spot rate.Offer F/X forward points added to spot rate. May be a negative value.[OrderQty (38)](tag:38) of the future part of a F/X swap order.[FutSettDate (64)](tag:64) of the future part of a F/X swap order.F/X spot rate.F/X forward points added to [LastSpotRate (194)](tag:194). May be a negative value.Can be used to link two different [Allocation &lt;35=J&gt;](msg:J) messages (each with unique [AllocID (70)](tag:70)) together, i.e. for F/X 'Netting' or 'Swaps'. Should be unique.Identifies the type of [Allocation &lt;35=J&gt;](msg:J) linkage when [AllocLinkID (196)](tag:196) is used.Assigned by the party which accepts the order. Can be used to provide the [OrderID (37)](tag:37) used by an exchange or executing system.Number of repeating groups of IOIQualifiers.Month and Year of the maturity for [SecurityType (167)](tag:167)=FUT or [SecurityType (167)](tag:167)=OPT. Required if [MaturityDay (205)](tag:205) is specified. Format: YYYYMM (i.e. 199903)Indicates whether an Option is for a put or call.Strike Price for an Option.Used for optionsUsed for options when delivering the order to an execution system/exchange to specify if the order is for a customer or the firm placing the order itself.Day of month used in conjunction with [MaturityMonthYear (200)](tag:200) to specify the maturity date for [SecurityType (167)](tag:167)=FUT or [SecurityType (167)](tag:167)=OPT.Can be used for [SecurityType (167)](tag:167)=OPT to identify a particular security. Valid values vary by [SecurityExchange (207)](tag:207): For Exchange: MONEP (Paris) L = Long (a.k.a. 'American') S = Short (a.k.a. 'European') For Exchanges: DTB (Frankfurt), HKSE (Hong Kong), and SOFFEX (Zurich) 0-9 = single digit 'version' number assigned by exchange following capital adjustments (0=current, 1=prior, 2=prior to 1, etc).Market used to help identify a security.Indicates whether or not details should be communicated to [BrokerOfCredit (92)](tag:92) (i.e. step-in broker).Indicates how the receiver (i.e. third party) of [Allocation &lt;35=J&gt;](msg:J) message should handle/process the account details.Maximum number of shares within an order to be shown to other customers (i.e. sent via an IOI). Prior to FIX 4.2 this field was of type int.Amount (signed) added to the price of the peg for a pegged order.Length of the [XmlData (213)](tag:213) data block.Actual XML data stream (e.g. FIXML). See approriate XML reference (e.g. FIXML). Note: may contain embedded SOH characters.Reference identifier for the [SettlInstID (162)](tag:162) with Cancel and Replace [SettlInstTransType (163)](tag:163) transaction types.Number of repeating groups of [RoutingID (217)](tag:217) and [RoutingType (216)](tag:216) values. See [Appendix L: Pre-Trade Message Targeting/Routing](app_l.html)Indicates the type of [RoutingID (217)](tag:217) specified.Assigned value used to identify a specific routing destination.For Fixed Income. Basis points relative to a benchmark. To be expressed as "count of basis points" (vs. an absolute value). E.g. High Grade Corporate Bonds may express price as basis points relative to benchmark (the [Benchmark (219)](tag:219) field). Note: Basis points can be negative.For Fixed Income. Identifies the benchmark (e.g. used in conjunction with the [SpreadToBenchmark (218)](tag:218) field).For Fixed Income. Coupon rate of the bond. Will be zero for step-up bonds.Specifies the ratio or multiply factor to convert from contracts to shares (e.g. 1.0, 100, 1000, etc). Applicable For Fixed Income, Convertible Bonds, Derivatives, etc. Note: If used, quantities should be expressed in the "nominal" (e.g. contracts vs. shares) amount.Unique identifier for [Market Data Request &lt;35=V&gt;](msg:V)Subscription Request TypeDepth of market for Book SnapshotSpecifies the type of Market Data update.Specifies whether or not book entries should be aggregated.Number of [MDEntryType (269)](tag:269) fields requested.Number of entries in Market Data message.Type Market Data entry.Price of the Market Data Entry.Number of shares represented by the Market Data Entry.Date of Market Data Entry.Time of Market Data Entry.Direction of the "tick".Market posting quote / trade.Space-delimited list of conditions describing a quote.Space-delimited list of conditions describing a tradeUnique Market Data Entry identifier.Type of Market Data update action.Refers to a previous [MDEntryID (278)](tag:278).Reason for the rejection of a[Market Data Request &lt;35=V&gt;](msg:V).Originator of a Market Data EntryIdentification of a Market Maker's locationIdentification of a Market Maker's deskReason for deletion.Flag that identifies a price.Specifies the number of days that may elapse before delivery of the securityBuying party in a tradeSelling party in a tradeDisplay position of a bid or offer, numbered from most competitive to least competitive, per market side, beginning with 1.Identifies a firm's financial status.Identifies the type of Corporate Action.Default Bid Size.Default Offer Size.The number of quote entries for a QuoteSet.The number of sets of quotes in the message.Identifies the status of the quote acknowledgement.Identifies the type of quote cancel. Valid Values: 1 = Cancel for [Symbol (55)](tag:55)(s) 2 = Cancel for [SecurityType (167)](tag:167)(s) 3 = Cancel for [UnderlyingSymbol (311)](tag:311) 4 = Cancel All QuotesUniquely identifies the quote as part of a QuoteSet.Reason Quote was rejected. Valid Values: 1 = Unknown symbol (Security) 2 = Exchange(Security) closed 3 = Quote Request exceeds limit 4 = Too late to enter 5 = Unknown Quote 6 = Duplicate Quote 7 = Invalid bid/ask spread 8 = Invalid price 9 = Not authorized to quote securityLevel of Response requested from receiver of quote messages. Valid Values: 0 = No Acknowledgement (Default) 1 = Acknowledge only negative or erroneous quotes 2 = Acknowledge each quote messagesUnique id for the Quote Set.Indicates the type of [Quote Request &lt;35=R&gt;](msg:R) being generatedTotal number of quotes for the quote set across all messages. Should be the sum of all [NoQuoteEntries (295)](tag:295) in each message that has repeating quotes that are part of the same quote set.Underlying security's IDSource. Valid values: see [IDSource (22)](tag:22) fieldUnderlying security's Issuer. See [Issuer (106)](tag:106) field for descriptionUnderlying security's SecurityDesc. See [SecurityDesc (107)](tag:107) field for descriptionUnderlying security's SecurityExchange. Can be used to identify the underlying security. Valid values: see [SecurityExchange (207)](tag:207)Underlying security's SecurityID. See [SecurityID (48)](tag:48) field for descriptionUnderlying security's SecurityType. Valid values: see [SecurityType (167)](tag:167) fieldUnderlying security's Symbol. See [Symbol (55)](tag:55) field for descriptionUnderlying security's SymbolSfx. See [SymbolSfx (65)](tag:65) field for descriptionUnderlying security's MaturityMonthYear. Required if [UnderlyingMaturityDay (314)](tag:314) is specified. See [MaturityMonthYear (200)](tag:200) field for descriptionUnderlying security's MaturityDay. See [MaturityDay (205)](tag:205) field for descriptionUnderlying security's PutOrCall. See [PutOrCall (201)](tag:201) field for descriptionUnderlying security's StrikePrice. See [StrikePrice (202)](tag:202) field for descriptionUnderlying security's OptAttribute. See [OptAttribute (206)](tag:206) field for descriptionUnderlying security's Currency. See [Currency (15)](tag:15) field for description and valid valuesQuantity of a particular leg in the security.Unique ID of a [Security Definition Request &lt;35=c&gt;](msg:c).Type of [Security Definition Request &lt;35=c&gt;](msg:c).Unique ID of a [Security Definition &lt;35=d&gt;](msg:d) message.Type of [Security Definition &lt;35=d&gt;](msg:d) message response.Unique ID of a [Security Status Request &lt;35=e&gt;](msg:e) message.Indicates whether or not message is being sent as a result of a subscription request or not.Identifies the trading status applicable to the transaction.Denotes the reason for the Opening Delay or Trading Halt.Indicates whether or not the halt was due to Common Stock trading being halted.Indicates whether or not the halt was due to the Related Security being halted.Number of shares bought.Number of shares sold.Represents an indication of the high end of the price range for a security prior to the open or reopenRepresents an indication of the low end of the price range for a security prior to the open or reopenIdentifies the type of adjustment.Unique ID of a [Trading Session Status &lt;35=h&gt;](msg:h) message.Identifier for Trading Session Can be used to represent a specific market trading session (e.g. 'PRE-OPEN", "CROSS_2", "AFTER-HOURS", "TOSTNET1", "TOSTNET2", etc). Values should be bi-laterally agreed to between counterparties.Identifies the trader (e.g. "badge number") of the [ContraBroker (375)](tag:375).Method of tradingTrading Session ModeState of the trading session.Starting time of the trading sessionTime of the opening of the trading sessionTime of the pre-closed of the trading sessionClosing time of the trading sessionEnd time of the trading sessionNumber of orders in the market.Type of message encoding (non-ASCII (non-English) characters) used in a message's 'Encoded' fields.Byte length of encoded (non-ASCII characters) [EncodedIssuer (349)](tag:349) field.Encoded (non-ASCII characters) representation of the [Issuer (106)](tag:106) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [Issuer (106)](tag:106) field.Byte length of encoded (non-ASCII characters) [EncodedSecurityDesc (351)](tag:351) field.Encoded (non-ASCII characters) representation of the [SecurityDesc (107)](tag:107) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [SecurityDesc (107)](tag:107) field.Byte length of encoded (non-ASCII characters) [EncodedListExecInst (353)](tag:353) field.Encoded (non-ASCII characters) representation of the [ListExecInst (69)](tag:69) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [ListExecInst (69)](tag:69) field.Byte length of encoded (non-ASCII characters) [EncodedText (355)](tag:355) field.Encoded (non-ASCII characters) representation of the [Text (58)](tag:58) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [Text (58)](tag:58) field.Byte length of encoded (non-ASCII characters) [EncodedSubject (357)](tag:357) field.Encoded (non-ASCII characters) representation of the [Subject (147)](tag:147) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [Subject (147)](tag:147) field.Byte length of encoded (non-ASCII characters) [EncodedHeadline (359)](tag:359) field.Encoded (non-ASCII characters) representation of the [Headline (148)](tag:148) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [Headline (148)](tag:148) field.Byte length of encoded (non-ASCII characters) [EncodedAllocText (361)](tag:361) field.Encoded (non-ASCII characters) representation of the [AllocText (161)](tag:161) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [AllocText (161)](tag:161) field.Byte length of encoded (non-ASCII characters) [EncodedUnderlyingIssuer (363)](tag:363) field.Encoded (non-ASCII characters) representation of the [UnderlyingIssuer (306)](tag:306) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [UnderlyingIssuer (306)](tag:306) field.Byte length of encoded (non-ASCII characters) [EncodedUnderlyingSecurityDesc (365)](tag:365) field.Encoded (non-ASCII characters) representation of the [UnderlyingSecurityDesc (307)](tag:307) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the UnderlyingSecurityeDesc field.Executed price for an [AllocAccount (79)](tag:79) entry used when using 'executed price' vs. 'average price' allocations (e.g. Japan).Indicates expiration time of this particular QuoteSet (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')Reason Quote Entry was rejected:The last [MsgSeqNum (34)](tag:34) value received and processed. Can be specified on every message sent. Useful for detecting a backlog with a counterparty.Used when a message is sent via a 'hub' or 'service bureau'. If A sends to Q (the hub) who then sends to B via a separate FIX session, then when Q sends to B the value of this field should represent the [SendingTime (52)](tag:52) on the message A sent to Q. (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')The tag number of the FIX field being referenced.The [MsgType (35)](tag:35) of the FIX message being referenced.Code to identify reason for a session-level [Reject &lt;35=3&gt;](msg:3) message.Identifies the [Bid Request &lt;35=k&gt;](msg:k) message type.Identifies contra broker. Standard NASD market-maker mnemonic is preferred.ID used to represent this transaction for compliance purposes (e.g. OATS reporting).Indicates whether or not the order was solicited.Code to identify reason for an ExecutionRpt message sent with [ExecType (150)](tag:150)=Restated or used when communicating an unsolicited cancel.The value of the business-level 'ID' field on the message being referenced.Code to identify reason for a [Business Message Reject &lt;35=j&gt;](msg:j) message.Total amount traded (e.g. [CumQty (14)](tag:14) * [AvgPx (6)](tag:6)) expressed in units of currency.The number of [ContraBroker (375)](tag:375) entries.Maximum number of bytes supported for a single message.Number of [MsgType (35)](tag:35) in repeating group.Specifies the direction of the message.Number of [TradingSessionID (336)](tag:336) in repeating group.Total volume (quantity) traded.Code to identify the price a [DiscretionOffset (389)](tag:389) is related to and should be mathematically added to.Amount (signed) added to the 'related to' price specified via [DiscretionInst (388)](tag:388).Unique identifier for [Bid Response &lt;35=l&gt;](msg:l) as assigned by broker. Uniqueness must be guaranteed within a single trading day.Unique identifier for a [Bid Request &lt;35=k&gt;](msg:k) as assigned by institution. Uniqueness must be guaranteed within a single trading day.Descriptive name for list order.Total number of securities.Code to identify the type of [Bid Request &lt;35=k&gt;](msg:k).Total number of tickets.Amounts in currencyAmounts in currencyNumber of [BidDescriptor (400)](tag:400) entries.Code to identify the type of [BidDescriptor (400)](tag:400).BidDescriptor value. Usage depends upon [BidDescriptorType (399)](tag:399). If BidDescriptorType = 1  Industrials etc - Free text If BidDescriptorType = 2  "FR" etc - ISO [Country (421)](tag:421) Codes If BidDescriptorType = 3  FT100, FT250, STOX - Free textCode to identify which "SideValue" the value refers to. [SideValue1 (396)](tag:396) and [SideValue2 (397)](tag:397) are used as opposed to Buy or Sell so that the basket can be quoted either way as Buy or Sell.Liquidity indicator or lower limit if [TotalNumSecurities (393)](tag:393) > 1. Represented as a percentage.Upper liquidity indicator if [TotalNumSecurities (393)](tag:393) > 1. Represented as a percentage.Value between [LiquidityPctLow (402)](tag:402) and [LiquidityPctHigh (403)](tag:403) in [Currency (15)](tag:15)Eg Used in EFP trades 12% (EFP - Exchange for Physical ). Represented as a percentage.Used in EFP tradesUsed in EFP trades. Represented as a percentage.Used in EFP tradesCode to identify the type of liquidity indicator.Overall weighted average liquidity expressed as a % of average daily volume. Represented as a percentage.Indicates whether or not to exchange for phsyical.Value of stocks in [Currency (15)](tag:15)Percentage of program that crosses in [Currency (15)](tag:15). Represented as a percentage.Code to identify the desired frequency of progress reports.Time in minutes between each [List Status &lt;35=N&gt;](msg:N) report sent by SellSide. Zero means don't send status.Code to represent whether value is net (inclusive of tax) or gross.Indicates the total number of bidders on the listCode to represent the type of trade.Code to represent the basis price type.Indicates the number of list entries.ISO Country Code in field.Total number of strike price entries across all messages. Should be the sum of all [NoStrikes (428)](tag:428) in each message that has repeating strike price entries related to the same [ListID (66)](tag:66). Used to support fragmentation.Code to represent the price type.For GT orders, the [OrderQty (38)](tag:38) less all shares (adjusted for stock splits) that traded on previous days. [DayOrderQty (424)](tag:424) = [OrderQty (38)](tag:38) - ([CumQty (14)](tag:14) - [DayCumQty (425)](tag:425))The number of shares on a GT order that have traded today.The average price of shares on a GT order that have traded today.Code to identify whether to book out executions on a part-filled GT order on the day of execution or to accumulate.Number of list strike price entries.Code to represent the price type.Code to represent whether value is net (inclusive of tax) or gross.Code to represent the status of a list order.Date of order expiration (last day the order can trade), always expressed in terms of the local market date. The time at which the order expires is determined by the local market's business practicesIdentifies the type of [ListExecInst (69)](tag:69).Identifies the type of request that a [Order Cancel Reject &lt;35=9&gt;](msg:9) is in response to.Underlying security's CouponRate. See [CouponRate (223)](tag:223) field for descriptionUnderlying security's ContractMultiplier. See [ContractMultiplier (231)](tag:231) field for descriptionQuantity traded with the [ContraBroker (375)](tag:375).Identifes the time of the trade with the [ContraBroker (375)](tag:375). (always expressed in UTC (Universal Time Coordinated, also known as 'GMT')Firm that will clear the trade. Used if different from the executing firm.Supplemental accounting information forwared to clearing house/firm.Number of Securites between [LiquidityPctLow (402)](tag:402) and [LiquidityPctHigh (403)](tag:403) in [Currency (15)](tag:15).Used to indicate what an [Execution Report &lt;35=8&gt;](msg:8) represents (e.g. used with multi-leg securiteis, such as option strategies, spreads, etc.). Valid Values: 1 = Single Security (default if not specified) 2 = Individual leg of a multi-leg security 3 = Multi-leg securityThe time at which current market prices are used to determine the value of a basket.Free format text string related to [List Status &lt;35=N&gt;](msg:N).Byte length of encoded (non-ASCII characters) [EncodedListStatusText (446)](tag:446) field.Encoded (non-ASCII characters) representation of the [ListStatusText (444)](tag:444) field in the encoded format specified via the [MessageEncoding (347)](tag:347) field. If used, the ASCII (English) representation should also be specified in the [ListStatusText (444)](tag:444) field.Indicates number of allocation groups to follow.Used if BidType="Disclosed"Number of bid repeating groupsUsed if BidType="Non Disclosed"Number of ContraBrokers repeating group instances.Indicates number of individual execution repeating group entries to follow. Absence of this field indicates that no individual execution entries are included. Primarily used to support step-outs.Required if any IOIQualifiers are specified. Indicates the number of repeating IOIQualifiers.Specifies the number of repeating symbols specifiedNumber of symbols requested.Number of strike price entriesSpecifies the number of repeating lines of text specifiedNumber of orders in this message (number of repeating groups to follow)Number of entries following.Number of entries following.Number of MDEntryType fields requested.Required if any miscellaneous fees are reported. Indicates number of repeating entries. Repeating group within Alloc repeating group. ** Nested Repeating Group follows **Specifies the number of repeating MsgTypes specifiedIndicates number of orders to be combined for allocation. If order(s) were manually delivered set to 1 (one).Number of orders statuses in this message, i.e. number of repeating groups to follow.Number of repeating groups for pre-trade allocationThe number of securities whose quotes are to be canceledNumber of related symbols in RequestThe number of sets of quotes in the messageThe number of sets of quotes in the messageThe number of quotes for this Symbol (QuoteSet) that follow in this message.Required if any RoutingType and RoutingIDs are specified. Indicates the number within repeating group.The standard FIX message headerThe standard FIX message trailerSpecifies the number of repeating TradingSessionIDsNumber of legs that make up the SecurityNumber of legs that make up the SecurityThe Heartbeat message is used as a keepalive for the connection, to make sure that the other party is still responsive after a period of inactivity. The heartbeat interval is specified in the original [Logon &lt;35=A&gt;](msg:A) message. When either end of a FIX connection has not sent any data for the heartbeat interval, it will transmit a Heartbeat message. When either end of the connection has not received any data for the heartbeat interval plus some reasonable transmission time, it will transmit a [Test Request &lt;35=1&gt;](msg:1) message. If there is still no Heartbeat message received after the heartbeat interval plus some reasonable transmission time then the connection should be considered lost and applications should attempt to recover. If the heartbeat interval is set to zero then no regular Heartbeat messages will be generated. In such case, a [Test Request &lt;35=1&gt;](msg:1) message can still be sent regardless, which will force a Heartbeat message. Heartbeats issued in response to a [Test Request &lt;35=1&gt;](msg:1) must contain the [TestReqID (112)](tag:112) present in the request. This is useful to verify that the Heartbeat is the result of the [Test Request &lt;35=1&gt;](msg:1) and not as the result of a regular timeout.This message requests a [Heartbeat &lt;35=0&gt;](msg:0) from the opposing application, to verify it is still responsive. The other application responds with a [Heartbeat &lt;35=0&gt;](msg:0) echoing back the given [TestReqID (112)](tag:112). [TestReqID (112)](tag:112) ensures that the opposite application has generated the Heartbeat as the result of a specific 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, but uniqueness is preferable for debugging purposes. Timestamps, sequences, or UUIDs are sensible choices.This message is sent by the receiving application to initiate the retransmission of messages. This happens if a sequence number gap is detected, if the receiving application lost a message, or during the initialization process. Applications can request a single message, a range of messages, or all messages which followed a particular message. The sending application may wish to consider the message type when resending messages. For example, 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 &lt;35=4&gt;](msg:4) message is used in Gap Fill mode to skip messages that a sender does not wish to resend. It is imperative that the receiving application process messages in sequence order. For example, 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 (7)](tag:7) = [EndSeqNo (16)](tag:16) - To request a range of messages: [BeginSeqNo (7)](tag:7) = first message of range, [EndSeqNo (16)](tag:16) = last message of range - To request all messages which followed a particular message: [BeginSeqNo (7)](tag:7) = first message of range, [EndSeqNo (16)](tag:16) = 0This message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. For example, upon receipt of a message with an invalid [MsgType (35)](tag:35) that is otherwise valid. 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 should be incremented. 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 &lt;35=2&gt;](msg:2) will be generated. FIX engines should be implemented to recognize a possibly 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 one or both applications. If the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number and sent with [PossResend (97)](tag:97)=Y. It is strongly recommended that the cause of the failure be described in the [Text (58)](tag:58) field. For example, "Invalid data - field 35". If an application-level message fulfills session-level rules then 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 rejection message types which should be used. All others can be rejected at a business-level with the [Business Message Reject &lt;35=j&gt;](msg:j) message. In the event that a business message is received, fulfills session-level rules, but cannot be processed by the business-level processing system, a [Business Message Reject &lt;35=j&gt;](msg:j) with [BusinessRejectReason (380)](tag:380) = "Application not available at this time" should be sent. Scenarios for a session-level Reject are listed in the documentation for [SessionRejectReason (373)](tag:373).The Sequence Reset message has two modes: Gap Fill mode and Reset mode. # Gap Fill mode Gap Fill mode is used in response to a [Resend Request &lt;35=2&gt;](msg:2) when one or more messages must be skipped. That may be because the sending application chooses not to send a message, e.g. an outdated order, or because the message is administrative and doesn't require resending, e.g. a [Heartbeat &lt;35=0&gt;](msg:0) or [Test Request &lt;35=1&gt;](msg:1). Gap Fill mode is indicated by [GapFillFlag (123)](tag:123) = "Y". In Gap Fill mode, the [MsgSeqNum (34)](tag:34) should conform to standard message sequencing rules. That is, the [MsgSeqNum (34)](tag:34) of the Sequence Reset message should represent the beginning [MsgSeqNum (34)](tag:34) in the Gap Fill range because the remote side is expecting that next message sequence number. # Reset mode Reset mode involves specifying an arbitrarily higher new sequence number to be expected by the receiver of the Sequence Reset message, and is used to reestablish a FIX session after an application failure. Reset mode is indicated by the [GapFillFlag (123)](tag:123) field = "N", or by omitting the field. In Reset mode, it can be assumed that the purpose of the Sequence Reset message is to recover from an out-of-sequence condition. In Reset mode, the [MsgSeqNum (34)](tag:34) in the header should be ignored. That is, the receipt of a Reset mode Sequence Reset message with an out of sequence [MsgSeqNum (34)](tag:34) should not generate resend requests. Reset mode should not be used as a normal response to a [Resend Request &lt;35=2&gt;](msg:2); Gap Fill mode should be used. Reset mode should only be used to recover from a disaster situation which cannot be recovered by using Gap Fill mode. Reset mode may result in the possibility of lost messages. # Processing a Sequence Reset The sending application will initiate the Sequence Reset. The message always specifies a [NewSeqNo (36)](tag:36) to reset to as the value of the next sequence number to be expected by the message recipient immediately following the messages and/or sequence numbers being skipped. A Sequence Reset can only increase the sequence number. If a Sequence Reset attempts to decrease the sequence number, the message should be rejected and treated as a serious error. It is possible to have multiple Resend Requests issued in a row, e.g. 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 &lt;35=2&gt;](msg:2) may appear as Gap Fill Sequence Reset with [NewSeqNo (36)](tag:36)=8, message 8, Gap Fill Sequence Reset with [NewSeqNo (36)](tag:36)=10, and message 10. This could then followed by Gap Fill Sequence Reset with [NewSeqNo (36)](tag:36)=8, message 8, a Gap Fill Sequence Reset with [NewSeqNo (36)](tag:36)=10, message 10, and message 11. FIX engines must ignore the duplicate Gap Fill Sequence Reset which is attempting to lower the next expected sequence number.The Logout message initiates or confirms the termination of a FIX session. Disconnecting without exchanging Logout messages should be considered abnormal. Before actually closing the session, the initiator of the logout should wait for the opposite side to respond with a confirming Logout message. This gives the other application 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. After sending the Logout message, the initiator of the logout should not send any messages, unless responding to a [Resend Request &lt;35=2&gt;](msg:2).This message is used to market merchandise which the broker is buying or selling in either a proprietary or agency capacity. The indications can be time-bound with a specific expiration value. Indications are distributed with the understanding that other firms may react to the message first and that the merchandise may no longer be available due to prior trades. Various transaction types are available: "new", "cancel", and "replace". "Cancel" and "replace" both modify the state of the message specified by [IOIRefID (26)](tag:26).This message is used to announce completed transactions. It can be transmitted in various transaction types: "new", "cancel" and "replace". "Cancel" and "replace" both modify the state of a previously transmitted Advertisement specified by [AdvRefID (3)](tag:3).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. Relay fill information on tradeable or restricted tradeable quotes 6. Reject orders 7. Report the post-trade fee calculations associated with a trade Execution Reports do not replace end-of-day confirmations. Separate Execution Reports are sent for each order in a [New Order List &lt;35=E&gt;](msg:E). An Execution Report communicates the current state of the order as understood by the broker, using [OrdStatus (39)](tag:39), and the purpose of the message, using [ExecType (150)](tag:150). In an Execution Report, [OrdStatus (39)](tag:39) 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 used in the [OrdStatus (39)](tag:39) field. The order statuses are as follows, from highest to lowest precedence: <table><thead><tr><th>Precedence</th><th>OrdStatus</th><th>Description</th></tr></thead> <tbody><tr><td>11</td><td>Pending Cancel</td><td>Order with an Order Cancel Request pending, used to confirm receipt of an Order Cancel Request. Does not indicate that the order has been canceled.</td></tr> <tr><td>10</td><td>Pending Replace</td><td>Order with an Order Cancel/Replace Request pending, used to confirm receipt of an Order Cancel/Replace Request. Does not indicate that the order has been replaced.</td></tr> <tr><td>9</td><td>Done for Day</td><td>Order not filled, or partially filled; no further executions possible for the trading day</td></tr> <tr><td>8</td><td>Calculated</td><td>Order has been completed for the day, either filled or done for day. Commission or currency settlement details have been calculated and reported in this execution message</td></tr> <tr><td>7</td><td>Filled</td><td>Order completely filled, no remaining quantity</td></tr> <tr><td>6</td><td>Stopped</td><td>Order has been stopped at the exchange. Used when guaranteeing or protecting a price and quantity</td></tr> <tr><td>5</td><td>Suspended</td><td>Order has been placed in suspended state at the request of the client</td></tr> <tr><td>4</td><td>Canceled</td><td>Canceled order with or without executions</td></tr> <tr><td>4</td><td>Expired</td><td>Order has been canceled in broker's system due to time-in-force instructions. The only exceptions are fill-or-kill and immediate-or-cancel orders that have Canceled as their terminal order state</td></tr> <tr><td>3</td><td>Partially Filled</td><td>Outstanding order with executions and remaining quantity</td></tr> <tr><td>2</td><td>New</td><td>Outstanding order with no executions</td></tr> <tr><td>2</td><td>Rejected</td><td>Order has been rejected by the sell-side. Note: an order can be rejected subsequent to order acknowledgment, i.e. an order can pass from New to Rejected status</td></tr> <tr><td>2</td><td>Pending New</td><td>Order has been received by the sell-side's system but not yet accepted for execution. An execution message with this status will only be sent in response to a Status Request message</td></tr> <tr><td>1</td><td>Accepted for bidding</td><td>Order has been received and is being evaluated for pricing. It is anticipated that this status will only be used with the “Disclosed” BidType List Order Trading model</td></tr> </tbody></table> [ExecType (150)](tag:150) is used to identify the purpose of the Execution Report. To transmit a change in [OrdStatus (39)](tag:39) for an order, the broker (sell-side) should send an Execution Report with the new [OrdStatus (39)](tag:39) value in both the [ExecType (150)](tag:150) and the [OrdStatus (39)](tag:39) 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 [Order Cancel Reject &lt;35=9&gt;](msg:9) message is used both to reject the request and to communicate the current [OrdStatus (39)](tag:39). An [ExecType (150)](tag:150) of Pending Cancel or Pending Replace is used to indicate that a cancel or cancel/replace request is being processed. An [ExecType (150)](tag:150) 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 while an order is pending and waiting to reach a new state must contain the original order parameters, prior to state change request, i.e. [ClOrdID (11)](tag:11), [OrderQty (38)](tag:38), [Price (44)](tag:44), etc. These fills will cause the [CumQty (14)](tag:14) and [AvgPx (6)](tag:6) to be updated. An order cannot be considered replaced until it has been explicitly accepted and confirmed to have been replaced via an Execution Report with [ExecType (150)](tag:150) = 'Replace', at which time the effect of the replacement (new quantity, price, etc.) will be seen. Requests to cancel or cancel/replace an order are only acted upon when there is an outstanding order quantity. A request to replace the [OrderQty (38)](tag:38) to a level lower than the [CumQty (14)](tag:14) will be interpreted by the broker as a request to stop executing the order. A request to change the price of a filled order will be rejected. The [OrderQty (38)](tag:38), [CumQty (14)](tag:14), [LeavesQty (151)](tag:151), and [AvgPx (6)](tag:6) 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 (38)](tag:38), [CumQty (14)](tag:14), [LeavesQty (151)](tag:151), and [AvgPx (6)](tag:6) on order B's fills should represent the cumulative result of order A plus those on order B. The general rule is: [OrderQty (38)](tag:38) = [CumQty (14)](tag:14) + [LeavesQty (151)](tag:151). There can be exceptions to this rule when [ExecType (150)](tag:150) or [OrdStatus (39)](tag:39) are Canceled, DoneForDay, Expired, Calculated, or Rejected. In which case, the order is no longer active and [LeavesQty (151)](tag:151) could be 0. Execution Reports communicate new fills with [ExecType (150)](tag:150) = Trade. Execution Reports with [ExecType (150)](tag:150) = Trade Cancel or Trade Correct are used to cancel or correct a previously modified execution report as follows: - The [ExecType (150)](tag:150) of Trade Cancel applies at the execution level and is used to cancel an execution which has been reported in error. The canceled execution will be identified in the [ExecRefID (19)](tag:19) field. Note: [ExecType (150)](tag:150) of Trade Cancel should not be used to cancel a previous Execution Report with [ExecType (150)](tag:150) of Trade Cancel (e.g. cannot cancel a cancel). - The [ExecType (150)](tag:150) of Trade Correct applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in the [ExecRefID (19)](tag:19) field. If a single execution is corrected more than once, [ExecRefID (19)](tag:19) should refer to the [ExecID (17)](tag:17) of the last corrected Execution Report (same convention as [ClOrdID (11)](tag:11) and [OrigClOrdID (41)](tag:41)). To correct an Execution Report which was previously canceled, an Execution Report with [ExecType (150)](tag:150)=Trade should be sent (e.g. cannot send [ExecType (150)](tag:150)=Trade Correct for an Execution Report with [ExecType (150)](tag:150)=Trade Cancel). Note: Data reported in the [CumQty (14)](tag:14), [LeavesQty (151)](tag:151), and [AvgPx (6)](tag:6) fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution. An [ExecType (150)](tag:150) of Order Status indicates that the execution messages contains no new information, only summary information regarding order status. It is used, for example, in response to an Order Status request message See "Order State Change Matrices" for examples of key state changes, processing of cancel and cancel/replace requests, and for execution cancel/corrects. An Execution Report with [ExecType (150)](tag:150) = Restated represents an Execution Report 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 (378)](tag:378) 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 (378)](tag:378) can also be used to communicate unsolicited cancels. The field [ClOrdID (11)](tag:11) is provided for institutions or buy-side brokers or intermediaries to affix an identification number to an order to coincide with internal systems. The [OrderID (37)](tag:37) field is populated with the sell-side broker-generated order number (or fund manager-generated order number for CIVs). Unlike [ClOrdID (11)](tag:11) / [OrigClOrdID (41)](tag:41) which requires a chaining through Cancel/Replaces and Cancels, [OrderID (37)](tag:37) and [SecondaryOrderID (198)](tag:198) 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 (150)](tag:150)='3' (Done for Day). When the [ExpireDate (432)](tag:432) or [ExpireTime (126)](tag:126) 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 (150)](tag:150) and [OrdStatus (39)](tag:39)=Expired (C). In handling GT orders, the [OrderQty (38)](tag:38), [CumQty (14)](tag:14) and [AvgPx (6)](tag:6) fields will represent the entirety of the order over all days. The fields [DayOrderQty (424)](tag:424), [DayCumQty (425)](tag:425), and [DayAvgPx (426)](tag:426) 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 (425)](tag:425) and [DayAvgPx (426)](tag:426) are set to zero, and [DayOrderQty (424)](tag:424) becomes the [LeavesQty (151)](tag:151). The following relationship holds: [DayOrderQty (424)](tag:424) = [OrderQty (38)](tag:38) - ([CumQty (14)](tag:14) - [DayCumQty (425)](tag:425)). Since ([CumQty (14)](tag:14) - [DayCumQty (425)](tag:425)) represents the volume traded on all previous days, [DayOrderQty (424)](tag:424) = [OrderQty (38)](tag:38) - Volume traded on all previous days. Note that when changing the quantity of an order, both [OrderQty (38)](tag:38) and [DayOrderQty (424)](tag:424) 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 (38)](tag:38)=10000 and 2000 shares trade during the previous days, a request to change [OrderQty (38)](tag:38) to 15000 will mean that 13000 shares will be open. See "Order State Change Matrices" for examples of canceling and changing GT orders partially filled on previous days. A Cancel on an execution (trade bust, [ExecType (150)](tag:150) = Trade Cancel) happening the same day of the trade will result in [CumQty (14)](tag:14) and [DayCumQty (425)](tag:425) each decreasing by the quantity busted, and [LeavesQty (151)](tag:151) increasing by the quantity busted. [OrderQty (38)](tag:38) and [DayOrderQty (424)](tag:424) 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 (38)](tag:38) and [DayCumQty (425)](tag:425) will remain unchanged, the [LeavesQty (151)](tag:151) and [DayOrderQty (424)](tag:424) will increase by the quantity busted, and the [CumQty (14)](tag:14) 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 (150)](tag:150) = Restated (D) and [ExecRestatementReason (378)](tag:378) = GT renewal / restatement (no corporate action) (1) for each open GT order. These Execution Reports may have [DayCumQty (425)](tag:425) and [DayAvgPx (426)](tag:426) restated to zero, and [DayOrderQty (424)](tag:424) restated to [LeavesQty (151)](tag:151) if the transmission occurs at the start of the following business day. The broker has the option of changing the [OrderID (37)](tag:37) and [SecondaryOrderID (198)](tag:198) fields, or leaving them unchanged. If they are changed, then the buy-side should use these new ID fields when sending [Order Cancel Request &lt;35=F&gt;](msg:F), [Order Cancel/Replace Request &lt;35=G&gt;](msg:G), and [Order Status Request &lt;35=H&gt;](msg:H) 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 (150)](tag:150) = Restated (D) and [ExecRestatementReason (378)](tag:378) = GT Corporate action (0) with the order's state after the corporate action adjustment. In the case of stock splits, [OrderQty (38)](tag:38), [CumQty (14)](tag:14), [AvgPx (6)](tag:6), and [LeavesQty (151)](tag:151) will be adjusted to reflect the order's state in terms of current quantity (e.g. shares), not pre-split quantity (e.g. shares). See "Order State Change Matrices" for examples of GT order restatement with and without a corporate action. CIV orders to be executed by the fund manager do not use the [TimeInForce (59)](tag:59) field and only a subset of [OrdStatus (39)](tag:39) values are expected to be used. See VOLUME 7 - "PRODUCT: COLLECTIVE INVESTMENT VEHICLES" for the CIV-specific [OrdStatus (39)](tag:39) values. The Execution Report message is also used for multileg instrument. See "Use of the Execution Report for Multileg Instruments" for multileg-specific details.This message is sent in response to the following messages if they cannot be honored: - [Order Cancel Request &lt;35=F&gt;](msg:F) - [Order Cancel/Replace Request &lt;35=G&gt;](msg:G) Requests to change price or decrease quantity are fulfilled only when an outstanding quantity exists. Filled orders cannot be changed, i.e to reduce the quantity or change the price. However, increasing the order quantity on a currently filled order may be supported. This message should provide the [ClOrdID (11)](tag:11) which was specified in the request, and the [OrigClOrdID (41)](tag:41) should be that of the last accepted order, except if the rejection is because the ID is unknown.This message is used to establish a FIX connection. The Logon message must be the first message sent by the application attempting to initiating a FIX session. Upon receipt of a Logon message, the session acceptor will authenticate the requester and respond with a Logon message as acknowledgment that the connection request has been accepted. The acknowledgment Logon can be used by the initiator for validation purposes. 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. 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 website's Application notes for more information on a method for encryption and key passing. The Logon message can be used to specify the [MaxMessageSize (383)](tag:383) supported, which can be used to control fragmentation rules for very large messages which support fragmentation. The Logon message can also be used to specify which [MsgType (35)](tag:35)s are supported. The [HeartBtInt (108)](tag:108) field is used to declare the interval for generating heartbeats. See [Heartbeat &lt;35=0&gt;](msg:0).This message is a general free-format message for describing news items. It contains flags to identify the news item's urgency and to allow sorting by subject company. This message may be sent by any type of institution.This message is similar in format and purpose to the [News &lt;35=B&gt;](msg:B) message. However, it is intended for private use between two parties.This message is used to submit orders for execution, for securities, forex, collective investment vehicles (CIV), and more. 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 (21)](tag:21). Execution instructions contain explicit directions as to how the order should be executed. See [ExecInst (18)](tag:18). Orders received with [PossResend (97)](tag:97) set in the header should be validated by [ClOrdID (11)](tag:11). Implementations should also consider checking order parameters (side, symbol, quantity, etc.) to determine if the order had been previously submitted. [PossResend (97)](tag:97) previously received should be acknowledged back to the client using an [Execution Report &lt;35=8&gt;](msg:8). [PossResend (97)](tag:97) not previously received should be processed as a new order. The given [TransactTime (60)](tag:60) 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 (121)](tag:121) and [SettlCurrency (120)](tag:120), 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 (121)](tag:121) = Y and [SettlCurrency (120)](tag:120) = "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 (119)](tag:119) and [SettlCurrency (120)](tag:120) fields. Orders involving or requiring pre-trade allocation consist of the following steps: - Buy-side sends a New Order Single specifying one or more [AllocAccount (79)](tag:79) and [AllocShares (80)](tag:80) values within the repeating group designated by [NoAllocs (78)](tag:78) - Sell-side sends [Execution Report &lt;35=8&gt;](msg:8) messages for the new and resulting fills. - Post-trade allocation messaging takes place To take an [Indication of Interest &lt;35=6&gt;](msg:6) or [Quote &lt;35=S&gt;](msg:S) from an ECN or exchange and not display the order on the book, the New Order Single message should contain [TimeInForce (59)](tag:59) = "ImmediateOrCancel" and [OrdType (40)](tag:40) = "Previously Indicated" or "Previously Quoted".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 [List Execute &lt;35=L&gt;](msg:L) 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](app_n.html) for an example.This message is used to request the cancellation of the remaining quantity of an existing order. The [Order Cancel/Replace Request &lt;35=G&gt;](msg:G) should be used to reduce an order's quantity. The request will only be accepted if the order can be successfully pulled from the exchange without executing. Each request is assigned a [ClOrdID (11)](tag:11) and is treated as a separate entity. The [ClOrdID (11)](tag:11) assigned to the request must be unique amongst the [ClOrdID (11)](tag:11) assigned to regular orders and replacement orders. If rejected, the [ClOrdID (11)](tag:11) of the request will be sent in the [Order Cancel Reject &lt;35=9&gt;](msg:9) message, as well as the [ClOrdID (11)](tag:11) of the actual order in the [OrigClOrdID (41)](tag:41) field. An immediate response to this message is required. It is recommended that an [Execution Report &lt;35=8&gt;](msg:8) with [ExecType (150)](tag:150) = "Pending Cancel" be sent unless the request can be immediately accepted or rejected.Order Cancel/Replace Request (a.k.a. Order Modification 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 [Order Cancel Request &lt;35=F&gt;](msg:F) 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 (38)](tag:38). An immediate response to this message is required. It is recommended that an [Execution Report &lt;35=8&gt;](msg:8) with [ExecType (150)](tag:150)='Pending Replace' be sent unless the Order Cancel/Replace Request can be immediately accepted ([Execution Report &lt;35=8&gt;](msg:8) with [ExecType (150)](tag:150)='Replaced') or rejected ([Order Cancel Reject &lt;35=9&gt;](msg:9) 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 [Order Cancel Reject &lt;35=9&gt;](msg:9) message. The [Order Cancel Reject &lt;35=9&gt;](msg:9) message should provide the [ClOrdID (11)](tag:11) and [OrigClOrdID (41)](tag:41) values which were specified on the Cancel/Replace Request message for identification. Note that while it is necessary for the [ClOrdID (11)](tag:11) to change and be unique, the broker's [OrderID (37)](tag:37) 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: - [ExecInst (18)](tag:18) - [OrderQty (38)](tag:38) - [OrdType (40)](tag:40) - [Price (44)](tag:44) - [HandlInst (21)](tag:21) - [TimeInForce (59)](tag:59) - [TradingSessionID (336)](tag:336) - [EffectiveTime (168)](tag:168) - [ExpireDate (432)](tag:432) - [ExpireTime (126)](tag:126) - [MinQty (110)](tag:110) - [MaxFloor (111)](tag:111) - [StopPx (99)](tag:99) - [PegDifference (211)](tag:211) - [DiscretionInst (388)](tag:388) - [DiscretionOffset (389)](tag:389) - [CashOrderQty (152)](tag:152) - [OrderQty2 (192)](tag:192) - [OpenClose (77)](tag:77) - [CoveredOrUncovered (203)](tag:203) - [Side (54)](tag:54) (i.e. sell to sell plus) - [MaxShow (210)](tag:210) - [LocateReqd (114)](tag:114) When modifying [ExecInst (18)](tag:18) fields in a replacement order, it is necessary to re-declare all [ExecInst (18)](tag:18) in the replacement order. [ExecInst (18)](tag:18)'s will not be carried forward from the original order to the replacement unless re-declared.This message is used to request the order status for an existing order.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 (71)](tag:71) field indicates the purpose of the message. When submitting calculated, replace, or cancel [AllocTransType (71)](tag:71) messages the [RefAllocID (72)](tag:72) field is required. Note that [AllocTransType (71)](tag:71) of Cancel, Reject, or Replace affects the entire Allocation message thus each [AllocAccount (79)](tag:79) (cannot cancel, reject, or replace a single [AllocAccount (79)](tag:79) instance without affecting the entire Allocation message). Replacement Allocation messages must contain all data for the replacement allocation. Calculated allocations should have a unique [AllocID (70)](tag:70) and use [RefAllocID (72)](tag:72) to specify the [AllocID (70)](tag:70) from the preliminary. Calculated without preliminary are sent unsolicited from the sellside and do not require [RefAllocID (72)](tag:72). The Allocation message contains repeating fields for each order, sub-account and individual execution. The repeating fields shown below are marked 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 (53)](tag:53) 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 (78)](tag:78). - Multiple orders can be combined for allocation by identifying the number of orders in the [NoOrders (73)](tag:73) field and each individual order in the [OrderID (37)](tag:37) 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 (79)](tag:79) and [AllocShares (80)](tag:80) values within the repeating group designated by [NoAllocs (78)](tag:78). - Sellside sends [Execution Report &lt;35=8&gt;](msg:8) 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 (79)](tag:79) has a single [AllocAvgPx (153)](tag:153) 2. Using Executed Price: Combination of each [AllocAccount (79)](tag:79) and [AllocPrice (366)](tag:366) (unique [LastPx (31)](tag:31)) (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](app_k.html) for more examples and details. Note: Req'd = "Y*" indicates that the field is **not** required for [AllocTransType (71)](tag:71) ='2' (Cancel)This message is used to cancel previously submitted lists, either before or during execution. If a list has not yet been submitted for execution, this message will instruct the broker not to execute it. If the list is being executed, this 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 using [Order Cancel Request &lt;35=F&gt;](msg:F). The response to this message is [List Status &lt;35=N&gt;](msg:N).This message is used to instruct the broker to begin executing a previously submitted list.This message is used to request the status of a previously submitted list. The corresponding response message is [List Status &lt;35=N&gt;](msg:N).This message contains the current state of the orders in a previously submitted list. It's used to respond to [List Status Request &lt;35=M&gt;](msg:M)s and [List Cancel Request &lt;35=K&gt;](msg:K)s. Orders within the list are given a summary status. The current state of the order is reported, not individual executions. The values for [ListOrderStatus (431)](tag:431) are: - "InBiddingProcess": indicates that a list has been received and is being evaluated 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. This would also apply if a list has been previously cancelled. The status of individual order can be determined from the detail repeating group. - "Alert": used whenever any of the individual orders have a status that requires something to be done. For instance, an 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 (66)](tag:66) is not recognised. The text field should include an explanation of why the Request s been rejected.This message is used to acknowledge and provide the status for an [Allocation &lt;35=J&gt;](msg:J) message. Multiple messages may be generated for a single allocation to acknowledge, then separately accept or reject the allocation.This message is used when an execution is rejected. The decision to reject ("DK") an execution lies with the institution. It is not a requirement to enforce all the reasons given in [DKReason (127)](tag:127).This message is used to request a [Quote &lt;35=S&gt;](msg:S), an indication of the current price of an instrument. It can be used to request quotes for one or more products. This message is commonly referred to as an RFQ, a "request for quote". In some markets, it's common to request quotes from brokers prior to placing an order. Securities quotes can be requested as either market quotes or for a specific quantity and side. If [OrderQty (38)](tag:38) and [Side (54)](tag:54) are absent, a market-style quote (bid x offer, size x size) will be returned. Forex quotes can be requested as indicative or at a specific quantity level. If an indicative quote is requested ([OrderQty (38)](tag:38) and [Side (54)](tag:54) 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 &lt;35=S&gt;](msg:S) messages specifying various levels and sides.This message contains quotes for a single instrument, an indication of the current price. It's used in response to a [Quote Request &lt;35=R&gt;](msg:R) and may also be unsolicited. If responding to a [Quote Request &lt;35=R&gt;](msg:R), this message must include the [QuoteReqID (131)](tag:131) from the request. Unsolicited quotes will omit that field. If the quote requires a response then [QuoteResponseLevel (301)](tag:301) should be populated. A quote can be canceled either using the [Quote Cancel &lt;35=Z&gt;](msg:Z) message or by sending a quote message with [BidPx (132)](tag:132), [OfferPx (133)](tag:133), [BidSize (134)](tag:134) and [OfferSize (135)](tag:135) all set to zero. The time in force for a quote is determined by agreement between counterparties. In tradeable and restricted-tradeable quoting models, the market maker sends quotes into a market as opposed to sending quotes directly to a counterparty. For fixed income in the indicative and tradeable quoting models, the quotes are typically sent directly to an interested counterparty. This message should not be used in tradeable and restricted-tradeable quoting markets to broadcast quotes to market participants. The recommended approach to reporting market state changes that result from quotes received by a market is to use market data messages. Orders can be created from quotes. Quoted orders include the [QuoteID (117)](tag:117) and [OrdType (40)](tag:40) = "previously quoted".This message provides instructions for trade settlement. [SettlInstSource (165)](tag:165) indicates if the settlement instructions belong to a broker or institution. It's been designed so that it can be sent between different types of institutions. This message can be used in one of two modes ([SettlInstMode (160)](tag:160)): - To provide "standing instructions" for the settlement of trades occurring in the future, messages should include some combination of: - [AllocAccount (79)](tag:79) - [LastMkt (30)](tag:30) - [Side (54)](tag:54) - [SecurityType (167)](tag:167) - [SettlLocation (166)](tag:166) - [SettlDeliveryType (172)](tag:172) - [EffectiveTime (168)](tag:168) - 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 &lt;35=J&gt;](msg:J) message: ([TradeDate (75)](tag:75) + [AllocID (70)](tag:70) + [AllocAccount (79)](tag:79)) 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 (169)](tag:169), [StandInstDbName (170)](tag:170), and [StandInstDbID (171)](tag:171) fields.This message is used to request for market data for specific instruments. This includes real-time quotes, orders, trades, trade volumes, open interest, or other price information on a subscription basis. A market data feed may consist of both [Market Data Snapshot Full Refresh &lt;35=W&gt;](msg:W) and [Market Data Incremental Refresh &lt;35=X&gt;](msg:X) messages. [SubscriptionRequestType (263)](tag:263) is used in the request to specify whether updates are required and to unsubscribe. To specify which types of market data are required, include one or more [MDEntryType (269)](tag:269)s in the request.This message includes the full market data state for a single instrument. It can be sent in response to a [Market Data Request &lt;35=V&gt;](msg:V) or can be unsolicited. If sent in response to a request, it should include the relevant [MDReqID (262)](tag:262). Multiple snapshots can potentially be used to provide updates in a subscription workflow, instead of [Market Data Incremental Refresh &lt;35=X&gt;](msg:X). In that case, each snapshot fully replaces the previous one. This potentially simplifies processing at the cost of additional bandwidth. This message includes many optional fields. Firms can individually decide which optional fields they wish to support.This message is used to send incremental updates to market data for one or more instruments. This is optimized to minimize network overhead. If doing so is not important then [Market Data Snapshot Full Refresh &lt;35=W&gt;](msg:W) will usually result in a simpler workflow. This message may contain any combination of new, changed, or deleted market data entries, for any number of instruments, so long as the maximum FIX message size is not exceeded. # Entry ID Market data entries may have an [MDEntryID (278)](tag:278), which must be unique among all currently active entries so they can be referenced later. When changing a market data entry, it may retain its [MDEntryID (278)](tag:278), in which case only [MDEntryID (278)](tag:278) would be populated. Alternatively, the [MDEntryID (278)](tag:278) can change, in which case [MDEntryID (278)](tag:278) will contain the new ID, and [MDEntryRefID (280)](tag:280) specifies. An [MDEntryID (278)](tag:278) can be reused within a day only if it has first been deleted. Alternately, when showing the best quotes from a market maker or exchange, rather than orders in a book, [MDEntryID (278)](tag:278) can be omitted. In this case, the combination side, symbol and market maker/exchange acts as a unique key. 'New' and 'change' entries will replace the previous entry for that key, and 'delete' will remove the entry. # Market Data Position If used, [MDEntryPositionNo (290)](tag:290) requires special consideration. For example, assume ten bids for a security. Adding a new bid with [MDEntryPositionNo (290)](tag:290) = 4 requires the receiver to shift down other entries, i.e. the 4th entry will shift to 5th, the 5th entry to 6th, etc. The sender must not send a modification of all entries in the less favourable positions just to update the [MDEntryPositionNo (290)](tag:290) field; the recipient must infer the change. Similarly, deleting an entry in the 7th position causes the 8th entry to move to 7th, the 9th entry to 8th, etc. A change to [MDEntryPositionNo (290)](tag:290) causes the entries lying between the old and new positions to shift. For instance, suppose an entry that occupied the 5th position is changed to the 8th position. This means that the 6th entry shifts to the 5th position, the 7th to 6th, and what was in the 8th position shifts into 7th to make room for the changed entry. # Reducing Traffic Several techniques are employed to reduce network traffic. An instrument only needs to be identified when a market data entry is first created. An entry can refer to a previous market data entry for the same instrument instead of duplicating the information. A new market data entry will default to the same instrument of the previous entry within the message if [Symbol (55)](tag:55) and [MDEntryRefID (280)](tag:280) are omitted. In the case of a change in an entry, only the changed fields need to be sent. For example, a change in [MDEntrySize (271)](tag:271) but not [MDEntryPx (270)](tag:270) only requires including the former. When creating a new entry for an instrument similar to the instrument of the previous entry in the same message, only the symbol identification fields that have changed need to be send, such as [MaturityMonthYear (200)](tag:200) or [StrikePrice (202)](tag:202).This message is used when a [Market Data Request &lt;35=V&gt;](msg:V) cannot be honored, due to business or technical reasons. Applications may limit various parameters, such as the size of requests, or which types of updates must be used.This message is used to cancel one or more existing [Quote &lt;35=S&gt;](msg:S)s. It's recommended that this message be acknowledged using a [Quote Acknowledgement &lt;35=b&gt;](msg:b).This message is used to request the status of one or more existing quotes. It results in an [Execution Report &lt;35=8&gt;](msg:8) containing the quote status.This message is a response to a [Mass Quote &lt;35=i&gt;](msg:i). If the entire quote is rejected, [QuoteRejectReason (300)](tag:300) is used to report the reason. If an entry is rejected, [QuoteEntryRejectReason (368)](tag:368) is used to report the reason. 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 MassQuote. Derivative markets are characterized by high bandwidth consumption, due to a change in an underlying security price causing multiple quotes to be recalculated and retransmitted to the market, often hundreds at a time. For that reason, the ability to set the level of response is specified using the [QuoteResponseLevel (301)](tag:301) field.This message is used to: - request a specific Security to be traded with the second party. The request security can be defined as a multileg security made up of one or more instrument legs - request a set of individual securities for a single market segment - request all securities, independent of market segment A subscription for security status can be optionally created by including [SubscriptionRequestType (263)](tag:263) on the message. See "Security Definition, Security Status, and Trading Session Message Scenarios"This message is used for the following reason: 1. To accept the security defined in another Security Definition, optionally with changes to the definition or identity 2. To reject the security requested in another Security Definition message 3. To respond to a request for securities within a specified market segment 4. To convey security definitions for all market segments that the security participates in 5. To convey the security's trading rules that differ from default rules for the market segmentThis message is a request for the status of a security. One or more [Security Status &lt;35=f&gt;](msg:f) messages are returned as a result. This message contains [SubscriptionRequestType (263)](tag:263) which specifies the type of the request: - 0 – a snapshot of the current status - 1 – a snapshot of the current status plus updates as the status changes (subscription) - 2 – cancel any pending snapshots or updates (unsubscribe)This message is used to report changes in the status of a security. It contains fields to indicate trading status, corporate actions, and financial status of the company. If the message is sent in response to a [Security Status Request &lt;35=e&gt;](msg:e), it should provide the [SecurityStatusReqID (324)](tag:324) from the request.This message is used to request information about the status of a market. With the move to multiple sessions occurring for a given trading party, e.g. morning and evening sessions, there is a need to be able to provide information on what product is trading on what market. This message can be used to inquire about the trading status of a trading party. It can be used to subscribe to updates to the status of a trading session by setting [SubscriptionRequestType (263)](tag:263) = 1. To list the securities available during a particular trading session, see [Security Definition Request &lt;35=c&gt;](msg:c).This message provides information about the status of a market. For markets with multiple trading sessions occurring, e.g. morning and evening sessions, this message details which products are trading on which market during which trading session.This message can contain quotes for multiple securities to support 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 [QuotSetGrp](component:QuotSetGrp) specifies the first level of repeating fields for the message. It represents a group of related quotes and may, for example, represent an option class. Each [QuotSetGrp](component:QuotSetGrp) contains the optional repeating group [QuoteEntryGrp](component:QuoteEntryGrp) which may represent an option series. It's possible that the number of entries for a quote set could exceed the physical or practical message size. It may be necessary to fragment a message across multiple quote messages. Message size limits must be mutually agreed between counterparties.This message can be used to reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. If the message fails a session-level rule, e.g. body length is incorrect, a session-level [Reject &lt;35=3&gt;](msg:3) message should be issued. The only exception to this rule is when the FIX session protocol is not being used. An appropriate reject message of the given session protocol or the Business Message Reject message should be used instead. It should **not** be used in the following situations: <table><thead><tr><th>In response to</th><th>Appropriate Response</th></tr></thead> <tbody><tr><td>A session-level problem meeting the criteria of the session-level <a href="msg:3">Reject &lt;35=3&gt;</a> message</td><td><a href="msg:3">Reject &lt;35=3&gt;</a> message</td></tr> <tr><td><a href="msg:D">Order Single &lt;35=D&gt;</a>, <a href="msg:H">Order Status Request &lt;35=H&gt;</a>, <a href="msg:E">New Order List &lt;35=E&gt;</a>, <a href="msg:L">List Execute &lt;35=L&gt;</a></td><td><a href="msg:8">Execution Report &lt;35=8&gt;</a></td></tr> <tr><td><a href="msg:F">Order Cancel Request &lt;35=F&gt;</a>, <a href="msg:G">Order Cancel/Replace Request &lt;35=G&gt;</a>, <a href="msg:K">List Cancel Request &lt;35=K&gt;</a></td><td><a href="msg:9">Order Cancel Reject &lt;35=9&gt;</a></td></tr> <tr><td><a href="msg:8">Execution Report &lt;35=8&gt;</a></td><td><a href="msg:Q">Don't Know Trade &lt;35=Q&gt;</a></td></tr> <tr><td><a href="msg:J">Allocation &lt;35=J&gt;</a></td><td><a href="msg:P">Allocation Ack &lt;35=P&gt;</a></td></tr> <tr><td><a href="msg:M">List Status Request &lt;35=M&gt;</a></td><td><a href="msg:N">List Status &lt;35=N&gt;</a></td></tr> <tr><td><a href="msg:R">Quote Request &lt;35=R&gt;</a>, <a href="msg:S">Quote &lt;35=S&gt;</a>, <a href="msg:i">Mass Quote &lt;35=i&gt;</a>, <a href="msg:Z">Quote Cancel &lt;35=Z&gt;</a>, <a href="msg:a">Quote Status Request &lt;35=a&gt;</a></td><td><a href="msg:b">Quote Acknowledgement &lt;35=b&gt;</a></td></tr> <tr><td><a href="msg:V">Market Data Request &lt;35=V&gt;</a></td><td><a href="msg:Y">Market Data Request Reject &lt;35=Y&gt;</a></td></tr> <tr><td><a href="msg:c">Security Definition Request &lt;35=c&gt;</a></td><td><a href="msg:d">Security Definition &lt;35=d&gt;</a></td></tr> <tr><td><a href="msg:e">Security Status Request &lt;35=e&gt;</a></td><td><a href="msg:f">Security Status &lt;35=f&gt;</a></td></tr> <tr><td><a href="msg:g">Trading Session Status Request &lt;35=g&gt;</a></td><td><a href="msg:h">Trading Session Status &lt;35=h&gt;</a></td></tr> <tr><td><a href="msg:k">Bid Request &lt;35=k&gt;</a></td><td><a href="msg:l">Bid Response &lt;35=l&gt;</a></td></tr> </tbody></table> The only exceptions to this rule are: 1. In the event a business message is received, fulfills session-level rules, but cannot be communicated to the business-level processing system. In this situation a Business Message Reject with [BusinessRejectReason (380)](tag:380) = "Application not available at this time" can be issued 2. In the event a valid business message is received, fulfills session-level rules, but contains a message type that's not supported by the recipient. In this situation a Business Message Reject with [BusinessRejectReason (380)](tag:380) = "Unsupported Message Type" can be issued 3. In the event a business message is received, fulfills session-level rules, but lacks a field conditionally required by the FIX specification. In this situation a Business Message Reject with [BusinessRejectReason (380)](tag:380) = "Conditionally Required Field Missing" can be issued Messages which can be referenced within a Business Message Reject message are as follows. The ID field which [BusinessRejectRefID (379)](tag:379) refers to is also noted: <table><thead><tr><th>Message</th><th>BusinessRejectRefID</th></tr></thead> <tbody><tr><td><a href="msg:6">Indication of Interest &lt;35=6&gt;</a></td><td><a href="tag:23">IOIid (23)</a></td></tr> <tr><td><a href="msg:7">Advertisement &lt;35=7&gt;</a></td><td><a href="tag:2">AdvId (2)</a></td></tr> <tr><td><a href="msg:B">News &lt;35=B&gt;</a></td><td><a href="tag:148">Headline (148)</a></td></tr> <tr><td><a href="msg:C">Email &lt;35=C&gt;</a></td><td><a href="tag:164">EmailThreadID (164)</a></td></tr> <tr><td><a href="msg:9">Order Cancel Reject &lt;35=9&gt;</a></td><td><a href="tag:11">ClOrdID (11)</a></td></tr> <tr><td><a href="msg:P">Allocation Ack &lt;35=P&gt;</a></td><td><a href="tag:70">AllocID (70)</a></td></tr> <tr><td><a href="msg:N">List Status &lt;35=N&gt;</a></td><td><a href="tag:66">ListID (66)</a></td></tr> <tr><td><a href="msg:Q">Don't Know Trade &lt;35=Q&gt;</a></td><td><a href="tag:17">ExecID (17)</a></td></tr> <tr><td><a href="msg:T">Settlement Instructions &lt;35=T&gt;</a></td><td><a href="tag:162">SettlInstID (162)</a></td></tr> <tr><td><a href="msg:W">Market Data Snapshot Full Refresh &lt;35=W&gt;</a></td><td><a href="tag:262">MDReqID (262)</a></td></tr> <tr><td><a href="msg:X">Market Data Incremental Refresh &lt;35=X&gt;</a></td><td><a href="tag:262">MDReqID (262)</a></td></tr> <tr><td><a href="msg:Y">Market Data Request Reject &lt;35=Y&gt;</a></td><td><a href="tag:262">MDReqID (262)</a></td></tr> <tr><td><a href="msg:d">Security Definition &lt;35=d&gt;</a></td><td><a href="tag:322">SecurityResponseID (322)</a></td></tr> <tr><td><a href="msg:f">Security Status &lt;35=f&gt;</a></td><td><a href="tag:324">SecurityStatusReqID (324)</a></td></tr> <tr><td><a href="msg:h">Trading Session Status &lt;35=h&gt;</a></td><td><a href="tag:335">TradSesReqID (335)</a></td></tr> <tr><td><a href="msg:l">Bid Response &lt;35=l&gt;</a></td><td><a href="tag:390">BidID (390)</a></td></tr> </tbody></table> Whenever possible, it is strongly recommended that the cause of the failure be described in the [Text (58)](tag:58) field.This 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, this message can be used to request a bid based on the sector, country, index and liquidity information provided. [BidDescReqGrp](component:BidDescReqGrp) describe the portfolio of stocks being traded in a number of "bid descriptors" entries. In the disclosed convention, e.g. Japanese model, this message can be used to request bids based on preceding [New Order List &lt;35=E&gt;](msg:E)s. [BidCompReqGrp](component:BidCompReqGrp) is used to define which [New Order List &lt;35=E&gt;](msg:E) messages a bid is being sought for and the directions of the required bids. [BidDescReqGrp](component:BidDescReqGrp) and [BidCompReqGrp](component:BidCompReqGrp) are mutually exclusive, depending which convention is being used. [SideValue1 (396)](tag:396) and [SideValue2 (397)](tag:397) are used to show the monetary total value of the transaction in either direction (buy or sell) without revealing whether the buy-side intends to buy or sell. [BidRequestTransType (374)](tag:374) = "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.This message can be used in one of two ways depending on which market conventions are being followed: In the non-disclosed convention, this message can be used to supply a bid based on the sector, country, index and liquidity information contained within the request. In the disclosed convention, this message can be used to supply bids based on preceding [New Order List &lt;35=E&gt;](msg:E) messages.This message is used to exchange strike price information for principal trades. It can also be used to exchange reference prices for agency trades.