Orchestra2025-04-18T09:45:45.419556264ZOrchestra 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 buy and sell sides, e.g. broker and institution or investor/intermediary and fund manager.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. For Fixed Income trades [AvgPx (6)](tag:6) is always expressed as [percent-of-par](glossary.html#PercentOfPar), regardless of the [PriceType (423)](tag:423) of [LastPx (31)](tag:31). I.e., [AvgPx (6)](tag:6) will contain an average of percent-of-par values (see [LastParPx (669)](tag:669)) for issues traded in Yield, Spread or Discount.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 bytes, simple checksum (see Volume 2: "Checksum Calculation" 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 the buy-side (institution, broker, intermediary etc.) (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 quantity (e.g. 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 6-A: Valid Currency Codes](app_6_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 sell-side (broker, exchange, ECN) (will be 0 (zero) for [ExecType (150)](tag:150) ='I' (Order 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 Trade Cancel and Trade Correct execution types. Prior to FIX 4.1 this field was of type int.Instructions for order handling on Broker trading floorIdentifies class or source of the [SecurityID (48)](tag:48) value. Required if [SecurityID (48)](tag:48) is specified.Unique identifier of [Indication of Interest &lt;35=6&gt;](msg:6) message. Prior to FIX 4.1 this field was of type int.Relative quality of indicationReference identifier used with CANCEL and REPLACE, transaction types. Prior to FIX 4.1 this field was of type int.Quantity (e.g. number of shares) in numeric form or relative size.Identifies [Indication of Interest &lt;35=6&gt;](msg:6) message transaction typeBroker capacity in order executionMarket of execution for last fill, or an indication of the market where an order was routedPrice of this (last) fill.Quantity (e.g. shares) bought/sold on this (last) fill. 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 sell-side (broker, exchange, ECN). 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.Quantity ordered. This represents the number of shares for equities or par, face or nominal value for FI instruments. 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 unit of quantity (e.g. per share)Reference message sequence numberSecurity identifier value of [SecurityIDSource (22)](tag:22) type (e.g. CUSIP, SEDOL, ISIN, etc). Requires [SecurityIDSource (22)](tag:22).Assigned value used to identify firm sending message.Assigned value used to identify specific message originator (desk, trader, etc.)Time of message transmission (always expressed in UTC (Universal Time Coordinated, also known as "GMT")Overall/total quantity (e.g. number of shares) Prior to FIX 4.2 this field was of type int.Side of order.Ticker symbol. Common, "human understood" representation of the security. [SecurityID (48)](tag:48) value can be specified if no symbol exists (e.g. non-exchange traded Collective Investment Vehicles) Use "[N/A]" for products which do not have a symbol.Assigned 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. NOTE not applicable to CIV Orders.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. If present, [SettlDate (64)](tag:64) overrides this field. If both [SettlType (63)](tag:63) and [SettlDate (64)](tag:64) are omitted, the default for [SettlType (63)](tag:63) is '0' (Regular) Regular is defined as the default settlement period for the particular security on the exchange of execution. In Fixed Income the contents of this field may influence the instrument definition if the [SecurityID (48)](tag:48) is ambiguous. In the US an active Treasury offering may be re-opened, and for a time one CUSIP will apply to both the current and "when-issued" securities. Supplying a value of "7" clarifies the instrument description; any other value or the absence of this field should cause the respondent to default to the active issue. Prior to FIX 4.4 this field was named "SettlmntTyp".Specific date of trade settlement (SettlementDate) in YYYYMMDD format. If present, this field overrides [SettlType (63)](tag:63). This field is required if the value of [SettlType (63)](tag:63) is '6' (Future) or '8' (Sellers Option). This field must be omitted if the value of [SettlType (63)](tag:63) is '7' (When and If Issued) (expressed in local time at place of settlement) Prior to FIX 4.4 this field was named "FutSettDate".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 message. Prior to FIX 4.1 this field was of type int.Identifies allocation transaction typeReference identifier to be used with [AllocTransType (71)](tag:71) = 'Replace' or 'Cancel'. 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. Prior to FIX 4.4 this field was named "AvgPrxPrecision".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).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.Number of repeating [AllocAccount (79)](tag:79)/[AllocPrice (366)](tag:366) entries.Sub-account mnemonicQuantity 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) /[AllocQty (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 quantity canceled for this order. Prior to FIX 4.2 this field was of type int.Number of delivery instruction fields in repeating group. **Note this field was removed in FIX 4.1 and reinstated in FIX 4.4**Identifies status of allocation.Identifies reason for rejection.Electronic signatureLength of encrypted messageActual encrypted data streamNumber 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.Method of encryption.Price per unit of quantity (e.g. per share)Execution 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.Name of security issuer (e.g. International Business Machines, GNMA). see also Volume 7: "PRODUCT: FIXED INCOME - Euro Issuer Values"Security description.[Heartbeat &lt;35=0&gt;](msg:0) interval (seconds)Minimum quantity of an order to be executed. Prior to FIX 4.2 this field was of type int.Maximum quantity (e.g. 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 6-A: Valid Currency Codes](app_6_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.Time/Date of order expiration (always expressed in UTC (Universal Time Coordinated, also known as "GMT") The meaning of expiration is specific to the context where the field is used. - For orders, this is the expiration time of a 'Good Till Date' [TimeInForce (59)](tag:59). - For Quotes - this is the expiration of the quote. - Expiration time is provided across the quote message dialog to control the length of time of the overall quoting process. - For collateral requests, this is the time by which collateral must be assigned. - For collateral assignments, this is the time by which a response to the assignment is expected.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 [Indication of Interest &lt;35=6&gt;](msg:6) 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 URI (Uniform Resource Identifier) or URL (Uniform Resource Locator) link to additional information (i.e. https://en.wikipedia.org/wiki/URL) See [Appendix 6-B: FIX Fields Based Upon Other Standards](app_6_b.html)Describes the specific Execution Report (i.e. Pending Cancel) while [OrdStatus (39)](tag:39) will always identify the current order status (i.e. Partially Filled)Quantity 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 tradeable units (e.g. number of shares). The broker or fund manager (for CIV orders) would be responsible for converting and calculating a tradeable unit (e.g. 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) For Fixed Income this is always expressed as "[percent of par](glossary.html#PercentOfPar)" price type.[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 income. Note value may be negative.The amount the buyer compensates the seller for the portion of the next coupon interest payment the seller has earned but will not receive from the issuer because the issuer will send the next coupon payment to the buyer. Accrued Interest Rate is the annualized Accrued Interest amount divided by the purchase price of the bond.Amount of Accrued Interest for convertible bonds and fixed incomeIndicates mode used for [Settlement Instructions &lt;35=T&gt;](msg:T) message.Free format text related to a specific [AllocAccount (79)](tag:79).Unique identifier for Settlement Instruction.[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)Indicates type of security. See also the [Product (460)](tag:460) and [CFICode (461)](tag:461) fields. It is recommended that [CFICode (461)](tag:461) be used instead of [SecurityType (167)](tag:167) for non-Fixed Income instruments. Example values (grouped by [Product (460)](tag:460) field value) (Note: additional values may be used by mutual agreement of the counterparties): AGENCY - EUSUPRA = Euro Supranational Coupons * - FAC = Federal Agency Coupon - FADN = Federal Agency Discount Note - PEF = Private Export Funding * - SUPRA = USD Supranational Coupons * - * Identify the Issuer in the [Issuer (106)](tag:106) field COMMODITY - Use [CFICode (461)](). See: [Appendix 6-F: 4.Replaced Field Enumerations for Futures and Options for SecurityType (tag 167) with CFICode (tag 461) [replaced in FIX 4.3]](app_6_f.html#4) CORPORATE - CORP = Corporate Bond - CPP = Corporate Private Placement - CB = Convertible Bond - DUAL = Dual Currency - EUCORP = Euro Corporate Bond - XLINKD = Indexed Linked - STRUCT = Structured Notes - YANK = Yankee Corporate Bond CURRENCY - FOR = Foreign Exchange Contract EQUITY - CS = Common Stock - PS = Preferred Stock WAR - Warrant now is listed under Municipals for consistency with Bloomberg fixed income product types. For equity warrants - use the [CFICode (461)](tag:461) instead. GOVERNMENT - BRADY = Brady Bond - EUSOV = Euro Sovereigns * - TBOND = US Treasury Bond - TINT = Interest strip from any bond or note - TIPS = Treasury Inflation Protected Securities - TCAL = Principal strip of a callable bond or note - TPRN = Principal strip from a non-callable bond or note - UST = US Treasury Note (deprecated value, use "**TNOTE**") - USTB = US Treasury Bill (deprecated value, use "**TBILL**") - TNOTE = US Treasury Note - TBILL = US Treasury Bill - * Identify the Issuer Name in [Issuer (106)](tag:106) FINANCING - REPO = Repurchase - FORWARD = Forward - BUYSELL = Buy Sellback - SECLOAN = Securities Loan - SECPLEDGE = Securities Pledge INDEX Note: "Indices" includes: Stock, Index Spot Options, Commodity, Physical Index Options, Share/Ratio, and Spreads. For index types use the [CFICode (461)](tag:461). LOAN - TERM = Term Loan - RVLV = Revolver Loan - RVLVTRM = Revolver/Term Loan - BRIDGE = Bridge Loan - LOFC = Letter of Credit - SWING = Swing Line Facility - DINP = Debtor in Possession - DEFLTED = Defaulted - WITHDRN = Withdrawn - REPLACD = Replaced - MATURED = Matured - AMENDED = Amended & Restated - RETIRED = Retired MONEYMARKET - BA = Bankers Acceptance - BN = Bank Notes - BOX = Bill of Exchanges - CD = Certificate of Deposit - CL = Call Loans - CP = Commercial Paper - DN = Deposit Notes - EUCD = Euro Certificate of Deposit - EUCP = Euro Commercial Paper - LQN = Liquidity Note - MTN = Medium Term Notes - ONITE = Overnight - PN = Promissory Note - PZFJ = Plazos Fijos - STN = Short Term Loan Note - TD = Time Deposit - XCN = Extended Comm Note - YCD = Yankee Certificate of Deposit MORTGAGE - ABS = Asset-backed Securities - CMBS = Corp. Mortgage-backed Securities - CMO = Collateralized Mortgage Obligation - IET = IOETTE Mortgage - MBS = Mortgage-backed Securities - MIO = Mortgage Interest Only - MPO = Mortgage Principal Only - MPP = Mortgage Private Placement - MPT = Miscellaneous Pass-through - PFAND = Pfandbriefe * - TBA = To be Announced - * Identify the Issuer Name in [Issuer (106)](tag:106) MUNICIPAL - AN = Other Anticipation Notes (BAN, GAN, etc.) - COFO = Certificate of Obligation - COFP = Certificate of Participation - GO = General Obligation Bonds - MT = Mandatory Tender - RAN = Revenue Anticipation Note - REV = Revenue Bonds - SPCLA = Special Assessment - SPCLO = Special Obligation - SPCLT = Special Tax - TAN = Tax Anticipation Note - TAXA = Tax Allocation - TECP = Tax Exempt Commercial Paper - TRAN = Tax & Revenue Anticipation Note - VRDN = Variable Rate Demand Note - WAR = Warrant OTHER - MF = Mutual Fund (i.e. any kind of open-ended "Collective Investment Vehicle") - MLEG = Multi-leg instrument (e.g. options strategy or futures spread. [CFICode (461)](tag:461) can be used to identify if options-based, futures-based, etc.) - NONE = No Security Type - ? = "Wildcard" entry (used on [Security Definition Request &lt;35=c&gt;](msg:c) message) **NOTE: Additional values may be used by mutual agreement of the counterparties)**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) Free 2 = Tri-Party 3 = Hold In CustodyBid 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.[SettlDate (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 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 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 [IOIQualifier (104)](tag:104).Can be used with standardized derivatives vs. the [MaturityDate (541)](tag:541) field. Month and Year of the maturity (used for standardized futures and options). Format: YYYYMM (i.e. 199903) YYYYMMDD (20030323) YYYYMMwN (200303w1) for week A specific date or can be appended to the [MaturityMonthYear (200)](tag:200). For instance, if multiple standard products exist that mature in the same Year and Month, but actually mature at a different time, a value can be appended, such as "w1" or "w2" to indicate week 1 as opposed to week 2 expiration. Likewise, the date (01-31) can be appended to indicate a specific expiration (maturity date).No longer used as of FIX 4.3. Included here for reference to prior versions. *** REPLACED FIELD - See: [Appendix 6-F: 5.Replaced Field: PutOrCall (tag 201) and UnderlyingPutOrCall (tag 315) with CFICode (tag 461) [Replaced in FIX 4.3]](app_6_f.html#5) *** Indicates whether an Option is for a put or call.Strike Price for an Option.Used for derivative products, such as optionsCan be used for [SecurityType (167)](tag:167)=OPT to identify a particular security. Valid values vary by [SecurityExchange (207)](tag:207): *** REPLACED values - See [Appendix 6-F: 7.Replaced values: OptAttribute(tag 206) with values in CFICode(tag 461) [Replaced in FIX 4.3]](app_6_f.html#7) *** # 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 (i.e. step-in broker).Indicates how the receiver (i.e. third party) of Allocation message should handle/process the account details.Maximum quantity (e.g. number of shares) within an order to be shown to other customers (i.e. sent via an [Indication of Interest &lt;35=6&gt;](msg:6)). Prior to FIX 4.2 this field was of type [int](index.html#int).Amount (signed) added to the peg for a pegged order in the context of the [PegOffsetType (836)](tag:836) Prior to FIX 4.4 this field was of type [PriceOffset](index.html#PriceOffset).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 3-A: Pre-Trade Message Targeting/Routing](app_3_a.html)Indicates the type of [RoutingID (217)](tag:217) specified.Assigned value used to identify a specific routing destination.For Fixed Income. Either Swap Spread or Spread to Benchmark depending upon the order type. Spread to Benchmark: 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 [BenchmarkCurveName (221)](tag:221) field). Note: Basis points can be negative. Swap Spread: Target spread for a swap.Identifies currency used for benchmark curve. See "[Appendix 6-A: Valid Currency Codes](app_6_a.html)" for information on obtaining valid values. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Name of benchmark curve.Point on benchmark curve. Free form values: e.g. "1Y", "7Y", "INTERPOLATED". Sample values: 1M = combination of a number between 1-12 and a "M" for month 1Y = combination of number between 1-100 and a "Y" for year 10Y-OLD = see above, then add "-OLD" when appropriate INTERPOLATED = the point is mathematically derived 2/2031 5 3/8 = the point is stated via a combination of maturity month / year and coupon See Fixed Income-specific documentation at [www.fixtrading.org](https://www.fixtrading.org/) for additional values. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)The rate of interest that, when multiplied by the principal, par value, or face value of a bond, provides the currency amount of the periodic interest payment. The coupon is always cited, along with maturity, in any quotation of a bond's price.Date interest is to be paid. Used in identifying Corporate Bond issues. (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).The date on which a bond or stock offering is issued. It may or may not be the same as the effective date ([DatedDate (873)](tag:873)) or the date on which interest begins to accrue ([InterestAccrualDate (874)](tag:874)) (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type UTCDate.*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Number of business days before repurchase of a repo. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Percent of par at which a Repo will be repaid. Represented as a percent, e.g. .9525 represents 95-1/4 percent of par. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)For Fixed Income: Amorization Factor for deriving Current face from Original face for ABS or MBS securities, note the fraction may be greater than, equal to or less than 1. In TIPS securities this is the Inflation index. Qty * [Factor (228)](tag:228) * [Price (44)](tag:44) = Gross Trade Amount For Derivatives: Contract Value Factor by which price must be adjusted to determine the true nominal value of one futures/options contract. (Qty * [Price (44)](tag:44)) * [Factor (228)](tag:228) = Nominal Value (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Used with Fixed Income for Muncipal New Issue Market. Agreement in principal between counter-parties prior to actual trade date. (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type UTCDate.The date when a distribution of interest is deducted from a securities assets or set aside for payment to bondholders. On the ex-date, the securities price drops by the amount of the distribution (plus or minus any market activity). (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type UTCDate.Specifies the ratio or multiply factor to convert from "nominal" units (e.g. contracts) to total units (e.g. shares) (e.g. 1.0, 100, 1000, etc). Applicable For Fixed Income, Convertible Bonds, Derivatives, etc. In general quantities for all calsses should be expressed in the basic unit of the instrument, e.g. shares for equities, norminal or par amount for bonds, currency for foreign exchange. When quantity is expressed in contracts, e.g. financing transactions and bond trade reporting, ContractMutliplier should contain the number of units in one contract and can be omitted if the multiplier is the default amount for the instrument, i.e. 1,000 par of bonds, 1,000,000 par for financing transactions.Number of stipulation entries (Note tag # was reserved in FIX 4.1, added in FIX 4.3).For Fixed Income. Type of Stipulation. Values include: AMT = AMT (y/n) AUTOREINV = Auto Reinvestment at <rate> or better BANKQUAL = Bank qualified (y/n) BGNCON = Bargain Conditions (see [StipulationValue (234)](tag:234) for values) COUPON = Coupon range CURRENCY = ISO [Currency (15)](tag:15) code CUSTOMDATE = Custom start/end date GEOG = Geographics and % Range (ex. 234=CA 0-80 [minimum of 80% California assets]) HAIRCUT = Valuation discount INSURED = Insured (y/n) ISSUE = Year or Year/Month of Issue (ex. 234=2002/09) ISSUER = [Issuer (106)](tag:106)'s ticker ISSUESIZE = issue size range LOOKBACK = Lookback days LOT = Explicit lot identifier LOTVAR = Lot Variance (value in percent maximum over- or under-allocation allowed) MAT = Maturity Year and Month MATURITY = Maturity range MAXSUBS = Maximum substitutions (Repo) MINQTY = Minimum quantity MININCR = Minimum increment MINDNOM = Minimum denomination PAYFREQ = Payment frequency, calendar PIECES = Number of Pieces PMAX = Pools Maximum PPM = Pools per Million PPL = Pools per Lot PPT = Pools per Trade PRICE = Price range PRICEFREQ = Pricing frequency PROD = Production Year PROTECT = Call protection PURPOSE = Purpose PXSOURCE = Benchmark price source RATING = Rating source and range REDEMPTION = Type of redemption - values are: NonCallable, Callable, Prefunded, EscrowedToMaturity, Putable, Convertible RESTRICTED = Restricted (y/n) SECTOR = Market sector SECTYPE = [SecurityType (167)](tag:167) included or excluded STRUCT = Structure SUBSFREQ = Substitutions frequency (Repo) SUBSLEFT = Substitutions left (Repo) TEXT = Freeform text TRDVAR = Trade Variance (value in percent maximum over- or under-allocation allowed) WAC = Weighted Average Coupon: value in percent (exact or range) plus 'Gross' or 'Net' of servicing spread (the default) (ex. 234=6.5- Net [minimum of 6.5% net of servicing fee]) WAL = Weighted Average Life Coupon: value in percent (exact or range) WALA = Weighted Average Loan Age: value in months (exact or range) WAM = Weighted Average Maturity : value in months (exact or range) WHOLE = Whole [Pool (691)](tag:691) (y/n) YIELD = Yield range **or the following Prepayment Speeds:** SMM = Single Monthly Mortality CPR = Constant Prepayment Rate CPY = Constant Prepayment Yield CPP = Constant Prepayment Penalty ABS = Absolute Prepayment Speed MPR = Monthly Prepayment Rate PSA = % of BMA Prepayment Curve PPC = % of Prospectus Prepayment Curve MHP = % of Manufactured Housing Prepayment Curve HEP = final CPR of Home Equity Prepayment Curve Other types may be used by mutual agreement of the counterparties. Note tag # was reserved in FIX 4.1, added in FIX 4.3For Fixed Income. Value of stipulation. The expression can be an absolute single value or a combination of values and logical operators: < value > value <= value >= value value value1 - value2 value1 OR value2 value1 AND value2 YES NO Bargain conditions recognized by the London Stock Exchange - to be used when [StipulationType (233)](tag:233) = "BGNCON". CD = Special cum Dividend XD = Special ex Dividend CC = Special cum Coupon XC = Special ex Coupon CB = Special cum Bonus XB = Special ex Bonus CR = Special cum Rights XR = Special ex Rights CP = Special cum Capital Repayments XP = Special ex Capital Repayments CS = Cash Settlement SP = Special Price TR = Report for European Equity Market Securities in accordance with Chapter 8 of the Rules. GD = Guaranteed Delivery Values for [StipulationType (233)](tag:233) = "PXSOURCE": BB GENERIC BB FAIRVALUE BROKERTEC ESPEED GOVPX HILLIARD FARBER ICAP TRADEWEB TULLETT LIBERTY If a particular side of the market is wanted append /BID /OFFER or /MID. plus appropriate combinations of the above and other expressions by mutual agreement of the counterparties. Examples: ">=60", ".25", "ORANGE OR CONTRACOSTA", etc. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Type of yield.Yield percentage. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)The price at which the securities are distributed to the different members of an underwriting group for the primary market in Municipals, total gross underwriter's spread. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Provides the reduction in price for the secondary market in Muncipals. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Identifies the collateral used in the transaction. Valid values: see [SecurityType (167)](tag:167) field (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 3.Deprecated Instrument-affiliated "RedemptionDate" Fields: RedemptionDate (240), UnderlyingRedemptionDate (247), and LegRedemptionDate (254) [deprecated in FIX 4.4]](app_6_e.html#3) *** Return of investor's principal in a security. Bond redemption can occur before maturity date. (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).Underlying security's CouponPaymentDate. See [CouponPaymentDate (224)](tag:224) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).Underlying security's IssueDate. See [IssueDate (225)](tag:225) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Underlying security's RepoCollateralSecurityType. See [RepoCollateralSecurityType (239)](tag:239) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Underlying security's RepurchaseTerm. See [RepurchaseTerm (226)](tag:226) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Underlying security's RepurchaseRate. See [RepurchaseRate (227)](tag:227) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Underlying security's Factor. See [Factor (228)](tag:228) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 3.Deprecated Instrument-affiliated "RedemptionDate" Fields: RedemptionDate (240), UnderlyingRedemptionDate (247), and LegRedemptionDate (254) [deprecated in FIX 4.4]](app_6_e.html) *** Underlying security's RedemptionDate. See [RedemptionDate (240)](tag:240) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).Multileg instrument's individual leg security's CouponPaymentDate. See [CouponPaymentDate (224)](tag:224) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).Multileg instrument's individual leg security's IssueDate. See [IssueDate (225)](tag:225) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Multileg instrument's individual leg security's RepoCollateralSecurityType. See [RepoCollateralSecurityType (239)](tag:239) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Multileg instrument's individual leg security's RepurchaseTerm. See [RepurchaseTerm (226)](tag:226) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 5.Deprecated various FIX 4.3-introduced "Repo" Fields [deprecated in FIX 4.4]](app_6_e.html#5) *** Multileg instrument's individual leg security's RepurchaseRate. See [RepurchaseRate (227)](tag:227) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Multileg instrument's individual leg security's Factor. See [Factor (228)](tag:228) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)*** DEPRECATED FIELD - See [Appendix 6-E: 3.Deprecated Instrument-affiliated "RedemptionDate" Fields: RedemptionDate (240), UnderlyingRedemptionDate (247), and LegRedemptionDate (254) [deprecated in FIX 4.4]](app_6_e.html#3) *** Multileg instrument's individual leg security's RedemptionDate. See [RedemptionDate (240)](tag:240) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).An evaluation of a company's ability to repay obligations or its likelihood of not defaulting. These evaluation are provided by Credit Rating Agencies, i.e. S&P, Moody's. (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Underlying security's CreditRating. See [CreditRating (255)](tag:255) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Multileg instrument's individual leg security's CreditRating. See [CreditRating (255)](tag:255) field for description (Note tag # was reserved in FIX 4.1, added in FIX 4.3)Driver and part of trade in the event that the Security Master file was wrong at the point of entry[BasisFeatureDate (259)](tag:259) allows requesting firms within fixed income the ability to request an alternative yield-to-worst, -maturity, -extended or other call. This flows through the confirm process. (Note tag # was reserved in FIX 4.1, added in FIX 4.3) prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).Price for BasisFeatureDate. See [BasisFeatureDate (259)](tag:259) (Note tag # was reserved in FIX 4.1, added in FIX 4.3)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.Quantity or volume represented by the Market Data Entry.Date of Market Data Entry. prior to FIX 4.4 field was of type [UTCDate](index.html#UTCDateOnly).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 market data entry.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.Uniquely identifies the quote as part of a QuoteSet.Reason Quote was rejected:Level of Response requested from receiver of Quote messages.Unique 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. Prior to FIX 4.4 this field was named TotQuoteEntries.Underlying security's SecurityIDSource. Valid values: see [SecurityIDSource (22)](tag:22) fieldUnderlying security'sIssuer. 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) field The following applies when used in conjunction with [SecurityType (167)](tag:167)=REPO. Represents the general or specific type of security that underlies a financing agreement. Valid values for [SecurityType (167)](tag:167)=REPO: TREASURY = Federal government or treasury PROVINCE = State, province, region, etc. AGENCY = Federal agency MORTGAGE = Mortgage passthrough CP = Commercial paper CORP = Corporate EQUITY = Equity SUPRA = Supra-national agency CASH If bonds of a particular issuer or country are wanted in an Order or are in the basket of an Execution and the [SecurityType (167)](tag:167) is not granular enough, include the [UnderlyingIssuer (306)](tag:306), [UnderlyingCountryOfIssue (592)](tag:592), UnderlyingProgram, UnderlyingRegType and/or [UnderlyingStipulations](component:UnderlyingStipulations) block e.g.: [SecurityType (167)](tag:167)=REPO [UnderlyingSecurityType (310)](tag:310)=MORTGAGE [UnderlyingIssuer (306)](tag:306)=GNMA or [SecurityType (167)](tag:167)=REPO [UnderlyingSecurityType (310)](tag:310)=AGENCY [UnderlyingIssuer (306)](tag:306)=CA Housing Trust [UnderlyingCountryOfIssue (592)](tag:592)=CA or [SecurityType (167)](tag:167)=REPO [UnderlyingSecurityType (310)](tag:310)=CORP [NoUnderlyingStips (887)](tag:887)=1 [UnderlyingStipType (888)](tag:888)=RATING [UnderlyingStipValue (889)](tag:889)=>bbb-Underlying 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. Can be used with standardized derivatives vs. the [UnderlyingMaturityDate (542)](tag:542) field. See [MaturityMonthYear (200)](tag:200) field for descriptionNo longer used as of FIX 4.3. Included here for reference to prior versions. *** REPLACED FIELD - See: [Appendix 6-F: 5.Replaced Field: PutOrCall (tag 201) and UnderlyingPutOrCall (tag 315) with CFICode (tag 461) [Replaced in FIX 4.3]](app_6_f.html#5) *** Underlying 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 valuesUnique 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.Quantity bought.Quantity 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", "TOSTNET", "TOSTNET2", etc). To specify good for session where session spans more than one calendar day, use [TimeInForce (59)](tag:59) = 'Day' in conjunction with [TradingSessionID (336)](tag:336). Values should be bi-laterally agreed to between counterparties. Firms may register Trading Session values on the FIX website (presently a document maintained within "ECN and Exchanges" working group section).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 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 by the FIX engine and processed by downstream application, such as trading engine or order routing system. Can be specified on every message sent. Useful for detecting a backlog with a counterparty.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 [Execution Report &lt;35=8&gt;](msg:8) 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 messsage.Number of [TradingSessionID (336)](tag:336) in repeating group.Total volume (quantity) traded.Code to identify the price a [DiscretionOffsetValue (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), in the context of [DiscretionOffsetType (842)](tag:842) Prior to FIX 4.4 this field was of type [PriceOffset](index.html#PriceOffset) and named DiscretionOffset.Unique identifier for [Bid Response &lt;35=l&gt;](msg:l) as assigned by sell-side (broker, exchange, ECN). 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. Prior to FIX 4.4 this field was named TotalNumSecurities.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 [TotNoRelatedSym (393)](tag:393) > 1. Represented as a percentage.Upper liquidity indicator if [TotNoRelatedSym (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 fieldTotal 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 quantity (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))Quantity on a GT order that has traded today.The average price for quantity on a GT order that has 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 status 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")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 securities, such as option strategies, spreads, etc.).The 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.Identifies class or source of the [PartyID (448)](tag:448) value. Required if [PartyID (448)](tag:448) is specified. Note: applicable values depend upon [PartyRole (452)](tag:452) specified. See [Appendix 6-G: Use of <Parties> Component Block](app_6_g.html)Party identifier/code. See [PartyIDSource (447)](tag:447) and [PartyRole (452)](tag:452). See [Appendix 6-G: Use of <Parties> Component Block](app_6_g.html)Net change from previous day's closing price vs. last traded price.Identifies the type or role of the [PartyID (448)](tag:448) specified. See "[Appendix 6-G – Use of <Parties> Component Block"](app_6_g.html)Number of [PartyID (448)](tag:448), [PartyIDSource (447)](tag:447), and [PartyRole (452)](tag:452) entriesNumber of [SecurityAltID (455)](tag:455) entries.Alternate Security identifier value for this security of [SecurityAltIDSource (456)](tag:456) type (e.g. CUSIP, SEDOL, ISIN, etc). Requires [SecurityAltIDSource (456)](tag:456).Identifies class or source of the [SecurityAltID (455)](tag:455) value. Required if [SecurityAltID (455)](tag:455) is specified.Number of [UnderlyingSecurityAltID (458)](tag:458) entries.Alternate Security identifier value for this underlying security of [UnderlyingSecurityAltIDSource (459)](tag:459) type (e.g. CUSIP, SEDOL, ISIN, etc). Requires [UnderlyingSecurityAltIDSource (459)](tag:459).Identifies class or source of the [UnderlyingSecurityAltID (458)](tag:458) value. Required if [UnderlyingSecurityAltID (458)](tag:458) is specified.Indicates the type of product the security is associated with. See also the [CFICode (461)](tag:461) and [SecurityType (167)](tag:167) fields.Indicates the type of security using ISO 10962 standard, Classification of Financial Instruments (CFI code) values. ISO 10962 is maintained by ANNA (Association of National Numbering Agencies) acting as Registration Authority. See [Appendix 6-B: FIX Fields Based Upon Other Standards](app_6_b.html). See also the [Product (460)](tag:460) and [SecurityType (167)](tag:167) fields. It is recommended that [CFICode (461)](tag:461) be used instead of [SecurityType (167)](tag:167) for non-Fixed Income instruments. A subset of possible values applicable to FIX usage are identified in [Appendix 6-D: CFICode Usage - ISO 10962 Classification of Financial Instruments (CFI code)](app_6_d.html)Underlying security's Product. Valid values: see [Product (460)](tag:460) fieldUnderlying security's CFICode. Valid values: see [CFICode (461)](tag:461) fieldIndicates whether or not this FIX Session is a "test" vs. "production" connection. Useful for preventing "accidents".Common reference passed to a post-trade booking process (e.g. industry matching utility).Unique identifier for a specific [NoAllocs (78)](tag:78) repeating group instance (e.g. for an [AllocAccount (79)](tag:79)).Specifies which direction to round For CIV - indicates whether or not the quantity of shares/units is to be rounded and in which direction where [CashOrderQty (152)](tag:152) or (for CIV only) [OrderPercent (516)](tag:516) are specified on an order. Valid values are: 0 = Round to nearest 1 = Round down 2 = Round up The default is for rounding to be at the discretion of the executing broker or fund manager. E.g. for an order specifying [CashOrderQty (152)](tag:152) or [OrderPercent (516)](tag:516) if the calculated number of shares/units was 325.76 and [RoundingModulus (469)](tag:469) was 10 - "round down" would give 320 units, "round up" would give 330 units and "round to nearest" would give 320 units.For CIV - a float value indicating the value to which rounding is required. i.e. 10 means round to a multiple of 10 units/shares; 0.5 means round to a multiple of 0.5 units/shares. The default, if [RoundingDirection (468)](tag:468) is specified without [RoundingModulus (469)](tag:469), is to round to a whole unit/share.ISO [Country (421)](tag:421) code of instrument issue (e.g. the country portion typically used in ISIN). Can be used in conjunction with non-ISIN [SecurityID (48)](tag:48) (e.g. CUSIP for Municipal Bonds without ISIN) to provide uniqueness.A two-character state or province abbreviation.Identifies the locale. For Municipal Security Issuers other than state or province. Refer to http://www.atmos.albany.edu/cgi/stagrep-cgi Reference the IATA city codes for values. Note IATA (International Air Transport Association) maintains the codes at www.iata.orgThe number of registration details on a [Registration Instructions &lt;35=o&gt;](msg:o) messageSet of Correspondence address details, possibly including phone, fax, etc.The ISO 3166 Country code (2 character) identifying which country the beneficial investor is resident for tax purposes. (e.g [https://en.wikipedia.org/wiki/ISO_3166-1](https://en.wikipedia.org/wiki/ISO_3166-1))"Settlement Payment Reference" - A free format Payment reference to assist with reconciliation, e.g. a Client and/or Order ID number.A code identifying the payment method for a (fractional) distribution. 1 = CREST 2 = NSCC 3 = Euroclear 4 = Clearstream 5 = Cheque 6 = Telegraphic Transfer 7 = FedWire 8 = Direct Credit (BECS, BACS) 9 = ACH Credit 10 = BPAY 11 = High Value Clearing System (HVACS) 12 = Reinvest in fund 13 through 998 are reserved for future use Values above 1000 are available for use by private agreement among counterpartiesSpecifies currency to be use for Cash Distributions. See [Appendix 6-A: Valid Currency Codes](app_6_a.html).Specifies currency to be use for [Commission (12)](tag:12) if the Commission currency is different from the Deal Currency. See [Appendix 6-A: Valid Currency Codes](app_6_a.html).For CIV - A one character code identifying whether Cancellation rights/Cooling off period applies. Valid values are: Y = Yes N = No - execution only M = No - waiver agreement O = No - institutional.A one character code identifying Money laundering status.Free format text to specify mailing instruction requirements, e.g. "no third party mailings".For CIV A date and time stamp to indicate the time a CIV order was booked by the fund manager.For CIV - Identifies how the execution price [LastPx (31)](tag:31) was calculated from the fund unit/share price(s) calculated at the fund valuation point. Valid values are: B = Bid price C = Creation price D = Creation price plus adjustment % E = Creation price plus adjustment amount O = Offer price P = Offer price minus adjustment % Q = Offer price minus adjustment amount S = Single priceFor CIV the amount or percentage by which the fund unit/share price was adjusted, as indicated by [ExecPriceType (484)](tag:484)The date of birth applicable to the individual, e.g. required to open some types of tax-exempt account.Identifies Trade Report message transaction typeThe name of the payment card holder as specified on the card being used for payment.The number of the payment card as specified on the card being used for payment.The expiry date of the payment card as specified on the card being used for payment.The issue number of the payment card as specified on the card being used for payment. This is only applicable to certain types of card.A code identifying the Settlement payment method. 1 = CREST 2 = NSCC 3 = Euroclear 4 = Clearstream 5 = Cheque 6 = Telegraphic Transfer 7 = FedWire 8 = Debit Card 9 = Direct Debit (BECS) 10 = Direct Credit (BECS) 11 = Credit Card 12 = ACH Debit 13 = ACH Credit 14 = BPAY 15 = High Value Clearing System (HVACS) 16 through 998 are reserved for future use Values above 1000 are available for use by private agreement among counterpartiesFor CIV - a fund manager-defined code identifying which of the fund manager's account types is required.Free format text defining the designation to be associated with a holding on the register. Used to identify assets of a specific underlying investor using a common registration, e.g. a broker's nominee or street name.For CIV - a code identifying the type of tax exempt account in which purchased shares/units are to be held. 0 = None/Not Applicable (default) 1 = Maxi ISA (UK) 2 = TESSA (UK) 3 = Mini Cash ISA (UK) 4 = Mini Stocks and Shares ISA (UK) 5 = Mini Insurance ISA (UK) 6 = Current year payment (US) 7 = Prior year payment (US) 8 = Asset transfer (US) 9 = Employee - prior year (US) 10 = Employee - current year (US) 11 = Employer - prior year (US) 12 = Employer - current year (US) 13 = Non-fund prototype IRA (US) 14 = Non-fund qualified plan (US) 15 = Defined contribution plan (US) 16 = Individual Retirement Account (US) 17 = Individual Retirement Account - Rollover (US) 18 = KEOGH (US) 19 = Profit Sharing Plan (US) 20 = 401K (US) 21 = Self-Directed IRA (US) 22 = 403(b) (US) 23 = 457 (US) 24 = Roth IRA (fund prototype) (US) 25 = Roth IRA (non-prototype) (US) 26 = Roth Conversion IRA (fund prototype) (US) 27 = Roth Conversion IRA (non-prototype) (US) 28 = Education IRA (fund prototype) (US) 29 = Education IRA (non-prototype) (US) 30 - 998 are reserved for future use by recognized taxation authorities 999 = Other values above 1000 are available for use by private agreement among counterpartiesText indicating reason(s) why a [Registration Instructions &lt;35=o&gt;](msg:o) has been rejected.A one character code identifying whether the Fund based renewal commission is to be waived. Valid values are: Y = Yes N = NoName of local agent bank if for cash distributionsBIC (Bank Identification Code - Swift managed) code of agent bank for cash distributions[Account (1)](tag:1) number at agent bank for distributions.Free format Payment reference to assist with reconciliation of distributions.Name of account at agent bank for distributions.The start date of the card as specified on the card being used for payment.The date written on a cheque or date payment should be submitted to the relevant clearing system.Identifies sender of a payment, e.g. the payment remitter or a customer reference number.Registration status as returned by the broker or (for CIV) the fund manager:Reason(s) why [Registration Instructions &lt;35=o&gt;](msg:o) has been rejected. Possible values of reason code include: 1 = Invalid/unacceptable Account Type 2 = Invalid/unacceptable Tax Exempt Type 3 = Invalid/unacceptable [OwnershipType (517)](tag:517) 4 = Invalid/unacceptable [NoRegistDtls (473)](tag:473) 5 = Invalid/unacceptable Reg Seq No 6 = Invalid/unacceptable [RegistDtls (509)](tag:509) 7 = Invalid/unacceptable [MailingDtls (474)](tag:474) 8 = Invalid/unacceptable [MailingInst (482)](tag:482) 9 = Invalid/unacceptable Investor ID 10 = Invalid/unacceptable Investor ID Source 11 = Invalid/unacceptable [DateOfBirth (486)](tag:486) 12 = Invalid/unacceptable [InvestorCountryOfResidence (475)](tag:475) 13 = Invalid/unacceptable [NoDistribInsts (510)](tag:510) 14 = Invalid/unacceptable [DistribPercentage (512)](tag:512) 15 = Invalid/unacceptable [DistribPaymentMethod (477)](tag:477) 16 = Invalid/unacceptable [CashDistribAgentAcctName (502)](tag:502) 17 = Invalid/unacceptable [CashDistribAgentCode (499)](tag:499) 18 = Invalid/unacceptable [CashDistribAgentAcctNumber (500)](tag:500) 99 = Other The reason may be further amplified in the [RegistRejReasonCode (507)](tag:507) field.Reference identifier for the [RegistID (513)](tag:513) with 'Cancel' and 'Replace' [RegistTransType (514)](tag:514) transaction types.Set of Registration name and address details, possibly including phone, fax etc.The number of Distribution Instructions on a [Registration Instructions &lt;35=o&gt;](msg:o) messageEmail address relating to Registration name and address detailsThe amount of each distribution to go to this beneficiary, expressed as a percentageUnique identifier of the registration details as assigned by institution or intermediary.Identifies [Registration Instructions &lt;35=o&gt;](msg:o) transaction typeFor CIV - a date and time stamp to indicate the fund valuation point with respect to which a order was priced by the fund manager.For CIV specifies the approximate order quantity desired. For a CIV Sale it specifies percentage of investor's total holding to be sold. For a CIV switch/exchange it specifies percentage of investor's cash realised from sales to be re-invested. The executing broker, intermediary or fund manager is responsible for converting and calculating [OrderQty (38)](tag:38) in shares/units for subsequent messages.The relationship between Registration parties.The number of Contract Amount details on an [Execution Report &lt;35=8&gt;](msg:8) messageType of [ContAmtValue (520)](tag:520). For UK valid values include: 1 = Commission Amount (actual) 2 = Commission % (actual) 3 = Initial Charge Amount 4 = Initial Charge % 5 = Discount Amount 6 = Discount % 7 = Dilution Levy Amount 8 = Dilution Levy % 9 = Exit Charge Amount 10 = Exit Charge % 11 = Fund-based Renewal Commission % (a.k.a. Trail commission) 12 = Projected Fund Value (i.e. for investments intended to realise or exceed a specific future value) 13 = Fund-based Renewal Commission Amount (based on Order value) 14 = Fund-based Renewal Commission Amount (based on Projected Fund value) 15 = Net Settlement Amount NOTE That Commission Amount / % in Contract Amounts is the commission actually charged, rather than the commission instructions given in Fields [Commission (12)](tag:12) and [CommType (13)](tag:13).Value of Contract Amount, e.g. a financial amount or percentage as indicated by [ContAmtType (519)](tag:519).Specifies currency for the Contract amount if different from the Deal Currency. See [Appendix 6-A: Valid Currency Codes](app_6_a.html).Identifies the type of owner.Sub-identifier (e.g. Clearing Account for [PartyRole (452)](tag:452)=Clearing Firm, Locate ID # for [PartyRole (452)](tag:452)=Locate/Lending Firm, etc). Not required when using [PartyID (448)](tag:448), [PartyIDSource (447)](tag:447), and [PartyRole (452)](tag:452).PartyID value within a nested repeating group. Same values as [PartyID (448)](tag:448)PartyIDSource value within a nested repeating group. Same values as [PartyIDSource (447)](tag:447)Assigned by the party which originates the order. Can be used to provide the [ClOrdID (11)](tag:11) used by an exchange or executing system.Assigned by the party which accepts the order. Can be used to provide the [ExecID (17)](tag:17) used by an exchange or executing system.Designates the capacity of the firm placing the order.Restrictions associated with an order. If more than one restriction is applicable to an order, this field can contain multiple instructions separated by space.Specifies scope of [Order Mass Cancel Request &lt;35=q&gt;](msg:q).Specifies the action taken by counterparty order handling system as a result of the [Order Mass Cancel Request &lt;35=q&gt;](msg:q)Reason [Order Mass Cancel Request &lt;35=q&gt;](msg:q) was rejectedTotal number of orders affected by [Order Mass Cancel Request &lt;35=q&gt;](msg:q).Number of affected orders in the repeating group of order ids.[OrderID (37)](tag:37) of an order affected by a [Order Mass Cancel Request &lt;35=q&gt;](msg:q).[SecondaryOrderID (198)](tag:198) of an order affected by a [Order Mass Cancel Request &lt;35=q&gt;](msg:q).Identifies the type of quote.PartyRole value within a nested repeating group. Same values as [PartyRole (452)](tag:452)Number of [NestedPartyID (524)](tag:524), [NestedPartyIDSource (525)](tag:525), and [NestedPartyRole (538)](tag:538) entries*** DEPRECATED FIELD - See [Appendix 6-E: 1.Deprecated Field: TotalAccruedInterestAmt (tag 540) [deprecated in FIX 4.4]](app_6_e.html#1) *** Total Amount of Accrued Interest for convertible bonds and fixed incomeDate of maturity.Underlying security's maturity date. See [MaturityDate (541)](tag:541) field for descriptionThe location at which records of ownership are maintained for this instrument, and at which ownership changes must be recorded.Identifies whether an order is a margin order or a non-margin order. This is primarily used when sending orders to Japanese exchanges to indicate sell margin or buy to cover. The same tag could be assigned also by buy-side to indicate the intent to sell or buy margin and the sell-side to accept or reject (base on some validation criteria) the margin request.PartySubID value within a nested repeating group. Same values as [PartySubID (523)](tag:523)Defines the scope of a data element.Defines how a server handles distribution of a truncated book. Defaults to broker option.Identifier for a cross order. Must be unique during a given trading day. Recommend that firms use the order date as part of the [CrossID (548)](tag:548) for Good Till Cancel (GT) orders.Type of cross being submitted to a marketIndicates if one side or the other of a cross order should be prioritized. 0 = None 1 = Buy side is prioritized 2 = Sell side is prioritized The definition of prioritization is left to the market. In some markets prioritization means which side of the cross order is applied to the market first. In other markets - prioritization may mean that the prioritized side is fully executed (sometimes referred to as the side being protected).[CrossID (548)](tag:548) of the previous cross order (NOT the initial cross order of the day) as assigned by the institution, used to identify the previous cross order in [Cross Order Cancel Request &lt;35=u&gt;](msg:u) and [Cross Order Cancel/Replace Request &lt;35=t&gt;](msg:t).Number of [Side (54)](tag:54) repeating group instances.Userid or username.Password or passphrase.Number of [InstrumentLeg](component:InstrumentLeg) repeating group instances.Currency associated with a particular Leg's quantityIndicates total number of security types in the event that multiple Security Type messages are used to return results Prior to FIX 4.4 this field was named TotalNumSecurityTypes.Number of [SecurityType (167)](tag:167) repeating group instances.Identifies the type/criteria of [Security List Request &lt;35=x&gt;](msg:x)The results returned to a Security Request messageThe trading lot size of a securityThe minimum trading volume for a securityIndicates the method of execution reporting requested by issuer of the order. 0 = Report by mulitleg security only (Do not report legs) 1 = Report by multileg security and by instrument legs belonging to the multileg security. 2 = Report by instrument legs belonging to the multileg security only (Do not report status of multileg security)PositionEffect for leg of a multileg See [PositionEffect (77)](tag:77) field for descriptionCoveredOrUncovered for leg of a multileg See [CoveredOrUncovered (203)](tag:203) field for descriptionPrice for leg of a multileg See [Price (44)](tag:44) field for descriptionIndicates the reason a [Trading Session Status Request &lt;35=g&gt;](msg:g) was rejected.[Trade Capture Report Request &lt;35=AD&gt;](msg:AD) IDType of [Trade Capture Report &lt;35=AE&gt;](msg:AE).Indicates if the trade capture report was previously reported to the counterpartyUnique identifier of trade capture reportReference identifier used with CANCEL and REPLACE transaction types.The status of this trade with respect to matching or comparison.The point in the matching process at which this trade was matched.This trade is to be treated as an odd lot Values: Y = treat as odd lot N = treat as round lot If this field is not specified, the default will be "N"Number of clearing instructionsEligibility of this trade for clearing and central counterparty processingType of input device or system from which the trade was entered.Specific device number, terminal number or station where trade was enteredNumber of Date fields provided in date rangeType of [Account (1)](tag:1) associated with an orderCapacity of customer placing the order 1 = Member trading for their own account 2 = Clearing Firm trading for its proprietary account 3 = Member trading for another member 4 = All other Primarily used by futures exchanges to indicate the CTICode (customer type indicator) as required by the US CFTC (Commodity Futures Trading Commission).Permits order originators to tie together groups of orders in which trades resulting from orders are associated for a specific purpose, for example the calculation of average execution price for a customer or to associate lists submitted to a broker as waves of a larger program trade.Value assigned by issuer of [Order Mass Status Request &lt;35=AF&gt;](msg:AF) to uniquely identify the request[Order Mass Status Request &lt;35=AF&gt;](msg:AF) TypeThe most recent (or current) modification [TransactTime (60)](tag:60) reported on an [Execution Report &lt;35=8&gt;](msg:8) for the order. The [OrigOrdModTime (586)](tag:586) is provided as an optional field on [Order Cancel Request &lt;35=F&gt;](msg:F) and [Order Cancel/Replace Request &lt;35=G&gt;](msg:G) to identify that the state of the order has not changed since the request was issued. This is provided to support markets similar to Eurex and A/C/E.Refer to values for [SettlType (63)](tag:63)Refer to description for [SettlDate (64)](tag:64)Indicates whether or not automatic booking can occur.Indicates what constitutes a bookable unit.Indicates the method of preallocation.Underlying security's CountryOfIssue. See [CountryOfIssue (470)](tag:470) field for descriptionUnderlying security's StateOrProvinceOfIssue. See [StateOrProvinceOfIssue (471)](tag:471) field for descriptionUnderlying security's LocaleOfIssue. See [LocaleOfIssue (472)](tag:472) field for descriptionUnderlying security's InstrRegistry. See [InstrRegistry (543)](tag:543) field for descriptionMultileg instrument's individual leg security's CountryOfIssue. See [CountryOfIssue (470)](tag:470) field for descriptionMultileg instrument's individual leg security's StateOrProvinceOfIssue. See [StateOrProvinceOfIssue (471)](tag:471) field for descriptionMultileg instrument's individual leg security's LocaleOfIssue. See [LocaleOfIssue (472)](tag:472) field for descriptionMultileg instrument's individual leg security's InstrRegistry. See [InstrRegistry (543)](tag:543) field for descriptionMultileg instrument's individual security's Symbol. See [Symbol (55)](tag:55) field for descriptionMultileg instrument's individual security's SymbolSfx. See [SymbolSfx (65)](tag:65) field for descriptionMultileg instrument's individual security's SecurityID. See [SecurityID (48)](tag:48) field for descriptionMultileg instrument's individual security's SecurityIDSource. See [SecurityIDSource (22)](tag:22) field for descriptionMultileg instrument's individual security's NoSecurityAltID. See [NoSecurityAltID (454)](tag:454) field for descriptionMultileg instrument's individual security's SecurityAltID. See [SecurityAltID (455)](tag:455) field for descriptionMultileg instrument's individual security's SecurityAltIDSource. See [SecurityAltIDSource (456)](tag:456) field for descriptionMultileg instrument's individual security's Product. See [Product (460)](tag:460) field for descriptionMultileg instrument's individual security's CFICode. See [CFICode (461)](tag:461) field for descriptionMultileg instrument's individual security's SecurityType. See [SecurityType (167)](tag:167) field for descriptionMultileg instrument's individual security's MaturityMonthYear. See [MaturityMonthYear (200)](tag:200) field for descriptionMultileg instrument's individual security's MaturityDate. See [MaturityDate (541)](tag:541) field for descriptionMultileg instrument's individual security's StrikePrice. See [StrikePrice (202)](tag:202) field for descriptionMultileg instrument's individual security's OptAttribute. See [OptAttribute (206)](tag:206) field for descriptionMultileg instrument's individual security's ContractMultiplier. See [ContractMultiplier (231)](tag:231) field for descriptionMultileg instrument's individual security's CouponRate. See [CouponRate (223)](tag:223) field for descriptionMultileg instrument's individual security's SecurityExchange. See [SecurityExchange (207)](tag:207) field for descriptionMultileg instrument's individual security's Issuer. See [Issuer (106)](tag:106) field for descriptionMultileg instrument's individual security's EncodedIssuerLen. See [EncodedIssuerLen (348)](tag:348) field for descriptionMultileg instrument's individual security's EncodedIssuer. See [EncodedIssuer (349)](tag:349) field for descriptionMultileg instrument's individual security's SecurityDesc. See [SecurityDesc (107)](tag:107) field for descriptionMultileg instrument's individual security's EncodedSecurityDescLen. See [EncodedSecurityDescLen (350)](tag:350) field for descriptionMultileg instrument's individual security's EncodedSecurityDesc. See [EncodedSecurityDesc (351)](tag:351) field for descriptionThe ratio of quantity for this individual leg relative to the entire multileg security.The side of this individual leg (multileg security). See [Side (54)](tag:54) field for description and valuesOptional market assigned sub identifier for a trading session. Usage is determined by market or counterparties. Used by US based futures markets to identify exchange specific execution time bracket codes as required by US market regulations.Describes the specific type or purpose of an Allocation message (i.e. "Buyside Calculated")Number of [HopCompID (628)](tag:628) entries in repeating group.Assigned value used to identify the third party firm which delivered a specific message either from the firm which originated the message or from another third party (if multiple "hops" are performed). It is recommended that this value be the [SenderCompID (49)](tag:49) of the third party. Applicable when messages are communicated/re-distributed via third parties which function as service bureaus or "hubs". Only applicable if [OnBehalfOfCompID (115)](tag:115) is being used.Time that [HopCompID (628)](tag:628) sent the message. It is recommended that this value be the [SendingTime (52)](tag:52) of the message sent by the third party. Applicable when messages are communicated/re-distributed via third parties which function as service bureaus or "hubs". Only applicable if [OnBehalfOfCompID (115)](tag:115) is being used.Reference identifier assigned by [HopCompID (628)](tag:628) associated with the message sent. It is recommended that this value be the [MsgSeqNum (34)](tag:34) of the message sent by the third party. Applicable when messages are communicated/re-distributed via third parties which function as service bureaus or "hubs". Only applicable if [OnBehalfOfCompID (115)](tag:115) is being used.Mid price/rateBid yieldMid yieldOffer yieldIndicates type of fee being assessed of the customer for trade executions at an exchange. Applicable for futures markets only at this time. Valid values (source CBOT, CME, NYBOT, and NYMEX): B = CBOE Member C = Non-member and Customer E = Equity Member and Clearing Member F = Full and Associate Member trading for own account and as floor Brokers H = 106.H and 106.J Firms I = GIM, IDEM and COM Membership Interest Holders L = Lessee and 106.F Employees M = All other ownership types 1 = 1st year delegate trading for his own account 2 = 2nd year delegate trading for his own account 3 = 3rd year delegate trading for his own account 4 = 4th year delegate trading for his own account 5 = 5th year delegate trading for his own account 9 = 6th year and beyond delegate trading for his own accountIndicates if the order is currently being worked. Applicable only for [OrdStatus (39)](tag:39) = 'New'. For open outcry markets this indicates that the order is being worked in the crowd. For electronic markets it indicates that the order has transitioned from a contingent order to a market order.Execution price assigned to a leg of a multileg instrument. See [LastPx (31)](tag:31) field for description and valuesIndicates if a Cancel/Replace has caused an order to lose book priority.Amount of price improvement.Price of the future part of a F/X swap order. See [Price (44)](tag:44) for description.F/X forward points of the future part of a F/X swap order added to [LastSpotRate (194)](tag:194). May be a negative value.Bid F/X forward points of the future portion of a F/X swap quote added to spot rate. May be a negative value.Offer F/X forward points of the future portion of a F/X swap quote added to spot rate. May be a negative value.RFQ Request ID - used to identify an [RFQ Request &lt;35=AH&gt;](msg:AH).Used to indicate the best bid in a marketUsed to indicate the best offer in a marketUsed to indicate a minimum quantity for a bid. If this field is used the [BidSize (134)](tag:134) field is interpreted as the maximum bid sizeUsed to indicate a minimum quantity for an offer. If this field is used the [OfferSize (135)](tag:135) field is interpreted as the maximum offer size.Unique identifier for [Quote Status Request &lt;35=a&gt;](msg:a).Indicates that this message is to serve as the final and legal confirmation.The calculated or traded price for the underlying instrument that corresponds to a derivative. Used for transactions that include the cash instrument and the derivative.The calculated or traded quantity for the underlying instrument that corresponds to a derivative. Used for transactions that include the cash instrument and the derivative.Unique indicator for a specific leg.Unique indicator for a specific leg for the [ContraBroker (375)](tag:375).Foreign exchange rate used to compute the bid [SettlCurrAmt (119)](tag:119) from [Currency (15)](tag:15) to [SettlCurrency (120)](tag:120)Foreign exchange rate used to compute the offer [SettlCurrAmt (119)](tag:119) from [Currency (15)](tag:15) to [SettlCurrency (120)](tag:120)Reason [Quote Request &lt;35=R&gt;](msg:R) was rejected.ID within repeating group of sides which is used to represent this transaction for compliance purposes (e.g. OATS reporting).Used to identify the source of the [Account (1)](tag:1) code. This is especially useful if the account is a new account that the Respondent may not have setup yet in their system.Used to identify the source of the [AllocAccount (79)](tag:79) code. See [AcctIDSource (660)](tag:660) for valid values.Specifies the price of the benchmark.Identifies type of [BenchmarkPrice (662)](tag:662). See [PriceType (423)](tag:423) for valid values.Message reference for [Confirmation &lt;35=AK&gt;](msg:AK)Identifies the status of the [Confirmation &lt;35=AK&gt;](msg:AK).Identifies the [Confirmation &lt;35=AK&gt;](msg:AK) transaction type.Specifies when the contract (i.e. MBS/TBA) will settle.Identifies the form of delivery.Last price expressed in [percent-of-par](glossary.html#PercentOfPar). Conditionally required for Fixed Income trades when [LastPx (31)](tag:31) is expressed in Yield, Spread, Discount or any other type (see [PriceType (423)](tag:423)). Usage: [Execution Report &lt;35=8&gt;](msg:8) and [Allocation Report &lt;35=AS&gt;](msg:AS) repeating executions block (from sellside).Number of Allocations for the legAllocation Account for the leg See [AllocAccount (79)](tag:79) for description and valid values.Reference for the individual allocation ticket See [IndividualAllocID (467)](tag:467) for description and valid values.Leg allocation quantity. See [AllocQty (80)](tag:80) for description and valid values.The source of the [LegAllocAccount (671)](tag:671) See [AllocAcctIDSource (661)](tag:661) for description and valid values.Identifies settlement currency for the Leg. See [SettlCurrency (120)](tag:120) for description and valid values[LegBenchmarkPrice (679)](tag:679) currency See [BenchmarkCurveCurrency (220)](tag:220) for description and valid values.Name of the Leg Benchmark Curve. See [BenchmarkCurveName (221)](tag:221) for description and valid values.Identifies the point on the Leg Benchmark Curve. See [BenchmarkCurvePoint (222)](tag:222) for description and valid values.Used to identify the price of the benchmark security. See [BenchmarkPrice (662)](tag:662) for description and valid values.The price type of the [LegBenchmarkPrice (679)](tag:679). See [BenchmarkPriceType (663)](tag:663) for description and valid values.Bid price of this leg. See [BidPx (132)](tag:132) for description and valid values.Leg-specific [Indication of Interest &lt;35=6&gt;](msg:6) quantity. See [IOIQty (27)](tag:27) for description and valid valuesNumber of leg stipulation entriesOffer price of this leg. See [OfferPx (133)](tag:133) for description and valid valuesThe price type of the [LegBidPx (681)](tag:681) and/or [LegOfferPx (684)](tag:684). See [PriceType (423)](tag:423) for description and valid valuesQuantity of this leg, e.g. in Quote dialog. See [Quantity (53)](tag:53) for description and valid valuesFor Fixed Income, type of Stipulation for this leg. See [StipulationType (233)](tag:233) for description and valid valuesFor Fixed Income, value of stipulation. See [StipulationValue (234)](tag:234) for description and valid valuesFor Fixed Income, used instead of [LegQty (687)](tag:687) to request the respondent to calculate the quantity based on the quantity on the opposite side of the swap.For Fixed Income, identifies MBS / ABS pool.Code to represent price type requested in Quote. If the [Quote Request &lt;35=R&gt;](msg:R) is for a Swap values 1-8 apply to all legs.Message reference for [Quote Response &lt;35=AJ&gt;](msg:AJ)Identifies the type of [Quote Response &lt;35=AJ&gt;](msg:AJ).Code to qualify Quote use See [IOIQualifier (104)](tag:104) for description and valid values.Date to which the yield has been calculated (i.e. maturity, par call or current call, pre-refunded date).Price to which the yield has been calculated.The price type of the [YieldRedemptionPrice (697)](tag:697) See [PriceType (423)](tag:423) for description and valid values.The identifier of the benchmark security, e.g. Treasury against Corporate bond. See [SecurityID (48)](tag:48) for description and valid values.Indicates a trade that reverses a previous trade.Include as needed to clarify yield irregularities associated with date, e.g. when it falls on a non-business day.Number of position entries.Used to identify the type of quantity that is being returned.Long QuantityShort QuantityStatus of this position.Type of Position amountPosition amountIdentifies the type of position transactionUnique identifier for the position maintenance request as assigned by the submitterNumber of underlying legs that make up the security.Maintenance Action to be performed.Reference to the [PosReqID (710)](tag:710) of a previous maintenance request that is being replaced or canceled.Reference to a [PosMaintRptID (721)](tag:721) from a previous [Position Maintenance Report &lt;35=AM&gt;](msg:AM) that is being replaced or canceled.The "Clearing Business Date" referred to by this maintenance request.Identifies a specific settlement session Examples: ITD = Intraday RTH = Regular Trading Hours ETH = Electronic Trading HoursSubID value associated with [SettlSessID (716)](tag:716)Type of adjustment to be applied, used for PCS & PAJRequired to be set to true (Y) when a position maintenance request is being performed contrary to current money position. Required when an exercise of an out of the money position is requested or an abandonement (do not exercise ) for an in the money position.Indicates if requesting a rollover of prior day's spread submissions.Unique identifier for this position reportStatus of [Position Maintenance Request &lt;35=AL&gt;](msg:AL)Result of [Position Maintenance Request &lt;35=AL&gt;](msg:AL).Unique identifier for the position maintenance request as assigned by the submitterIdentifies how the response to the request should be transmitted.URI (Uniform Resource Identifier) for details) or other pre-arranged value. Used in conjunction with [ResponseTransportType (725)](tag:725) value of Out-of-Band to identify the out-of-band destination. See [Appendix 6-B: FIX Fields Based Upon Other Standards](app_6_b.html)Total number of Position Reports being returned.Result of [Request for Positions &lt;35=AN&gt;](msg:AN)Status of [Request for Positions &lt;35=AN&gt;](msg:AN)Settlement priceType of settlement priceUnderlying security's SettlPrice. See [SettlPrice (730)](tag:730) field for descriptionUnderlying security's SettlPriceType. See [SettlPriceType (731)](tag:731) field for descriptionPrevious settlement priceNumber of repeating groups of [QuoteQualifier (695)](tag:695).Currency code of settlement denomination for a specific [AllocAccount (79)](tag:79). See [Appendix 6-A: Valid Currency Codes](app_6_a.html) for information on obtaining valid values.Total amount due expressed in settlement currency (includes the effect of the forex transaction) for a specific [AllocAccount (79)](tag:79).Amount of interest (i.e. lump-sum) at maturity.The effective date of a new securities issue determined by its underwriters. Often but not always the same as the [IssueDate (225)](tag:225) and the [InterestAccrualDate (874)](tag:874)For Fixed Income, identifies MBS / ABS pool for a specific leg of a multi-leg instrument. See [Pool (691)](tag:691) for description and valid values.Amount of interest (i.e. lump-sum) at maturity at the account-level.Amount of Accrued Interest for convertible bonds and fixed income at the allocation-level.Date of delivery.Method under which assignment was conductedQuantity Increment used in performing assignment.Open interest that was eligible for assignment.Exercise Method used to in performing assignment.Total number of trade reports returned.Result of Trade RequestStatus of Trade Request.Reason Trade Capture Request was rejected.Used to indicate if the side being reported on [Trade Capture Report &lt;35=AE&gt;](msg:AE) represents a leg of a multileg instrument or a single security.Number of position amount entries.Identifies whether or not an allocation has been automatically accepted on behalf of the Carry Firm by the Clearing House.Unique identifier for Allocation Report message.Number of [Nested2PartyID (757)](tag:757), [Nested2PartyIDSource (758)](tag:758), and [Nested2PartyRole (759)](tag:759) entriesPartyID value within a "second instance" Nested repeating group. Same values as [PartyID (448)](tag:448)PartyIDSource value within a "second instance" Nested repeating group. Same values as [PartyIDSource (447)](tag:447)PartyRole value within a "second instance" Nested repeating group. Same values as [PartyRole (452)](tag:452)PartySubID value within a "second instance" Nested repeating group. Same values as [PartySubID (523)](tag:523)Identifies class or source of the [BenchmarkSecurityID (699)](tag:699) value. Required if BenchmarkSecurityID is specified. Same values as the [SecurityIDSource (22)](tag:22) fieldSub-type qualification/identification of the [SecurityType (167)](tag:167) (e.g. for SecurityType="REPO"). Example values: General = General Collateral (for [SecurityType (167)](tag:167)="REPO") For [SecurityType (167)](tag:167)="MLEG" markets can provide the name of the option or futures strategy, such as Calendar, Vertical, Butterfly, etc. NOTE: Additional values may be used by mutual agreement of the counterpartiesUnderlying security's SecuritySubType. See [SecuritySubType (762)](tag:762) field for descriptionSecuritySubType of the leg instrument. See [SecuritySubType (762)](tag:762) field for descriptionThe maximum percentage that execution of one side of a program trade can exceed execution of the other.The maximum amount that execution of one side of a program trade can exceed execution of the other.The currency that [AllowableOneSidednessValue (766)](tag:766) is expressed in if AllowableOneSidednessValue is used.Number of [TrdRegTimestamp (769)](tag:769) entriesTraded / Regulatory timestamp value. Use to store time information required by government regulators or self regulatory organizations (such as an exchange or clearing house).Traded / Regulatory timestamp type.Text which identifies the "origin" (i.e. system which was used to generate the time stamp) for the Traded / Regulatory timestamp value.Reference identifier to be used with [ConfirmTransType (666)](tag:666) = "Replace" or "Cancel"Identifies the type of [Confirmation &lt;35=AK&gt;](msg:AK) message being sent.Identifies the reason for rejecting a [Confirmation &lt;35=AK&gt;](msg:AK).Method for booking out this order. Used when notifying a broker that an order to be settled by that broker is to be booked out as an OTC derivative (e.g. CFD or similar).Identified reason for rejecting an individual [AllocAccount (79)](tag:79) detail. Same values as [AllocRejCode (88)](tag:88)Unique identifier for Settlement Instruction message.Number of settlement instructions within repeating group.Timestamp of last update to data item (or creation if no updates made since creation).Used to indicate whether settlement instructions are provided on an [Allocation Instruction &lt;35=J&gt;](msg:J) message, and if not, how they are to be derived.Number of [SettlPartyID (782)](tag:782), [SettlPartyIDSource (783)](tag:783), and [SettlPartyRole (784)](tag:784) entriesPartyID value within a Settlement Parties component. Nested repeating group. Same values as [PartyID (448)](tag:448)PartyIDSource value within a Settlement Parties component. Same values as [PartyIDSource (447)](tag:447)PartyRole value within a Settlement Parties component. Same values as [PartyRole (452)](tag:452)PartySubID value within a Settlement Parties component. Same values as [PartySubID (523)](tag:523)Type of [SettlPartySubID (785)](tag:785) value. Same values as [PartySubIDType (803)](tag:803)Used to indicate whether a delivery instruction is used for securities or cash settlement.Type of financing termination.Next expected [MsgSeqNum (34)](tag:34) value to be received.Can be used to uniquely identify a specific [Order Status Request &lt;35=H&gt;](msg:H) message.Unique ID of [Settlement Instruction Request &lt;35=AV&gt;](msg:AV) messageIdentifies reason for rejection (of a [Settlement Instruction Request &lt;35=AV&gt;](msg:AV) message).Secondary allocation identifier. Unlike the [AllocID (70)](tag:70), this can be shared across a number of allocation instruction or allocation report messages, thereby making it possible to pass an identifier for an original allocation message on multiple messages (e.g. from one party to a second to a third, across cancel and replace messages etc.).Describes the specific type or purpose of an [Allocation Report &lt;35=AS&gt;](msg:AS) messageReference identifier to be used with [AllocTransType (71)](tag:71) = 'Replace' or 'Cancel'Reason for cancelling or replacing an [Allocation Instruction &lt;35=J&gt;](msg:J) or [Allocation Report &lt;35=AS&gt;](msg:AS) messageIndicates whether or not this message is a drop copy of another message.Type of account associated with a confirmation or other trade-level messageAverage price for a specific orderQuantity of the order that is being booked out as part of an [Allocation Instruction &lt;35=J&gt;](msg:J) or [Allocation Report &lt;35=AS&gt;](msg:AS) messageNumber of [SettlPartySubID (785)](tag:785) and [SettlPartySubIDType (786)](tag:786) entriesNumber of [PartySubID (523)](tag:523) and [PartySubIDType (803)](tag:803) entriesType of [PartySubID (523)](tag:523) value Example values: 1 = Firm 2 = Person 3 = System 4 = Application 5 = Full legal name of firm 6 = Postal address (inclusive of street address, location, and postal code) 7 = Phone number 8 = Email address 9 = Contact name 10 = Securities account number (for settlement instructions) 11 = Registration number (for settlement instructions and confirmations) 12 = Registered address (for confirmation purposes) 13 = Regulatory status (for confirmation purposes) 14 = Registration name (for settlement instructions) 15 = Cash account number (for settlement instructions) 16 = BIC 17 = CSD participant/member code (e.g. Euroclear, DTC, CREST or Kassenverein number) 18 = Registered address 19 = Fund/account name 20 = Telex number 21 = Fax number 22 = Securities account name 23 = Cash account name 24 = Department 25 = Location / Desk 26 = Position Account Type 4000+ = Reserved and available for bi-laterally agreed upon user defined valuesNumber of [NestedPartySubID (545)](tag:545) and [NestedPartySubIDType (805)](tag:805) entriesType of [NestedPartySubID (545)](tag:545) value. Same values as [PartySubIDType (803)](tag:803)Number of [Nested2PartySubID (760)](tag:760) and [Nested2PartySubIDType (807)](tag:807) entries. Second instance of [NestedParties](component:NestedParties).Type of [Nested2PartySubID (760)](tag:760) value. Second instance of [NestedParties](component:NestedParties). Same values as [PartySubIDType (803)](tag:803)Response to allocation to be communicated to a counterparty through an intermediary, i.e. clearing house. Used in conjunction with [AllocType (626)](tag:626) = "Request to Intermediary" and [AllocReportType (794)](tag:794) = "Request to Intermediary"Underlying price associate with a derivative instrument.Delta calculated from theoretical priceUsed to specify the maximum number of application messages that can be queued before a corrective action needs to take place to resolve the queuing issue.Current number of application messages that were queued at the time that the message was created by the counterparty.Resolution taken when [ApplQueueDepth (813)](tag:813) exceeds [ApplQueueMax (812)](tag:812) or system specified maximum queue size.Action to take to resolve an application message queue (backlog).Number of alternative market data sourcesSession layer source for market data (For the standard FIX session layer, this would be the [TargetCompID (56)](tag:56) where market data can be obtained).Secondary trade report identifier - can be used to associate an additional identifier with a trade.Average Pricing IndicatorUsed to link a group of trades together. Useful for linking a group of trades together for average price calculations.Specific device number, terminal number or station where order was enteredTrading Session in which the underlying instrument tradesTrading Session sub identifier in which the underlying instrument tradesReference to the leg of a multileg instrument to which this trade refersUsed to report any exchange rules that apply to this trade. Primarily intended for US futures markets. Certain trading practices are permitted by the CFTC, such as large lot trading, block trading, all or none trades. If the rules are used, the exchanges are required to indicate these rules on the trade.Identifies how the trade is to be allocatedPart of trading cycle when an instrument expires. Field is applicable for derivatives.Type of Trade.Further qualification to the trade typeReason trade is being transferredTotal Number of Assignment Reports being returned to a firmUnique identifier for the Assignment ReportAmount that a position has to be in the money before it is exercised.Describes whether peg is static or floatsType of Peg Offset valueType of Peg LimitIf the calculated peg price is not a valid tick price, specifies whether to round the price to be more or less aggressiveThe price the order is currently pegged atThe scope of the pegDescribes whether discretionay price is static or floatsType of Discretion Offset valueType of Discretion LimitIf the calculated discretionary price is not a valid tick price, specifies whether to round the price to be more or less aggressiveThe current discretionary price of the orderThe scope of the discretionThe target strategy of the order Example values: 1 = VWAP 2 = Participate (i.e. aim to be x percent of the market volume) 3 = Mininize market impact 1000+ = Reserved and available for bi-laterally agreed upon user defined valuesField to allow further specification of the [TargetStrategy (847)](tag:847) - usage to be agreed between counterpartiesFor a [TargetStrategy (847)](tag:847)="Participate" order specifies the target particpation rate. For other order types this is a volume limit (i.e. do not be more than this percent of the market volume)For communication of the performance of the order versus the target strategyIndicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity. Applicable only for [OrdStatus (39)](tag:39) of 'Partial' or 'Filled'.Indicates if a trade should be reported via a market reporting service.Reason for short sale.Type of quantity specified in a [Quantity (53)](tag:53) field:Additional TrdType assigned to a trade by trade match system. See [TrdType (828)](tag:828) tagType of Trade ReportIndicates how the orders being booked and allocated by an [Allocation Instruction &lt;35=J&gt;](msg:J) or [Allocation Report &lt;35=AS&gt;](msg:AS) message are identified, i.e. by explicit definition in the [NoOrders (73)](tag:73) group or not.Commission to be shared with a third party, e.g. as part of a directed brokerage commission sharing arrangement.Unique identifier for a Confirmation Request messageUsed to express average price as percent of par (used where [AvgPx (6)](tag:6) field is expressed in some other way)Reported price (used to differentiate from [AvgPx (6)](tag:6) on a confirmation of a marked-up or marked-down principal trade)Number of repeating [OrderCapacity (528)](tag:528) entries.Quantity executed under a specific [OrderCapacity (528)](tag:528) (e.g. quantity executed as agent, quantity executed as principal)Number of repeating [EventType (865)](tag:865) entries.Code to represent the type of eventDate of eventPredetermined price of issue at event, if applicableComments related to the event.Percent at risk due to lowest possible call.Number of repeating [InstrAttribType (871)](tag:871) entries.Code to represent the type of instrument attributeAttribute value appropriate to the [InstrAttribType (871)](tag:871) field.The effective date of a new securities issue determined by its underwriters. Often but not always the same as the [IssueDate (225)](tag:225) and the [InterestAccrualDate (874)](tag:874)The start date used for calculating accrued interest on debt instruments which are being sold between interest payment dates. Often but not always the same as the [IssueDate (225)](tag:225) and the [DatedDate (873)](tag:873)The program under which a commercial paper is issuedThe registration type of a commercial paper issuanceThe program under which the underlying commercial paper is issuedThe registration type of the underlying commercial paper issuanceUnit amount of the underlying security (par, shares, currency, etc.)Identifier assigned to a trade by a matching system.Used to refer to a previous [SecondaryTradeReportRefID (881)](tag:881) when amending the transaction (cancel, replace, release, or reversal).Price (percent-of-par or per unit) of the underlying security or basket. "Dirty" means it includes accrued interestPrice (percent-of-par or per unit) of the underlying security or basket at the end of the agreement.Currency value attributed to this collateral at the start of the agreementCurrency value currently attributed to this collateralCurrency value attributed to this collateral at the end of the agreementNumber of underlying stipulation entriesType of stipulation. Same values as [StipulationType (233)](tag:233)Value of stipulation. Same values as [StipulationValue (234)](tag:234)Net Money at maturity if Zero Coupon and maturity value is different from par valueDefines the unit for a miscellaneous fee.Total number of NoAlloc entries across all messages. Should be the sum of all [NoAllocs (78)](tag:78) in each message that has repeating NoAlloc entries related to the same [AllocID (70)](tag:70) or [AllocReportID (755)](tag:755). Used to support fragmentation.Indicates whether this message is the last in a sequence of messages for those messages that support fragmentation, such as [Allocation Instruction &lt;35=J&gt;](msg:J), [Mass Quote &lt;35=i&gt;](msg:i), [Security List &lt;35=y&gt;](msg:y), [Derivative Security List &lt;35=AA&gt;](msg:AA)Collateral Request IdentifierReason for [Collateral Assignment &lt;35=AY&gt;](msg:AY)Collateral inquiry qualifiersNumber of trades in repeating group.The fraction of the cash consideration that must be collateralized, expressed as a percent. A [MarginRatio (898)](tag:898) of 102% indicates that the value of the collateral (after deducting for "haircut") must exceed the cash consideration by 2%.Excess margin amount (deficit if value is negative)TotalNetValue is determined as follows: At the initial collateral assignment [TotalNetValue (900)](tag:900) is the sum of ([UnderlyingStartValue (884)](tag:884) * (1-haircut)). In a collateral substitution [TotalNetValue (900)](tag:900) is the sum of ([UnderlyingCurrentValue (885)](tag:885) * (1-haircut)).Starting consideration less repaymentsCollateral Assignment Identifier[Collateral Assignment &lt;35=AY&gt;](msg:AY) Transaction TypeCollateral Response Identifier[Collateral Assignment &lt;35=AY&gt;](msg:AY) Response Type[Collateral Assignment &lt;35=AY&gt;](msg:AY) Reject ReasonCollateral Assignment Identifier to which a transaction refersCollateral Report IdentifierCollateral Inquiry IdentifierCollateral StatusTotal number or reports returned in response to a request.Indicates whether this message is that last report message in response to a request, such as [Order Mass Status Request &lt;35=AF&gt;](msg:AF).The full name of the base standard agreement, annexes and amendments in place between the principals applicable to a financing transaction.A common reference to the applicable standing agreement between the counterparties to a financing transaction.A reference to the date the underlying agreement specified by [AgreementID (914)](tag:914) and [AgreementDesc (913)](tag:913) was executed.Start date of a financing deal, i.e. the date the buyer pays the seller cash and takes control of the collateralEnd date of a financing deal, i.e. the date the seller reimburses the buyer and takes back control of the collateralContractual currency forming the basis of a financing agreement and associated transactions. Usually, but not always, the same as the trade currency.Identifies type of settlementAccrued Interest Amount applicable to a financing transaction on the [EndDate (917)](tag:917).Starting dirty cash consideration of a financing deal, i.e. paid to the seller on the [StartDate (916)](tag:916).Ending dirty cash consideration of a financing deal. i.e. reimbursed to the buyer on the [EndDate (917)](tag:917).Unique identifier for a User Request.Indicates the action required by a [User Request &lt;35=BE&gt;](msg:BE) MessageNew [Password (554)](tag:554) or passphraseIndicates the status of a userA text description associated with a user status.Indicates the status of a network connectionA text description associated with a network status.Assigned value used to identify a firm.Assigned value used to identify specific elements within a firm.Unique identifier for a network response.Unique identifier for a network resquest.Identifier of the previous Network Response message sent to a counterparty, used to allow incremental updates.Indicates the type and level of details required for a Network Status Request Message Boolean logic applies EG If you want to subscribe for changes to certain id's then [UserRequestType (924)](tag:924) = 10 (8+2), Snapshot for certain ID's = 9 (8+1)Number of CompID entries in a repeating group.Indicates the type of Network Response Message.Number of [CollInquiryQualifier (896)](tag:896) entries in a repeating group.Trade Report StatusIdentifies the status of the ConfirmationAck.Currency in which the strike price of an underlying instrument ([UnderlyingStrikePrice (316)](tag:316)) is denominatedCurrency in which the strike price of an instrument leg of a multileg instrument ([LegStrikePrice (612)](tag:612)) is denominatedA code that represents a time interval in which a fill or trade occurred. Required for US futures markets.Action proposed for an [UnderlyingInstrument](component:UnderlyingInstrument) instance.Status of [Collateral Inquiry &lt;35=BB&gt;](msg:BB)Result returned in response to [Collateral Inquiry &lt;35=BB&gt;](msg:BB)Currency in which the [StrikePrice (202)](tag:202) is denominated.Number of [Nested3PartyID (949)](tag:949), [Nested3PartyIDSource (950)](tag:950), and [Nested3PartyRole (951)](tag:951) entriesPartyID value within a "third instance" Nested repeating group. Same values as [PartyID (448)](tag:448)PartyIDSource value within a "third instance" Nested repeating group. Same values as [PartyIDSource (447)](tag:447)PartyRole value within a "third instance" Nested repeating group. Same values as [PartyRole (452)](tag:452)Number of [Nested3PartySubID (953)](tag:953) entriesPartySubID value within a "third instance" Nested repeating group. Same values as [PartySubID (523)](tag:523)PartySubIDType value within a "third instance" Nested repeating group. Same values as [PartySubIDType (803)](tag:803)Specifies when the contract (i.e. MBS/TBA) will settle.The start date used for calculating accrued interest on debt instruments which are being sold between interest payment dates. Often but not always the same as the [IssueDate (225)](tag:225) and the [DatedDate (873)](tag:873)The CommissionDate component block is used to carry commission information such as the type of commission and the rate.The presence of DiscretionInstructions component block on an order indicates that the trader wishes to display one price but will accept trades at another price.Component block is optionally used only for financing deals to identify the legal agreement under which the deal was made and other unique characteristics of the transaction. The AgreementDesc field refers to base standard documents such as MRA 1996 Repurchase Agreement, GMRA 2000 Bills Transaction (U.K.), MSLA 1993 Securities Loan – Amended 1998, for example.The Instrument component block contains all the fields commonly used to describe a security or instrument. Typically the data elements in this component block are considered the static data of a security, data that may be commonly found in a security master database. The Instrument component block can be used to describe any asset type supported by FIX.The InstrumentExtension component block identifies additional security attributes that are more commonly found for Fixed Income securities.The InstrumentLeg component block, like the Instrument component block, contains all the fields commonly used to describe a security or instrument. In the case of the InstrumentLeg component block it describes a security used in multileg-oriented messages.The LegBenchmarkCurveData is used to convey the benchmark information used for pricing in a multi-legged Fixed Income security.The LegStipulations component block has the same usage as the Stipulations component block, but for a leg instrument in a multi-legged security.The logon message authenticates a user establishing a connection to a remote system.The NestedParties component block is identical to the Parties Block. It is used in other component blocks and repeating groups when nesting will take place resulting in multiple occurrences of the Parties block within a single FIX message. Use of NestedParties under these conditions avoids multiple references to the Parties block within the same message which is not allowed in FIX tag/value syntax.The NestedParties2 component block is identical to the Parties Block. It is used in other component blocks and repeating groups when nesting will take place resulting in multiple occurrences of the Parties block within a single FIX message. Use of NestedParties2 under these conditions avoids multiple references to the Parties block within the same message which is not allowed in FIX tag/value syntax.The NestedParties3 component block is identical to the Parties Block. It is used in other component blocks and repeating groups when nesting will take place resulting in multiple occurrences of the Parties block within a single FIX message. Use of NestedParties3 under these conditions avoids multiple references to the Parties block within the same message which is not allowed in FIX tag/value syntax.The OrderQtyData component block contains the fields commonly used for indicating the amount or quantity of an order. Note that when this component block is marked as "required" in a message either one of these three fields must be used to identify the amount: OrderQty, CashOrderQty or OrderPercent (in the case of CIV).The Parties component block is used to identify and convey information on the entities both central and peripheral to the financial transaction represented by the FIX message containing the Parties Block. The Parties block allows many different types of entites to be expressed through use of the PartyRole field and identifies the source of the PartyID through the PartyIDSource.The Peg Instructions component block is used to tie the price of a security to a market event such as opening price, mid-price, best price. The Peg Instructions block may also be used to tie the price to the behavior of a related security.The PositionAmountData component block is used to report netted amounts associated with position quantities. In the listed derivatives market the amount is generally expressing a type of futures variation or option premium. In the equities market this may be the net pay or collect on a given position.The PositionQty component block specifies the various types of position quantity in the position life-cycle including start-of-day, intraday, trade, adjustments, and end-of-day position quantities. Quantities are expressed in terms of long and short quantities.The SettlInstructionsData component block is used to convey key information regarding standing settlement and delivery instructions. It also provides a reference to standing settlement details regarding the source, delivery instructions, and settlement partiesThe SettlParties component block is used in a similar manner as Parties Block within the context of settlement instruction messages to distinguish between parties involved in the settlement and parties who are expected to execute the settlement process.The SpreadOrBenchmarkCurveData component block is primarily used for Fixed Income to convey spread to a benchmark security or curve.The standard FIX message headerThe standard FIX message trailerThe Stipulations component block is used in Fixed Income to provide additional information on a given security. These additional information are usually not considered static data information.The TrdRegTimestamps component block is used to express timestamps for an order or trade that are required by regulatory agencies. These timestamps are used to identify the timeframes for when an order or trade is received on the floor, received and executed by the broker, etc.The UnderlyingInstrument component block, like the Instrument component block, contains all the fields commonly used to describe a security or instrument. In the case of the UnderlyingInstrument component block it describes an instrument which underlies the primary instrument Refer to the Instrument component block comments as this component block mirrors Instrument, except for the noted fields.The UnderlyingStipulations component block has the same usage as the Stipulations component block, but for an underlying security.The YieldData component block conveys yield information for a given Fixed Income security.The 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) - [Order Mass Cancel Request &lt;35=q&gt;](msg:q) 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. When rejecting an [Order Cancel Request &lt;35=F&gt;](msg:F) or an [Order Cancel/Replace Request &lt;35=G&gt;](msg:G), 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. When rejecting an [Order Mass Cancel Request &lt;35=q&gt;](msg:q), the [ClOrdID (11)](tag:11) should be set to the [ClOrdID (11)](tag:11) value which was present in the request. [OrigClOrdID (41)](tag:41) is not specified for a rejected Order Mass Cancel Request.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).The Derivative Security List message is used as a response to a [Derivative Security List Request &lt;35=z&gt;](msg:z), and includes a list of securities that matches the criteria specified. This message is used to send a predefined list of securities - usually options - based on a common underlying and option class. It can also be used to send the rules for security creation - again, usually options - which imply the existence of a set of securities. Other uses of this message may include: - Convey comprehensive set of option classes for all market segments in which these option classes participates in - Convey the option classes' trading rules that differ from the default trading rules for the market segmentThe New Order - Multileg message is used to submit orders for securities that are made up of multiple securities, known as legs.The Multileg Order Cancel/Replace message is used to modify a multileg order previously placed using [New Order Multileg &lt;35=AB&gt;](msg:AB). See also [Order Cancel/Replace Request &lt;35=G&gt;](msg:G).The Trade Capture Report Request can be used to: - Request one or more [Trade Capture Report &lt;35=AE&gt;](msg:AE)s based upon the criteria provided - Subscribe to [Trade Capture Report &lt;35=AE&gt;](msg:AE)s based upon tge criteria provided The following criteria can be specified - All trades matching specified trade identification: [TradeReportID (571)](tag:571), [SecondaryTradeReportID (818)](tag:818) - All trades matching specified trade types: [TrdType (828)](tag:828), [TrdSubType (829)](tag:829), [TransferReason (830)](tag:830), [SecondaryTrdType (855)](tag:855), [TradeLinkID (820)](tag:820) - All trades matching the order identification information: [LastPx (31)](tag:31), [ClOrdID (11)](tag:11), [ExecID (17)](tag:17) - Trades that have specified [MatchStatus (573)](tag:573) - All trades for the party defined in the component block [Parties](component:Parties) - This can be a trader id, firm, broker id, clearing firm - All trades for a specific instrument, specified using the component block [Instrument](component:Instrument), the component block [UnderlyingInstrument](component:UnderlyingInstrument), and/or the component block [InstrumentLeg](component:InstrumentLeg). - All unreported trades - Executions that have not been sent - All unmatched trades - Trades that have not been matched - All trades matching specific date and trading session criteria - Trades entered via a specific [TradeInputSource (578)](tag:578) - Trades entered via a specific [TradeInputDevice (579)](tag:579) - All Advisories Each field in the Trade Capture Report Request (other than [TradeRequestID (568)](tag:568) and [SubscriptionRequestType (263)](tag:263)) identify filters - trade reports that satisfy all specified filters will be returned. Note that the filters are combined using an implied "and" - a trade report must satisfy every specified filter to be returned. The optional date or time range-specific filter criteria (within [NoDates (580)](tag:580) repeating group) can be used in one of two modes: - "Since" a time period. [NoDates (580)](tag:580)=1 with first [TradeDate (75)](tag:75) (and optional [TransactTime (60)](tag:60)) indicating the "since" (greater than or equal to operation) point in time. - "Between" time periods. [NoDates (580)](tag:580)=2 with first [TradeDate (75)](tag:75) (and optional [TransactTime (60)](tag:60)) indicating the "beginning" (greater than or equal to operation) point in time and the second [TradeDate (75)](tag:75) (and optional [TransactTime (60)](tag:60)) indicating the "ending" (less than or equal to operation) point in time. The response to a Trade Capture Report Request can be: - One or more [Trade Capture Report &lt;35=AE&gt;](msg:AE)s - A [Trade Capture Report Request Ack &lt;35=AQ&gt;](msg:AQ) followed by one or more [Trade Capture Report &lt;35=AE&gt;](msg:AE)s in two specific cases: - When the Trade Capture Reports are being delivered out of band, such as a file transfer - When there is a processing delay between the time of the request and when the reports will be sent. For instance, in a distributed trading environment where trades are distributed across multiple trading systems - A [Trade Capture Report Ack &lt;35=AR&gt;](msg:AR) only - When no trades are found that match the criteria specified - When the request was deemed invalid for business reasonsThe Trade Capture Report message can be: - Used to report trades between counterparties. - Used to report trades to a trade matching system - Can be sent unsolicited between counterparties. - Sent as a reply to a Trade Capture Report Request. - Can be used to report unmatched and matched trades.This message is used to request the status for orders matching criteria specified within the request. A mass status request is assigned a [ClOrdID (11)](tag:11) and is treated as a separate entity. [Execution Report &lt;35=8&gt;](msg:8)s with [ExecType (150)](tag:150)="Order Status" are returned for all orders matching the criteria in the request. Order selection criteria is specified using the [MassStatusReqType (585)](tag:585) field.The Quote Request Reject message is used to reject [Quote Request &lt;35=R&gt;](msg:R) messages for all quoting models.The RFQ Request is used by liquidity providers to indicate to the market which instruments they're interested in receiving [Quote Request &lt;35=R&gt;](msg:R)s for. It can be used to register interest in receiving quote requests for a single instrument or for multiple instruments. In tradeable and restricted tradeable quoting markets - [Quote Request &lt;35=R&gt;](msg:R)s are issued by counterparties interested in ascertaining the market for an instrument. [Quote Request &lt;35=R&gt;](msg:R)s are then distributed by the market to liquidity providers who make markets in the instrument.This message is used as a response to the following messages: - [Quote Status Request &lt;35=a&gt;](msg:a) - [Quote Cancel &lt;35=Z&gt;](msg:Z) - [Quote Response &lt;35=AJ&gt;](msg:AJ), in a negotiation dialogThis message is used to respond to an [Indication of Interest &lt;35=6&gt;](msg:6) or a [Quote &lt;35=S&gt;](msg:S). It is also used to counter a [Quote &lt;35=S&gt;](msg:S) or to end a negotiation dialog. For usage of this message in a negotiation or counter-quote dialog for fixed income and exchanges/marketplace, see Volume 7, Fixed Income and Exchanges and Markets sections respectively.This message is used to provide individual trade-level confirmations from the sell-side to the buy-side. Prior to FIX 4.4, this role was performed by the Allocation message. Unlike the Allocation message, the Confirmation message operates at an allocation-account level (trade level) rather than block level, allowing for the affirmation or rejection of individual confirmations. This message is also used to report the booking status of each allocation instance. When the buy-side, in response, affirms with the [Confirmation Ack &lt;35=AU&gt;](msg:AU) message, the trade is ready to settle. Because each message reports the details of a single ticket, [Account (1)](tag:1) names, fees, net money, and settlement information are reported using fields designated for single-account trades. Every Confirmation message has a unique [ConfirmID (664)](tag:664). It's recommended that the sell-side system trade reference be used as the [ConfirmID (664)](tag:664) where possible, to allow the [ConfirmID (664)](tag:664) to be used as a mutually understood trade reference, e.g. for use in manual conversations regarding specific trades. The capacities of the firm executing the order or orders covered by this confirmation is represented in a repeating group. This is to support confirmations covering orders executed under more than one capacity, e.g. a mixture of agency and principal execution. The [OrderCapacityQty (863)](tag:863) field shows the quantity executed under each [OrderCapacity (528)](tag:528). The sum of the [OrderCapacityQty (863)](tag:863) values must equal the confirmation's [AllocQty (80)](tag:80).The Position Maintenance Request message allows the position owner to submit requests to the holder of a position which will result in a specific action being taken which will affect the position. Generally, the holder of the position is a central counter party or clearing organization but can also be a party providing investment services. Submission of a request may result in the following: - adjustment of both the long and short start of day position quantity - exercise of an option position into a position in the instrument underlying the option - abandonment of an option position that would otherwise exercise - netting of current day trades to change to the end of day long and short position - spreading of a position against other position in order to reduce margin requirements - pledge of a position for collateral purposes - large trader submission of the long and short quantities The request may be submitted as either new, replace or cancel and may refer to a specific position or the previously submitted message. The request is always submitted as of a [ClearingBusinessDate (715)](tag:715) and is therefore required. The parties both owning and holding the position are specified in the parties block.The Position Maintenance Report message is sent by the holder of a position in response to a [Position Maintenance Request &lt;35=AL&gt;](msg:AL) and is used to confirm that a request has been successfully processed or rejected.This message is used by the owner of a position to request a [Position Report &lt;35=AP&gt;](msg:AP) from the holder of the position, usually the central counterparty or clearing organization. The request can be made at several levels of granularity. - Position Report only - Positions and related Trades - Exercises only - Assignments only - Settlements activity The message can be used to request a one=time snapshot of positions, or to subscribe to updates as they occur using the [SubscriptionRequestType (263)](tag:263). The [ResponseTransportType (725)](tag:725) can be used to specify if the reports are to be sent in-band over the session transport or out-of-band of band over an alternative transport such as FTP.This message is returned in response to a [Request for Positions &lt;35=AN&gt;](msg:AN) by the holder of the position. It's used to acknowledge that a request has been received and is being processed.This message is a response to a [Request for Positions &lt;35=AN&gt;](msg:AN) message, returned by the holder of the position. It's used to report all aspects of a position and may be provided on a standing basis to report end-of-day positions to an owner.This message is used as as response to a [Trade Capture Report Request &lt;35=AD&gt;](msg:AD), in these scenarios: - When the request is used to specify an out-of-band subscription or delivery of reports - When the return of the matching [Trade Capture Report &lt;35=AE&gt;](msg:AE)s will be delayed or delivered asynchronously - When no trades were found that matched the criteria in the request - When the request was invalid for some business reason, such as request not being authorized, unknown instrument, etc. A Trade Capture Report Request Ack is not required if one or more [Trade Capture Report &lt;35=AE&gt;](msg:AE)s will be returned in-band immediately.This message can be used to acknowledge or reject [Trade Capture Report &lt;35=AE&gt;](msg:AE)s received from a counterparty.Sent from sell-side to buy-side, sell-side to 3rd-party or 3rd-party to buy-side, the Allocation Report (Claim) provides account breakdown of an order or set of orders plus any additional follow-up front-office information developed post-trade during the trade allocation, matching and calculation phase. In versions of FIX prior to version 4.4, this functionality was provided through the Allocation message. Depending on the needs of the market and the timing of "confirmed" status, the role of Allocation Report can be taken over in whole or in part by the [Confirmation &lt;35=AK&gt;](msg:AK) message. Note the response to the Allocation Report message is the [Allocation Report Ack &lt;35=AT&gt;](msg:AT) message. In versions of FIX prior to version 4.4, the Allocation ACK served this purpose. An Allocation Report message can be submitted with [AllocReportType (794)](tag:794) of - Sellside Calculated Using Preliminary (includes Misc Fees, Accrued Interest and Net Money) - Sellside Calculated Without Preliminary (includes Misc Fees, Accrued Interest and Net Money). ([AllocType (626)](tag:626) = "Sellside Initiated"), i.e. where the allocations have been provided via some other mechanism or agreed earlier in the order process. - Warehouse recap - sent unsolicited by sellside, used to communicate confirmation and current status of any warehoused position in a particular stock (see Volume 7 - PRODUCT: EQUITIES for specific usage guidance on this topic) Settlement instructions are supported on the Allocation Report message to allow the Respondent (sell-side party or carry firm) to send an override of its own instructions to the Initiator. General guidelines applicable to this message: - [AllocReportID (755)](tag:755) should be unique for all Allocation Report messages. - To reject an Allocation Report message, an AllocationReportAck(AT) with [AllocStatus (87)](tag:87) 'Block level reject' or '[Account (1)](tag:1) level reject' should be used. Use of 'Block level reject' means the entire message has been rejected (e.g. net money mismatch). '[Account (1)](tag:1) level reject' is used when the block level matches successfully but one or more (or all) of the constituent account level details fails validation (e.g. account not found, incorrect MiscFees). In the latter case, the rejecting party can (optionally) notify the instructing party of those allocation details that are being rejected by listing the offending account numbers in the [Allocation Instruction Ack &lt;35=P&gt;](msg:P) message. - A rejected Allocation Report must be resolved out-of-band. - Where settling in markets where multiple alternative settlement locations exist, it is recommended that the settlement location (equivalent to ISO15022 'PSET' field) be identified on each allocation detail within the [NoAllocs (78)](tag:78) repeating group. A nested parties component block is provided which can be used for this purpose. The allocation message contains repeating fields for each order, sub-account and individual execution. The repeating fields are shown in the message definition below in typeface Bold-Italic and indented with the → symbol. The field's relative position within the repeating group in the message is important. For example, each instance of allocation must be in the order as shown in the message definition below. - The number of sub-account instances is indicated in [NoAllocs (78)](tag:78). - Multiple orders can be combined for allocation or for [AllocType (626)](tag:626)=" Ready-To-Book" or [AllocType (626)](tag:626) = "Warehouse instruction". Note that combined orders must refer to the same instrument and have the same trade date, settlement date and side. The identification of the orders to be combined can be achieved in one of two ways: - By identifying the number of orders in the [NoOrders (73)](tag:73) field and each individual order in the [OrderID (37)](tag:37) fields. The [AllocNoOrdersType (857)](tag:857) field is used to denote that this is happening and takes value "1=Explicit list provided". If any orders were handled outside FIX, the [ClOrdID (11)](tag:11) must be set to 'MANUAL'. Regardless of whether the orders were handled within or outside FIX, the order quantity and average price must also be specified for each order. This is to assist in validating the message and, for manual orders, to help identify the correct orders to book. - By stating that an unspecified group of orders is to be combined. The [NoOrders (73)](tag:73) field in this case is left blank. The [AllocNoOrdersType (857)](tag:857) field is set to "0=Not specified" to specify that this is happening. Note use of this approach is only recommended where either the number of orders being booked is extremely large or some kind of aggregation rule is being used. - Multiple executions can be combined for allocation by identifying the number of executions in the [NoExecs (124)](tag:124) field and each individual execution in the [ExecID (17)](tag:17) fields. Combined executions must refer to the same instrument, trade date, settlement date and side.This message is used to acknowledge the receipt of and provide status for an [Allocation Report &lt;35=AS&gt;](msg:AS) message. It is possible that multiple Allocation Report Ack messages can be generated for a single [Allocation Report &lt;35=AS&gt;](msg:AS) message to acknowledge the receipt and then to detail the acceptance or rejection of the [Allocation Report &lt;35=AS&gt;](msg:AS) message. It is recommended, when appropriate, that the [MatchStatus (573)](tag:573) field be used in the Allocation Report Ack to denote whether any financial details provided in the [Allocation Report &lt;35=AS&gt;](msg:AS) with [AllocStatus (87)](tag:87) of 'Accepted' were matched by the Initiator. If a match takes place and succeeds, then the match status will be '0-Compared and affirmed'. If the match takes place and fails, or no match takes place, then the match status will be '1-Uncompared or unaffirmed'.The Confirmation Ack (aka Affirmation) message is used to respond to a Confirmation message.The Settlement Instruction Request message is used to request standing settlement instructions from another party. This could be: - A buyside firm requesting standing instructions from a sellside firm. - A sellside firm requesting standing instructions from a buyside firm. - A sellside or buyside firm requesting standing instructions from a third party central static data database. - A third party central static data database requesting standing instructions from a sellside or buyside firm. Settlement instructions can be requested for any combination of the following parameters (in addition to the party whose instructions are being requested): - [AllocAccount (79)](tag:79) - [Country (421)](tag:421) (of settlement) - [Side (54)](tag:54) - [SecurityType (167)](tag:167) (and/or CFI code) - [SettlCurrency (120)](tag:120) - [SettlDeliveryType (172)](tag:172) (i.e. DVP vs. FOP) - [EffectiveTime (168)](tag:168) (i.e. all instructions valid at any time from this date/time) - Expiry Time (i.e. all instructions valid until this date/time) - Last update time (i.e. all instructions created or updated since this date/time) Alternatively, settlement instructions can be queried by reference to a database of standing instructions using the identifiers of that database as follows: - Database id - Database name - Id of the settlement instructions on this database The response to such a request should be a Settlement Instruction message with [SettlInstTransType (163)](tag:163) "New" containing all SSIs meeting the criteria specified in the Settlement Instruction request. If the request cannot be processed, the request should be rejected with a Settlement Instruction message with [SettlInstTransType (163)](tag:163) "Request rejected". Similarly, if the request returns no data, the request should be rejected with a Settlement Instruction message with [SettlInstTransType (163)](tag:163) "No matching data found".Assignment Reports are sent from a clearing house to counterparties, such as a clearing firm as a result of the assignment process. Communication Scenarios: - Assignment Report can be sent unsolicited from the clearing house to a clearing firm. - Assignment Report can be returned in response to a Request for Positions message with a [PosReqType (724)](tag:724) set to 3 (Assignment).An initiator that requires collateral from a respondent sends a Collateral Request. The initiator can be either counterparty to a trade in a two party model or an intermediary such as an ATS or clearinghouse in a three party model. A Collateral Assignment is expected as a response to a request for collateral.This message is used to assign collateral to cover a trading position. This message can be unsolicited or in response to a [Collateral Request &lt;35=AX&gt;](msg:AX). It can be used to assign initial collateral or to replace collateral.This message is used to respond to a [Collateral Assignment &lt;35=AY&gt;](msg:AY).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 used to report collateral status when responding to a [Collateral Inquiry &lt;35=BB&gt;](msg:BB).This message is used to inquire for collateral status.This message is sent either immediately after logging on to inform the counterparty system of the type of updates required, or at any other time in the FIX conversation to change the types of status updates required. It can also be used with [NetworkRequestType (935)](tag:935) = Snapshot to request a one-off report of the status of the counterparty system. This message can also be used to cancel a previous subscription, with [NetworkRequestType (935)](tag:935) = StopSubscribing.This message is sent in response to a [Network Counterparty System Status Request &lt;35=BC&gt;](msg:BC). If the network response payload is larger than the maximum permitted message size for that FIX conversation, the response would be split into several messages, the first with [NetworkStatusResponseType (937)](tag:937) = Full and then multiple updates to the first message, adding information as required.This message is used to initiate a user action, logon, logout or password change. It can also be used to request a report on a user’s status.This message is used to respond to a [User Request &lt;35=BE&gt;](msg:BE). It reports the status of the user after the completion of any action requested in the [User Request &lt;35=BE&gt;](msg:BE).Used to respond to a Collateral Inquiry in the following situations: - When the [Collateral Inquiry &lt;35=BB&gt;](msg:BB) will result in an out of band response (such as a file transfer). - When the inquiry is otherwise valid but no collateral is found to match the criteria specified on the Collateral Inquiry message. - When the Collateral Inquiry is invalid based upon the business rules of the counterparty.The Confirmation Request message is used to request a [Confirmation &lt;35=AK&gt;](msg:AK) message.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 [AllocQty (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".This 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 lists the stocks, quantities, and direction for the trade and may contain pre-allocation information. 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 lists 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. 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. Where multiple waves of a program trade are submitted by an institution or retail intermediaries, as a series of separate lists, to a broker [ClOrdLinkID (583)](tag:583) may be used to link the orders together. The New Order List message type may also be used by institutions or retail intermediaries wishing to electronically submit multiple Collective Investment Vehicle orders to a broker or fund manager for execution.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.This message 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 [Order Cancel Request &lt;35=F&gt;](msg:F) instead. This request can be used to change any valid attribute of an open order, e.g. to reduce or increase quantity, to change limit price, or to change instructions. Subject to agreement between counterparties, 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 request can be immediately accepted or rejected. The request will only be accepted if the order can successfully be pulled from the exchange 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 request. 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 an accepted request. The protocol supports the chaining of multiple cancel/replace requests, though trading counterparties may not support this functionality. Care should be taken if the order owner wishes to send a cancel/replace request when there is any cancel/replace requests which have not yet been accepted or rejected. In general: - The order sender should chain client order ids on an 'optimistic' basis, i.e. set the [OrigClOrdID (41)](tag:41) to the last non-rejected [ClOrdID (11)](tag:11) sent - The order receiver should chain client order ids on a 'pessimistic' basis, i.e. set the [OrigClOrdID (41)](tag:41) on execution reports that convey the receipt or successful application of a cancel/replace and [Order Cancel Reject &lt;35=9&gt;](msg:9) messages to be the last 'accepted' [ClOrdID (11)](tag:11) In the event that an application chains order cancel/replaces rapidly, it should ensure that each request contains the desirable state of the order in full. For example, if an attempt is made to change the limit price and then an immediate request to change the quantity is issued, then if the desired behaviour is that both the limit price and quantity should be changed then the second request should include the revised limit price, in case the first request is rejected. All of the application-level fields in the original order should be retransmitted with the original values in the request, except the fields that are being changed. Any field may be changed with this message except those in the [Instrument](component:Instrument) component block and limited changes to the [Side (54)](tag:54) field, noted below. Applications may further restrict which fields are allowed to change, so bilateral agreement is required. For example, some firms may not allow fields such as [Side (54)](tag:54) to change. Applications should validate the request to ensure that it does not attempt to change a field that cannot change; if it does, a [Order Cancel Reject &lt;35=9&gt;](msg:9) with [CxlRejReason (102)](tag:102) = 2 should be sent. When modifying [ExecInst (18)](tag:18) values in a replacement order, it is necessary to re-declare all [ExecInst (18)](tag:18)s. [ExecInst (18)](tag:18) values 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.This message used to to specify how an order or set of orders should be subdivided amongst one or more accounts. Prior to FIX 4.4, this message used the name "Allocation", and was also used to communicate fee and expense details from the sell-side to the buy-side. This role has now been removed from and is now performed by [Allocation Report &lt;35=AS&gt;](msg:AS) and [Confirmation &lt;35=AK&gt;](msg:AK). The [Allocation Report &lt;35=AS&gt;](msg:AS) message should be used for the sell-side-initiated allocation role as defined in previous versions of the protocol. The response to this message is the [Allocation Instruction Ack &lt;35=P&gt;](msg:P) message. 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 accounts and their respective order quantities which make up the order. This is a regulatory requirement in certain markets and for certain types of securities. This message can be submitted with [AllocTransType (71)](tag:71) = "new", "cancel" or "replace". The [AllocType (626)](tag:626) field indicates the type or purpose of the message: - Calculated - includes MiscFees and [NetMoney (118)](tag:118) - Preliminary - without MiscFees and [NetMoney (118)](tag:118) - Ready-To-Book - Warehouse instruction [AllocSettlInstType (780)](tag:780) is used to specify full settlement instruction details, to provide a reference to a settlement instruction held on a database of such instructions or to instruct the receiving party to perform one of the following actions: - Use default instructions - Derive the instructions from the parameters of the trade - Phone for instructions [AllocID (70)](tag:70) should be unique for all messages with [AllocTransType (71)](tag:71) = "new". When [AllocTransType (71)](tag:71) = "replace" or "cancel", [RefAllocID (72)](tag:72) and [AllocCancReplaceReason (796)](tag:796) are required. To reject an Allocation Instruction, an [Allocation Instruction Ack &lt;35=P&gt;](msg:P) with [AllocStatus (87)](tag:87) = "'Block-level reject" or "Account-level reject" should be used. Block-level reject is used to reject the entire message, e.g. due to one or more of the orders not matching. An account-level reject is used when the block-level matches successfully but one or more of the constituent account-level details failed validation, e.g. the account was not found. In the latter case, the rejecting party can optionally notify the instructing party of those allocation details that are being rejected by listing the offending account IDs in the [Allocation Instruction Ack &lt;35=P&gt;](msg:P). [AllocGrp](component:AllocGrp) exists for this purpose. The correct response to a block-level reject [Allocation Instruction Ack &lt;35=P&gt;](msg:P) is a new Allocation Instruction with [AllocTransType (71)](tag:71) = "new", as the previous message has been rejected in entirety. In the case of an account-level reject, either: - the original Allocation Instruction should be cancelled (an Allocation Instruction referencing the original in [RefAllocID (72)](tag:72), with [AllocTransType (71)](tag:71) = "cancel") then reinstated (a second Allocation Instruction with [AllocTransType (71)](tag:71) = "new") - the original Allocation Instruction should be fully replaced (an Allocation Instruction referencing the original in [RefAllocID (72)](tag:72), with [AllocTransType (71)](tag:71) = "replace"). A replacement allocation message must contain all data for the replacement allocation. It is the responsibility of the recipient to identify which fields have been changed Optionally, an Allocation Instruction with [AllocTransType (71)](tag:71) = "cancel" or "replace" can be rejected if an [Allocation Instruction Ack &lt;35=P&gt;](msg:P) with status = "accepted" has already been sent. Manual communication would then be required to effect the required changes. This approach would generally be required where the generation of the accepted [Allocation Instruction Ack &lt;35=P&gt;](msg:P) is used to move the allocation details into downstream processing, e.g. confirmation generation. In which case, a subsequent cancellation or amendment may require the details to be retrieved from the downstream process. Where an amendment or cancellation of an Allocation Instruction has taken place out outside of FIX, an [Allocation Report &lt;35=AS&gt;](msg:AS) message can be sent to confirm that the relevant action has taken place. Where settling in markets where multiple alternative settlement locations exist, it is recommended that the settlement location be specified on each allocation detail within the [AllocGrp](component:AllocGrp) component. A [NestedParties](component:NestedParties) component block exists for this purpose. [Quantity (53)](tag:53) must equal the total quantity allocated. If present, the total quantity in the execution section must also be equal to this value. The total quantity of the allocation does not necessarily have to equal the total quantity of the orders being allocated. For example in good-til (GT) orders, especially where multi-day average pricing is taking place. The quantity of each order being booked must also be specified on the message. This will be equal to the order quantity if the entire order is being booked, though can be less if only part of the order is being booked. The sum of the order booking quantities must be equal to [Quantity (53)](tag:53). The number of sub-account instances is indicated in the [AllocGrp](component:AllocGrp) component. Multiple orders can be combined for allocation or for [AllocType (626)](tag:626) = "Ready-To-Book" or for [AllocType (626)](tag:626) = "Warehouse instruction". Note that combined orders must refer to the same instrument and have the same trade date, settlement date and side. The identification of the orders to be combined can be achieved in one of two ways: - By identifying the number of orders in the [NoOrders (73)](tag:73) field and each individual order in the [OrderID (37)](tag:37) fields. The [AllocNoOrdersType (857)](tag:857) field is used to denote that this is happening and takes value "1=Explicit list provided". If any orders were handled outside FIX, the [ClOrdID (11)](tag:11) must be set to 'MANUAL'. Regardless of whether the orders were handled within or outside FIX, the order quantity and average price must also be specified for each order. This is to assist in validating the message and, for manual orders, to help identify the correct orders to book. - By stating that an unspecified group of orders is to be combined. The [NoOrders (73)](tag:73) field in this case is left blank. The [AllocNoOrdersType (857)](tag:857) field is set to "0=Not specified" to specify that this is happening. This approach is only recommended where either the number of orders being booked is extremely large or some kind of aggregation rule is being used. Multiple executions can be combined for allocation by identifying the number of executions in the [NoExecs (124)](tag:124) field and each individual execution in the [ExecID (17)](tag:17) fields. Combined executions must refer to the same instrument, trade date, settlement date and side. Except where [AllocTransType (71)](tag:71) = 'Cancel' or where [AllocNoOrdersType (857)](tag:857) = "Not specified", the list of orders being booked or allocated must be specified by using their [ClOrdID (11)](tag:11). If any orders were handled outside FIX, the [ClOrdID (11)](tag:11) must be set to 'MANUAL'. Regardless of whether the orders were handled within or outside FIX, and where the orders are specified, the order quantity and average price must also be specified for each order. This is to assist in validating the message and, for manual orders, to help identify the correct orders to book.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 Instruction &lt;35=J&gt;](msg:J) message. Prior to FIX 4.4, this message was known as "Allocation ACK". The status is indicated by the [AllocStatus (87)](tag:87) field as follows: <table><thead><tr><th>AllocStatus value</th><th>Description</th></tr></thead> <tbody><tr><td>3 = received, not yet processed</td><td>Used to acknowledge receipt of an <a href="msg:J">Allocation Instruction &lt;35=J&gt;</a> message. This should always be followed by a second Allocation Instruction Ack of status 0, 1 or 2 as follows or an <a href="msg:AS">Allocation Report &lt;35=AS&gt;</a> message. </td></tr> <tr><td>0 = accepted</td><td>The <a href="msg:J">Allocation Instruction &lt;35=J&gt;</a> has been validated and processed successfully. </td></tr> <tr><td>1 = block level reject</td><td>The entire <a href="msg:J">Allocation Instruction &lt;35=J&gt;</a> has been rejected. The <a href="tag:88">AllocRejCode (88)</a> field must be populated when performing a block level reject; this gives the reason for rejecting the <a href="msg:J">Allocation Instruction &lt;35=J&gt;</a>. </td></tr> <tr><td>2 = account level reject</td><td>The <a href="msg:J">Allocation Instruction &lt;35=J&gt;</a> has been validated and one or more of the <a href="tag:79">AllocAccount (79)</a> details in the <a href="tag:78">NoAllocs (78)</a> repeating group has failed validation, e.g. account not found. In this case, applications can optionally include a list of the <a href="tag:79">AllocAccount (79)</a> details that failed validation, together with reject reasons. </td></tr> </tbody></table> If [AllocStatus (87)](tag:87) = "accepted" in response to an [Allocation Instruction &lt;35=J&gt;](msg:J) with [AllocType (626)](tag:626) = "calculated", it is recommended that the [MatchStatus (573)](tag:573) field be used to denote whether any financial details provided in the [Allocation Instruction &lt;35=J&gt;](msg:J) were matched. If a match takes place and succeeds, then the match status will be '0' (compared and affirmed). If the match takes place and fails, or no match takes place, then the MatchStatus will be '1' (uncompared or unaffirmed).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. In the tradeable and restricted-tradeable quote models, this message may be preceded by the [RFQ Request &lt;35=AH&gt;](msg:AH) message. For tradeable quote requests, it is possible to specify the time the request is valid for, and that the resulting quote must be valid for.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. It's been designed so that it can be sent between different types of institutions. This message can be used in one of three modes, using [SettlInstMode (160)](tag:160): - To provide "standing instructions" for the settlement of trades occurring in the future. It can provide multiple settlement instructions. It could either be unsolicited or sent in response to a [Settlement Instruction Request &lt;35=AV&gt;](msg:AV). - To reject a [Settlement Instruction Request &lt;35=AV&gt;](msg:AV) - To provide settlement instructions for a specific order. [ClOrdID (11)](tag:11) should be used to link the settlement instructions to the corresponding order. The settlement instructions can be either explicitly specified using the [SettlInstructionsData](component:SettlInstructionsData) component, or can exist within an independent database and be referenced using 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 Status Report &lt;35=AI&gt;](msg:AI).The Quote Status Request message is used in markets that employ tradeable or restricted tradeable quotes, for the following reasons: - For the issuer of a quote to query the status of that quote, using [QuoteID (117)](tag:117) to specify the target quote - To subscribe and unsubscribe to [Quote Status Report &lt;35=AI&gt;](msg:AI) messages for one or more securitiesThis 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 [QuotEntryGrp](component:QuotEntryGrp) 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:R">Quote Request &lt;35=R&gt;</a></td><td><a href="msg:AG">Quote Request Reject &lt;35=AG&gt;</a></td></tr> <tr><td><a href="msg:S">Quote &lt;35=S&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>, <a href="msg:AJ">Quote Response &lt;35=AJ&gt;</a></td><td><a href="msg:AI">Quote Status Report &lt;35=AI&gt;</a></td></tr> <tr><td><a href="msg:i">Mass Quote &lt;35=i&gt;</a></td><td><a href="msg:b">Mass 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:v">Security Type Request &lt;35=v&gt;</a></td><td><a href="msg:w">Security Types &lt;35=w&gt;</a></td></tr> <tr><td><a href="msg:x">Security List Request &lt;35=x&gt;</a></td><td><a href="msg:y">Security List &lt;35=y&gt;</a></td></tr> <tr><td><a href="msg:z">Derivative Security List Request &lt;35=z&gt;</a></td><td><a href="msg:AA">Derivative Security List &lt;35=AA&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:D">New Order Single &lt;35=D&gt;</a>, <a href="msg:H">Order Status Request &lt;35=H&gt;</a>, <a href="msg:AF">Order Mass Status Request &lt;35=AF&gt;</a>, <a href="msg:s">New Order Cross &lt;35=s&gt;</a>, <a href="msg:AB">New Order Multileg &lt;35=AB&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:u">Cross Order Cancel Request &lt;35=u&gt;</a>, <a href="msg:t">Cross Order Cancel/Replace Request &lt;35=t&gt;</a>, <a href="msg:AC">Multileg Order Cancel/Replace &lt;35=AC&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:q">Order Mass Cancel Request &lt;35=q&gt;</a></td><td><a href="msg:r">Order Mass Cancel Report &lt;35=r&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:J">Allocation Instruction &lt;35=J&gt;</a></td><td><a href="msg:P">Allocation Instruction Ack &lt;35=P&gt;</a></td></tr> <tr><td><a href="msg:AS">Allocation Report &lt;35=AS&gt;</a></td><td><a href="msg:AT">Allocation Report Ack &lt;35=AT&gt;</a></td></tr> <tr><td><a href="msg:AK">Confirmation &lt;35=AK&gt;</a></td><td><a href="msg:AU">Confirmation Ack &lt;35=AU&gt;</a></td></tr> <tr><td><a href="msg:o">Registration Instructions &lt;35=o&gt;</a></td><td><a href="msg:p">Registration Instructions Response &lt;35=p&gt;</a></td></tr> <tr><td><a href="msg:AD">Trade Capture Report Request &lt;35=AD&gt;</a></td><td><a href="msg:AE">Trade Capture Report &lt;35=AE&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> <tr><td><a href="msg:BH">Confirmation Request &lt;35=BH&gt;</a></td><td><a href="msg:AK">Confirmation &lt;35=AK&gt;</a></td></tr> <tr><td><a href="msg:AV">Settlement Instruction Request &lt;35=AV&gt;</a></td><td><a href="msg:T">Settlement Instructions &lt;35=T&gt;</a></td></tr> <tr><td><a href="msg:AL">Position Maintenance Request &lt;35=AL&gt;</a></td><td><a href="msg:AM">Position Maintenance Report &lt;35=AM&gt;</a></td></tr> <tr><td><a href="msg:AN">Request for Positions &lt;35=AN&gt;</a></td><td><a href="msg:AO">Request for Positions Ack &lt;35=AO&gt;</a></td></tr> <tr><td><a href="msg:AX">Collateral Request &lt;35=AX&gt;</a></td><td><a href="msg:AY">Collateral Assignment &lt;35=AY&gt;</a></td></tr> <tr><td><a href="msg:AY">Collateral Assignment &lt;35=AY&gt;</a></td><td><a href="msg:AZ">Collateral Response &lt;35=AZ&gt;</a></td></tr> <tr><td><a href="msg:BB">Collateral Inquiry &lt;35=BB&gt;</a></td><td><a href="msg:BG">Collateral Inquiry Ack &lt;35=BG&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 Instruction Ack &lt;35=P&gt;</a></td><td><a href="tag:70">AllocID (70)</a></td></tr> <tr><td><a href="msg:AT">Allocation Report Ack &lt;35=AT&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:b">Mass Quote Acknowledgement &lt;35=b&gt;</a></td><td><a href="tag:117">QuoteID (117)</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:r">Order Mass Cancel Report &lt;35=r&gt;</a></td><td><a href="tag:37">OrderID (37)</a></td></tr> <tr><td><a href="msg:w">Security Types &lt;35=w&gt;</a></td><td><a href="tag:322">SecurityResponseID (322)</a></td></tr> <tr><td><a href="msg:y">Security List &lt;35=y&gt;</a></td><td><a href="tag:322">SecurityResponseID (322)</a></td></tr> <tr><td><a href="msg:AA">Derivative Security List &lt;35=AA&gt;</a></td><td><a href="tag:322">SecurityResponseID (322)</a></td></tr> <tr><td><a href="msg:AG">Quote Request Reject &lt;35=AG&gt;</a></td><td><a href="tag:131">QuoteReqID (131)</a></td></tr> <tr><td><a href="msg:AH">RFQ Request &lt;35=AH&gt;</a></td><td><a href="tag:644">RFQReqID (644)</a></td></tr> <tr><td><a href="msg:AI">Quote Status Report &lt;35=AI&gt;</a></td><td><a href="tag:117">QuoteID (117)</a></td></tr> <tr><td><a href="msg:p">Registration Instructions Response &lt;35=p&gt;</a></td><td><a href="tag:513">RegistID (513)</a></td></tr> <tr><td><a href="msg:AE">Trade Capture Report &lt;35=AE&gt;</a></td><td><a href="tag:571">TradeReportID (571)</a></td></tr> <tr><td><a href="msg:AU">Confirmation Ack &lt;35=AU&gt;</a></td><td><a href="tag:664">ConfirmID (664)</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> <tr><td><a href="msg:m">List Strike Price &lt;35=m&gt;</a></td><td><a href="tag:66">ListID (66)</a></td></tr> <tr><td><a href="msg:T">Settlement Instructions &lt;35=T&gt;</a></td><td><a href="tag:777">SettlInstMsgID (777)</a></td></tr> <tr><td><a href="msg:AQ">Trade Capture Report Request Ack &lt;35=AQ&gt;</a></td><td><a href="tag:568">TradeRequestID (568)</a></td></tr> <tr><td><a href="msg:AR">Trade Capture Report Ack &lt;35=AR&gt;</a></td><td><a href="tag:571">TradeReportID (571)</a></td></tr> <tr><td><a href="msg:AM">Position Maintenance Report &lt;35=AM&gt;</a></td><td><a href="tag:721">PosMaintRptID (721)</a></td></tr> <tr><td><a href="msg:AO">Request for Positions Ack &lt;35=AO&gt;</a></td><td><a href="tag:721">PosMaintRptID (721)</a></td></tr> <tr><td><a href="msg:AP">Position Report &lt;35=AP&gt;</a></td><td><a href="tag:721">PosMaintRptID (721)</a></td></tr> <tr><td><a href="msg:AW">Assignment Report &lt;35=AW&gt;</a></td><td><a href="tag:833">AsgnRptID (833)</a></td></tr> <tr><td><a href="msg:AZ">Collateral Response &lt;35=AZ&gt;</a></td><td><a href="tag:904">CollRespID (904)</a></td></tr> <tr><td><a href="msg:BG">Collateral Inquiry Ack &lt;35=BG&gt;</a></td><td><a href="tag:909">CollInquiryID (909)</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.This message is used to embed XML content within FIX as raw data. [XmlDataLen (212)](tag:212) specifies the length of the content to follow, and [XmlData (213)](tag:213) holds the data. Since these fields exist within the standard header, they can be used with any message type. This message is used when there isn't a more specific message type which is appropriate. The XML content may be FIXML (FIX encoded as XML), or any other XML document.This message is used to submit registration information for an order or for an allocation. This message can be submitted with [RegistTransType (514)](tag:514) = "new", "cancel" or "replace". When replacing or cancelling a registration, [RegistRefID (508)](tag:508) is required. When replacing information, the message must contain all the data for the replacement registration. The structure contains repeating fields for each of several joint registrants. The number of registration details instances is indicated in [RgstDtlsGrp](component:RgstDtlsGrp).This message is used to respond to a [Registration Instructions &lt;35=o&gt;](msg:o) request, which may be accepted or rejected. [RegistStatus (506)](tag:506) represents the current state of the instructions. The statuses are as follows, from highest to lowest precedence: <table><thead><tr><th>RegistStatus</th><th>Description</th></tr></thead> <tbody><tr><td>Accepted</td><td>Registration details are acceptable to the receiving broker, intermediary or fund manager. Assigned client and account Ids may be returned </td></tr> <tr><td>Rejected</td><td>Registration details have been rejected by the receiving broker, intermediary or fund manager</td></tr> <tr><td>Held</td><td>Registration details have been held by the receving broker, intermediary or fund manager. Assigned (possibly provisional) client and account IDs may be returned </td></tr> </tbody></table>This message requests the cancellation of the remaining quantity of a group of orders matching the criteria specified. It cannot be used to partially reduce the order quantity. This message is acknowledged using an [Order Mass Cancel Report &lt;35=r&gt;](msg:r), but each affected order will result in an [Execution Report &lt;35=8&gt;](msg:8) or an [Order Cancel Reject &lt;35=9&gt;](msg:9). Each request is assigned a [ClOrdID (11)](tag:11) and is treated as a separate entity. The [Order Mass Cancel Report &lt;35=r&gt;](msg:r) will contain the [ClOrdID (11)](tag:11) from the request. The [ClOrdID (11)](tag:11) must be unique amongst the [ClOrdID (11)](tag:11)s used across all message types. 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 cancellation criteria are specified using the [MassCancelRequestType (530)](tag:530) field: <table><thead><tr><th>Field Value</th><th>Description</th><th>Explanation</th></tr></thead> <tbody><tr><td>1</td><td>Cancel orders that match the <a href="component:Instrument">Instrument</a> component </td></tr> <tr><td>2</td><td>Cancel orders that match the <a href="component:UnderlyingInstrument">UnderlyingInstrument</a> component </td></tr> <tr><td>3</td><td>Cancel orders for a <a href="tag:460">Product (460)</a></td></tr> <tr><td>4</td><td>Cancel orders for a <a href="tag:461">CFICode (461)</a></td></tr> <tr><td>5</td><td>Cancel orders for a <a href="tag:167">SecurityType (167)</a></td></tr> <tr><td>6</td><td>Cancel orders for a <a href="tag:336">TradingSessionID (336)</a></td></tr> <tr><td>7</td><td>Cancel all orders</td></tr> </tbody></table>This message is used to acknowledge an [Order Mass Cancel Request &lt;35=q&gt;](msg:q), however each affected order produces a separate [Execution Report &lt;35=8&gt;](msg:8) or [Order Cancel Reject &lt;35=9&gt;](msg:9).Used to submit a cross order into a market. The cross order contains two order sides (a buy and a sell). The cross order is identified by its [CrossID (548)](tag:548). New Order - CrossThis message is used to modify a cross order previously submitted using [New Order Cross &lt;35=s&gt;](msg:s). See also [Order Cancel/Replace Request &lt;35=G&gt;](msg:G). The cross-order-specific fields [CrossType (549)](tag:549) and [CrossPrioritization (550)](tag:550) can not be modified using this message.This message is used to fully cancel the remaining quantity of a cross order previously placed using [Security List Request &lt;35=x&gt;](msg:x).This message is used to list the security types available from a counterparty or market. The request can include a specific [TradingSessionID (336)](tag:336) for which security types should be returned.This message lists the security types available from a counterparty or market. It is sent in response to a [Security Type Request &lt;35=v&gt;](msg:v) and should include the [SecurityReqID (320)](tag:320) that was included in the request.This message is used to request a list of securities that match the criteria provided. The response is a [Security List &lt;35=y&gt;](msg:y). [SubscriptionRequestType (263)](tag:263) can optionally be used to create a subscription.This message provides a list of securities. It may act as a response to [Security List Request &lt;35=x&gt;](msg:x) and contain securities that matches the criteria specified. It may also be unsolicited. For example, to list all available securities after logging on.This message is used to request a list of securities that match the criteria provided. It's similar to [Security List Request &lt;35=x&gt;](msg:x) but uses the [UnderlyingInstrument](component:UnderlyingInstrument) component instead of the [Instrument](component:Instrument) component. [SubscriptionRequestType (263)](tag:263) can optionally be used to create a subscription.