Orchestra2025-03-09T21:22:22.786191458ZOrchestra schemaSequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. "00023" = "23"). Examples: 723 in field 21 would be mapped int as |21=723|. -723 in field 12 would be mapped int as |12=-723| The following data types are based on int.int field representing the length in bytes. Value must be positive.int field representing the number of entries in a repeating group. Value must be positive.int field representing a message sequence number. Value must be positive.int field representing a field's tag number when using FIX "Tag=Value" syntax. Value must be positive and may not contain leading zeros.int field representing a day during a particular month (values 1 to 31).Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. "00023.23" = "23.23") and may contain or omit trailing zeros after the decimal point (e.g. "23.0" = "23.0000" = "23" = "23."). Note that fields which are derived from float may contain negative values unless explicitly specified otherwise.float field capable of storing either a whole number (no decimal places) of "shares" (securities denominated in whole units) or a decimal value containing decimal places for non-share quantity asset classes (securities denominated in fractional units).float field representing a price. Note the number of decimal places may vary. For certain asset classes prices may be negative values. For example, prices for options strategies can be negative under certain market conditions. Refer to Volume 7: FIX Usage by Product for asset classes that support negative price values.float field representing a price offset, which can be mathematically added to a "Price". Note the number of decimal places may vary and some fields such as LastForwardPoints may be negative.float field typically representing a Price times a Qtyfloat field representing a percentage (e.g. 0.05 represents 5% and 0.9525 represents 95.25%). Note the number of decimal places may vary.Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case-sensitive (i.e. m != M).char field containing one of two values: 'Y' = True/Yes 'N' = False/NoAlpha-numeric free format strings, can include any character or punctuation except the delimiter. All String fields are case-sensitive (i.e. test != Test).string field containing one or more space delimited single character values.string field representing a country using ISO 3166 Country code (2 character) values.string field representing a currency type using ISO 4217 Currency code (3 character) values.string field representing a market or exchange using ISO 10383 Market Identifier Code (MIC) values.string field representing month of a year. An optional day of the month can be appended or an optional week code. Valid formats: YYYYMM YYYYMMDD YYYYMMWW Valid values: YYYY = 0000-9999; MM = 01-12; DD = 01-31; WW = w1, w2, w3, w4, w5.string field representing Time/date combination represented in UTC (Universal Time Coordinated, also known as "GMT") in either YYYY-MM-DDTHH:MM:SS (whole seconds) or YYYY-MM-DDTHH:MM:SS.sss (milliseconds) format, colons, dash, and period required. Valid values: * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second) (without milliseconds). * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating milliseconds). Leap Seconds: Note that UTC includes corrections for leap seconds, which are inserted to account for slowing of the rotation of the earth. Leap second insertion is declared by the International Earth Rotation Service (IERS) and has, since 1972, only occurred on the night of Dec. 31 or Jun 30. The IERS considers March 31 and September 30 as secondary dates for leap second insertion, but has never utilized these dates. During a leap second insertion, a UTCTimestamp field may read "1998-12-31T23:59:59", "1998-12-31T23:59:60", "1999-01-01T00:00:00".string field representing Time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss (milliseconds) format, colons, and period required. This special-purpose field is paired with UTCDateOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: HH = 00-23, MM = 00-60 (60 only if UTC leap second), SS = 00-59. (without milliseconds) HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating milliseconds).string field representing Date represented in UTC (Universal Time Coordinated, also known as "GMT") in YYYYMMDD format. This special-purpose field is paired with UTCTimeOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31.string field representing a Date of Local Market (as opposed to UTC) in YYYYMMDD format. This is the "normal" date field used by the FIX Protocol. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31. Raw data with no format or content restrictions. Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH). Caution: the value of one of these fields may contain the delimiter (SOH) character. Note that the value specified for this field should be followed by the delimiter (SOH) character as all fields are terminated with an "SOH". Account mnemonic as agreed between broker and institution.Unique identifier of [Advertisement &lt;35=7&gt;](msg:7) message. Prior to FIX 4.1 this field was of type int.Reference identifier used with CANCEL and REPLACE transaction types. Prior to FIX 4.1 this field was of type int.Broker's side of advertised tradeIdentifies [Advertisement &lt;35=7&gt;](msg:7) message transaction typeCalculated average price of all fills on this order.Message sequence number of first record in range to be resentIdentifies beginning of new message and protocol version. ALWAYS FIRST FIELD IN MESSAGE. (Always unencrypted)Message length, in bytes, forward to the [CheckSum (10)](tag:10) field. ALWAYS SECOND FIELD IN MESSAGE. (Always unencrypted)Three byte, simple checksum (see [Appendix B: "CheckSum Calculation"](app_b.html) for description). ALWAYS LAST FIELD IN RECORD; i.e. serves, with the trailing <SOH>, as the end-of-record delimiter. Always defined as three characters. (Always unencrypted)Unique identifier for Order as assigned by institution. Uniqueness must be guaranteed within a single trading day. Firms which electronically submit multi-day orders should consider embedding a date within the [ClOrdID (11)](tag:11) field to assure uniqueness across days.Commission. Note if [CommType (13)](tag:13) is percentage, [Commission (12)](tag:12) of 5% should be represented as .05.[Commission (12)](tag:12) typeTotal number of shares filled.Identifies currency used for price. Absence of this field is interpreted as the default for the security. It is recommended that systems provide the currency value whenever possible. See [Appendix A: "Valid Currency Codes"](app_a.html) for information on obtaining valid values.Message sequence number of last record in range to be resent. If request is for a single record [BeginSeqNo (7)](tag:7) = [EndSeqNo (16)](tag:16). If request is for all messages subsequent to a particular message, [EndSeqNo (16)](tag:16) = "999999"Unique identifier of execution message as assigned by broker (will be 0 (zero) for [ExecTransType (20)](tag:20) ='3' (Status)). Uniqueness must be guaranteed within a single trading day or the life of a multi-day order. Firms which accept multi-day orders should consider embedding a date within the [ExecID (17)](tag:17) field to assure uniqueness across days. Prior to FIX 4.1 this field was of type int.Instructions for order handling on exchange trading floor. If more than one instruction is applicable to an order, this field can contain multiple instructions separated by space.Reference identifier used with Cancel and Correct transaction types. Prior to FIX 4.1 this field was of type int.Identifies transaction typeInstructions for order handling on Broker trading floorIdentifies class of alternative [SecurityID (48)](tag:48)Unique identifier of [Indication of Interest &lt;35=6&gt;](msg:6) message. Prior to FIX 4.1 this field was of type int.Indicates if, and on which other services, the indication has been advertised. Each character represents an additional service (e.g. if on Bridge and Autex, field = BA, if only on Autex, field = A)Relative quality of indicationReference identifier used with CANCEL and REPLACE, transaction types. Prior to FIX 4.1 this field was of type int.Number of shares in numeric or relative size.Identifies IOI message transaction typeBroker capacity in order executionMarket of execution for last fillPrice of this (last) fill. Field not required for [ExecTransType (20)](tag:20) ='3' (Status)Quantity of shares bought/sold on this (last) fill. Field not required for [ExecTransType (20)](tag:20) ='3' (Status)Identifies number of lines of text bodyInteger message sequence number.Defines message type. Always third field in message. Always unencrypted. The value is case-sensitive. "U" as the first character of the value (e.g. U1, U2) indicates that the message format is privately defined between the sender and receiver.New sequence numberUnique identifier for Order as assigned by broker. Uniqueness must be guaranteed within a single trading day. Firms which accept multi-day orders should consider embedding a date within the [OrderID (37)](tag:37) field to assure uniqueness across days.Number of shares orderedIdentifies 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 GMT)Indicates possible retransmission of message with this sequence numberPrice per shareReference message sequence numberSymbol of issue related to story. Can be repeated within message to identify multiple companies.Note that the name of this field is changing to 'OrderCapacity' as Rule80A is a very US market-specific term. Other world markets need to convey similar information, however, often a subset of the US values. See the [Rule80A (aka OrderCapacity) Usage by Market](app_g.html) appendix for market-specific usage of this field.CUSIP or other alternate security identifierAssigned value used to identify firm sending message.Assigned value used to identify specific message originator (desk, trader, etc.)Time of message transmission (always expressed in GMT)Number of sharesSide of orderTicker symbolAssigned value used to identify receiving firm.Assigned value used to identify specific individual or unit intended to receive message. 'ADMIN' reserved for administrative messages not intended for a specific user.Free format text string (Note: this field does not have a specified maximum length)Specifies how long the order remains in effect. Absence of this field is interpreted as DAY.Time of execution/order creation (expressed in GMT)Urgency flagIndicates expiration time of indication message (always expressed in GMT)Indicates order settlement period. Absence of this field is interpreted as Regular. Regular is defined as the default settlement period for the particular security on the exchange of execution.Specific date of trade settlement in YYYYMMDD format. Required when [SettlmntTyp (63)](tag:63) ='6' (Future) or [SettlmntTyp (63)](tag:63) ='8' (Sellers Option). (expressed in local time at place of settlement)Additional information about the security (e.g. preferred, warrants, etc.). Absence of this field indicates common.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 [ListNoOrds (68)](tag:68), 2 of 25, 3 of 25, . . . )Total number of orders within list (i.e. [ListSeqNo (67)](tag:67) of [ListNoOrds (68)](tag:68), e.g. 2 of 25, 3 of 25, . . . )Free format text message containing list handling and execution instructions.Unique identifier for allocation record. Prior to FIX 4.1 this field was of type int.Identifies allocation transaction typeReference identifier to be used with 'Replace' and 'Cancel' [AllocTransType (71)](tag:71) records. Prior to FIX 4.1 this field was of type int.Indicates number of orders to be combined for average pricing and allocation.Indicates number of decimal places to be used for average pricing. Absence of this field indicates that default precision arranged by the broker/institution is to be used.Indicates date of trade referenced in this record in YYYYMMDD format. Absence of this field indicates current day (expressed in local time at place of trade).Identifies executing / give-up broker. Standard NASD market-maker mnemonic is preferred.For options only. Valid Values: O = Open C = CloseNumber of [AllocAccount (79)](tag:79)/[AllocShares (80)](tag:80)/[ProcessCode (81)](tag:81) instances included in allocation record.Sub-account mnemonicNumber of shares to be allocated to specific sub-accountProcessing code for sub-account. Absence of this field in [AllocAccount (79)](tag:79) / [AllocShares (80)](tag:80) / [ProcessCode (81)](tag:81) instance indicates regular trade.Total number of reports within series.Sequence number of message within report series.Total number of shares canceled for this order.Number of delivery instruction fields to follow No longer used. Included here for reference to prior versions.Free format text field to indicate delivery instructions No longer used. Included here for reference to prior versions.Identifies status of allocation.Identifies reason for rejection.Electronic signatureLength of encrypted messageActual encrypted data streamBroker to receive trade creditNumber of bytes in [Signature (89)](tag:89) field.[Email &lt;35=C&gt;](msg:C) message type.Number of bytes in raw data field.Unformatted raw data, can include bitmaps, word processor documents, etc.Indicates that message may contain information that has been sent under another sequence number. Valid Values: Y=Possible resend N=Original transmissionMethod of encryption.Price per shareExecution destination as defined by institution when order is entered.Code to identify reason for cancel rejection.Code to identify reason for order rejection.Code to qualify [Indication of Interest &lt;35=6&gt;](msg:6) use.Identifier to aid in the management of multiple lists derived from a single, master list.Company name of security issuer (e.g. International Business Machines)Security description.[Heartbeat &lt;35=0&gt;](msg:0) interval (seconds)Firm identifier used in third party-transactions.Minimum quantity of an order to be executed.Maximum number of shares within an order to be shown on the exchange floor at any given time.Identifier included in [Test Request &lt;35=1&gt;](msg:1) message to be returned in resulting [Heartbeat &lt;35=0&gt;](msg:0)Identifies party of trade responsible for exchange reporting.Indicates whether the broker is to locate the stock in conjunction with a short sell order.Assigned value used to identify firm originating message if the message was delivered by a third party i.e. the third party firm identifier would be delivered in the [SenderCompID (49)](tag:49) field and the firm originating the message in this field.Assigned value used to identify specific message originator (i.e. trader) if the message was delivered by a third partyUnique identifier for quoteTotal amount due as the result of the transaction (e.g. for Buy order - principal + commission + fees) reported in currency of execution.Total amount due expressed in settlement currency (includes the effect of the forex transaction)Currency code of settlement denomination. See [Appendix A: "Valid Currency Codes"](app_a.html) for information on obtaining valid values.Indicates request for forex accommodation trade to be executed along with security transaction.Original time of message transmission (always expressed in 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 record groups to follow.Time/Date of order expiration (always expressed in GMT)Reason for execution rejection.Assigned value used to identify the firm targeted to receive the message if the message is delivered by a third party i.e. the third party firm identifier would be delivered in the [TargetCompID (56)](tag:56) field and the ultimate receiver firm ID in this field.Assigned value used to identify specific message recipient (i.e. trader) if the message is delivered by a third partyIndicates that IOI is the result of an existing agency order or a facilitation position resulting from an agency order, not from principal trading or order solicitation activity.Unique identifier for quote requestBid price/rateOffer price/rateQuantity of bidQuantity of offerNumber 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 originator'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 originator's location (i.e. geographic location and/or desk, trader) if the message was delivered by a third partySpecifies the number of repeating symbols specified.The subject of an [Email &lt;35=C&gt;](msg:C) messageThe headline of a [News &lt;35=B&gt;](msg:B) messageA URL (Uniform Resource Locator) link to additional information (i.e. http://en.wikipedia.org/wiki/Uniform_Resource_Locator)Describes the specific [Execution Report &lt;35=8&gt;](msg:8) (i.e. Pending Cancel) while [OrdStatus (39)](tag:39) will always identify the current order status (i.e. Partially Filled)Amount of shares open for further execution. If the [OrdStatus (39)](tag:39) is Canceled, DoneForTheDay, Expired, Calculated, or Rejected (in which case the order is no longer active) then [LeavesQty (151)](tag:151) could be 0, otherwise [LeavesQty (151)](tag:151) = [OrderQty (38)](tag:38) - [CumQty (14)](tag:14).Specifies the approximate order quantity desired in total monetary units vs. as a number of shares. The broker would be responsible for converting and calculating a share quantity ([OrderQty (38)](tag:38)) based upon this amount to be used for the actual order and subsequent messages.[AvgPx (6)](tag:6) for a specific [AllocAccount (79)](tag:79)[NetMoney (118)](tag:118) for a specific [AllocAccount (79)](tag:79)Foreign exchange rate used to compute [SettlCurrAmt (119)](tag:119) from [Currency (15)](tag:15) to [SettlCurrency (120)](tag:120)Specifies whether or not [SettlCurrFxRate (155)](tag:155) should be multiplied or divided. M=Multiply D=DivideNumber of Days of Interest for convertible bonds and fixed incomeAccrued Interest Rate for convertible bonds and fixed incomeAmount of Accrued Interest for convertible bonds and fixed incomeIndicates mode used for [Settlement Instructions &lt;35=T&gt;](msg:T)Free format text related to a specific [AllocAccount (79)](tag:79).Unique identifier for [Settlement Instructions &lt;35=T&gt;](msg:T) record.[Settlement Instructions &lt;35=T&gt;](msg:T) message transaction typeUnique identifier for an email thread (new and chain of replies)Indicates source of [Settlement Instructions &lt;35=T&gt;](msg:T)Identifies Settlement Depository or Country Code (ISITC spec)Indicates type of security (ISITC spec)Time the details within the message should take effect (always expressed in GMT)Identifies the Standing Instruction database usedName of the Standing Instruction database represented with [StandInstDbType (169)](tag:169) (i.e. the Global Custodian's name).Unique identifier used on the Standing Instructions database for the Standing Instructions to be referenced.Identifies type of settlement 0 = 'Versus. Payment': Deliver (if Sell) or Receive (if Buy) vs. (Against) Payment 1 = 'Free': Deliver (if Sell) or Receive (if Buy) FreeBroker's account code at the depository (i.e. CEDEL ID for CEDEL, FINS for DTC, or Euroclear ID for Euroclear) if [SettlLocation (166)](tag:166) is a depositoryBIC (Bank Identification Code-Swift managed) code of the broker involved (i.e. for multi-company brokerage firms)BIC (Bank Identification Code-Swift managed) code of the institution involved (i.e. for multi-company institution firms)Name of [SettlInstSource (165)](tag:165)'s local agent bank if [SettlLocation (166)](tag:166) is not a depositoryBIC (Bank Identification Code-Swift managed) code of the [SettlInstSource (165)](tag:165)'s local agent bank if [SettlLocation (166)](tag:166) is not a depository[SettlInstSource (165)](tag:165)'s account number at local agent bank if [SettlLocation (166)](tag:166) is not a depositoryName of [SettlInstSource (165)](tag:165)'s account at local agent bank if [SettlLocation (166)](tag:166) is not a depositoryName of contact at local agent bank for [SettlInstSource (165)](tag:165)'s account if [SettlLocation (166)](tag:166) is not a depositoryPhone number for contact at local agent bank if [SettlLocation (166)](tag:166) is not a depositoryName of [SettlInstSource (165)](tag:165)'s local agent bank if [SettlDeliveryType (172)](tag:172)=FreeBIC (Bank Identification Code - Swift managed) code of the [SettlInstSource (165)](tag:165)'s local agent bank if [SettlDeliveryType (172)](tag:172)=Free[SettlInstSource (165)](tag:165)'s account number at local agent bank if [SettlDeliveryType (172)](tag:172)=FreeName of [SettlInstSource (165)](tag:165)'s account at local agent bank if [SettlDeliveryType (172)](tag:172)=FreeName of contact at local agent bank for [SettlInstSource (165)](tag:165)'s account if [SettlDeliveryType (172)](tag:172)=FreePhone number for contact at local agent bank for [SettlInstSource (165)](tag:165)'s account if [SettlDeliveryType (172)](tag:172)=FreeBid F/X spot rate.Bid F/X forward points added to spot rate. May be a negative value.Offer F/X spot rate.Offer F/X forward points added to spot rate. May be a negative value.[OrderQty (38)](tag:38) of the future part of a F/X swap order.[FutSettDate (64)](tag:64) of the future part of a F/X swap order.F/X spot rate.F/X forward points added to [LastSpotRate (194)](tag:194). May be a negative value.Can be used to link two different [Allocation &lt;35=J&gt;](msg:J) messages (each with unique [AllocID (70)](tag:70)) together, i.e. for F/X 'Netting' or 'Swaps'. Should be unique.Identifies the type of [Allocation &lt;35=J&gt;](msg:J) linkage when [AllocLinkID (196)](tag:196) is used.Assigned by the party which accepts the order. Can be used to provide the [OrderID (37)](tag:37) used by an exchange or executing system.Number of repeating groups of IOIQualifiers.Month and Year of the maturity for [SecurityType (167)](tag:167)=FUT or [SecurityType (167)](tag:167)=OPT. Format: YYYYMM (i.e. 199903)Indicates whether an Option is for a put or call.Strike Price for an Option.Used for optionsUsed for options when delivering the order to an execution system/exchange to specify if the order is for a customer or the firm placing the order itself.Day of month used in conjunction with [MaturityMonthYear (200)](tag:200) to specify the maturity date for [SecurityType (167)](tag:167)=FUT or [SecurityType (167)](tag:167)=OPT.Can be used for [SecurityType (167)](tag:167)=OPT to identify a particular security. Valid values vary by [SecurityExchange (207)](tag:207): For Exchange: MONEP (Paris) L = Long (a.k.a. 'American') S = Short (a.k.a. 'European') For Exchanges: DTB (Frankfurt), HKSE (Hong Kong), and SOFFEX (Zurich) 0-9 = single digit 'version' number assigned by exchange following capital adjustments (0=current, 1=prior, 2=prior to 1, etc).Market used to help identify a security.Indicates whether or not details should be communicated to [BrokerOfCredit (92)](tag:92) (i.e. step-in broker).Indicates how the receiver (i.e. third party) of [Allocation &lt;35=J&gt;](msg:J) message should handle/process the account details.Maximum number of shares within an order to be shown to other customers (i.e. sent via an IOI).Price difference for a pegged order.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".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. Reject orders 6. 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). [OrdStatus (39)](tag:39) is used to convey the current state of the order. The order statuses are as follows: <table><thead><tr><th>OrdStatus</th><th>Description</th></tr></thead> <tbody><tr><td>New</td><td>Outstanding order with no executions</td></tr> <tr><td>Partially Filled</td><td>Outstanding order with executions and remaining quantity</td></tr> <tr><td>Filled</td><td>Order completely filled, no remaining quantity</td></tr> <tr><td>Done for Day</td><td>Order not filled, or partially filled; no further executions possible for the trading day</td></tr> <tr><td>Canceled</td><td>Canceled order with or without executions</td></tr> <tr><td>Replaced</td><td>Replaced order with or without executions</td></tr> <tr><td>Pending Cancel/Replace</td><td>Order with cancel request pending, used to confirm receipt of cancel or replace request. Does not indicate that the order has been canceled or replaced</td></tr> <tr><td>Stopped</td><td>Order has been stopped at the exchange. Used when guaranteeing or protecting a price and quantity</td></tr> <tr><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>Suspended</td><td>Order has been placed in suspended state at the request of the client</td></tr> <tr><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>Expired</td><td>Order has been canceled in broker's system due to time-in-force instructions</td></tr> <tr><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> </tbody></table> The [CumQty (14)](tag:14) and [AvgPx (6)](tag:6) fields should be calculated to reflect the fills on all versions of an order. For example, if partially filled order A were replaced by order B, the [CumQty (14)](tag:14) and [AvgPx (6)](tag:6) on order B’s fills should represent the fills on order A plus those on order B. The field [ClOrdID (11)](tag:11) is provided for institutions to affix an identification number to an order to coincide with internal systems. The OrderId field is populated with the broker-generated order number.This message is sent in response to the following messages if they cannot be honored: - [Order Cancel Request &lt;35=F&gt;](msg:F) - [Order Cancel/Replace Request &lt;35=G&gt;](msg:G) Requests to change price or decrease quantity are fulfilled only when an outstanding quantity exists. Filled orders cannot be changed, i.e to reduce the quantity or change the price. However, increasing the order quantity on a currently filled order may be supported. This message should provide the [ClOrdID (11)](tag:11) which was specified in the request, and the [OrigClOrdID (41)](tag:41) should be that of the last accepted order, except if the rejection is because the ID is unknown.This message is used to establish a FIX connection. The Logon message must be the first message sent by the application attempting to initiating a FIX session. Upon receipt of a Logon message, the session acceptor will authenticate the requester and respond with a Logon message as acknowledgment that the connection request has been accepted. The acknowledgment Logon can be used by the initiator for validation purposes. The session acceptor must be prepared to immediately begin processing messages after receipt of the Logon. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation Logon, however it is recommended that normal message delivery wait until after the return Logon is received. The confirmation Logon can be used for encryption key negotiation. If a session key is deemed to be weak, a stronger session key can be suggested by returning a Logon message with a new key. This is only valid for encryption protocols that allow for key negotiation. See the FIX website's Application notes for more information on a method for encryption and key passing. The [HeartBtInt (108)](tag:108) field is used to declare the interval for generating heartbeats. See [Heartbeat &lt;35=0&gt;](msg:0).This message is a general free-format message for describing news items. It contains flags to identify the news item's urgency and to allow sorting by subject company. This message may be sent by any type of institution.This message is similar in format and purpose to the [News &lt;35=B&gt;](msg:B) message. However, it is intended for private use between two parties.This message is used to submit orders for execution, for securities, forex, collective investment vehicles (CIV), and more. Orders can be submitted with special handling instructions and execution instructions. Handling instructions refer to how the broker should handle the order on its trading floor. See [HandlInst (21)](tag:21). Execution instructions contain explicit directions as to how the order should be executed. See [ExecInst (18)](tag:18). Orders received with [PossResend (97)](tag:97) set in the header should be validated by [ClOrdID (11)](tag:11). Implementations should also consider checking order parameters (side, symbol, quantity, etc.) to determine if the order had been previously submitted. [PossResend (97)](tag:97) previously received should be acknowledged back to the client using an [Execution Report &lt;35=8&gt;](msg:8). [PossResend (97)](tag:97) not previously received should be processed as a new order. The given [TransactTime (60)](tag:60) should allow the receiver of the order to apply business rules to determine if the order is potentially stale, e.g. in the event that there have been communication problems. To support forex accommodation trades, two fields, [ForexReq (121)](tag:121) and [SettlCurrency (120)](tag:120), are included in the message. To request a broker to execute a forex trade in conjunction with the securities trade, the institution would set the [ForexReq (121)](tag:121) = Y and [SettlCurrency (120)](tag:120) = "intended settlement currency". The broker would then execute a forex trade from the execution currency to the settlement currency and report the results via the execution message in the [SettlCurrAmt (119)](tag:119) and [SettlCurrency (120)](tag:120) fields. Orders involving or requiring pre-trade allocation consist of the following steps: - Buy-side sends a New Order Single specifying one or more [AllocAccount (79)](tag:79) and [AllocShares (80)](tag:80) values within the repeating group designated by [NoAllocs (78)](tag:78) - Sell-side sends [Execution Report &lt;35=8&gt;](msg:8) messages for the new and resulting fills. - Post-trade allocation messaging takes place To take an [Indication of Interest &lt;35=6&gt;](msg:6) or [Quote &lt;35=S&gt;](msg:S) from an ECN or exchange and not display the order on the book, the New Order Single message should contain [TimeInForce (59)](tag:59) = "ImmediateOrCancel" and [OrdType (40)](tag:40) = "Previously Indicated" or "Previously Quoted".This message is used to submit lists of related orders to a broker for execution. The New Order List is intended for use in staging lists to be executed by the broker. If the institution wishes to work a list using the broker's execution services, the orders should be submitted as individual [New Order Single &lt;35=D&gt;](msg:D)s. After staging, the list can be operated on in the following ways: - Execute: The broker can be instructed to release the list for execution using a [List Execute &lt;35=L&gt;](msg:L) message. - Cancel: After the list has been staged with the broker, it can be canceled using a [List Cancel Request &lt;35=K&gt;](msg:K). If the list has not yet been submitted for execution, the [List Cancel Request &lt;35=K&gt;](msg:K) message will instruct the broker not to execute it. If the list is being executed, the [List Cancel Request &lt;35=K&gt;](msg:K) 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 an [Order Cancel Request &lt;35=F&gt;](msg:F). - Status: A status of the list can be requested via the submission of the [List Status Request &lt;35=M&gt;](msg:M) message. The broker will respond with one or more [List Status &lt;35=N&gt;](msg:N) messages which will report executed quantity, canceled quantity and average price for each order in the list. - Replace: Individual orders within the list can be replaced using an [Order Cancel/Replace Request &lt;35=G&gt;](msg:G). Executions against orders within the list will not normally be reported as they occur. If this feature is desired the institution and broker should arrange for this reporting as a custom feature using the Execution message. Executions against the list will be reported within the [List Status &lt;35=N&gt;](msg:N) message.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. 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. Only a limited number of fields can be changed using this message. All other fields should be retransmitted as sent in the original order. These fields are: - [ExecInst (18)](tag:18) - [OrderQty (38)](tag:38) - [OrdType (40)](tag:40) - [Price (44)](tag:44) - [HandlInst (21)](tag:21) - [TimeInForce (59)](tag:59) - [ExpireTime (126)](tag:126) - [MinQty (110)](tag:110) - [MaxFloor (111)](tag:111) 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 is used to instruct a broker on how to allocate executed shares to sub-accounts. It can also be used as a confirmation message through which third parties can communicate execution and settlement instructions between trading partners. An Allocation message can be submitted with type "new", "cancel" or "replace". The [AllocTransType (71)](tag:71) field indicates the purpose of the message. When submitting "replace" or "cancel", the [RefAllocID (72)](tag:72) field is required. Replacement Allocation messages must contain all data for the replacement allocation. The allocation record contains repeating fields for each order, sub-account and individual execution. The total shares allocated must equal the [Shares (53)](tag:53) value which must equal the total executed quantity of the original order. If present, the total shares in the execution section must also be equal to this value. The number of sub-account instances is indicated in [NoAllocs (78)](tag:78). Multiple orders can be combined for allocation by identifying the number of orders in the [NoOrders (73)](tag:73) field and each individual order in the [OrderID (37)](tag:37) fields. Combined orders must have the same ticker, trade date, settlement date and side.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. Each message will include a maximum of 50 orders. If the list contains more than 50 orders, multiple status messages will be required.This message is used to acknowledge and provide the status for an [Allocation &lt;35=J&gt;](msg:J) message. Multiple messages may be generated for a single allocation to acknowledge, then separately accept or reject the allocation.This message is used when an execution is rejected. The decision to reject ("DK") an execution lies with the institution. It is not a requirement to enforce all the reasons given in [DKReason (127)](tag:127).This message is used to request a [Quote &lt;35=S&gt;](msg:S), an indication of the current price of an instrument. It can be used to request quotes for one or more products. This message is commonly referred to as an RFQ, a "request for quote". In some markets, it's common to request quotes from brokers prior to placing an order. Securities quotes can be requested as either market quotes or for a specific quantity and side. If [OrderQty (38)](tag:38) and [Side (54)](tag:54) are absent, a market-style quote (bid x offer, size x size) will be returned. Forex quotes can be requested as indicative or at a specific quantity level. If an indicative quote is requested ([OrderQty (38)](tag:38) and [Side (54)](tag:54) are absent), the broker has discretion to quote at either a specific trade level and side or to provide an indicative quote at the mid-point of the spread. The broker can also choose to respond to an indicative quote by sending multiple [Quote &lt;35=S&gt;](msg:S) messages specifying various levels and sides.This message contains quotes for a single instrument, an indication of the current price. It's used in response to a [Quote Request &lt;35=R&gt;](msg:R) and may also be unsolicited. If responding to a [Quote Request &lt;35=R&gt;](msg:R), this message must include the [QuoteReqID (131)](tag:131) from the request. Unsolicited quotes will omit that field. Orders can be created from quotes. Quoted orders include the [QuoteID (117)](tag:117) and [OrdType (40)](tag:40) = "previously quoted".This message provides instructions for trade settlement. [SettlInstSource (165)](tag:165) indicates if the settlement instructions belong to a broker or institution. It's been designed so that it can be sent between different types of institutions. This message can be used in one of two modes ([SettlInstMode (160)](tag:160)): - To provide "standing instructions" for the settlement of trades occurring in the future, messages should include some combination of: - [AllocAccount (79)](tag:79) - [LastMkt (30)](tag:30) - [Side (54)](tag:54) - [SecurityType (167)](tag:167) - [SettlLocation (166)](tag:166) - [SettlDeliveryType (172)](tag:172) - [EffectiveTime (168)](tag:168) - To provide settlement instructions for a specific Allocation Account either as overriding or standing instructions to support matching. The following key should be used to tie the settlement instructions to the corresponding [Allocation &lt;35=J&gt;](msg:J) message: ([TradeDate (75)](tag:75) + [AllocID (70)](tag:70) + [AllocAccount (79)](tag:79)) The Settlement Instruction detail can be either explicitly specified (via SecuritySettl* and CashSettl* fields) or can exist on within an independent standing instructions database and can be referenced via the [StandInstDbType (169)](tag:169), [StandInstDbName (170)](tag:170), and [StandInstDbID (171)](tag:171) fields.