FIX Tag Reference: Professional Guide to FIX 4.4 Protocol Tags

Home / Financial Markets Infrastructure, FIX Standard / FIX Tag Reference: Professional Guide to FIX 4.4 Protocol Tags

FIX Tag Reference: Professional Guide to FIX 4.4 Protocol Tags

FIX 4.4 Standard FIX Tags

Tag 1: Account
Tag 1 (Account) identifies the client or institutional account associated with an order, execution, or allocation. It is used for commission calculation, regulatory reporting, and trade reconciliation. While optional in some messages, it is often required by brokers and regulators to attribute trades correctly. The Account field may represent a fund, desk, or strategy and must remain consistent across related messages. It supports post-trade processing and is critical in environments with multiple sub-accounts or managed portfolios. In FIX 4.4, it ensures transparency and auditability in transaction reporting.

Tag 2: AdvId
Tag 2 (AdvId) is a unique identifier assigned by the sender to an Advertisement message (MsgType 7). It enables tracking and referencing of specific market interest announcements for a security. This ID remains constant when the advertisement is modified or canceled, ensuring continuity. It allows the recipient to correlate incoming messages with prior activity and manage market interest effectively. AdvId is essential for maintaining accurate records in block trading or large-position marketing, where non-binding indications are exchanged before formal orders. It supports message linkage and lifecycle management in advertising workflows.

Tag 3: AdvRefID
Tag 3 (AdvRefID) references a previously sent advertisement when canceling or replacing it. It links new Advertisement messages to prior ones, enabling proper message sequencing and state management. For example, when canceling an existing ad, the AdvRefID field contains the AdvId of the original message. This ensures the receiving system can locate and update the correct advertisement. It enhances reliability in communication and prevents confusion between unrelated ads. AdvRefID is crucial for maintaining accurate market interest tracking and supports clean lifecycle management of advertising messages in FIX 4.4.

Tag 4: AdvSide
Tag 4 (AdvSide) indicates the trading side in an Advertisement message: Buy (B), Sell (S), or Sell Short (T). It conveys the sender’s market intent for a specific security. This field helps recipients assess supply and demand imbalances and respond appropriately. While advertisements are non-binding, they provide valuable market color, especially for large or illiquid securities. AdvSide is mandatory in Advertisement messages and must be clearly specified. It supports transparency in pre-trade communication and is used in conjunction with IOI and indication-of-interest workflows to signal interest without commitment.

Tag 5: AdvTransType
Tag 5 (AdvTransType) specifies the type of transaction being performed on an advertisement: New (N), Cancel (C), or Replace (R). It controls how the receiving system should process the message. A “New” creates a fresh advertisement, “Cancel” removes an existing one referenced by AdvRefID, and “Replace” updates prior details. This tag ensures correct handling and prevents misinterpretation. It is essential for maintaining accurate market interest records and supports dynamic updates in advertising workflows. AdvTransType enables reliable, state-aware messaging in non-binding pre-trade communication.

Tag 6: AvgPx
Tag 6 (AvgPx) represents the average execution price of an order, calculated as the total value of fills divided by the cumulative quantity. It appears in Execution Reports (MsgType 8) and Allocation messages. AvgPx is updated incrementally with each partial fill and becomes final upon full execution. It is critical for performance measurement, commission calculations, and accounting. The value must reflect all executions under the same OrderID and ClOrdID. In FIX 4.4, AvgPx is typically rounded to a precision defined by AvgPxPrecision (Tag 74) and is used across trading, risk, and settlement systems.

Tag 7: BeginSeqNo
Tag 7 (BeginSeqNo) is used in Resend Request messages (MsgType 2) to specify the starting message sequence number for retransmission. When a receiver detects a gap in MsgSeqNum (Tag 34), it sends a Resend Request with BeginSeqNo and EndSeqNo (Tag 16) to recover missing messages. BeginSeqNo ensures reliable message delivery and session integrity. It is a core mechanism for handling network interruptions or system failures. The sender must retransmit all messages in the requested range. This tag is essential for maintaining accurate, ordered communication in high-frequency trading environments.

Tag 8: BeginString
Tag 8 (BeginString) identifies the FIX protocol version in use. In FIX 4.4, this field is set to “FIX.4.4” and appears in every message. It is the first field transmitted and ensures both parties use compatible syntax and message formats. BeginString is critical for session initialization and routing. It allows gateways and message parsers to validate and process messages correctly. Without a matching BeginString, connections may be rejected. This tag forms the foundation of interoperability between counterparties using different FIX versions or custom dialects.

Tag 9: BodyLength
Tag 9 (BodyLength) specifies the number of bytes from the beginning of the message (after BeginString) up to, but not including, the CheckSum field. It is used by FIX engines to parse messages and detect truncation or corruption. While typically calculated automatically, it must be accurate for proper message processing. BodyLength includes all fields except the CheckSum and is essential for low-level message framing. It supports reliable transmission over TCP and ensures data integrity during parsing. Though rarely inspected manually, it plays a critical role in message structure.

Tag 10: CheckSum
Tag 10 (CheckSum) is a three-digit numeric value (000–255) representing the modulo 256 sum of all bytes in the message, excluding the CheckSum field itself. It is the final field in every FIX message and is used to verify transmission integrity. A mismatch indicates corruption, leading to message rejection. CheckSum is calculated automatically by FIX engines and ensures data accuracy over networks. It is a simple but effective error-detection mechanism. In FIX 4.4, it is mandatory and critical for maintaining message reliability in high-speed trading environments.

Tag 11: ClOrdID
Tag 11 (ClOrdID) is the unique identifier assigned by the client (e.g., buy-side firm) to an order. It must be unique within a session and is used to reference new orders, modifications, and cancellations. The ClOrdID is echoed in Execution Reports and other responses, enabling order tracking and reconciliation. When modifying an order, the new request uses the same ClOrdID as the original. It is a cornerstone of order lifecycle management. Brokers use ClOrdID to match client requests with internal OrderID (Tag 37).

Tag 12: Commission
Tag 12 (Commission) specifies the monetary amount of commission charged for an execution. It can be positive (cost) or negative (rebate) and is typically included in Execution Reports and Allocation messages. The currency is defined by Tag 15 (Currency). Commission may be based on volume, value, or flat fees. It is used for billing, performance analysis, and regulatory reporting. While optional, it is often required in institutional trading. The value should reflect the actual fee charged by the broker or exchange for execution services.

Tag 13: CommType
Tag 13 (CommType) defines the method used to calculate commission: per share (1), percentage (2), absolute (3), or other. It is used in conjunction with Commission (Tag 12) to clarify the fee structure. For example, a commission of $0.01 per share would use CommType=1. This field enhances transparency in cost reporting and supports accurate billing. It is particularly important in multi-broker environments where fee models vary. CommType ensures both parties interpret the commission correctly for accounting and compliance.

Tag 14: CumQty
Tag 14 (CumQty) represents the total number of shares or contracts executed for an order to date. It is updated in each Execution Report and reflects the sum of all LastQty (Tag 32) values for that order. CumQty is essential for tracking order progress and determining fill status. When CumQty equals OrderQty (Tag 38), the order is fully filled. It is used in algorithmic trading, risk systems, and execution monitoring. CumQty must be non-decreasing and is a key indicator of order completion in FIX 4.4 workflows.

Tag 15: Currency
Tag 15 (Currency) specifies the currency of a price, commission, or amount using the ISO 4217 standard (e.g., USD, EUR, JPY). It is used in pricing, settlement, and fee fields to avoid ambiguity. Currency is critical in cross-border transactions and multi-currency portfolios. It ensures correct valuation and prevents misinterpretation of monetary values. The field appears in orders, executions, and allocations. In FIX 4.4, it supports global trading and is essential for accurate financial reporting and compliance with international standards.

Tag 16: EndSeqNo
Tag 16 (EndSeqNo) is used in Resend Request messages to define the ending message sequence number for a resend range. Together with BeginSeqNo (Tag 7), it specifies the window of messages to be retransmitted. For example, requesting messages 100 to 150 ensures recovery of any missing data. EndSeqNo supports reliable message delivery and session recovery after disruptions. It is a core component of FIX’s guaranteed delivery mechanism. The sender must retransmit all messages in the range, even if they were previously sent.

Tag 17: ExecID
Tag 17 (ExecID) is a unique identifier assigned by the sell-side (broker or exchange) to each execution event. It distinguishes between new fills, corrections, and cancellations. Every Execution Report contains a unique ExecID, even for partial fills of the same order. It enables precise tracking of trade events and prevents duplicate processing. ExecID is critical for audit trails, reconciliation, and execution quality analysis. It is never reused and is essential for maintaining accurate trade records in high-volume environments.

Tag 18: ExecInst
Tag 18 (ExecInst) specifies special handling instructions for order execution, such as “Work” (I), “Not held” (N), or “Call first” (C). These instructions guide the broker on execution strategy and urgency. Multiple instructions can be combined (e.g., “NI”). ExecInst influences algorithmic behavior and execution timing. It is particularly relevant for large or sensitive orders. While not binding, it provides valuable guidance. In FIX 4.4, it supports flexible execution policies and helps align broker actions with client intent.

Tag 19: ExecRefID
Tag 19 (ExecRefID) references the ExecID (Tag 17) of a prior execution, typically used in Corrected (ExecType=I) or Cancelled (ExecType=4) Execution Reports. It links the current message to the original fill, enabling accurate audit trails and trade reconciliation. For example, if a fill is reported with an incorrect price, the correction message includes ExecRefID pointing to the erroneous execution. This ensures clarity in trade history and supports regulatory reporting. ExecRefID is essential for maintaining data integrity in execution workflows.

Tag 20: ExecTransType (replaced)
Tag 20 (ExecTransType) was used to indicate the type of execution transaction: New (0), Cancel (1), Correct (2), or Status (3). However, it has been replaced in FIX 4.4 by the more comprehensive ExecType (Tag 150), which provides finer granularity (e.g., Trade, Trade Correct, Trade Cancel). ExecTransType is deprecated and should not be used in new implementations. Continued use may lead to interoperability issues. FIX 4.4 encourages migration to ExecType for accurate execution event classification.

Tag 21: HandlInst
Tag 21 (HandlInst) specifies how the broker should handle the order: Auto-execute (1), Manual (2), or Auto-select (3). It informs the execution desk whether the order can be routed directly to an automated system or requires human review. This impacts speed, cost, and execution quality. For example, “Manual” may be used for large block trades requiring negotiation. HandlInst helps align execution method with order characteristics and is particularly relevant in hybrid trading environments combining algorithmic and human-driven execution.

Tag 22: SecurityIDSource
Tag 22 (SecurityIDSource) identifies the source or namespace of the SecurityID (Tag 48), such as CUSIP (1), SEDOL (2), ISIN (4), or ticker (5). It ensures unambiguous security identification, especially when symbols overlap across markets. For example, “AAPL” could refer to different instruments in different countries. SecurityIDSource prevents misidentification and supports global trading. It is used with Symbol (Tag 55) and SecurityID to provide a complete security key. This tag is essential for accurate routing and compliance.

Tag 23: IOIID
Tag 23 (IOIID) is the unique identifier assigned by the sender to an Indication of Interest (IOI) message. It allows recipients to reference the IOI in follow-up communications or responses. This ID remains constant across modifications or cancellations. IOIID supports message threading and ensures continuity in pre-trade dialogue. It is used in IOI messages (MsgType 6) and is critical for tracking unsolicited market interest, particularly in block trading or dark pool environments where formal orders are not yet placed.

Tag 24: IOIOthSvc (no longer used)
Tag 24 (IOIOthSvc) was intended to indicate other services related to an IOI, such as settlement or financing options. However, it is no longer used in FIX 4.4 and has been deprecated. Modern implementations do not include this field. Its functionality was never widely adopted, and it has been removed from active use. Applications should ignore or omit this tag to ensure compliance with current standards and avoid potential parsing errors in receiving systems.

Tag 25: IOIQltyInd
Tag 25 (IOIQltyInd) indicates the firmness of an IOI: Firm (F), Medium (M), or Soft (S). It helps recipients assess the likelihood of execution if they act on the indication. A “Firm” IOI suggests the sender is ready to trade at the indicated price and size, while “Soft” means the quantity is negotiable. This field provides context in non-binding communications and supports informed decision-making. It is particularly useful in over-the-counter or block trading scenarios.

Tag 26: IOIRefID
Tag 26 (IOIRefID) references a prior IOI message, typically used when responding to, canceling, or replacing an existing indication. It contains the IOIID (Tag 23) of the original message. This enables message threading and ensures accurate lifecycle management. For example, a “Cancel” IOI must include IOIRefID to specify which IOI is being withdrawn. IOIRefID enhances reliability in pre-trade communication and prevents confusion between unrelated indications.

Tag 27: IOIQty
Tag 27 (IOIQty) specifies the quantity of shares in an IOI. It can be a specific number or a reference like “Large” (L), “Medium” (M), or “Small” (S). This field conveys the scale of interest without committing to a trade. It is used in IOI messages to signal buying or selling intent. While not binding, it helps counterparties assess market depth and respond appropriately. IOIQty supports pre-trade transparency in illiquid or large-size securities.

Tag 28: IOITransType
Tag 28 (IOITransType) specifies the type of IOI transaction: New (N), Cancel (C), or Replace (R). It controls how the receiving system should process the message. A “New” creates a fresh IOI, “Cancel” removes a prior one referenced by IOIRefID, and “Replace” updates previous details. This tag ensures correct handling and prevents misinterpretation. It is essential for managing dynamic market interest and supports reliable, state-aware messaging in pre-trade workflows.

Tag 29: LastCapacity
Tag 29 (LastCapacity) indicates the role of the last trader in an execution: Agency (1), Principal (2), or Riskless Principal (3). It is critical for regulatory reporting (e.g., MiFID II, TRACE) and affects commission and markup disclosures. Agency means the broker acted as an agent, Principal means they used their own capital, and Riskless Principal involves offsetting trades. This field ensures transparency in execution quality and supports compliance with best execution obligations.

Tag 30: LastMkt
Tag 30 (LastMkt) identifies the market (exchange or ECN) where the last trade occurred, using a MIC code (e.g., XNYS for NYSE). It provides transparency into execution venue and is used in execution quality reporting. LastMkt helps assess liquidity, price improvement, and routing efficiency. It is particularly relevant for best execution analysis and regulatory filings. The field ensures accurate attribution of trade location and supports post-trade analytics and compliance.

Tag 31: LastPx
Tag 31 (LastPx) is the price at which the most recent portion of an order was executed. It appears in Execution Reports and fills and is used to calculate average price and performance metrics. LastPx is essential for tracking execution quality and price improvement. It must be reported accurately and consistently. Combined with LastQty (Tag 32), it provides granular detail on each fill event within a larger order, supporting reconciliation and audit.

Tag 32: LastQty
Tag 32 (LastQty) specifies the number of shares or contracts in the most recent fill. It is reported in Execution Reports and reflects a single execution event. When an order is partially filled, multiple LastQty values accumulate into CumQty (Tag 14). LastQty is critical for tracking fill progression and detecting execution patterns. It must be positive and is used in conjunction with LastPx (Tag 31) to compute trade value and average price.

Tag 33: NoLinesOfText
Tag 33 (NoLinesOfText) indicates the number of text lines in a News (MsgType B) or Email (MsgType C) message. It precedes a repeating group of Text (Tag 58) fields and defines how many times the group repeats. This tag enables structured transmission of multi-line messages. It ensures the receiver knows how many text segments to expect. NoLinesOfText supports rich communication in administrative and market news messages.

Tag 34: MsgSeqNum
Tag 34 (MsgSeqNum) is a sequential number assigned by the sender to each message, starting at 1 and incrementing with each transmission. It ensures message order and detects gaps or duplicates. The receiver validates sequence numbers and requests resends if gaps are detected. MsgSeqNum is reset at the start of each session. It is a cornerstone of FIX reliability and is critical for maintaining message integrity in high-speed trading environments.

Tag 35: MsgType
Tag 35 (MsgType) defines the type of FIX message being sent, such as “D” for New Order, “8” for Execution Report, or “5” for Logout. It is one of the most critical tags, as it determines message structure and processing logic. MsgType enables routing, parsing, and validation. It is included in every message and must be correctly set. Without it, systems cannot interpret the message content, making it fundamental to FIX communication.

Tag 36: NewSeqNo
Tag 36 (NewSeqNo) is used in Sequence Reset messages to set a new message sequence number. It allows manual correction of sequence gaps after system recovery. For example, if a sender restarts, it may send a Sequence Reset with NewSeqNo=1 to reset the count. The receiver must accept this only if PossDupFlag (Tag 43) is set. NewSeqNo supports session recovery and ensures continuity in message sequencing after disruptions.

Tag 37: OrderID
Tag 37 (OrderID) is a unique identifier assigned by the broker or exchange to an order upon receipt. It is used in Execution Reports and replaces ClOrdID (Tag 11) for tracking the order on the sell-side. OrderID is immutable and remains constant throughout the order’s lifecycle. It enables the client to correlate executions with the broker’s internal system. OrderID is essential for accurate trade reporting and reconciliation.

Tag 38: OrderQty
Tag 38 (OrderQty) specifies the number of shares or contracts in an order. It is a core field in order submission and execution messages. OrderQty must be positive and is used to determine order size and margin requirements. Changes to OrderQty require a new ClOrdID (Tag 11) via an order modification. It is used in conjunction with Side (Tag 54) and Symbol (Tag 55) to define the trade intent.

Tag 39: OrdStatus
Tag 39 (OrdStatus) indicates the current status of an order: New (0), Partially filled (1), Filled (2), Done (3), Canceled (4), etc. It is returned in Execution Reports and is vital for order monitoring and workflow. OrdStatus helps clients track order progress and respond to changes. It must be updated accurately with each execution event. This field supports real-time decision-making and risk management in trading operations.

Tag 40: OrdType
Tag 40 (OrdType) specifies the order type: Market (1), Limit (2), Stop (3), Stop Limit (4), etc. It defines the execution logic and price conditions. For example, a Limit order requires a Price (Tag 44), while a Market order does not. OrdType influences routing, timing, and risk. It is a key input for algorithmic strategies and must be correctly interpreted by the execution system.

Tag 41: OrigClOrdID
Tag 41 (OrigClOrdID) references the original ClOrdID when modifying or canceling an order. It links the new request to the prior order, enabling the broker to locate and update the correct order. This field is mandatory in Order Cancel/Replace and Cancel Request messages. It prevents errors in order management and supports accurate lifecycle tracking. OrigClOrdID ensures message linkage and consistency in order processing.

Tag 42: OrigTime
Tag 42 (OrigTime) specifies the timestamp of the original order request, typically used in modification or cancellation messages. It helps prevent processing stale orders by confirming the timing context of the original ClOrdID. When a cancel or replace request is sent, including OrigTime ensures the broker applies the change to the correct instance, especially in high-frequency environments where multiple versions may exist. It enhances message sequencing accuracy and mitigates race conditions. While optional, OrigTime improves reliability in order lifecycle management and supports robust trade control.

Tag 43: PossDupFlag
Tag 43 (PossDupFlag) indicates whether a message may be a duplicate (Y) or is original (N). It is set to ‘Y’ when resending messages after a system failure or session reset. This flag alerts the receiver to check for duplicates using ClOrdID and MsgSeqNum. It is critical during recovery scenarios to avoid double execution. PossDupFlag enables safe message retransmission without unintended side effects. It works with RefSeqNum and OrigTime to ensure message integrity and is a key component of FIX’s reliability mechanism.

Tag 44: Price
Tag 44 (Price) specifies the limit price for a Limit (2) or Stop-Limit (4) order. It defines the maximum price a buyer is willing to pay or the minimum a seller will accept. Price is mandatory for these order types and must be a positive decimal value. It is used in routing, matching, and execution logic. Price is typically expressed in the currency defined by Tag 15. In FIX 4.4, it supports precise price representation and is essential for price-controlled execution strategies.

Tag 45: RefSeqNum
Tag 45 (RefSeqNum) references the MsgSeqNum (Tag 34) of a previously sent message, typically used in administrative responses like Reject (MsgType 3) or Business Message Reject (MsgType j). It enables the receiver to correlate the response with the original message. This is especially useful when rejecting a message that cannot be fully parsed. RefSeqNum supports debugging and error tracking. It ensures clarity in message flow and helps identify the source of processing issues in the communication stream.

Tag 46: RelatdSym (no longer used)
Tag 46 (RelatdSym) was intended to specify related securities in derivative or spread trading but is no longer used in FIX 4.4. It has been deprecated due to lack of adoption and clarity. Modern implementations use structured repeating groups or multileg instruments instead. Applications should not include this tag. Its use may cause parsing errors or interoperability issues. FIX 4.4 recommends avoiding deprecated fields to ensure clean, standards-compliant messaging.

Tag 47: Rule80A (No Longer Used)
Tag 47 (Rule80A) was used to indicate order categorization under NYSE Rule 80A, such as Program Trade (P) or Non-Program Trade (N). However, it is no longer used and has been deprecated. Regulatory reporting now uses more comprehensive fields. This tag should not be included in FIX 4.4 messages. Its presence may be ignored or rejected by exchanges. Modern systems rely on other identifiers for regulatory compliance, making Rule80A obsolete in current trading protocols.

Tag 48: SecurityID
Tag 48 (SecurityID) is the identifier for a financial instrument, such as a CUSIP, ISIN, or proprietary code. Used with SecurityIDSource (Tag 22), it ensures unambiguous security identification across markets. It is critical for accurate routing, clearing, and settlement. While Symbol (Tag 55) is human-readable, SecurityID provides a unique, standardized key. It supports global trading and reduces misidentification risk, especially for bonds, ETFs, or non-US equities with overlapping ticker symbols.

Tag 49: SenderCompID
Tag 49 (SenderCompID) identifies the sending firm in a FIX session, such as a buy-side institution or broker. It is used for routing, authentication, and logging. The receiver validates this ID against known counterparties. SenderCompID is mandatory in every message and must match the session configuration. It enables secure, targeted communication and prevents spoofing. It is a foundational element of FIX session establishment and message integrity.

Tag 50: SenderSubID
Tag 50 (SenderSubID) specifies a sub-entity within the sending firm, such as a trading desk, algorithm, or region. It allows granular message routing and monitoring. For example, different algorithms can use unique SenderSubIDs for performance tracking. It is optional but useful in large institutions with multiple internal systems. SenderSubID enhances auditability and supports detailed reporting without requiring separate sessions.

Tag 51: SendingDate (no longer used)
Tag 51 (SendingDate) was part of older checksum calculations but is no longer used in FIX 4.4. Its functionality has been absorbed into SendingTime (Tag 52), which includes both date and time. Including SendingDate may cause parsing errors. It has been deprecated to simplify message structure and avoid redundancy. Applications should omit this tag to maintain compliance with the FIX 4.4 specification.

Tag 52: SendingTime
Tag 52 (SendingTime) is the UTC timestamp when the message was transmitted, formatted as YYYYMMDD-HH:MM:SS.sss. It ensures temporal ordering and is critical for audit trails, latency analysis, and replay. SendingTime is set by the sender and must be accurate. It differs from TransactTime (Tag 60), which reflects event time. SendingTime supports regulatory compliance (e.g., MiFID II clock synchronization) and is mandatory in all FIX 4.4 messages.

Tag 53: Quantity
Tag 53 (Quantity) is a generic field used to specify a quantity, often in allocation or confirmation messages. It may represent shares, contracts, or units being allocated. While similar to OrderQty (Tag 38) or LastQty (Tag 32), it is context-dependent and typically used in repeating groups. It supports post-trade processing and ensures accurate distribution of executed volume across accounts.

Tag 54: Side
Tag 54 (Side) indicates the trading side of an order: Buy (1), Sell (2), Sell Short (5), or Sell Short Exempt (6). It is fundamental to order routing and execution logic. Side determines whether the order adds liquidity or takes it and impacts commission and regulatory reporting. It must be consistent with the order’s intent and is used in conjunction with Symbol and OrderQty. Side is mandatory in all order and execution messages.

Tag 55: Symbol
Tag 55 (Symbol) is the ticker symbol of the security (e.g., AAPL, TSLA). It is a human-readable identifier used in order and quote messages. While widely used, Symbol should be paired with SecurityID (Tag 48) and SecurityIDSource (Tag 22) for unambiguous identification, especially across exchanges. It supports quick recognition but may be ambiguous without additional context. Symbol is essential for pre-trade communication and market data.

Tag 56: TargetCompID
Tag 56 (TargetCompID) identifies the receiving firm in a FIX session, such as a broker or exchange. It ensures messages are routed correctly. The sender sets this field based on the session configuration. TargetCompID is validated at the session level and must match the intended recipient. It enables secure, point-to-point communication and is mandatory in every message.

Tag 57: TargetSubID
Tag 57 (TargetSubID) specifies a sub-entity within the target firm, such as a specific desk, gateway, or algorithmic trading system. It allows precise message delivery without requiring multiple sessions. For example, different trading strategies can route to distinct TargetSubIDs. It is optional but useful for large institutions. TargetSubID enhances routing flexibility and supports detailed monitoring and control.

Tag 58: Text
Tag 58 (Text) carries free-form text for comments, reasons, or notes. It is used in Execution Reports to explain rejections, in News messages for announcements, or in Emails for communication. While not parsed programmatically, it provides valuable context. Text can include trader notes, error details, or compliance remarks. It supports human-readable communication and enhances transparency in automated workflows.

Tag 59: TimeInForce
Tag 59 (TimeInForce) specifies how long an order remains active: Day (0), Good Till Cancel (1), Immediate Or Cancel (3), Fill Or Kill (4), or Good Till Date (6). It controls order lifespan and execution strategy. For example, IOC orders are partially filled or canceled immediately. TimeInForce influences routing and algorithmic behavior. It is essential for defining order persistence and must be set appropriately based on trading objectives.

Tag 60: TransactTime
Tag 60 (TransactTime) is the UTC timestamp when the transaction occurred—e.g., order received, execution completed. It reflects the event time, not transmission time. TransactTime is critical for audit trails, best execution analysis, and regulatory reporting. It must be synchronized across systems. Unlike SendingTime, it is set by the executing system and ensures accurate event sequencing.

Tag 61: Urgency
Tag 61 (Urgency) indicates the priority of a message: Normal (0), Flash (1), or Background (2). Though rarely used, it can signal time-sensitive communications. Flash urgency may prompt faster processing. However, most systems treat all messages equally. Urgency is optional and primarily informational. It supports prioritization in congested environments but is not a guaranteed service level.

Tag 62: ValidUntilTime
Tag 62 (ValidUntilTime) specifies the expiration time for a Good-Till-Time (GTT) order. The order is automatically canceled after this UTC timestamp. It is used with TimeInForce=6. ValidUntilTime enables precise control over order duration and supports automated trading strategies. It must be set in the future and is critical for time-sensitive execution policies in global markets.

Tag 63: SettlType
Tag 63 (SettlType) defines the standard settlement period: Regular (0), Cash (1), Next Day (2), etc. It determines the default settlement date unless overridden by SettlDate (Tag 64). SettlType is used in order and execution messages to specify delivery terms. It impacts margin, clearing, and accounting. It is essential for ensuring correct trade settlement and compliance with market conventions.

Tag 64: SettlDate
Tag 64 (SettlDate) specifies the actual settlement date in YYYYMMDD format. It overrides SettlType when a custom settlement date is required. For example, forward-settling trades use SettlDate to define the delivery date. It is critical for accurate clearing and reconciliation. SettlDate must be consistent with the trade’s economic terms and is used in confirmations and allocations.

Tag 65: SymbolSfx
Tag 65 (SymbolSfx) is a suffix used on some exchanges to denote special characteristics of a security, such as warrants (WS) or preferred shares (PR). It is rarely used in modern markets. While supported in FIX 4.4, most systems rely on SecurityID for unambiguous identification. SymbolSfx is optional and primarily historical. Its use is limited to specific exchange conventions.

Tag 66: ListID
Tag 66 (ListID) uniquely identifies a list of orders in a List Execute (MsgType E) or List Status (MsgType FS) message. It enables coordination of multiple orders in a single strategy, such as a basket trade. ListID ensures all orders in the list are processed together. It supports algorithmic and program trading workflows and is essential for managing complex, multi-order executions.

Tag 67: ListSeqNo
Tag 67 (ListSeqNo) indicates the sequence number of an order within a list, starting at 1. It ensures correct ordering and processing of orders in a List Execute message. Combined with ListID (Tag 66), it defines the position of each order in the sequence. ListSeqNo supports structured execution of multi-leg strategies and prevents misordering in automated trading systems.

Tag 68: TotNoOrders
Tag 68 (TotNoOrders) specifies the total number of orders in a list. It appears in List Status messages to confirm list completeness. It helps the receiver verify that all expected orders have been reported. TotNoOrders supports reconciliation and ensures transparency in list-based trading strategies. It is essential for monitoring the progress of large-scale order executions.

Tag 69: ListExecInst
Tag 69 (ListExecInst) contains execution instructions for an entire list of orders, such as “All or None” or “Work the list.” It guides the broker on how to handle the list as a whole. Instructions may include time constraints or execution priorities. ListExecInst supports coordinated execution of baskets and is critical for achieving optimal execution in portfolio trading.

Tag 70: AllocID
Tag 70 (AllocID) is a unique identifier assigned to an allocation message. It tracks the distribution of executed shares to multiple accounts. AllocID ensures each allocation is processed once and supports reconciliation. It is used in Allocation (MsgType J) and Allocation Ack (MsgType P) messages. AllocID is essential for accurate post-trade processing and compliance with institutional accounting standards.

Tag 71: AllocTransType
Tag 71 (AllocTransType) specifies the type of allocation transaction: New (0), Replace (1), or Cancel (2). It controls how the allocation is processed. A “Replace” updates a prior allocation, while “Cancel” removes it. AllocTransType ensures correct handling of allocation lifecycle events and supports accurate position updates across multiple accounts.

Tag 72: RefAllocID
Tag 72 (RefAllocID) references a prior AllocID when canceling or replacing an allocation. It links the new message to the original, enabling accurate updates. RefAllocID prevents errors in allocation processing and supports audit trails. It is mandatory in Cancel and Replace allocation messages and ensures consistency in post-trade workflows.

Tag 73: NoOrders
Tag 73 (NoOrders) indicates the number of orders in a repeating group within an allocation message. It defines the size of the NoOrders group, which contains ClOrdID, OrderID, and related fields. NoOrders supports structured transmission of multiple order references in a single allocation. It is essential for linking executions to their source orders in complex trading environments.

Tag 74: AvgPxPrecision
Tag 74 (AvgPxPrecision) specifies the number of decimal places to use when expressing AvgPx (Tag 6). It ensures consistent price formatting across systems. For example, a precision of 4 means prices are reported to four decimal places. AvgPxPrecision supports accurate price representation and avoids rounding discrepancies in performance and accounting systems.

Tag 75: TradeDate
Tag 75 (TradeDate) is the date the trade was executed, in YYYYMMDD format. It may differ from the settlement date (SettlDate). TradeDate is used for accounting, performance measurement, and regulatory reporting. It is critical for accurate trade lifecycle tracking and ensures proper date attribution in financial records.

Tag 76: ExecBroker (replaced)
Tag 76 (ExecBroker) was used to identify the executing broker but has been replaced by more structured fields. It is deprecated and should not be used. Modern systems use ExecID, OrderID, and PartyIDs for broker identification. ExecBroker is obsolete in FIX 4.4 and may be ignored or rejected by receiving systems.

Tag 77: PositionEffect
Tag 77 (PositionEffect) indicates whether an order opens (O) or closes (C) a position. It is critical for margin, tax, and accounting systems. For example, closing a short position requires different handling than opening one. PositionEffect ensures correct position tracking and supports regulatory compliance in portfolio management.

Tag 78: NoAllocs
Tag 78 (NoAllocs) specifies the number of allocation blocks in a repeating group. It defines how many times the AllocAccount (Tag 79) and AllocQty (Tag 80) fields repeat. NoAllocs supports structured transmission of multiple allocations in a single message. It is essential for efficient post-trade processing and reconciliation.

Tag 79: AllocAccount
Tag 79 (AllocAccount) specifies the client account to which a portion of the execution is allocated. It is used in Allocation messages to distribute fills across multiple funds or desks. AllocAccount ensures correct position attribution and supports institutional portfolio management and compliance.

Tag 80: AllocQty
Tag 80 (AllocQty) specifies the quantity of shares allocated to a particular account. It appears in repeating groups within Allocation messages. AllocQty must sum to the total executed quantity. It supports accurate position updates and is essential for reconciliation and settlement.

Tag 81: ProcessCode
Tag 81 (ProcessCode) was used to indicate special processing instructions but is rarely used and often ignored. It has no standard meaning and is not recommended for use. Modern systems rely on other fields for workflow control. ProcessCode is obsolete and should be omitted in FIX 4.4 implementations.

Tag 82: NoRpts
Tag 82 (NoRpts) indicates the number of repeating report blocks in a message, such as in a List Status (MsgType FS). It defines the size of the repeating group containing RptSeq (Tag 83) and related fields. NoRpts supports structured reporting of list execution status and ensures complete message parsing.

Tag 83: RptSeq
Tag 83 (RptSeq) is a sequence number for report messages, used in List Status to identify the order of status updates. It ensures correct sequencing of status reports for multi-order lists. RptSeq supports monitoring and reconciliation of large-scale trading strategies.

Tag 84: CxlQty
Tag 84 (CxlQty) specifies the quantity of shares canceled in a partial cancel. It appears in Execution Reports with ExecType = Canceled. CxlQty updates CumQty (Tag 14) and reflects the reduction in order size. It supports accurate order tracking and reconciliation.

Tag 85: NoDlvyInst
Tag 85 (NoDlvyInst) indicates the number of delivery instruction blocks in a message. It defines the size of the repeating group for delivery details. NoDlvyInst supports structured transmission of settlement instructions and ensures complete processing of delivery requirements.

Tag 86: DlvyInst (no longer used)
Tag 86 (DlvyInst) was used for delivery instructions but is no longer used. It has been deprecated in favor of structured repeating groups. Applications should not include this field. Its use may cause parsing issues. Modern systems use NoDlvyInst and related fields for delivery handling.

Tag 87: AllocStatus
Tag 87 (AllocStatus) indicates the status of an allocation: Accepted (0), Rejected (1), or Partial Accept (2). It is returned in Allocation Ack messages. AllocStatus enables confirmation of allocation processing and supports reconciliation and error resolution in post-trade workflows.

Tag 88: AllocRejCode
Tag 88 (AllocRejCode) specifies the reason for allocation rejection, such as Unknown Account (0), Incorrect Quantity (1), or Mismatched Data (2). It provides transparency in failure scenarios and supports troubleshooting. AllocRejCode is essential for resolving allocation errors and ensuring accurate position updates.

Tag 89: Signature
Tag 89 (Signature) contains a digital signature for message authentication. Used with SecureData (Tag 91), it supports secure, tamper-proof communication. Signature ensures message integrity and non-repudiation. It is part of FIX’s optional security framework and is used in regulated or high-risk environments.

Tag 90: SecureDataLen
Tag 90 (SecureDataLen) specifies the length in bytes of the encrypted data in SecureData (Tag 91). It enables proper parsing of the encrypted payload. SecureDataLen is used in conjunction with EncryptMethod (Tag 98) and is essential for secure message transmission.

Tag 91: SecureData
Tag 91 (SecureData) carries encrypted payload data, such as order details or account information. It supports confidentiality in sensitive communications. SecureData is used with SecureDataLen and EncryptMethod to enable end-to-end encryption in FIX sessions.

Tag 92: BrokerOfCredit (replaced)
Tag 92 (BrokerOfCredit) was used in credit-related messages but is replaced. It is obsolete and should not be used. Modern credit workflows use other identifiers. BrokerOfCredit is deprecated in FIX 4.4.

Tag 93: SignatureLength
Tag 93 (SignatureLength) specifies the length of the Signature field (Tag 89). It enables correct parsing of the digital signature. SignatureLength is used in secure FIX implementations to ensure data integrity.

Tag 94: EmailType
Tag 94 (EmailType) specifies the type of email message: New (0), Reply (1), or Forward (2). It is used in Email (MsgType C) messages to define message threading. EmailType supports structured communication and ensures proper handling of email exchanges.

Tag 95: RawDataLength
Tag 95 (RawDataLength) specifies the length of the RawData field (Tag 96). It enables parsing of binary or free-form data. RawDataLength is used when transmitting non-text content, such as images or encoded files.

Tag 96: RawData
Tag 96 (RawData) carries binary or unformatted data, such as chart images, encoded documents, or proprietary content. It is used with RawDataLength and supports rich data transmission in FIX messages.

Tag 97: PossResend
Tag 97 (PossResend) indicates a possible resend of a message (Y/N). It helps receivers detect and handle duplicates. PossResend is set to ‘Y’ when resending messages after a failure. It supports reliable message delivery.

Tag 98: EncryptMethod
Tag 98 (EncryptMethod) specifies the encryption algorithm used: None (0), DES (1), 3DES (2), etc. It defines how SecureData is encrypted. EncryptMethod ensures both parties use compatible encryption and supports secure communication.

Tag 99: StopPx
Tag 99 (StopPx) is the trigger price for a Stop (OrdType=3) or Stop-Limit (OrdType=4) order. When the market reaches StopPx, the order becomes active. StopPx is essential for risk management and automated trading strategies.

Tag 100: ExDestination
Tag 100 (ExDestination) specifies the destination exchange or ECN where an order should be routed. It supports smart order routing and algorithmic trading. ExDestination enables precise control over execution venue selection and is critical for achieving best execution.

Tag 102: CxlRejReason
Tag 102 (CxlRejReason) specifies the reason an order cancellation request was rejected. It appears in Order Cancel Reject messages (MsgType 9) and helps the client understand why the cancel failed. Valid values include “Too late to cancel” (0), “Unknown order” (1), “Broker option” (2), or “Order already pending cancel” (3). This field enhances transparency and supports troubleshooting. It enables clients to adjust their strategies or resubmit requests appropriately. CxlRejReason is critical for robust order management and ensures accurate feedback in high-frequency trading environments.

Tag 103: OrdRejReason
Tag 103 (OrdRejReason) indicates why a new order was rejected, returned in Order Cancel Reject (MsgType 9) or Execution Report (MsgType 8) messages. Common codes include “Broker option” (0), “Unknown symbol” (1), “Price exceeds limit” (3), or “Insufficient credit” (4). It provides actionable feedback to the client, enabling corrective action. OrdRejReason supports compliance, risk control, and system diagnostics. It is essential for debugging order routing issues and improving execution success rates in automated trading systems.

Tag 104: IOIQualifier
Tag 104 (IOIQualifier) specifies the nature of an Indication of Interest, such as “In line” (A), “Working away” (B), or “At the close” (C). It adds context to IOI messages, helping recipients assess timing and intent. For example, “At the close” suggests interest near market close. This field supports pre-trade communication in block trading and program execution. IOIQualifier enhances message clarity and enables more informed responses from counterparties in non-binding trading scenarios.

Tag 105: WaveNo (no longer used)
Tag 105 (WaveNo) was used to identify waves in order list executions but is no longer used in FIX 4.4. It has been deprecated due to redundancy and lack of adoption. Modern list management uses ListID (Tag 66) and ListSeqNo (Tag 67) for sequencing. Applications should omit WaveNo to ensure compliance. Its inclusion may cause parsing errors or interoperability issues. FIX 4.4 discourages the use of obsolete fields to maintain clean, standardized messaging.

Tag 106: Issuer
Tag 106 (Issuer) identifies the issuing entity of a security, such as a corporation or government. It is used in security definition and trading messages to provide issuer context. While Symbol (Tag 55) identifies the ticker, Issuer gives additional detail for bonds, preferred shares, or structured products. It supports research, compliance, and clearing. Though optional, it enhances transparency, especially for securities with similar names or tickers across issuers.

Tag 107: SecurityDesc
Tag 107 (SecurityDesc) provides a free-form description of a security, such as “Apple Inc. 5% Bond 2030.” It supplements Symbol and SecurityID with human-readable details. SecurityDesc is used in quotes, orders, and market data to convey characteristics not captured by standard identifiers. It supports trader recognition and compliance reporting. While not parsed algorithmically, it improves clarity in trading workflows involving complex or fixed-income instruments.

Tag 108: HeartBtInt
Tag 108 (HeartBtInt) specifies the heartbeat interval in seconds for a FIX session. It defines how often heartbeat messages (MsgType 0) are exchanged to confirm connectivity. For example, a value of 30 means heartbeats every 30 seconds. Both parties negotiate this during logon. HeartBtInt ensures session liveness and detects connection failures. It is critical for reliability and is used in session-level monitoring and automated recovery systems.

Tag 109: ClientID (replaced)
Tag 109 (ClientID) was used to identify the end-client in agency trading but is replaced by PartyID and related fields in FIX 4.4. It has been deprecated to support a more flexible party identification model. Modern implementations use NoPartyIDs and PartyID fields for granular role-based identification. ClientID should not be used in new systems. Its use may lead to compatibility issues. FIX 4.4 encourages migration to the standardized PartyID framework.

Tag 110: MinQty
Tag 110 (MinQty) specifies the minimum quantity that must be executed on a single fill. If the available liquidity is less than MinQty, no execution occurs. It is used in conjunction with OrderQty (Tag 38) and supports partial execution control. MinQty is useful for avoiding small, inefficient fills. It is optional and commonly used in block trading or iceberg orders where large minimum executions are preferred.

Tag 111: MaxFloor
Tag 111 (MaxFloor) specifies the maximum number of shares that can be shown in the market at any time for an order. It is used in reserve or iceberg orders to hide the full size. For example, an order of 100,000 with MaxFloor=10,000 shows only 10,000 visible. This supports stealth trading and reduces market impact. MaxFloor is critical for algorithmic execution strategies focused on minimizing information leakage.

Tag 112: TestReqID
Tag 112 (TestReqID) is a unique identifier sent in a Test Request message (MsgType 1) to verify connectivity. The receiver must echo this ID in a Heartbeat message. It confirms that messages are being transmitted and received correctly. TestReqID is used for latency testing, session validation, and network diagnostics. It supports proactive monitoring and ensures message delivery integrity in production environments.

Tag 113: ReportToExch
Tag 113 (ReportToExch) indicates whether the counterparty is required to report the trade to the exchange (Y/N). It is used in Execution Reports to support regulatory compliance. When set to ‘Y’, the broker confirms the trade will be reported. This field is particularly relevant in markets with mandatory post-trade reporting, such as swaps or OTC derivatives. It enhances transparency and ensures adherence to exchange rules.

Tag 114: LocateReqd
Tag 114 (LocateReqd) indicates whether a short sale requires a locate (Y/N). It is set to ‘Y’ when the seller must confirm stock borrow availability before execution. This field supports compliance with short-selling regulations like Regulation SHO. It is used in order routing and risk checks. Brokers validate locate availability before executing such orders, preventing fails and regulatory violations.

Tag 115: OnBehalfOfCompID
Tag 115 (OnBehalfOfCompID) identifies the firm on whose behalf a message is sent, typically used in third-party routing. For example, a broker routing for a hedge fund uses the fund’s OnBehalfOfCompID. It enables centralized messaging while preserving counterparty identity. This field supports agency trading and multilateral relationships. It is validated at the session level and ensures correct attribution.

Tag 116: OnBehalfOfSubID
Tag 116 (OnBehalfOfSubID) specifies a sub-entity within the firm identified by OnBehalfOfCompID, such as a trading desk or strategy. It allows granular identification when routing on behalf of others. Combined with OnBehalfOfCompID, it supports detailed audit trails and performance attribution. It is optional but useful in complex institutional environments with multiple internal clients.

Tag 117: QuoteID
Tag 117 (QuoteID) is a unique identifier assigned by the quoting party to a quote. It is used in Quote (MsgType S) and Quote Response (MsgType AQ) messages. QuoteID enables tracking and referencing of quotes, especially when responding to Quote Requests (MsgType R). It supports quote lifecycle management and ensures correct matching of requests and responses in RFQ workflows.

Tag 118: NetMoney
Tag 118 (NetMoney) represents the net monetary value of an execution, including commissions and fees. It is used in Execution Reports and Allocation messages. NetMoney helps determine the total cost or proceeds of a trade. It is particularly useful in fixed income or complex instruments where accrued interest or fees affect net settlement. This field supports accurate accounting and reconciliation.

Tag 119: SettlCurrAmt
Tag 119 (SettlCurrAmt) specifies the amount in the settlement currency for cross-currency trades. It differs from LastPx (Tag 31) when settlement currency differs from trade currency. SettlCurrAmt is used with SettlCurrency (Tag 120) and SettlCurrFxRate (Tag 155) to define the actual settlement value. It supports accurate FX conversion and clearing in multi-currency transactions.

Tag 120: SettlCurrency
Tag 120 (SettlCurrency) identifies the currency in which a trade will settle, using ISO 4217 codes. It is used when settlement currency differs from trade currency. SettlCurrency is critical for cross-border transactions and ensures correct payment processing. It is used with SettlCurrAmt (Tag 119) and supports regulatory reporting and accounting in global trading environments.

Tag 121: ForexReq
Tag 121 (ForexReq) indicates whether a forex accommodation is required for settlement (Y/N). It is used in allocation messages to signal that currency conversion is needed. ForexReq helps clearing systems prepare for FX transactions. It is particularly relevant in international portfolios where trades are executed in one currency but settled in another. This field supports seamless cross-border settlement.

Tag 122: OrigSendingTime
Tag 122 (OrigSendingTime) is the SendingTime (Tag 52) of the original message being referenced, typically used in delayed or resent messages. It helps receivers correlate messages across time and detect duplicates. When PossDupFlag (Tag 43) is ‘Y’, OrigSendingTime confirms the timing of the original transmission. It enhances message sequencing accuracy and supports reliable recovery.

Tag 123: GapFillFlag
Tag 123 (GapFillFlag) indicates that a message is part of a sequence reset to fill a gap (Y/N). When ‘Y’, the message bypasses normal sequence checking. It is used in Sequence Reset messages with NewSeqNo (Tag 36). GapFillFlag enables safe recovery after message loss. It prevents rejection of valid messages during resynchronization and supports session continuity.

Tag 124: NoExecs
Tag 124 (NoExecs) specifies the number of execution reports in a repeating group within an Allocation message. It defines how many times the ExecID, LastPx, and LastQty fields repeat. NoExecs supports structured transmission of multiple fills for a single order. It is essential for accurate allocation and reconciliation, especially in partial or multi-leg executions.

Tag 125: CxlType (no longer used)
Tag 125 (CxlType) was used to indicate cancellation type but is no longer used in FIX 4.4. It has been deprecated due to redundancy with ExecType and other fields. Applications should not include this tag. Its use may cause parsing issues. Modern systems rely on ExecType (Tag 150) and CxlRejReason (Tag 102) for cancellation handling.

Tag 126: ExpireTime
Tag 126 (ExpireTime) specifies the absolute UTC time when a Good-Till-Time (GTT) order expires. It overrides TimeInForce (Tag 59) and is used with SettlType=6. ExpireTime ensures precise control over order duration. It is critical for time-sensitive strategies and global trading, where local time zones differ. The order is automatically canceled after this timestamp.

Tag 127: DKReason
Tag 127 (DKReason) indicates the reason for a Don’t Know (DK) trade report, such as “Unknown client” (A) or “Mismatched quantity” (B). It is used in DK Reason messages to resolve trade mismatches. DKReason supports post-trade affirmation and reconciliation. It enables quick resolution of discrepancies between counterparties in clearing workflows.

Tag 128: DeliverToCompID
Tag 128 (DeliverToCompID) identifies the final recipient of a message in a routing chain. It is used when a message is forwarded through intermediaries. The sender sets DeliverToCompID to ensure the message reaches the intended destination. It supports multi-hop messaging and is validated at each hop. It enhances routing flexibility in complex trading networks.

Tag 129: DeliverToSubID
Tag 129 (DeliverToSubID) specifies a sub-entity within the firm identified by DeliverToCompID. It allows granular delivery targeting in multi-hop messaging. Combined with DeliverToCompID, it supports precise message routing to specific desks or systems. It is optional but useful in large institutions with distributed architectures.

Tag 130: IOINaturalFlag
Tag 130 (IOINaturalFlag) indicates whether an IOI is from a natural person (Y/N). It is used in regulatory reporting to distinguish individual from institutional interest. This field supports compliance with market transparency rules. It is particularly relevant in dark pools or OTC markets where participant type affects execution eligibility.

Tag 131: QuoteReqID
Tag 131 (QuoteReqID) is a unique identifier assigned by the requester in a Quote Request message (MsgType R). It is echoed in Quote (MsgType S) and Quote Response (MsgType AQ) messages. QuoteReqID links requests to responses and supports RFQ workflows. It ensures correct matching and enables tracking of quote lifecycles in fixed income or derivatives trading.

Tag 132: BidPx
Tag 132 (BidPx) specifies the bid price in a quote or market data entry. It represents the highest price a buyer is willing to pay. BidPx is used in Quote, Market Data, and Execution messages. It is essential for price discovery and execution quality analysis. Combined with BidSize (Tag 134), it defines the bid side of the market.

Tag 133: OfferPx
Tag 133 (OfferPx) specifies the offer (ask) price in a quote or market data entry. It represents the lowest price a seller is willing to accept. OfferPx is used in Quote and Market Data Incremental Refresh messages. It is critical for spread analysis and trade execution. Combined with OfferSize (Tag 135), it defines the offer side of the market.

Tag 134: BidSize
Tag 134 (BidSize) specifies the quantity available at the bid price. It is used in quotes and market data to indicate buy-side depth. BidSize helps assess liquidity and market strength. Combined with BidPx (Tag 132), it provides a complete view of the bid side. It is essential for algorithmic trading and market-making strategies.

Tag 135: OfferSize
Tag 135 (OfferSize) specifies the quantity available at the offer price. It indicates sell-side depth in the market. OfferSize is used in quotes and market data messages. Combined with OfferPx (Tag 133), it defines the ask side. It supports liquidity analysis and execution decision-making in high-frequency and statistical arbitrage strategies.

Tag 136: NoMiscFees
Tag 136 (NoMiscFees) indicates the number of miscellaneous fee entries in a repeating group. It defines how many times MiscFeeAmt (Tag 137), MiscFeeCurr (Tag 138), and MiscFeeType (Tag 139) repeat. NoMiscFees supports detailed fee breakdowns in allocations and executions. It is essential for transparent cost reporting and regulatory compliance.

Tag 137: MiscFeeAmt
Tag 137 (MiscFeeAmt) specifies the amount of a miscellaneous fee, such as exchange fees, regulatory charges, or taxes. It is used in Allocation messages with MiscFeeType. MiscFeeAmt supports granular cost attribution and accurate net performance calculation. It is critical for institutional investors requiring detailed expense reporting.

Tag 138: MiscFeeCurr
Tag 138 (MiscFeeCurr) specifies the currency of a miscellaneous fee using ISO 4217. It is used with MiscFeeAmt (Tag 137) to define the fee’s denomination. MiscFeeCurr ensures correct valuation and accounting, especially in cross-border transactions. It supports multi-currency fee reporting and reconciliation.

Tag 139: MiscFeeType
Tag 139 (MiscFeeType) categorizes a miscellaneous fee: Regulatory (1), Tax (2), Levy (3), etc. It provides transparency into fee nature. MiscFeeType is used in Allocation messages and supports compliance with cost disclosure regulations like MiFID II. It enables accurate classification and reporting of non-commission expenses.

Tag 140: PrevClosePx
Tag 140 (PrevClosePx) specifies the previous day’s closing price for a security. It is used in market data and order messages for reference. PrevClosePx supports technical analysis, volatility assessment, and price limit checks. It is essential for algorithms that compare current prices to prior closes for trading signals.

Tag 141: ResetSeqNumFlag
Tag 141 (ResetSeqNumFlag) indicates whether message sequence numbers should be reset to 1 (Y/N) at logon. When ‘Y’, both sides restart counting. It is used during system restarts or recovery. ResetSeqNumFlag supports clean session initialization and prevents sequence mismatches. It is a critical parameter in the Logon message (MsgType A).

Tag 142: SenderLocationID
Tag 142 (SenderLocationID) identifies the physical or logical location of the sender, such as a data center or trading desk. It supports latency monitoring and routing optimization. SenderLocationID enhances auditability and is used in high-frequency trading to analyze geographic performance.

Tag 143: TargetLocationID
Tag 143 (TargetLocationID) identifies the location of the receiving party. It is used with SenderLocationID for end-to-end path tracking. TargetLocationID supports network diagnostics and ensures messages reach the correct geographic or logical endpoint in distributed systems.

Tag 144: OnBehalfOfLocationID
Tag 144 (OnBehalfOfLocationID) specifies the location of the firm on whose behalf a message is sent. It complements OnBehalfOfCompID and supports granular location tracking in routed messages. It is useful for performance analysis and regulatory reporting in multi-location trading environments.

Tag 145: DeliverToLocationID
Tag 145 (DeliverToLocationID) identifies the final delivery location in a multi-hop message chain. It ensures precise routing to the correct data center or system. DeliverToLocationID supports complex network topologies and is critical for low-latency trading infrastructure.

Tag 146: NoRelatedSym
Tag 146 (NoRelatedSym) indicates the number of securities in a repeating group, such as in Market Data requests. It defines how many times Symbol (Tag 55) and related fields repeat. NoRelatedSym supports batch requests and efficient subscription management in market data workflows.

Tag 147: Subject
Tag 147 (Subject) specifies the subject line of an Email message (MsgType C). It provides a summary of the email content. Subject supports message categorization and filtering. It is essential for organizing communication in trading desks and compliance departments.

Tag 148: Headline
Tag 148 (Headline) is the headline of a News message (MsgType B). It summarizes the news content and appears in alerts. Headline supports quick scanning and prioritization of market-moving information. It is critical for timely dissemination of financial news.

Tag 149: URLLink
Tag 149 (URLLink) provides a web link in a News or Email message. It directs users to additional content, such as reports or filings. URLLink enhances information richness and supports deeper research. It is used in market news and corporate announcements.

Tag 150: ExecType
Tag 150 (ExecType) specifies the type of execution event: New (0), Partial Fill (1), Fill (2), Done (3), Canceled (4), etc. It replaces ExecTransType (Tag 20) and provides detailed execution lifecycle tracking. ExecType is critical for accurate trade reporting and reconciliation in FIX 4.4.

Tag 151: LeavesQty
Tag 151 (LeavesQty) represents the remaining quantity of an order that has not yet been executed. It is calculated as OrderQty (Tag 38) minus CumQty (Tag 14). LeavesQty is included in Execution Reports and is essential for tracking order progress. When LeavesQty reaches zero, the order is fully filled. It helps traders and algorithms monitor unfilled portions and decide whether to cancel or modify. LeavesQty must be non-negative and is a key indicator of order status in real-time trading systems.

Tag 152: CashOrderQty
Tag 152 (CashOrderQty) specifies the order quantity in monetary terms rather than units. For example, a client may request to buy $100,000 worth of a stock. The broker converts this to shares based on the current price. CashOrderQty supports dollar-cost averaging and portfolio rebalancing strategies. It is particularly useful in algorithmic and institutional trading where capital allocation is prioritized over share count.

Tag 153: AllocAvgPx
Tag 153 (AllocAvgPx) is the average price used for a specific allocation account. It may differ from the overall AvgPx (Tag 6) if allocations are based on different execution segments. AllocAvgPx ensures accurate cost basis assignment per account. It is used in Allocation messages and supports precise performance measurement and tax reporting across multiple portfolios.

Tag 154: AllocNetMoney
Tag 154 (AllocNetMoney) represents the net monetary value allocated to a specific account, including commissions and fees. It is calculated as AllocQty (Tag 80) multiplied by AllocAvgPx (Tag 153), adjusted for costs. AllocNetMoney supports accurate accounting and reconciliation. It is essential for determining the total cost or proceeds attributable to each beneficiary in a trade.

Tag 155: SettlCurrFxRate
Tag 155 (SettlCurrFxRate) specifies the foreign exchange rate used to convert from trade currency to settlement currency. It ensures accurate valuation in cross-currency trades. SettlCurrFxRate is used with SettlCurrency (Tag 120) and SettlCurrAmt (Tag 119). It supports transparent FX handling and is critical for clearing and accounting in global transactions.

Tag 156: SettlCurrFxRateCalc
Tag 156 (SettlCurrFxRateCalc) indicates how the settlement FX rate was calculated: Multiply (M) or Divide (D). It defines the conversion method between trade and settlement currencies. For example, “Multiply” means trade amount × rate = settlement amount. This field ensures consistent interpretation of SettlCurrFxRate (Tag 155) and prevents calculation errors in multi-currency allocations.

Tag 157: NumDaysInterest
Tag 157 (NumDaysInterest) specifies the number of days used to calculate accrued interest on fixed-income securities. It is used in bond trades to determine interest owed from the last coupon date to settlement. NumDaysInterest supports accurate pricing and settlement. It is essential for fair value transfer between buyer and seller in debt instruments.

Tag 158: AccruedInterestRate
Tag 158 (AccruedInterestRate) is the per-share accrued interest rate for a bond trade. It represents the interest accumulated since the last coupon payment. AccruedInterestRate is used to calculate the total accrued interest (AccruedInterestAmt, Tag 159). It ensures the buyer compensates the seller for holding the bond during the coupon period.

Tag 159: AccruedInterestAmt
Tag 159 (AccruedInterestAmt) is the total accrued interest amount due on a bond trade. It is added to the principal for settlement. AccruedInterestAmt ensures fair compensation for interest earned but not yet paid. It is critical for accurate bond pricing and is used in Execution Reports and Allocations.

Tag 160: SettlInstMode
Tag 160 (SettlInstMode) specifies the method for delivering settlement instructions: Default (0), Standing Instructions (1), Specific Allocation (2), or Request Reversal (3). It controls how settlement details are determined. SettlInstMode supports automation and reduces manual input. It is used in Settlement Instruction messages and ensures correct handling of delivery instructions.

Tag 161: AllocText
Tag 161 (AllocText) contains free-form text for allocation instructions, such as special handling notes or comments. It is used in Allocation messages to convey context not captured by structured fields. AllocText supports communication between brokers and asset managers. While not parsed algorithmically, it enhances transparency in post-trade workflows.

Tag 162: SettlInstID
Tag 162 (SettlInstID) is a unique identifier assigned to a settlement instruction. It enables tracking and referencing of delivery instructions. SettlInstID is used in SettlInst messages and supports reconciliation. It ensures that the correct instructions are applied to the right trade, reducing settlement risk.

Tag 163: SettlInstTransType
Tag 163 (SettlInstTransType) specifies the type of settlement instruction transaction: New (0), Cancel (1), or Replace (2). It controls how the instruction is processed. SettlInstTransType ensures correct lifecycle management of delivery instructions and supports accurate updates or cancellations in post-trade processing.

Tag 164: EmailThreadID
Tag 164 (EmailThreadID) groups related email messages into a conversation thread. It allows recipients to follow message history. EmailThreadID supports organized communication and prevents fragmented discussions. It is used in Email messages (MsgType C) and enhances collaboration in trading and compliance teams.

Tag 165: SettlInstSource
Tag 165 (SettlInstSource) identifies the source of settlement instructions: Broker (1), Institution (2), or Third Party (3). It clarifies responsibility for delivery details. SettlInstSource supports auditability and ensures correct attribution in complex trading relationships involving multiple intermediaries.

Tag 166: SettlLocation (replaced)
Tag 166 (SettlLocation) was used to identify the settlement location but is replaced by more structured fields. It has been deprecated in favor of PartyIDs and other identifiers. Applications should not use this tag. Its functionality is now handled through standardized party and location identifiers in FIX 4.4.

Tag 167: SecurityType
Tag 167 (SecurityType) specifies the type of financial instrument: Common Stock (CS), Corporate Bond (CB), Option (OPT), etc. It is used in order, quote, and market data messages. SecurityType ensures correct handling based on instrument class. It supports routing, pricing, and regulatory reporting across diverse asset classes.

Tag 168: EffectiveTime
Tag 168 (EffectiveTime) is the UTC time when an order becomes active. It allows delayed activation, such as for time-based strategies. EffectiveTime differs from TransactTime (Tag 60) and supports conditional order execution. It is essential for automated trading systems requiring precise timing control.

Tag 169: StandInstDbType
Tag 169 (StandInstDbType) identifies the type of database used for standing settlement instructions: Proprietary (0), National (1), or Global (2). It helps locate instruction records. StandInstDbType supports automated settlement and reduces manual entry. It is used with StandInstDbName and StandInstDbID.

Tag 170: StandInstDbName
Tag 170 (StandInstDbName) is the name of the database containing standing settlement instructions. It provides context for instruction lookup. StandInstDbName is used with StandInstDbType (Tag 169) and supports centralized management of delivery details across large institutions.

Tag 171: StandInstDbID
Tag 171 (StandInstDbID) is a unique identifier for the standing instruction database. It enables precise retrieval of settlement rules. StandInstDbID is used in conjunction with StandInstDbType and StandInstDbName. It supports automation and accuracy in post-trade processing.

Tag 172: SettlDeliveryType
Tag 172 (SettlDeliveryType) specifies the delivery method: Free (1) or vs. Payment (2). It defines whether securities and cash are exchanged simultaneously. SettlDeliveryType supports settlement risk management and is used in DVP (Delivery vs. Payment) workflows to ensure secure transfer.

Tag 173: SettlDepositoryCode (replaced)
Tag 173 (SettlDepositoryCode) was used to identify the depository but is replaced. It has been deprecated in favor of more standardized identifiers. Modern systems use PartyIDs or MIC codes. This tag should not be used in FIX 4.4 implementations.

Tag 174: SettlBrkrCode (replaced)
Tag 174 (SettlBrkrCode) was used for settlement broker identification but is replaced. It is obsolete and should not be included. Current standards use PartyID fields for broker identification. Use of this tag may lead to compatibility issues.

Tag 175: SettlInstCode (replaced)
Tag 175 (SettlInstCode) was used to identify settlement institutions but is replaced. It has been superseded by PartyID structures. Applications should avoid this deprecated field to ensure compliance with FIX 4.4.

Tag 176: SecuritySettlAgentName (replaced)
Tag 176 was used for security settlement agent name but is replaced. Deprecated in favor of structured PartyID usage. Do not use in new implementations.

Tag 177: SecuritySettlAgentCode (replaced)
Tag 177 was used for agent code but is replaced. Use PartyID instead for standardized identification.

Tag 178: SecuritySettlAgentAcctNum (replaced)
Tag 178 was used for account number but is replaced. Modern systems use standardized account fields.

Tag 179: SecuritySettlAgentAcctName (replaced)
Tag 179 was used for account name but is replaced. Superseded by clearer field definitions.

Tag 180: SecuritySettlAgentContactName (replaced)
Tag 180 was used for contact name but is replaced. Use PartySubID for contact details.

Tag 181: SecuritySettlAgentContactPhone (replaced)
Tag 181 was used for phone number but is replaced. Deprecated in favor of structured communication fields.

Tag 182: CashSettlAgentName (replaced)
Tag 182 was used for cash agent name but is replaced. Use PartyID framework instead.

Tag 183: CashSettlAgentCode (replaced)
Tag 183 was used for cash agent code but is replaced. No longer valid in FIX 4.4.

Tag 184: CashSettlAgentAcctNum (replaced)
Tag 184 was used for cash account number but is replaced. Use modern account fields.

Tag 185: CashSettlAgentAcctName (replaced)
Tag 185 was used for cash account name but is replaced. Obsolete and should be omitted.

Tag 186: CashSettlAgentContactName (replaced)
Tag 186 was used for contact name but is replaced. Use standardized PartyID structures.

Tag 187: CashSettlAgentContactPhone (replaced)
Tag 187 was used for phone number but is replaced. Deprecated in FIX 4.4.

Tag 188: BidSpotRate
Tag 188 (BidSpotRate) is the spot exchange rate for the bid side in FX quotes. It represents the price at which the market maker will buy the base currency. BidSpotRate is used in FX-specific messages and supports accurate pricing in currency pairs.

Tag 189: BidForwardPoints
Tag 189 (BidForwardPoints) specifies the forward points added to the spot rate for the bid side in FX forwards. It determines the forward rate. BidForwardPoints is used with BidSpotRate (Tag 188) to calculate the total forward price.

Tag 190: OfferSpotRate
Tag 190 (OfferSpotRate) is the spot exchange rate for the offer (ask) side in FX quotes. It represents the price at which the market maker will sell the base currency. OfferSpotRate is critical for FX execution and pricing.

Tag 191: OfferForwardPoints
Tag 191 (OfferForwardPoints) specifies the forward points for the offer side in FX forwards. Combined with OfferSpotRate (Tag 190), it determines the forward rate. OfferForwardPoints supports accurate FX derivative pricing.

Tag 192: OrderQty2
Tag 192 (OrderQty2) is an optional second quantity field, often used for futures or complex instruments. It may represent contract size or multiplier-adjusted quantity. OrderQty2 supports instruments where standard OrderQty is insufficient.

Tag 193: SettlDate2
Tag 193 (SettlDate2) is a second settlement date, used in complex instruments like dual-currency bonds. It supports multiple payment dates and is critical for accurate settlement in structured products.

Tag 194: LastSpotRate
Tag 194 (LastSpotRate) is the spot rate associated with the last FX execution. It provides context for FX trade pricing and is used in Execution Reports for currency pairs.

Tag 195: LastForwardPoints
Tag 195 (LastForwardPoints) is the forward points of the last FX forward execution. Combined with LastSpotRate (Tag 194), it defines the full forward rate. It supports FX trade reconciliation.

Tag 196: AllocLinkID
Tag 196 (AllocLinkID) references a prior allocation message. It supports linking related allocations, such as corrections or partial updates. AllocLinkID enhances auditability and reconciliation.

Tag 197: AllocLinkType
Tag 197 (AllocLinkType) specifies the type of link: F/X Netting (0) or F/X Swap (1). It defines the relationship between linked allocations. AllocLinkType supports complex FX settlement workflows.

Tag 198: SecondaryOrderID
Tag 198 (SecondaryOrderID) is an alternate identifier for an order, often used by exchanges or clearinghouses. It supports cross-referencing between systems and enhances traceability.

Tag 199: NoIOIQualifiers
Tag 199 (NoIOIQualifiers) indicates the number of qualifiers in an IOI repeating group. It defines how many times IOIQualifier (Tag 104) repeats. Supports rich IOI descriptions.

Tag 200: MaturityMonthYear
Tag 200 (MaturityMonthYear) specifies the maturity of a futures or option in YYYYMM format. It identifies the contract month and is essential for derivatives trading.

Tag 201: PutOrCall (replaced)
Tag 201 was used for option type but is replaced by Product and SecurityType. Use SecurityType=OPT with PutOrCall in repeating groups.

Tag 202: StrikePrice
Tag 202 (StrikePrice) is the exercise price of an option. It defines the price at which the underlying can be bought (call) or sold (put). StrikePrice is critical for options pricing and execution.

Tag 203: CoveredOrUncovered
Tag 203 (CoveredOrUncovered) indicates whether an option position is covered (1) or uncovered (0). It affects margin and risk. Covered options are backed by the underlying asset.

Tag 204: CustomerOrFirm (replaced)
Tag 204 was used to classify order origin but is replaced by OrderCapacity and PartyIDs. Do not use.

Tag 205: MaturityDay (replaced)
Tag 205 was used for maturity day but is replaced. Use MaturityDate instead.

Tag 206: OptAttribute
Tag 206 (OptAttribute) specifies the style of an option: American (A) or European (E). It defines exercise rights and impacts pricing and risk models.

Tag 207: SecurityExchange
Tag 207 (SecurityExchange) identifies the exchange where a security is listed, using a MIC code. It supports accurate routing and market identification.

Tag 208: NotifyBrokerOfCredit
Tag 208 (NotifyBrokerOfCredit) indicates whether the broker should be notified of credit terms (Y/N). It supports credit risk management in OTC trading.

Tag 209: AllocHandlInst
Tag 209 (AllocHandlInst) specifies how allocations should be handled: Match (1), Forward (2), or Forward and Match (3). It guides post-trade processing.

Tag 210: MaxShow
Tag 210 (MaxShow) is the maximum quantity shown in a reserve order. It hides the full size to reduce market impact. MaxShow supports iceberg and dark pool strategies.

Tag 211: PegOffsetValue
Tag 211 (PegOffsetValue) specifies the offset from a reference price in a pegged order. For example, “pegged to bid minus $0.01”. It supports algorithmic execution.

Tag 212: XmlDataLen
Tag 212 (XmlDataLen) specifies the length of XML data in XmlData (Tag 213). It enables parsing of embedded XML payloads.

Tag 213: XmlData
Tag 213 (XmlData) carries XML-formatted data, such as custom instructions or regulatory details. It supports extensibility in FIX messages.

Tag 214: SettlInstRefID
Tag 214 (SettlInstRefID) references a prior settlement instruction. It supports cancellation or replacement of delivery details.

Tag 215: NoRoutingIDs
Tag 215 (NoRoutingIDs) indicates the number of routing entries in a repeating group. It defines how many times RoutingType and RoutingID repeat.

Tag 216: RoutingType
Tag 216 (RoutingType) specifies the type of routing instruction: Target Firm (1), Target List (2), etc.

Tag 217: RoutingID
Tag 217 (RoutingID) is the identifier for a routing destination, such as a broker or exchange.

Tag 218: Spread
Tag 218 (Spread) is the difference between bid and offer prices. It measures market liquidity and trading cost.

Tag 219: Benchmark (no longer used)
Tag 219 is deprecated. Use BenchmarkCurveName instead.

Tag 220: BenchmarkCurveCurrency
Tag 220 specifies the currency of the benchmark curve used in yield calculations.

Tag 221: BenchmarkCurveName
Tag 221 identifies the benchmark curve, such as LIBOR or Treasury, used for pricing.

Tag 222: BenchmarkCurvePoint
Tag 222 specifies the maturity point on the benchmark curve, e.g., “3M”.

Tag 223: CouponRate
Tag 223 (CouponRate) is the annual interest rate for a bond. It determines periodic payments.

Tag 224: CouponPaymentDate
Tag 224 is the date of the next coupon payment for a bond.

Tag 225: IssueDate
Tag 225 is the date a security was issued.

Tag 226: RepurchaseTerm (Deprecated)
Tag 226 is deprecated. Use alternative fields for repo terms.

Tag 227: RepurchaseRate (Deprecated)
Tag 227 is deprecated. No longer used.

Tag 228: Factor
Tag 228 (Factor) is the multiplier for mortgage-backed securities, adjusting for prepayment.

Tag 229: TradeOriginationDate
Tag 229 is the date a trade was initiated, which may precede execution.

Tag 230: ExDate
Tag 230 is the ex-dividend date for a stock. Buyers after this date do not receive the dividend.

Tag 231: ContractMultiplier
Tag 231 (ContractMultiplier) defines the contract size for futures or options, e.g., 100 shares per contract.

Tag 232: NoStipulations
Tag 232 indicates the number of stipulations in a repeating group.

Tag 233: StipulationType
Tag 233 specifies the type of stipulation, e.g., “Maturity” or “Coupon Range”.

Tag 234: StipulationValue
Tag 234 is the value associated with a stipulation, such as “5Y”.

Tag 235: YieldType
Tag 235 identifies the yield calculation method, e.g., “Current Yield”.

Tag 236: Yield
Tag 236 is the calculated yield of a bond, used in quotes and executions.

Tag 237: TotalTakedown
Tag 237 is the total underwriting fee in a bond offering.

Tag 238: Concession
Tag 238 is the concession paid to distributors in a bond sale.

Tag 239: RepoCollateralSecurityType (Deprecated)
Tag 239 is deprecated. Use SecurityType instead.

Tag 240: RedemptionDate (Deprecated)
Tag 240 is deprecated. Use MaturityDate.

Tag 241: UnderlyingCouponPaymentDate
Tag 241 (UnderlyingCouponPaymentDate) specifies the next coupon payment date for the underlying security in a derivative, such as an option or future on a bond. It helps determine cash flows and valuation. This field is used in complex instruments where the underlying’s payment schedule affects pricing and margin. It supports accurate risk modeling and accounting. While optional, it is essential for fixed-income derivatives. The date is formatted in YYYYMMDD and ensures correct attribution of interest timing in structured products and multi-leg strategies.

Tag 242: UnderlyingIssueDate
Tag 242 (UnderlyingIssueDate) indicates the original issuance date of the underlying security in a derivative contract. It is used to determine the age, maturity, and historical context of the underlying asset. This information supports pricing, risk analysis, and compliance. For bonds or structured products, the issue date affects accrued interest and yield calculations. It is formatted as YYYYMMDD and is particularly relevant in options or futures linked to debt instruments. UnderlyingIssueDate enhances transparency in derivative valuation and supports accurate lifecycle tracking.

Tag 243: UnderlyingRepoCollateralSecurityType (Deprecated)
Tag 243 (UnderlyingRepoCollateralSecurityType) was used to specify the type of collateral in a repurchase agreement involving the underlying security but is now deprecated. It has been removed from active use in FIX 4.4 due to redundancy and lack of standardization. Modern implementations rely on SecurityType (Tag 167) and structured repeating groups for collateral identification. Applications should not include this tag. Its use may cause parsing errors or interoperability issues. It is recommended to use current field standards for repo and collateral messaging.

Tag 244: UnderlyingRepurchaseTerm (Deprecated)
Tag 244 (UnderlyingRepurchaseTerm) was intended to define the term of a repurchase agreement for the underlying security but is deprecated. It is no longer used in FIX 4.4. The field lacked clarity and consistency in implementation. Current standards use alternative mechanisms for defining repo terms. Applications should avoid this tag. Its presence may be ignored or rejected. Use of structured fields or custom data in repeating groups is preferred for specifying repurchase terms in modern trading systems.

Tag 245: UnderlyingRepurchaseRate (Deprecated)
Tag 245 (UnderlyingRepurchaseRate) was used to specify the interest rate on a repurchase agreement for the underlying security but is deprecated. It has been removed from FIX 4.4 due to inconsistent usage and redundancy. The rate information is now conveyed through other pricing fields or application-specific extensions. This tag should not be used in new implementations. Its inclusion may lead to parsing issues. Use standardized interest rate fields or custom XML data for repo rate transmission in current workflows.

Tag 246: UnderlyingFactor
Tag 246 (UnderlyingFactor) specifies the adjustment factor for the underlying security in a derivative, such as a multiplier for mortgage-backed securities. It accounts for prepayments, amortization, or structural changes. This field ensures accurate valuation and margin calculation. For example, a factor of 0.95 indicates 95% of the original principal remains. It is used in futures and options on bonds or MBS. UnderlyingFactor supports risk modeling and is critical for correct position sizing and performance attribution in complex instruments.

Tag 247: UnderlyingRedemptionDate (Deprecated)
Tag 247 (UnderlyingRedemptionDate) was used to indicate the redemption date of the underlying security but is deprecated. It has been superseded by MaturityDate and other standardized fields. Redemption and maturity are now treated uniformly. This tag should not be used. Its functionality is covered by MaturityMonthYear (Tag 200) and SettlDate (Tag 64). Modern systems rely on consistent date handling. Avoid deprecated tags to ensure compatibility and clarity in derivative and fixed-income messaging.

Tag 248: LegCouponPaymentDate
Tag 248 (LegCouponPaymentDate) specifies the next coupon payment date for a leg in a multi-leg instrument, such as a swap or convertible bond. It enables accurate cash flow forecasting per leg. This field is used in complex derivatives with multiple underlying components. It supports pricing, risk, and settlement processes. LegCouponPaymentDate is formatted as YYYYMMDD and ensures each leg’s payment schedule is clearly defined. It enhances transparency in structured products and is essential for correct accounting and performance measurement.

Tag 249: LegIssueDate
Tag 249 (LegIssueDate) indicates the issuance date of a leg in a multi-leg security. It provides historical context for that leg’s valuation and risk profile. Used in swaps, straddles, or convertible bonds, it helps determine accrued interest and maturity. LegIssueDate is formatted as YYYYMMDD and supports accurate lifecycle tracking. It is particularly relevant when legs have different tenors or structures. This field enhances precision in derivative analysis and ensures correct handling of non-uniform components in composite financial instruments.

Tag 250: LegRepoCollateralSecurityType (Deprecated)
Tag 250 (LegRepoCollateralSecurityType) was used to define the collateral type for a leg in a repo-based derivative but is deprecated. It is obsolete in FIX 4.4 and should not be used. The functionality is now handled through SecurityType and PartyID structures. Including this tag may cause parsing errors. Modern systems use standardized fields for collateral identification. Avoid deprecated tags to ensure message clarity and interoperability in multi-leg and repo-related trading workflows.

Tag 251: LegRepurchaseTerm (Deprecated)
Tag 251 (LegRepurchaseTerm) was intended to specify the repurchase term for a leg in a multi-leg repo transaction but is deprecated. It lacked consistent implementation and has been removed from FIX 4.4. Current standards use alternative methods for defining repo terms. This tag should not be used. Its presence may be ignored. Use structured repeating groups or custom extensions for conveying repurchase terms in complex instruments.

Tag 252: LegRepurchaseRate (Deprecated)
Tag 252 (LegRepurchaseRate) was used to indicate the interest rate on a repurchase agreement for a leg but is deprecated. It is no longer supported in FIX 4.4. The rate is now conveyed through pricing or yield fields. Applications should not include this tag. Its use may lead to compatibility issues. Use standardized interest rate mechanisms or XML data for transmitting repo rates in multi-leg derivative transactions.

Tag 253: LegFactor
Tag 253 (LegFactor) specifies the adjustment multiplier for a leg in a multi-leg instrument, such as a swap leg or option leg. It accounts for amortization, prepayment, or structural changes. For example, a factor of 0.90 means 90% of the original notional remains. It supports accurate valuation, margining, and risk modeling. LegFactor is essential for instruments with evolving notional values and ensures correct position tracking and performance attribution in complex derivatives.

Tag 254: LegRedemptionDate (Deprecated)
Tag 254 (LegRedemptionDate) was used to indicate the redemption date of a leg in a multi-leg instrument but is deprecated. It has been replaced by MaturityDate and SettlDate. This tag should not be used. Its functionality is covered by standardized date fields. Avoid deprecated tags to ensure clean, interoperable messaging. Use MaturityMonthYear (Tag 200) or SettlDate (Tag 64) for defining leg-specific maturity in structured products.

Tag 255: CreditRating
Tag 255 (CreditRating) specifies the credit rating of a security, such as “Aaa” (Moody’s) or “AAA” (S&P). It is used in fixed-income and corporate bond trading to assess credit risk. CreditRating supports risk management, compliance, and investment policy checks. It may appear in quotes, orders, or market data. The rating agency is implied or specified via context. This field enhances transparency and supports automated credit screening in portfolio and algorithmic trading systems.

Tag 256: UnderlyingCreditRating
Tag 256 (UnderlyingCreditRating) specifies the credit rating of the underlying security in a derivative. It helps assess the risk of options, futures, or swaps linked to bonds or corporate debt. This field supports margin calculation, risk modeling, and regulatory reporting. It is particularly relevant in OTC derivatives and structured products. UnderlyingCreditRating ensures that risk systems have complete information about the quality of the referenced asset.

Tag 257: LegCreditRating
Tag 257 (LegCreditRating) specifies the credit rating for a leg in a multi-leg derivative. It allows per-leg risk assessment in instruments like cross-currency swaps or structured notes. This field supports granular risk management and compliance. LegCreditRating ensures that each component’s credit quality is evaluated independently. It is essential for accurate margining and counterparty risk analysis in complex, multi-asset transactions.

Tag 258: TradedFlatSwitch
Tag 258 (TradedFlatSwitch) indicates whether a bond is traded without accrued interest (Y/N). When ‘Y’, the price does not include accrued interest, which is paid separately. This is common in certain markets or for specific bond types. TradedFlatSwitch supports accurate pricing and settlement. It ensures correct calculation of total trade value and prevents misunderstandings between counterparties during confirmation and clearing.

Tag 259: BasisFeatureDate
Tag 259 (BasisFeatureDate) specifies the date when a bond’s yield basis changes, such as a step-up coupon or reset date. It is used in floating-rate or structured notes. BasisFeatureDate supports accurate yield and price calculations. It helps traders and systems anticipate changes in cash flows. This field is essential for modeling instruments with non-standard payment features and ensures correct valuation throughout the bond’s life.

Tag 260: BasisFeaturePrice
Tag 260 (BasisFeaturePrice) specifies the price associated with a bond’s basis feature, such as a call or put price. It defines the value at which a feature can be exercised. BasisFeaturePrice supports valuation of embedded options in bonds. It is used in risk systems and pricing models. This field ensures accurate assessment of optionality and helps determine fair value in callable or puttable securities.

Tag 262: MDReqID
Tag 262 (MDReqID) is a unique identifier assigned by the requester in a Market Data Request message (MsgType V). It is echoed in Market Data responses to link requests to updates. MDReqID supports subscription management and ensures correct handling of multiple data streams. It is essential for tracking and canceling market data subscriptions. This field enables efficient, targeted delivery of price and volume information in high-frequency environments.

Tag 263: SubscriptionRequestType
Tag 263 (SubscriptionRequestType) specifies the type of market data subscription: Snapshot (0), Subscribe (1), or Unsubscribe (2). It controls how the receiver processes the request. “Subscribe” starts a streaming feed, “Unsubscribe” stops it. SubscriptionRequestType is critical for managing real-time data flow. It supports efficient bandwidth use and ensures clients receive only the data they need.

Tag 264: MarketDepth
Tag 264 (MarketDepth) specifies the number of price levels (e.g., top 5) to return in a market data response. A value of 1 returns only the best bid and offer. Higher values provide deeper book visibility. MarketDepth supports algorithmic trading and liquidity analysis. It allows clients to tailor data volume to their strategy. This field is essential for managing bandwidth and processing load in market data systems.

Tag 265: MDUpdateType
Tag 265 (MDUpdateType) specifies the type of market data update: Full Refresh (0) or Incremental (1). Full Refresh sends the entire book; Incremental sends only changes. MDUpdateType optimizes bandwidth and processing. It ensures clients can reconstruct the order book correctly. This field is fundamental to efficient market data delivery and supports high-performance trading systems.

Tag 266: AggregatedBook
Tag 266 (AggregatedBook) indicates whether market depth is aggregated by price (Y) or shows individual orders (N). When ‘Y’, all orders at the same price are summed. When ‘N’, each order is listed separately. AggregatedBook affects liquidity perception and trading strategy. It supports different trading styles, from iceberg detection to volume analysis. This field enhances flexibility in market data presentation.

Tag 267: NoMDEntryTypes
Tag 267 (NoMDEntryTypes) specifies the number of MDEntryType values in a repeating group within a Market Data Request. It defines which types of entries (bid, ask, trade) the client wants to receive. NoMDEntryTypes enables selective subscription. It supports efficient data filtering and reduces unnecessary message traffic. This field is key to customizing market data feeds.

Tag 268: NoMDEntries
Tag 268 (NoMDEntries) indicates the number of market data entries in a repeating group. It defines how many times MDEntryType, MDEntryPx, and MDEntrySize repeat. NoMDEntries supports batch transmission of price levels. It is used in both full refresh and incremental updates. This field is essential for parsing market data messages and reconstructing the order book.

Tag 269: MDEntryType
Tag 269 (MDEntryType) specifies the type of market data entry: Bid (0), Offer (1), Trade (2), Opening Price (4), etc. It categorizes each price level in the book. MDEntryType enables proper sorting and display. It supports trading logic, such as identifying last sale or spread. This field is fundamental to interpreting market data messages.

Tag 270: MDEntryPx
Tag 270 (MDEntryPx) is the price of a market data entry. It represents the bid, offer, or last traded price. MDEntryPx is a core component of price discovery. It is used in algorithms for execution, valuation, and risk. The price is expressed in the security’s currency and supports high-precision trading. This field is critical for real-time decision-making.

Tag 271: MDEntrySize
Tag 271 (MDEntrySize) is the quantity available at a given price level in the market data feed. It indicates liquidity depth. MDEntrySize is used with MDEntryPx to assess supply and demand. It supports volume-weighted strategies and liquidity analysis. This field is essential for understanding market strength and executing large orders efficiently.

Tag 272: MDEntryDate
Tag 272 (MDEntryDate) is the date of a market data entry, formatted as YYYYMMDD. It is used when the entry refers to a historical or non-current event. For real-time data, MDEntryTime (Tag 273) is preferred. MDEntryDate supports historical data feeds and end-of-day reporting. It ensures correct temporal context for delayed or archived market information.

Tag 273: MDEntryTime
Tag 273 (MDEntryTime) is the time of a market data entry, formatted as HH:MM:SS.sss. It provides millisecond precision for real-time updates. MDEntryTime supports latency analysis and event sequencing. It is critical for high-frequency trading and audit trails. This field ensures accurate timestamping of price changes and trade executions in the market data stream.

Tag 274: TickDirection
Tag 274 (TickDirection) indicates the direction of the last price change: Plus Tick (0), Zero-Plus Tick (1), Minus Tick (2), or Zero-Minus Tick (3). It shows momentum and trading pressure. TickDirection supports technical analysis and short-term trading strategies. It helps algorithms detect trends and avoid adverse selection in fast-moving markets.

Tag 275: MDMkt
Tag 275 (MDMkt) identifies the market (exchange or ECN) from which market data originated, using a MIC code. It supports multi-venue analysis and best execution reporting. MDMkt enables traders to compare prices across exchanges. It is essential for smart order routing and liquidity aggregation in fragmented markets.

Tag 276: QuoteCondition
Tag 276 (QuoteCondition) describes the condition of a quote: Open (A), Closed (B), or Locked (C). It provides context on market state. QuoteCondition helps traders interpret price validity. It is particularly relevant in fast-moving or halted markets. This field supports risk management and execution quality assessment.

Tag 277: TradeCondition
Tag 277 (TradeCondition) specifies the condition of a trade: Regular (A), Non-Consolidated (B), or Cross (C). It indicates execution context. TradeCondition supports regulatory reporting and best execution analysis. It helps distinguish between different types of transactions for compliance and performance measurement.

Tag 278: MDEntryID
Tag 278 (MDEntryID) is a unique identifier for a market data entry. It enables tracking of individual price levels across updates. MDEntryID supports delta-based feeds and order book reconstruction. It is particularly useful in incremental updates to identify added, changed, or deleted entries. This field enhances efficiency and accuracy in market data processing.

Tag 279: MDUpdateAction
Tag 279 (MDUpdateAction) specifies the action on a market data entry: New (0), Change (1), or Delete (2). It controls how the entry should be processed in incremental updates. MDUpdateAction enables efficient book maintenance. It is essential for real-time order book reconstruction and supports high-performance trading systems.

Tag 280: MDEntryRefID
Tag 280 (MDEntryRefID) references the ID of a prior market data entry, typically used when modifying or deleting. It links updates to original entries. MDEntryRefID supports accurate book management. It ensures correct handling of price changes and cancellations in incremental market data feeds.

Tag 281: MDReqRejReason
Tag 281 (MDReqRejReason) specifies why a market data request was rejected: Invalid Subscription (0), Unknown MDEntryType (1), etc. It provides feedback for troubleshooting. MDReqRejReason enhances transparency and helps clients adjust their requests. This field is returned in Market Data Request Reject messages.

Tag 282: MDEntryOriginator
Tag 282 (MDEntryOriginator) identifies the trader or firm that placed the order behind a market data entry. It is used in quote or order book data to show origin. MDEntryOriginator supports transparency and relationship management. It is particularly relevant in RFQ or dark pool environments.

Tag 283: LocationID
Tag 283 (LocationID) identifies the physical or logical location of a trading desk or gateway. It supports latency monitoring and regulatory reporting. LocationID enhances auditability and is used in high-frequency trading to analyze geographic performance and compliance with clock synchronization rules.

Tag 284: DeskID
Tag 284 (DeskID) specifies the trading desk responsible for an order or trade. It supports internal attribution and performance measurement. DeskID enables firms to track activity by desk, such as equities, fixed income, or derivatives. It is used in execution reports and supports management reporting and compliance.

Tag 285: DeleteReason
Tag 285 (DeleteReason) specifies why a market data entry was deleted: Canceled (1), Expired (2), or Market Closed (3). It provides context for removals in the order book. DeleteReason supports accurate book reconstruction and audit. It helps distinguish between intentional and system-driven deletions.

Tag 286: OpenCloseSettlFlag
Tag 286 (OpenCloseSettlFlag) indicates whether a trade is for opening (0), closing (1), or intraday (2) a position. It affects margin and accounting. This field supports accurate position tracking and is essential for tax and regulatory reporting in futures and options trading.

Tag 287: SellerDays
Tag 287 (SellerDays) specifies the number of days the seller has held a security, used in short sale regulation. It supports compliance with locate requirements and short-selling rules. SellerDays helps brokers verify eligibility for short sales and prevents regulatory violations in equity trading.

Tag 288: MDEntryBuyer
Tag 288 (MDEntryBuyer) identifies the buyer in a market data entry, such as a large block trade. It supports transparency in dark pools or OTC markets. MDEntryBuyer enables relationship tracking and is used in quote responses to indicate interest.

Tag 289: MDEntrySeller
Tag 289 (MDEntrySeller) identifies the seller in a market data entry. It provides context on supply-side activity. MDEntrySeller supports counterparty analysis and is used in RFQ and block trading environments to signal interest from specific firms.

Tag 290: MDEntryPositionNo
Tag 290 (MDEntryPositionNo) specifies the priority or position of a price level in the order book, such as first or second in the queue. It supports time-pro-rata allocation and price-time matching. MDEntryPositionNo enhances fairness in execution and is used in exchanges with queue-based matching.

Tag 291: FinancialStatus
Tag 291 (FinancialStatus) indicates a company’s financial condition: Bankrupt (1), Pending Delisting (2), etc. It supports risk management and compliance. FinancialStatus alerts traders to potential liquidity or credit issues. It is used in market data and news messages to inform trading decisions.

Tag 292: CorporateAction
Tag 292 (CorporateAction) specifies a corporate event affecting a security: Dividend (A), Split (B), or Merger (C). It supports pre- and post-event pricing adjustments. CorporateAction ensures correct handling of stock adjustments and cash payments. It is essential for accurate position and valuation management.

Tag 293: DefBidSize
Tag 293 (DefBidSize) is the default bid size in a market data entry when the full size is hidden. It represents the visible portion of a reserve order. DefBidSize supports liquidity estimation in dark or iceberg books. It is used with MaxShow (Tag 210) to manage displayed depth.

Tag 294: DefOfferSize
Tag 294 (DefOfferSize) is the default offer size in a market data entry for hidden orders. It shows the visible quantity at the ask. DefOfferSize supports depth analysis in non-transparent markets. It helps algorithms estimate true liquidity and avoid information leakage.

Tag 295: NoQuoteEntries
Tag 295 (NoQuoteEntries) indicates the number of quote entries in a Quote message. It defines the size of the repeating group containing Symbol, BidPx, and OfferPx. NoQuoteEntries supports batch quoting in RFQ workflows. It is essential for efficient transmission of multiple quotes.

Tag 296: NoQuoteSets
Tag 296 (NoQuoteSets) specifies the number of quote sets in a message, used in mass quoting. It defines how many QuoteSetID groups repeat. NoQuoteSets supports large-scale quote distribution, such as in bond or swap markets. It enhances efficiency in wholesale quoting environments.

Tag 297: QuoteStatus
Tag 297 (QuoteStatus) indicates the status of a quote: Accepted (0), Canceled (1), or Pending (2). It is returned in Quote Status Report messages. QuoteStatus supports quote lifecycle tracking and ensures clients know if their quotes are active. It is essential for RFQ and dealer-to-client workflows.

Tag 298: QuoteCancelType
Tag 298 (QuoteCancelType) specifies the scope of a quote cancellation: Cancel for Symbol (1), Cancel for Security Type (2), or Cancel All Quotes (3). It controls the breadth of cancellation. QuoteCancelType supports flexible quote management and is used in mass cancel requests.

Tag 299: QuoteEntryID
Tag 299 (QuoteEntryID) is a unique identifier for a quote entry in a multi-quote message. It enables individual tracking of quotes within a set. QuoteEntryID supports precise referencing and cancellation. It is essential for managing complex quote responses in fixed-income and derivatives markets.

Tag 300: QuoteRejectReason
Tag 300 (QuoteRejectReason) specifies why a quote was rejected: Unknown Symbol (1), Price Exceeds Limit (2), etc. It is returned in Quote Response messages. QuoteRejectReason provides actionable feedback and supports error resolution in RFQ workflows.

Tag 301: QuoteResponseLevel
Tag 301 (QuoteResponseLevel) specifies the level of detail in a quote response: No Acknowledgment (0), Acknowledge Only (1), or Acknowledge with Error (2). It controls feedback verbosity. QuoteResponseLevel supports efficient communication and reduces message overhead in high-volume quoting.

Tag 302: QuoteSetID
Tag 302 (QuoteSetID) uniquely identifies a set of quotes, such as a basket or portfolio. It supports mass quoting and response management. QuoteSetID enables grouping of related quotes and ensures coherent handling of multi-security requests.

Tag 303: QuoteRequestType
Tag 303 (QuoteRequestType) specifies the type of quote request: Manual (1), Automatic (2), or Derivative (3). It indicates the source and intent. QuoteRequestType supports workflow routing and helps providers tailor responses to request context.

Tag 304: TotNoQuoteEntries
Tag 304 (TotNoQuoteEntries) specifies the total number of quote entries across all messages in a quote response. It supports reconciliation and ensures completeness. TotNoQuoteEntries is used in multi-message quote workflows to confirm all entries have been received.

Tag 305: UnderlyingSecurityIDSource
Tag 305 (UnderlyingSecurityIDSource) identifies the source of the underlying security’s ID, such as ISIN (4) or CUSIP (1). It ensures unambiguous identification of the underlying in derivatives. It is used with UnderlyingSecurityID (Tag 309) and supports accurate routing and clearing.

Tag 306: UnderlyingIssuer
Tag 306 (UnderlyingIssuer) specifies the name of the issuing entity for the underlying security in a derivative instrument, such as an option, future, or structured product. It provides essential context for credit analysis, risk assessment, and compliance. While not a unique identifier, it enhances clarity when combined with other fields like Symbol or SecurityID. UnderlyingIssuer is particularly useful for fixed-income derivatives or equity options where issuer identity impacts valuation and margin. It supports research, reporting, and execution workflows by ensuring accurate attribution of the referenced asset.

Tag 307: UnderlyingSecurityDesc
Tag 307 (UnderlyingSecurityDesc) provides a free-form textual description of the underlying security in a derivative contract. It supplements structured identifiers with human-readable details, such as “Apple Inc. 3.0% Bond Due 2040” or “Microsoft Quarterly Call Option.” This field enhances trader recognition and supports compliance and audit processes. While not parsed algorithmically, it improves transparency in complex instruments. UnderlyingSecurityDesc is used in quotes, orders, and market data to convey characteristics not captured by standard identifiers, ensuring clarity in trading and reporting.

Tag 308: UnderlyingSecurityExchange
Tag 308 (UnderlyingSecurityExchange) identifies the exchange or trading venue where the underlying security is listed, using a market identifier code (MIC). It ensures accurate routing and market data handling for derivatives linked to exchange-traded assets. This field is critical for determining the source of pricing, trading hours, and regulatory jurisdiction. It supports smart order routing and best execution analysis. UnderlyingSecurityExchange is used in options, futures, and ETFs to maintain consistency between the derivative and its underlying market.

Tag 309: UnderlyingSecurityID
Tag 309 (UnderlyingSecurityID) is the unique identifier (e.g., CUSIP, ISIN, or proprietary code) assigned to the underlying security in a derivative instrument. It enables precise identification, reducing ambiguity in clearing and settlement. Used in conjunction with UnderlyingSecurityIDSource (Tag 305), it ensures the correct asset is referenced, especially when symbols overlap across markets. This field is essential for accurate risk modeling, margin calculation, and lifecycle management of options, futures, and structured products in global trading environments.

Tag 310: UnderlyingSecurityType
Tag 310 (UnderlyingSecurityType) specifies the type of the underlying security in a derivative, such as Common Stock (COMMON), Corporate Bond (CORP), or Index (INDEX). It supports correct handling of pricing, margin, and regulatory requirements. This field ensures that trading systems apply appropriate logic based on the asset class. For example, an option on a bond is treated differently than one on a stock. UnderlyingSecurityType is essential for accurate risk modeling and execution in multi-asset derivative strategies.

Tag 311: UnderlyingSymbol
Tag 311 (UnderlyingSymbol) is the ticker symbol of the underlying security in a derivative contract, such as “AAPL” for an Apple option. It provides a human-readable reference for traders and systems. While not unique across markets, it is widely used for quick identification. UnderlyingSymbol should be used with UnderlyingSecurityID and UnderlyingSecurityIDSource for unambiguous identification. This field is critical in order routing, market data, and execution reporting for options, futures, and swaps.

Tag 312: UnderlyingSymbolSfx
Tag 312 (UnderlyingSymbolSfx) is a suffix used to denote special characteristics of the underlying security, such as warrant (WS) or preferred share (PR). Though rarely used in modern markets, it supports legacy symbol conventions on certain exchanges. The suffix is appended to the UnderlyingSymbol (Tag 311) to provide additional context. While largely historical, it may still appear in specific regional or exchange-specific implementations. Its use is optional and typically limited to non-standard securities.

Tag 313: UnderlyingMaturityMonthYear
Tag 313 (UnderlyingMaturityMonthYear) specifies the maturity of the underlying security in a derivative, formatted as YYYYMM. It is used when the underlying is a futures contract, bond, or other time-bound instrument. This field ensures correct identification of the specific contract series, especially in options on futures. It supports accurate pricing, margining, and clearing. UnderlyingMaturityMonthYear is essential for managing expiration cycles and avoiding misidentification in multi-contract environments.

Tag 314: UnderlyingMaturityDay (replaced)
Tag 314 (UnderlyingMaturityDay) was used to specify the day of the month for the underlying security’s maturity but is replaced in FIX 4.4. It has been deprecated due to redundancy and lack of standardization. The full maturity date is now conveyed using MaturityDate or derived from MaturityMonthYear (Tag 313) and exchange rules. Applications should not use this tag. Its inclusion may cause parsing issues. Modern systems rely on complete date fields for clarity and consistency.

Tag 315: UnderlyingPutOrCall (replaced)
Tag 315 (UnderlyingPutOrCall) was used to indicate whether the underlying security was a put or call option but is replaced in FIX 4.4. It is obsolete because the underlying of an option is typically a non-option instrument (e.g., stock or bond). If the underlying is another option, its type should be defined using SecurityType and PutOrCall in a nested context. This tag should not be used. Its functionality is handled through structured repeating groups in modern implementations.

Tag 316: UnderlyingStrikePrice
Tag 316 (UnderlyingStrikePrice) specifies the strike price of the underlying option in a multi-leg derivative, such as a spread or straddle. It is used when the underlying itself is an option contract. This field supports accurate valuation and risk modeling of complex strategies. UnderlyingStrikePrice ensures that pricing engines and margin systems correctly interpret the payoff structure. It is essential for correct handling of compound or nested options in advanced trading and clearing workflows.

Tag 317: UnderlyingOptAttribute
Tag 317 (UnderlyingOptAttribute) specifies the exercise style of the underlying option in a derivative: American (A) or European (E). It affects pricing, volatility modeling, and early exercise risk. This field is used when the underlying of a derivative is itself an option. UnderlyingOptAttribute ensures that risk systems apply the correct valuation methodology. It is critical for accurate Greeks calculation and margining in complex, multi-layered options strategies.

Tag 318: UnderlyingCurrency
Tag 318 (UnderlyingCurrency) specifies the currency in which the underlying security is denominated, using ISO 4217 codes (e.g., USD, EUR). It is essential for derivatives involving foreign assets, such as FX options or ADRs. UnderlyingCurrency supports accurate pricing, margin calculation, and settlement handling. It helps determine FX conversion requirements and ensures correct valuation in multi-currency portfolios. This field is critical for risk management and compliance in global trading environments.

Tag 319: RatioQty (replaced)
Tag 319 (RatioQty) was used to specify the quantity ratio in a multi-leg derivative, such as the number of underlying shares per option contract. However, it has been replaced in FIX 4.4 by more structured fields within repeating groups, such as LegRatioQty. Its use is deprecated to support greater flexibility in defining complex instruments. Applications should not include this tag. Continued use may result in parsing errors or interoperability issues. Modern implementations rely on standardized leg-based definitions for accurate representation of ratios in options, spreads, and baskets.

Tag 320: SecurityReqID
Tag 320 (SecurityReqID) is a unique identifier assigned by the requester in a Security Definition Request message (MsgType x). It links the request to its corresponding response. This tag ensures message correlation and supports tracking of security inquiries. It is mandatory in security lookup workflows and is echoed in the Security Response message. SecurityReqID enables efficient handling of requests for instrument details, such as options, futures, or bonds, and is essential for automated trading systems requiring dynamic security discovery.

Tag 321: SecurityRequestType
Tag 321 (SecurityRequestType) specifies the type of security request: Request Security ID (0), Request All Securities (1), or Request List of Securities (2). It controls the scope of the query in a Security Definition Request. This field enables clients to retrieve specific or broad instrument data. It supports market data initialization, trading system setup, and compliance checks. SecurityRequestType is essential for flexible and efficient interaction with security master databases in exchange and broker environments.

Tag 322: SecurityResponseID
Tag 322 (SecurityResponseID) is a unique identifier assigned by the responder to a security request. It references the original SecurityReqID (Tag 320) and ensures message linkage. SecurityResponseID is included in Security Definition messages (MsgType y) and supports reconciliation of request-response pairs. It enables clients to verify that the correct data has been returned and is critical for reliable security discovery and onboarding in automated trading environments.

Tag 323: SecurityResponseType
Tag 323 (SecurityResponseType) indicates the result of a security request: Accept (1), Reject (2), or Not Found (3). It is returned in the Security Definition message and provides feedback on the request outcome. This field helps clients determine whether the requested instrument exists or if there was an error. SecurityResponseType supports troubleshooting and ensures accurate handling of security definitions in trading and market data systems.

Tag 324: SecurityStatusReqID
Tag 324 (SecurityStatusReqID) is a unique identifier assigned by the requester in a Security Status Request message (MsgType f). It is echoed in the Security Status response to maintain message correlation. This tag supports tracking of real-time status inquiries for a security, such as trading halts or auction states. SecurityStatusReqID is essential for monitoring market conditions and ensuring timely updates in algorithmic and high-frequency trading strategies.

Tag 325: UnsolicitedIndicator
Tag 325 (UnsolicitedIndicator) indicates whether a message is unsolicited (Y) or in response to a request (N). It is used in Security Status (MsgType g) and other broadcast messages. When ‘Y’, the message is sent proactively by the exchange or broker. This field helps receivers distinguish between event-driven alerts and query responses. UnsolicitedIndicator supports real-time market monitoring and is critical for timely dissemination of trading halts or corporate actions.

Tag 326: SecurityTradingStatus
Tag 326 (SecurityTradingStatus) indicates the current trading state of a security: Open (2), Halted (4), Closed (6), or Pre-Close (10). It is used in Security Status messages to inform clients of market conditions. This field supports algorithmic trading logic, risk control, and order routing decisions. SecurityTradingStatus ensures traders are aware of execution eligibility and helps prevent order submission during non-trading periods.

Tag 327: HaltReason
Tag 327 (HaltReason) specifies why a security is halted: News Dissemination (0), Order Influx (1), or Regulatory Concerns (3). It provides context for trading interruptions. HaltReason is included in Security Status messages and supports transparency. It helps traders understand market dynamics and adjust strategies accordingly. This field is essential for compliance and operational awareness in fast-moving markets.

Tag 328: InViewOfCommon
Tag 328 (InViewOfCommon) indicates whether a trading halt is due to a pending corporate action affecting common stock (Y/N). It is used in conjunction with HaltReason to provide additional context. When ‘Y’, it signals that the halt is related to dividends, splits, or mergers. This field supports investor communication and helps market participants anticipate resumption of trading after corporate events.

Tag 329: DueToRelated
Tag 329 (DueToRelated) indicates if a trading halt is due to issues with a related security (Y/N). For example, a halt in a derivative due to a halt in the underlying stock. This field enhances transparency in interconnected markets. It helps traders understand cross-market impacts and supports risk management in multi-asset strategies. DueToRelated is critical for accurate interpretation of trading status messages.

Tag 330: BuyVolume
Tag 330 (BuyVolume) represents the total volume of buy-side trades for a security over a specified period. It is used in Market Data messages to indicate demand. BuyVolume supports liquidity analysis and sentiment assessment. When compared to SellVolume (Tag 331), it helps identify buying pressure. This field is valuable for algorithmic strategies that monitor order flow and volume imbalance in real time.

Tag 331: SellVolume
Tag 331 (SellVolume) represents the total volume of sell-side trades for a security over a period. It indicates supply in the market. SellVolume is used with BuyVolume (Tag 330) to analyze net order flow. High sell volume may signal distribution or bearish sentiment. This field supports technical analysis and execution algorithms that adapt to market conditions based on trade imbalance.

Tag 332: HighPx
Tag 332 (HighPx) is the highest price at which a security has traded during the current trading session. It is updated in real time and appears in Market Data and Execution Reports. HighPx supports technical analysis, volatility measurement, and price limit checks. It helps traders assess resistance levels and is used in algorithms that track daily price ranges for breakout or reversal strategies.

Tag 333: LowPx
Tag 333 (LowPx) is the lowest traded price for a security during the session. It is used in Market Data messages and Execution Reports. LowPx supports support level analysis and volatility monitoring. Combined with HighPx (Tag 332), it defines the daily trading range. This field is essential for range-based strategies and risk models that rely on intraday price extremes.

Tag 334: Adjustment
Tag 334 (Adjustment) indicates whether a price or trade correction has occurred: Cancel (1), Error (2), or Correction (3). It is used in Market Data Incremental Refresh messages to signal adjustments to prior data. Adjustment ensures data integrity and supports accurate book reconstruction. It helps algorithms distinguish between new trades and corrected entries, preventing misinterpretation of market activity.

Tag 335: TradSesReqID
Tag 335 (TradSesReqID) is a unique identifier assigned by the requester in a Trading Session Status Request message (MsgType g). It is echoed in the response to maintain message linkage. This tag supports tracking of session status inquiries. TradSesReqID is essential for monitoring exchange operating states and ensuring trading systems are synchronized with market hours.

Tag 336: TradingSessionID
Tag 336 (TradingSessionID) identifies a specific trading session, such as “DAY”, “AFTER_HOURS”, or “CLOSE”. It is used in Trading Session Status messages to differentiate between multiple sessions in a day. TradingSessionID supports global trading across time zones and ensures correct handling of pre-market, regular, and post-market activities. It is critical for algorithmic systems that operate across session boundaries.

Tag 337: ContraTrader
Tag 337 (ContraTrader) identifies the trader on the opposite side of a trade, typically used in voice-brokered or hybrid markets. It supports relationship tracking and compliance. ContraTrader is included in Execution Reports and helps firms monitor counterparty interactions. This field is particularly relevant in less automated markets where trader identity affects execution quality and best execution obligations.

Tag 338: TradSesMethod
Tag 338 (TradSesMethod) specifies the trading method used in a session: Electronic (1), Open Outcry (2), or Hybrid (3). It provides context on execution mechanics. TradSesMethod supports regulatory reporting and best execution analysis. It helps clients understand how orders are matched and is essential for transparency in mixed-mode trading environments.

Tag 339: TradSesMode
Tag 339 (TradSesMode) indicates the mode of a trading session: Testing (1), Simulated (2), or Production (3). It distinguishes between live and non-live environments. TradSesMode prevents accidental trading in test systems. It is used in session status messages and supports operational clarity. This field is essential for system integration and user awareness in development and production workflows.

Tag 340: TradSesStatus
Tag 340 (TradSesStatus) indicates the current status of a trading session: Halted (1), Open (2), Closed (3), or Pre-Close (5). It is used in Trading Session Status messages to inform participants of market state. TradSesStatus supports automated trading logic and order routing. It ensures systems respond appropriately to session changes and is critical for operational reliability.

Tag 341: TradSesStartTime
Tag 341 (TradSesStartTime) is the scheduled start time of a trading session in UTC. It is included in Trading Session Status messages. This field helps clients prepare for market opening and synchronize systems. TradSesStartTime supports pre-market activities like order entry and risk checks. It is essential for time-sensitive trading strategies and global coordination.

Tag 342: TradSesOpenTime
Tag 342 (TradSesOpenTime) is the actual time a trading session opened, in UTC. It may differ from the scheduled start due to delays. This field provides auditability and transparency. TradSesOpenTime supports latency analysis and compliance with exchange reporting rules. It ensures accurate timestamping of the beginning of trading activity.

Tag 343: TradSesPreCloseTime
Tag 343 (TradSesPreCloseTime) is the time when pre-close trading begins, such as for auction or imbalance resolution. It is used in equity and futures markets. TradSesPreCloseTime supports end-of-day strategies and order submission for closing auctions. It is critical for algorithms targeting closing prices or managing position exposure before session end.

Tag 344: TradSesCloseTime
Tag 344 (TradSesCloseTime) is the scheduled closing time of a trading session in UTC. It is included in session status messages. This field helps traders plan for session end and manage risk. TradSesCloseTime supports automated workflows that close positions or roll futures before market close. It is essential for time-based execution strategies.

Tag 345: TradSesEndTime
Tag 345 (TradSesEndTime) is the actual time a trading session ended, in UTC. It may differ from the scheduled close due to extensions. TradSesEndTime supports audit trails and reporting. It ensures accurate recording of session duration and is used in compliance and performance analysis for time-sensitive trading operations.

Tag 346: NumberOfOrders
Tag 346 (NumberOfOrders) indicates the total number of active orders in the market for a security at a given time. It is used in Market Data messages to reflect market depth and liquidity. NumberOfOrders supports order book analysis and volatility forecasting. High order counts may indicate interest or uncertainty. This field is valuable for algorithms that assess market activity and participation.

Tag 347: MessageEncoding
Tag 347 (MessageEncoding) specifies the character encoding used in encoded text fields, such as UTF-8, ISO-2022-JP, or Shift_JIS. It ensures proper interpretation of non-ASCII characters in Issuer, SecurityDesc, and Text fields. MessageEncoding supports global trading with multilingual content. It is essential for accurate parsing of encoded data in international markets.

Tag 348: EncodedIssuerLen
Tag 348 (EncodedIssuerLen) specifies the byte length of the data in the EncodedIssuer field (Tag 349). It enables correct parsing of binary or encoded issuer information. This tag is used when the issuer name contains non-ASCII characters and is encoded (e.g., base64). It supports global securities with complex character sets.

Tag 349: EncodedIssuer
Tag 349 (EncodedIssuer) contains the issuer name in encoded format (e.g., base64) when it includes non-ASCII characters. It ensures safe transmission of names with special characters. EncodedIssuer is used with EncodedIssuerLen (Tag 348) and MessageEncoding (Tag 347). It supports accurate representation of international issuers in global trading systems.

Tag 350: EncodedSecurityDescLen
Tag 350 (EncodedSecurityDescLen) specifies the byte length of the data in EncodedSecurityDesc (Tag 351). It enables proper parsing of encoded security descriptions. This tag is used when the description contains non-ASCII characters. EncodedSecurityDescLen ensures accurate handling of multilingual or complex security names in international markets.

Tag 351: EncodedSecurityDesc
Tag 351 (EncodedSecurityDesc) contains the security description in encoded format (e.g., base64) for non-ASCII content. It supports accurate transmission of complex or foreign-language descriptions. Used with EncodedSecurityDescLen (Tag 350), it ensures integrity. This field is essential for global trading where security names include special characters or non-Latin scripts.

Tag 352: EncodedListExecInstLen
Tag 352 (EncodedListExecInstLen) specifies the length of the encoded data in EncodedListExecInst (Tag 353). It supports parsing of binary or encoded list execution instructions. This tag is used when instructions contain special characters. It ensures accurate transmission of complex execution logic in multi-order strategies.

Tag 353: EncodedListExecInst
Tag 353 (EncodedListExecInst) contains ListExecInst (Tag 69) in encoded format for non-ASCII content. It ensures safe transmission of execution instructions with special characters. Used with EncodedListExecInstLen (Tag 352), it supports international workflows. This field maintains clarity in complex, multi-leg order execution.

Tag 354: EncodedTextLen
Tag 354 (EncodedTextLen) specifies the byte length of the data in EncodedText (Tag 355). It enables correct parsing of encoded free-text fields. This tag is used when Text (Tag 58) contains non-ASCII characters. It supports multilingual communication in execution reports and news messages.

Tag 355: EncodedText
Tag 355 (EncodedText) contains the Text field in encoded format (e.g., base64) for non-ASCII content. It ensures safe transmission of comments, reasons, or notes with special characters. Used with EncodedTextLen (Tag 354), it supports global communication. This field enhances clarity in international trading environments.

Tag 356: EncodedSubjectLen
Tag 356 (EncodedSubjectLen) specifies the length of the data in EncodedSubject (Tag 357). It supports parsing of encoded email or news subject lines with non-ASCII characters. This tag ensures accurate handling of multilingual subjects in messaging workflows.

Tag 357: EncodedSubject
Tag 357 (EncodedSubject) contains the Subject field in encoded format for non-ASCII content. It ensures safe transmission of email or news subject lines with special characters. Used with EncodedSubjectLen (Tag 356), it supports global communication. This field maintains clarity in administrative messaging.

Tag 358: EncodedHeadlineLen
Tag 358 (EncodedHeadlineLen) specifies the length of the data in EncodedHeadline (Tag 359). It enables correct parsing of encoded news headlines with non-ASCII characters. This tag supports international news dissemination.

Tag 359: EncodedHeadline
Tag 359 (EncodedHeadline) contains the Headline field in encoded format for non-ASCII content. It ensures safe transmission of news headlines with special characters. Used with EncodedHeadlineLen (Tag 358), it supports multilingual market news distribution.

Tag 360: EncodedAllocTextLen
Tag 360 (EncodedAllocTextLen) specifies the length of the data in EncodedAllocText (Tag 361). It supports parsing of encoded allocation instructions with non-ASCII content. This tag ensures accurate handling of complex allocation notes.

Tag 361: EncodedAllocText
Tag 361 (EncodedAllocText) contains AllocText (Tag 161) in encoded format for non-ASCII characters. It ensures safe transmission of allocation comments. Used with EncodedAllocTextLen (Tag 360), it supports global post-trade communication and compliance.

Tag 362: EncodedUnderlyingIssuerLen
Tag 362 (EncodedUnderlyingIssuerLen) specifies the length of the data in EncodedUnderlyingIssuer (Tag 363). It enables parsing of encoded underlying issuer names with special characters. This tag supports accurate representation of international underlying securities.

Tag 363: EncodedUnderlyingIssuer
Tag 363 (EncodedUnderlyingIssuer) contains the underlying issuer name in encoded format for non-ASCII content. Used with EncodedUnderlyingIssuerLen (Tag 362), it ensures correct transmission of complex issuer names in derivatives and structured products.

Tag 364: EncodedUnderlyingSecurityDescLen
Tag 364 (EncodedUnderlyingSecurityDescLen) specifies the length of the data in EncodedUnderlyingSecurityDesc (Tag 365). It supports parsing of encoded descriptions for the underlying security.

Tag 365: EncodedUnderlyingSecurityDesc
Tag 365 (EncodedUnderlyingSecurityDesc) contains the underlying security description in encoded format for non-ASCII content. It ensures accurate transmission of complex or foreign-language descriptions in derivatives. Used with Tag 364, it supports global trading.

Tag 366: AllocPrice
Tag 366 (AllocPrice) specifies the price used for allocating a trade to a specific account. It may differ from the overall AvgPx (Tag 6) if allocations are based on different execution segments. AllocPrice ensures accurate cost basis assignment per account. It is used in Allocation messages and supports precise performance measurement, tax reporting, and compliance across multiple portfolios.

Tag 367: QuoteSetValidUntilTime
Tag 367 (QuoteSetValidUntilTime) specifies the UTC expiration time for an entire set of quotes in a mass quoting scenario. It defines when all quotes within a Quote Set (identified by QuoteSetID) will automatically expire if not accepted. This field supports time-sensitive wholesale quoting in fixed income and derivatives markets. It ensures pricing discipline and prevents stale quotes from being executed. QuoteSetValidUntilTime is critical for dealer-to-client platforms and algorithmic market-making systems that manage multiple simultaneous quotes with coordinated lifetimes.

Tag 368: QuoteEntryRejectReason
Tag 368 (QuoteEntryRejectReason) specifies why a specific quote entry was rejected in a Quote Response message. Valid values include “Unknown symbol” (1), “Invalid bid/ask pricing” (2), or “Insufficient credit” (3). It provides granular feedback when only part of a multi-quote request is rejected. This field enhances transparency in RFQ workflows and enables clients to correct errors. QuoteEntryRejectReason supports efficient troubleshooting and improves the reliability of automated quoting and response systems in complex trading environments.

Tag 369: LastMsgSeqNumProcessed
Tag 369 (LastMsgSeqNumProcessed) indicates the last message sequence number (MsgSeqNum) successfully processed by the counterparty. It is used in application-level messages to confirm receipt and processing up to a certain point. This tag supports reconciliation and gap detection beyond the session layer. It is particularly useful in high-frequency environments where application-level latency or processing delays may occur. LastMsgSeqNumProcessed enhances auditability and ensures both parties are synchronized in message handling.

Tag 370: OnBehalfOfSendingTime (no longer used)
Tag 370 (OnBehalfOfSendingTime) was used to carry the SendingTime of the original sender when routing on behalf of another party but is no longer used in FIX 4.4. It has been deprecated due to redundancy with OrigSendingTime (Tag 122) and PossDupFlag (Tag 43). Applications should not include this field. Its use may cause parsing errors or interoperability issues. Modern implementations rely on standardized duplicate handling and timestamping mechanisms, making OnBehalfOfSendingTime obsolete in current FIX messaging.

Tag 371: RefTagID
Tag 371 (RefTagID) specifies the tag number of a field that caused a session-level rejection. It is used in Session Reject messages (MsgType 3) to pinpoint the invalid field. For example, if Price (Tag 44) is missing, RefTagID=44. This field enhances debugging by identifying the exact source of a parsing or validation error. RefTagID is critical for rapid troubleshooting and ensures both parties can resolve message format issues efficiently.

Tag 372: RefMsgType
Tag 372 (RefMsgType) identifies the MsgType (Tag 35) of the message that caused a session-level rejection. It is included in Session Reject messages to indicate which message failed. For example, if a New Order (MsgType D) is malformed, RefMsgType=D. This field supports message correlation and helps diagnose systemic issues. RefMsgType is essential for maintaining communication integrity and ensuring correct interpretation of rejected messages.

Tag 373: SessionRejectReason
Tag 373 (SessionRejectReason) specifies why a message was rejected at the session level: Invalid Tag Number (1), Required Tag Missing (2), or Incorrect CheckSum (4). It is returned in Session Reject messages (MsgType 3). This field provides actionable feedback for connectivity and formatting issues. SessionRejectReason supports rapid diagnosis of protocol errors and is critical for maintaining reliable FIX session operations and ensuring message validity.

Tag 374: BidRequestTransType
Tag 374 (BidRequestTransType) specifies the type of transaction in a Bid Request message: New (N), Cancel (C), or Replace (R). It controls how the bid request should be processed by the recipient. This field supports dynamic updates to unsolicited bids or market-making quotes. BidRequestTransType ensures correct handling of bid lifecycle events and is used in fixed-income and wholesale markets where dealers publish indicative pricing.

Tag 375: ContraBroker
Tag 375 (ContraBroker) identifies the broker on the opposite side of a trade, typically used in exchange-based or multilateral trading. It supports regulatory reporting and trade affirmation. ContraBroker is included in Execution Reports and helps counterparties reconcile trades. This field is particularly relevant in markets requiring disclosure of the contra-side broker for audit or clearing purposes. It enhances transparency in execution workflows.

Tag 376: ComplianceID
Tag 376 (ComplianceID) is a unique identifier assigned by a firm to an order for internal compliance tracking. It links the trade to pre-trade compliance checks, risk approvals, or regulatory filings. ComplianceID supports auditability and ensures adherence to internal policies. It is often generated by compliance or risk systems before order submission. This field is essential for institutional firms managing complex regulatory and investment mandates.

Tag 377: SolicitedFlag
Tag 377 (SolicitedFlag) indicates whether an execution was solicited (Y) or unsolicited (N). A solicited trade results from direct client interaction, while unsolicited may stem from market-making or algorithmic activity. This field supports best execution reporting and regulatory disclosures. It helps distinguish between agency and principal trading. SolicitedFlag is particularly relevant under MiFID II and other regimes requiring transparency in trade initiation.

Tag 378: ExecRestatementReason
Tag 378 (ExecRestatementReason) specifies why an execution is being restated: Cancel (1), Correct (2), or Replacement (3). It is used in Execution Reports with ExecType=I (Correction) or D (Restatement). This field provides context for changes to prior executions. ExecRestatementReason supports audit trails and ensures counterparties understand the nature of adjustments in trade reporting and clearing.

Tag 379: BusinessRejectRefID
Tag 379 (BusinessRejectRefID) references the MsgSeqNum or ClOrdID of the message being rejected at the application level. It is used in Business Message Reject messages (MsgType j) to identify the rejected message. This field enables precise correlation between rejection notices and original requests. BusinessRejectRefID is essential for troubleshooting order rejections due to business logic, such as credit limits or invalid parameters.

Tag 380: BusinessRejectReason
Tag 380 (BusinessRejectReason) specifies why a message was rejected for business reasons: Unrecognized Instrument (1), Price Exceeds Limit (6), or Other (0). It is returned in Business Message Reject messages. Unlike session-level rejections, this reflects application logic failures. BusinessRejectReason supports client feedback and error resolution in order routing and execution workflows.

Tag 381: GrossTradeAmt
Tag 381 (GrossTradeAmt) represents the total trade value before commissions, fees, or taxes. It is calculated as LastQty (Tag 32) × LastPx (Tag 31) for equities or using accrued interest for bonds. GrossTradeAmt supports clearing, accounting, and regulatory reporting. It ensures accurate valuation of the transaction and is used in confirmations and allocations to determine the base amount for cost breakdowns.

Tag 382: NoContraBrokers
Tag 382 (NoContraBrokers) specifies the number of contra brokers in a repeating group within an Execution Report. It defines how many times ContraBroker (Tag 375) and related fields repeat. This field supports multi-party trades, such as block crosses or exchange-for-physical transactions. NoContraBrokers enables accurate reporting of all counterparties involved in a single execution.

Tag 383: MaxMessageSize
Tag 383 (MaxMessageSize) indicates the maximum message size (in bytes) that a FIX engine can receive. It is exchanged during session initialization (Logon message) to prevent message truncation. This field supports interoperability between systems with different buffer limits. MaxMessageSize ensures reliable transmission of large messages, such as mass quotes or complex allocations, without fragmentation or failure.

Tag 384: NoMsgTypes
Tag 384 (NoMsgTypes) specifies the number of message types in a repeating group, typically used in News or Market Data messages to indicate supported MsgTypes. It defines how many times RefMsgType repeats. NoMsgTypes supports capability negotiation and filtering. This field is essential for systems that need to advertise or query message type support during session setup or content distribution.

Tag 385: MsgDirection
Tag 385 (MsgDirection) indicates the direction of a message type: Send (S), Receive (R), or Both (B). It is used in repeating groups with RefMsgType to define whether a message is sent, received, or bidirectional. MsgDirection supports capability exchange and ensures both parties understand messaging roles. It is particularly useful in asymmetric communication models or gateway configurations.

Tag 386: NoTradingSessions
Tag 386 (NoTradingSessions) specifies the number of trading sessions in a repeating group, such as in a Trading Session Status message. It defines how many times TradingSessionID (Tag 336) and related fields repeat. NoTradingSessions supports markets with multiple sessions per day (e.g., pre-market, regular, after-hours). This field enables comprehensive session state reporting.

Tag 387: TotalVolumeTraded
Tag 387 (TotalVolumeTraded) represents the total number of shares or contracts traded for a security during a session. It is used in Market Data and end-of-day reports. TotalVolumeTraded supports liquidity analysis, volume profiling, and benchmarking. It is essential for technical analysis, VWAP calculations, and regulatory transparency reports on market activity.

Tag 388: DiscretionInst
Tag 388 (DiscretionInst) specifies instructions for a discretion price, such as “Related to displayed price” (1) or “Optimal” (2). It guides how the broker should set a discretionary price within a pegged or reserve order. DiscretionInst supports algorithmic trading strategies that allow brokers to improve execution within defined bands. This field enhances flexibility in order handling while maintaining client control.

Tag 389: DiscretionOffsetValue
Tag 389 (DiscretionOffsetValue) specifies the offset from the primary price for the discretion price in a pegged or reserve order. For example, “displayed price + $0.01.” It defines how much the broker can improve the order. DiscretionOffsetValue supports aggressive or passive execution strategies and is used in conjunction with DiscretionInst (Tag 388) for dynamic pricing.

Tag 390: BidID
Tag 390 (BidID) is a unique identifier assigned by the seller to a bid quote, typically in a wholesale or fixed-income market. It is used in Quote and Quote Response messages to reference a specific bid. BidID enables tracking and matching of quotes in RFQ workflows. It supports quote lifecycle management and ensures accurate handling of bid submissions and responses.

Tag 391: ClientBidID
Tag 391 (ClientBidID) is a unique identifier assigned by the client to a bid request or quote in wholesale or fixed-income markets. It enables tracking and referencing of bid submissions across responses and executions. ClientBidID is used in Bid Request and Quote messages to support RFQ workflows. It ensures message linkage and helps counterparties correlate responses with original requests. This field enhances transparency and auditability in dealer-to-client platforms and is essential for managing multiple concurrent bids.

Tag 392: ListName
Tag 392 (ListName) specifies a descriptive name for an order list, such as “Tech Basket” or “Morning Sweep.” It is used in List Execute and List Status messages to provide human-readable context. ListName supports trader recognition and operational clarity in multi-order strategies. While not used for routing, it aids in monitoring and reconciliation. This field enhances usability in algorithmic and program trading environments where large sets of orders are managed collectively.

Tag 393: TotNoRelatedSym
Tag 393 (TotNoRelatedSym) indicates the total number of securities in a Market Data Request or response. It is used to confirm completeness when multiple messages are sent. TotNoRelatedSym ensures all requested symbols have been processed and supports reconciliation. It is particularly useful in batch requests for basket quotes or volatility surfaces. This field enhances reliability in market data workflows involving multiple instruments.

Tag 394: BidType
Tag 394 (BidType) specifies the type of bid: Non-Competitive (1), Competitive (2), or Top of Book (3). It is used in Bid Request and Quote messages to convey bidding strategy. For example, a non-competitive bid accepts the clearing price. BidType supports auction-based trading and government securities markets. It enables brokers and exchanges to process bids appropriately based on client intent and market rules.

Tag 395: NumTickets
Tag 395 (NumTickets) indicates the number of individual orders or “tickets” associated with a single execution. It is used in block trading to show how a large trade was broken down. NumTickets supports post-trade reporting and best execution analysis. It helps assess execution quality by revealing slicing behavior. This field is particularly relevant in dark pools and agency execution where order fragmentation impacts performance.

Tag 396: SideValue1
Tag 396 (SideValue1) is a generic field used to specify a monetary value associated with one side of a trade, often in complex or multi-leg instruments. It may represent notional, premium, or cash flow. SideValue1 is typically used with SideValueInd (Tag 401) to indicate which side it applies to. It supports structured products and derivatives pricing in non-standard workflows.

Tag 397: SideValue2
Tag 397 (SideValue2) is a second generic monetary value field, used in conjunction with SideValue1 (Tag 396) for multi-value instruments. It may represent the counter-side value in a swap or cross-currency transaction. SideValue2 enhances flexibility in bilateral pricing and supports accurate valuation in complex derivatives and structured trades where dual cash flows exist.

Tag 398: NoBidDescriptors
Tag 398 (NoBidDescriptors) specifies the number of bid descriptor entries in a repeating group within a Bid Request message. It defines how many times BidDescriptorType (Tag 399) and BidDescriptor (Tag 400) repeat. NoBidDescriptors supports rich bid context, such as yield, maturity, or credit criteria. It is essential for fixed-income and wholesale markets where bids include multiple qualitative or quantitative filters.

Tag 399: BidDescriptorType
Tag 399 (BidDescriptorType) specifies the type of bid descriptor: Industry (1), Country (2), or Rating (3). It categorizes the content of the BidDescriptor field. This field enables structured filtering of bids based on client preferences. For example, a bid may target “A-rated” bonds or “Technology” sector issuers. BidDescriptorType supports sophisticated matching in dealer-to-client and electronic bond trading platforms.

Tag 400: BidDescriptor
Tag 400 (BidDescriptor) contains the actual value of a bid descriptor, such as “Technology” or “AA+”. It is used with BidDescriptorType (Tag 399) to define client-specific criteria in a bid request. This field supports targeted quoting and enables dealers to respond selectively. BidDescriptor enhances precision in wholesale fixed-income and OTC derivatives markets.

Tag 401: SideValueInd
Tag 401 (SideValueInd) indicates which side of a trade a SideValue field applies to: Side 1 (1) or Side 2 (2). It is used in multi-leg or cross-product trades to assign values correctly. SideValueInd ensures accurate interpretation of SideValue1 (Tag 396) and SideValue2 (Tag 397). It supports complex instruments like swaps, straddles, and baskets.

Tag 402: LiquidityPctLow
Tag 402 (LiquidityPctLow) specifies the lower bound of a liquidity provider’s participation rate as a percentage. It indicates the minimum volume the provider commits to trade. This field supports EFP (Exchange for Physical) and block trading models. LiquidityPctLow helps counterparties assess execution certainty and is used in algorithmic liquidity programs.

Tag 403: LiquidityPctHigh
Tag 403 (LiquidityPctHigh) specifies the upper bound of a liquidity provider’s participation rate. It defines the maximum volume they may trade. Used with LiquidityPctLow (Tag 402), it sets a range for expected participation. This field supports transparency in liquidity provision and helps clients estimate fill probability in low-volume markets.

Tag 404: LiquidityValue
Tag 404 (LiquidityValue) represents the monetary value of liquidity provided in a trade or quote. It may reflect the notional size or cash value of a bid/offer. LiquidityValue supports performance measurement and compensation for market makers. It is used in EFP and wholesale markets to quantify contribution to market depth.

Tag 405: EFPTrackingError
Tag 405 (EFPTrackingError) specifies the tracking error between a cash position and its futures equivalent in an Exchange for Physical (EFP) transaction. It measures basis deviation and supports fair pricing. EFPTrackingError ensures both parties agree on the value differential. This field is critical for accurate EFP execution and risk management.

Tag 406: FairValue
Tag 406 (FairValue) is the theoretical fair price of a security, often used in derivatives or stale markets. It is derived from models, futures, or indices. FairValue supports pricing when no recent trades exist. It is used in allocations and valuations to ensure accurate cost basis. This field enhances consistency in financial reporting.

Tag 407: OutsideIndexPct
Tag 407 (OutsideIndexPct) specifies the percentage deviation of a bid/offer from a benchmark index. It measures relative value and supports relative pricing strategies. This field is used in fixed income and structured products to assess richness or cheapness. OutsideIndexPct helps traders make informed decisions based on index comparisons.

Tag 408: ValueOfFutures
Tag 408 (ValueOfFutures) represents the total value of futures contracts used in a transaction, such as in an EFP or spread trade. It supports valuation and margin calculation. ValueOfFutures ensures correct accounting for the futures leg and is used in clearing and risk systems to determine exposure.

Tag 409: LiquidityIndType
Tag 409 (LiquidityIndType) specifies the type of liquidity indicator: Five-Sided (1), Four-Sided (2), or Three-Sided (3). It describes the market depth available. This field supports algorithmic trading and market-making strategies by conveying liquidity structure. LiquidityIndType helps systems assess execution quality and market conditions.

Tag 410: WtAverageLiquidity
Tag 410 (WtAverageLiquidity) is the volume-weighted average liquidity available over a period. It measures average market depth and supports execution strategy design. WtAverageLiquidity helps traders assess typical order book conditions and plan large trades accordingly. This field is valuable for VWAP and implementation shortfall algorithms.

Tag 411: ExchangeForPhysical
Tag 411 (ExchangeForPhysical) indicates whether a trade is an Exchange for Physical (EFP) transaction (Y/N). EFPs involve swapping a futures position for a cash position. This field supports clearing, margining, and regulatory reporting. It ensures correct handling of physically settled derivatives and is critical in futures and commodities markets.

Tag 412: OutMainCntryUIndex
Tag 412 (OutMainCntryUIndex) indicates if a trade is outside the main country of the underlying index (Y/N). It supports regulatory and tax reporting. This field helps identify cross-border transactions and ensures compliance with local rules. It is particularly relevant in ETFs and index-linked products.

Tag 413: CrossPercent
Tag 413 (CrossPercent) specifies the percentage of a block trade that was crossed internally versus executed externally. It supports transparency in internal crossing and best execution reporting. CrossPercent helps firms demonstrate fairness and price improvement in agency execution.

Tag 414: ProgRptReqs
Tag 414 (ProgRptReqs) specifies the frequency of progress reports for a large order: No Reports (0), Urgent (1), or Regular (2). It guides how often the broker updates the client on order status. ProgRptReqs supports communication in iceberg or TWAP orders and enhances execution transparency.

Tag 415: ProgPeriodInterval
Tag 415 (ProgPeriodInterval) specifies the time interval (in minutes) between progress reports for a large order. It is used with ProgRptReqs (Tag 414) to define reporting frequency. This field ensures timely updates and supports client monitoring of order execution. It is essential for algorithmic and institutional trading workflows.

Tag 416: IncTaxInd
Tag 416 (IncTaxInd) indicates whether a distribution includes tax (Y/N). It is used in corporate actions and dividend processing. IncTaxInd supports accurate tax withholding and reporting. This field ensures correct handling of gross vs. net payments in international securities.

Tag 417: NumBidders
Tag 417 (NumBidders) specifies the number of bidders in an auction or RFQ. It supports market analysis and competition assessment. NumBidders helps clients evaluate pricing quality based on participant count. This field enhances transparency in competitive bidding environments.

Tag 418: BidTradeType
Tag 418 (BidTradeType) specifies the type of bid trade: Risk Trade (R), Volatility Trade (V), or Basis Trade (B). It conveys trading intent and supports risk classification. BidTradeType helps brokers route and manage bids appropriately. This field is used in derivatives and volatility-sensitive strategies.

Tag 419: BasisPxType
Tag 419 (BasisPxType) specifies the type of basis price used: Closing Price (2), Composite (3), or Last Sale (4). It defines the reference for price adjustments. BasisPxType supports accurate pricing in relative-value trades and is used in corporate actions and dividend adjustments.

Tag 420: NoBidComponents
Tag 420 (NoBidComponents) indicates the number of bid components in a repeating group. It defines how many times ContraBroker (Tag 375) and related fields repeat in a multi-party bid. NoBidComponents supports complex bid structures and ensures complete reporting of all participants.

Tag 421: Country
Tag 421 (Country) specifies the country of a participant, instrument, or payment using ISO 3166-1 alpha-2 codes (e.g., US, GB). It supports regulatory reporting, tax withholding, and jurisdictional compliance. Country is used in PartyIDs, distributions, and security definitions. It ensures correct handling of cross-border transactions.

Tag 422: TotNoStrikes
Tag 422 (TotNoStrikes) specifies the total number of strike prices in an option chain request or response. It supports reconciliation of multi-strike data. TotNoStrikes ensures completeness in market data feeds for volatility surfaces and options strategies.

Tag 423: PriceType
Tag 423 (PriceType) specifies the type of price: Percentage (1), Per Unit (2), or Yield (4). It defines how a price field should be interpreted. PriceType supports accurate valuation in bonds, derivatives, and structured products. It prevents misinterpretation of pricing data.

Tag 424: DayOrderQty
Tag 424 (DayOrderQty) specifies the portion of an order intended for execution in the current trading day. It is used in Good-Till-Cancel (GTC) orders to show daily exposure. DayOrderQty supports risk management and position monitoring.

Tag 425: DayCumQty
Tag 425 (DayCumQty) is the cumulative quantity executed for an order on the current day. It resets daily and supports intraday performance tracking. DayCumQty helps traders assess daily progress and adjust strategies accordingly.

Tag 426: DayAvgPx
Tag 426 (DayAvgPx) is the average execution price for an order on the current day. It resets daily and supports intraday execution quality analysis. DayAvgPx is used in algorithmic trading to measure performance against benchmarks like VWAP.

Tag 427: GTBookingInst
Tag 427 (GTBookingInst) specifies how a trade should be booked: Book Immediately (0), Accumulate (1), or Book at End of Day (2). It guides post-trade processing. GTBookingInst supports operational flexibility in institutional workflows.

Tag 428: NoStrikes
Tag 428 (NoStrikes) specifies the number of strike prices in a repeating group. It defines how many times StrikePrice (Tag 202) repeats in an option chain. NoStrikes supports batch transmission of option data.

Tag 429: ListStatusType
Tag 429 (ListStatusType) specifies the status of an order list: Ack (1), Reject (2), or Done (3). It is used in List Status messages. ListStatusType supports coordination of multi-order strategies.

Tag 430: NetGrossInd
Tag 430 (NetGrossInd) indicates whether a price is net (1) or gross (2) of commissions. It supports accurate cost reporting. NetGrossInd ensures correct interpretation of execution prices.

Tag 431: ListOrderStatus
Tag 431 (ListOrderStatus) indicates the current status of an individual order within a list in a List Status message (MsgType FS). It provides granular visibility into the execution state of each order in a multi-order strategy, such as a basket or program trade. Valid values include “Cancelled” (4), “Executing” (6), “Done” (7), “Rejected” (8), and “Pending” (10). This field enables institutional traders and algorithms to monitor the progress of complex order sets in real time. Unlike the overall list status, ListOrderStatus allows for per-order tracking, which is essential when some orders in a list are filled while others are pending or rejected. It supports operational transparency and helps traders assess execution efficiency. The field is repeated for each order in the list, allowing detailed reporting on order-level events. ListOrderStatus is particularly valuable in algorithmic trading, where large portfolios are traded systematically, and performance must be measured across all components. It ensures that portfolio managers and risk systems have accurate, up-to-date information on the lifecycle of each order, enabling timely decisions and post-trade analysis.

Tag 432: ExpireDate
Tag 432 (ExpireDate) specifies the date on which a Good Till Date (GTD) order will automatically expire if not executed. The date is formatted in YYYYMMDD and is used in conjunction with TimeInForce = 6 (Good Till Date). This field allows traders to set a precise end date for an order’s validity, beyond which it will be canceled by the broker or exchange. ExpireDate is particularly useful for long-term orders in illiquid securities or for institutional investors managing future exposure. It provides greater control than a simple “Good Till Cancel” (GTC) order by limiting the order’s lifespan to a defined calendar date. The field ensures that stale orders do not remain open indefinitely, reducing operational risk and unintended executions. ExpireDate is echoed in Execution Reports and can be modified via an Order Cancel/Replace Request. It is widely used in equities, fixed income, and derivatives markets where timing is critical. The use of UTC ensures consistency across time zones. ExpireDate enhances order management flexibility and supports disciplined trading strategies by enabling time-bound execution control.

Tag 433: ListExecInstType
Tag 433 (ListExecInstType) defines the execution instruction type for an entire list of orders in a List Execute message (MsgType E). It controls how the orders within the list should be processed by the broker or execution system. Valid values include “Immediate” (1), meaning all orders should be executed as soon as possible, and “Wait for Execute” (2), indicating that execution should await further instruction. This field supports complex trading strategies such as basket trading, portfolio rebalancing, or risk reduction across multiple securities. ListExecInstType ensures that the execution logic is clearly communicated, preventing unintended partial executions or sequencing issues. It enables institutional traders to coordinate the timing and method of execution across a portfolio. For example, setting ListExecInstType to “Immediate” triggers simultaneous processing, while “Wait for Execute” allows for phased or conditional execution. The field enhances control over multi-order workflows and is essential for achieving best execution in large-scale trades. It also supports algorithmic trading systems that manage batch orders based on market conditions. ListExecInstType works in conjunction with other list-level fields such as ListID (Tag 66) and ListSeqNo (Tag 67) to provide a complete execution framework for coordinated trading.

Tag 434: CxlRejResponseTo
Tag 434 (CxlRejResponseTo) specifies the type of request to which a cancellation rejection applies. It is used in Order Cancel Reject messages (MsgType 9) to clarify whether the rejection is in response to an Order Cancel Request (value 1) or an Order Cancel/Replace Request (value 2). This distinction is crucial for accurate order management, as it informs the client whether their attempt to cancel or modify an order was rejected. By identifying the source request, CxlRejResponseTo helps prevent confusion in high-frequency trading environments where multiple order actions may be in flight. It supports precise troubleshooting and enables trading systems to take appropriate follow-up actions, such as resubmitting a cancel or adjusting the replacement order. The field enhances transparency in order lifecycle management and ensures that both client and broker maintain a consistent view of order status. Without this tag, it would be difficult to determine which operation failed, especially when a Cancel/Replace request is rejected—was it the cancel part or the new order part that caused the issue? CxlRejResponseTo resolves this ambiguity. It is a key diagnostic field in FIX 4.4, supporting robust error handling and reliable execution workflows.

Tag 435: UnderlyingCouponRate
Tag 435 (UnderlyingCouponRate) specifies the annual interest rate (as a percentage) of the underlying bond in a derivative contract, such as an option or future on a fixed-income security. This field is essential for accurately pricing and valuing derivatives linked to bonds, as the coupon rate directly affects the bond’s yield, duration, and present value. It is used in conjunction with other underlying fields like UnderlyingMaturityMonthYear (Tag 313) and UnderlyingParValue (if available) to model cash flows. UnderlyingCouponRate supports risk management, margin calculation, and fair value assessment in fixed-income derivatives. It is particularly relevant in markets for bond options, interest rate futures, and structured notes. The rate is typically expressed in decimal form (e.g., 5.25 for 5.25%). Accurate transmission of this data ensures that pricing engines and clearing systems apply correct valuation models. The field also aids in regulatory reporting, where the characteristics of the underlying asset must be disclosed. UnderlyingCouponRate enhances transparency and precision in derivative trading, ensuring that all parties have consistent information about the referenced security. It is a critical component in the accurate representation of complex financial instruments.

Tag 436: UnderlyingContractMultiplier
Tag 436 (UnderlyingContractMultiplier) defines the multiplier applied to the underlying futures contract in a derivative instrument. It specifies how many units of the underlying asset are represented by one contract. For example, an S&P 500 futures contract might have a multiplier of 250, meaning each point move equals $250. This field is used in options on futures or other multipliers-based derivatives to ensure correct notional value calculation. UnderlyingContractMultiplier is critical for accurate pricing, margining, and profit/loss computation. Without it, systems may misinterpret the exposure size, leading to incorrect risk assessments or execution errors. It is particularly important in commodities, equity indices, and interest rate futures markets. The multiplier is applied to the futures price to determine the total contract value. UnderlyingContractMultiplier works in tandem with UnderlyingSymbol (Tag 311), StrikePrice (Tag 202), and ContractMultiplier (Tag 231) to fully define the economic terms of the derivative. It supports consistency across trading, clearing, and risk systems. This field ensures that all parties—traders, brokers, and clearinghouses—have a uniform understanding of the contract size, preventing disputes and operational errors in high-value transactions.

Tag 437: ContraTradeQty
Tag 437 (ContraTradeQty) specifies the quantity of shares or contracts traded by the counterparty in a matched or crossed trade. It is used in Execution Reports and affirmation messages to provide full transparency on both sides of a transaction, particularly in block trades, exchange-for-physical (EFP) transactions, or internal crosses. ContraTradeQty ensures that both parties can reconcile their records accurately. In a cross-trade scenario, where two counterparties agree to trade directly, each may report slightly different quantities due to rounding or timing; ContraTradeQty allows for comparison and resolution. This field supports post-trade processing, clearing, and regulatory reporting by confirming the exact volume exchanged. It is especially useful in dark pools, bilateral OTC markets, and principal trading where trade affirmation is required. ContraTradeQty enhances auditability and reduces settlement risk by ensuring both sides agree on the trade size. It complements ContraTradeTime (Tag 438) and ContraBroker (Tag 375) to provide a complete picture of the contra-side execution. The field is optional but highly valuable in environments requiring detailed trade validation.

Tag 438: ContraTradeTime
Tag 438 (ContraTradeTime) specifies the timestamp (in UTC) at which the counterparty executed their side of a trade. It is used in Execution Reports to provide synchronization between counterparties in matched or crossed trades. This field is particularly important in block trading, EFPs, and internal crossing networks where timing consistency is critical for confirmation and regulatory reporting. ContraTradeTime allows both sides to verify that the trade occurred at the same moment, reducing disputes and reconciliation issues. It is formatted as YYYYMMDD-HH:MM:SS.sss and supports millisecond precision. When combined with ContraTradeQty (Tag 437) and ContraBroker (Tag 375), it enables full auditability of the contra-side execution. ContraTradeTime is essential for best execution analysis and trade affirmation workflows, ensuring that both parties have consistent records. It also supports regulatory requirements under MiFID II and other regimes that mandate precise trade reporting. The field enhances transparency in bilateral trading and helps prevent “late trade” reporting. While optional, its use is strongly recommended in non-transparent or OTC markets where independent verification is necessary.

Tag 439: ClearingFirm (replaced)
Tag 439 (ClearingFirm) was historically used to identify the firm responsible for clearing a trade, such as a clearing broker or central counterparty (CCP). However, it has been replaced in FIX 4.4 by the more flexible and standardized PartyID (Tag 448) mechanism. The PartyID framework, used with PartyIDSource (Tag 447) and PartyRole (Tag 452), allows for multiple parties to be specified with clear roles (e.g., Clearing Firm = Role 7). This provides greater extensibility and supports complex clearing arrangements involving multiple intermediaries. Tag 439 is now obsolete and should not be used in new implementations. Its inclusion may cause parsing issues or be ignored by receiving systems. Modern FIX engines expect clearing firm identification via the NoPartyIDs repeating group. The deprecation of ClearingFirm reflects the evolution of FIX toward a more scalable and role-based identification model. Applications should migrate to the PartyID structure to ensure compliance and interoperability. Using deprecated fields can lead to connectivity failures or regulatory non-compliance in automated trading environments.

Tag 440: ClearingAccount (replaced)
Tag 440 (ClearingAccount) was used to specify the account number at the clearing firm for a trade but is now replaced in FIX 4.4. It has been superseded by the AllocAccount (Tag 79) field in allocation messages and the PartyID framework for party-specific account identification. The modern approach uses structured repeating groups to associate accounts with specific roles, enhancing clarity and flexibility. Tag 440 is deprecated due to ambiguity and lack of standardization. Its use is discouraged, as it may not be supported by current systems. Instead, clearing account information should be conveyed using AllocAccount with appropriate qualifiers or via PartyID with PartyRole = 7 (Clearing Firm) and sub-identifiers. This allows for richer, more accurate representation of account hierarchies and relationships. The replacement of ClearingAccount reflects FIX’s move toward modular, extensible messaging. Applications should avoid this tag to ensure compatibility with modern clearing and settlement workflows.

Tag 441: LiquidityNumSecurities
Tag 441 (LiquidityNumSecurities) indicates the number of securities for which a market participant is providing liquidity. It is used in wholesale quoting, market-making programs, and liquidity provision reports. This field helps exchanges, brokers, and clients assess the breadth of a liquidity provider’s commitment. For example, a dealer offering quotes in 500 equities would set LiquidityNumSecurities = 500. The value supports performance evaluation, compensation models, and regulatory reporting on market quality. It is particularly relevant in programs that incentivize liquidity provision, such as exchange rebate schemes or dark pool participation. LiquidityNumSecurities provides a quantitative measure of market-making activity and helps identify dominant players in specific sectors or asset classes. It enhances transparency in trading ecosystems and supports best execution analysis by revealing the scope of available liquidity. The field may be included in custom messages or repeating groups to report liquidity commitments over time. While optional, it is valuable in fixed-income, ETFs, and less liquid equities where liquidity depth is a concern. LiquidityNumSecurities enables data-driven decision-making for both providers and takers of liquidity.

Tag 442: MultiLegReportingType
Tag 442 (MultiLegReportingType) specifies how a multi-leg instrument, such as an option spread or convertible bond, should be reported for regulatory or clearing purposes. Valid values include “Single Security” (1), meaning the entire strategy is reported as one instrument, and “Individual Legs” (2), indicating that each leg is reported separately. This field is crucial for compliance with trade reporting regulations like MiFID II, Dodd-Frank, or EMIR, which have specific requirements for derivatives and complex products. MultiLegReportingType ensures that the trade is reported in the correct format, avoiding penalties or rejections. It also affects clearing and margin calculations, as some systems treat multi-leg trades as a single unit with reduced risk. The choice of reporting type depends on the venue, asset class, and jurisdiction. For example, exchange-traded options spreads are typically reported as single securities, while OTC swaps may require leg-by-leg reporting. MultiLegReportingType enhances consistency across post-trade workflows and supports accurate risk aggregation. It is a key control field in institutional trading systems, ensuring that complex strategies are handled correctly from execution to settlement.

Tag 443: StrikeTime
Tag 443 (StrikeTime) specifies the exact time at which the strike price of an option is determined, particularly for exotic or path-dependent options such as Asian, barrier, or lookback options. For example, in an Asian option, the strike may be based on the average price over a period, and StrikeTime indicates when that averaging window begins or ends. This field is critical for accurate valuation and payoff calculation, as the timing directly affects the final settlement amount. StrikeTime is formatted in UTC as YYYYMMDD-HH:MM:SS.sss and ensures consistency across global markets. It is used in option definitions, pricing messages, and trade confirmations. Without a precise StrikeTime, there could be disputes over the reference price used for exercise. The field supports transparency in OTC derivatives and structured products, where terms are often customized. It also aids in risk management and back-testing by providing a clear audit trail of pricing events. StrikeTime is particularly relevant in energy, commodities, and FX options, where exotic structures are common. It enhances the precision of financial contracts and ensures fair execution.

Tag 444: ListStatusText
Tag 444 (ListStatusText) provides free-form textual information about the status of an order list in a List Status message (MsgType FS). It allows brokers or execution systems to include human-readable comments, such as “Delayed due to market volatility” or “Awaiting client confirmation.” This field enhances communication between counterparties and provides context beyond the coded ListOrderStatus (Tag 431) values. While not parsed by algorithms, ListStatusText is valuable for traders and operations teams monitoring large-scale order executions. It supports transparency in complex trading strategies like basket trades or portfolio rebalancing. The text can explain partial fills, cancellations, or system issues affecting the list. ListStatusText is optional but recommended in environments where operational clarity is essential. It complements structured fields by conveying nuances that codes alone cannot express. For example, a status code may indicate “Executing,” but the text can clarify that “3 out of 10 orders are filled.” This field improves situational awareness and supports post-trade analysis and client reporting.

Tag 445: EncodedListStatusTextLen
Tag 445 (EncodedListStatusTextLen) specifies the byte length of the data contained in the EncodedListStatusText field (Tag 446). It is used when the ListStatusText (Tag 444) contains non-ASCII characters, such as accented letters, Asian scripts, or special symbols, and must be encoded (e.g., using Base64). The length value enables the receiving system to correctly parse the encoded payload. This tag is essential for ensuring data integrity when transmitting multilingual or complex text in List Status messages. It prevents truncation or misinterpretation of encoded content. EncodedListStatusTextLen works in tandem with MessageEncoding (Tag 347) to indicate the original character set (e.g., UTF-8, Shift_JIS). Together, these fields support global trading environments where status updates may need to be communicated in local languages. The use of encoded text ensures compatibility with the FIX protocol’s ASCII-based transmission while preserving the richness of human-readable information. EncodedListStatusTextLen is a technical enabler for internationalization in electronic trading.

Tag 446: EncodedListStatusText
Tag 446 (EncodedListStatusText) contains the ListStatusText (Tag 444) in encoded format, typically Base64, when the original text includes non-ASCII characters. It allows the transmission of multilingual or special-character content in List Status messages without violating FIX’s ASCII transmission rules. The encoded data represents the same information as ListStatusText but in a safe, transmittable form. It is used in conjunction with EncodedListStatusTextLen (Tag 445) and MessageEncoding (Tag 347) to ensure correct decoding. For example, a status message in Japanese or German with umlauts can be accurately conveyed using this field. EncodedListStatusText supports global trading operations where brokers and clients communicate in multiple languages. It preserves the clarity and intent of operational messages across linguistic boundaries. While not machine-readable in its encoded form, it can be decoded for display or logging. This field enhances inclusivity and operational efficiency in multinational financial institutions.

Tag 447: PartyIDSource
Tag 447 (PartyIDSource) identifies the namespace or coding system used for a PartyID (Tag 448), ensuring unambiguous identification of counterparties. Valid values include BIC (1), SID (2), Proprietary (3), ISIN (4), and CFTC (7). For example, if PartyID is a SWIFT BIC code, PartyIDSource = 1. This field prevents misidentification when different firms use overlapping identifiers. It is used in the NoPartyIDs repeating group to provide context for each PartyID. PartyIDSource is essential for accurate routing, clearing, and regulatory reporting. It supports global interoperability by aligning with international standards. The field is particularly important in cross-border transactions where multiple identification schemes coexist. By specifying the source, it enables systems to validate and process PartyIDs correctly. PartyIDSource enhances the reliability of counterparty data and reduces operational risk. It is a foundational element of the modern FIX party identification model, replacing older, less flexible fields like ClearingFirm (Tag 439).

Tag 448: PartyID
Tag 448 (PartyID) is a unique identifier for a counterparty in a financial transaction, such as a client, broker, clearing firm, or exchange. It is used within the NoPartyIDs (Tag 453) repeating group and is paired with PartyIDSource (Tag 447) and PartyRole (Tag 452) to define who is involved and in what capacity. For example, a broker might be identified by its BIC code with PartyRole = 3. PartyID supports flexible, scalable identification across multiple roles in a single message. It replaces older, single-purpose fields like SenderCompID or ClearingFirm, enabling richer messaging. The field is critical for regulatory reporting, risk management, and trade affirmation. It ensures that all parties in a transaction are clearly identified, reducing ambiguity and operational errors. PartyID is a cornerstone of modern FIX messaging, supporting complex trading relationships and multi-hop routing.

Tag 449: TotalVolumeTradedDate (replaced)
Tag 449 (TotalVolumeTradedDate) was used to specify the date associated with the TotalVolumeTraded (Tag 387) value but is now replaced in FIX 4.4. It has been deprecated due to redundancy, as the date can be derived from the message’s TransactTime (Tag 60) or TradeDate (Tag 75). Modern implementations combine TotalVolumeTraded with existing date fields to avoid duplication. The use of separate date tags for volume metrics complicates parsing and increases message size without adding value. Applications should not use this tag. Its functionality is fully covered by standard date fields. Continuing to use deprecated tags can lead to interoperability issues or rejection by receiving systems. The removal of TotalVolumeTradedDate reflects FIX’s ongoing effort to streamline message formats and eliminate obsolete fields. Users are encouraged to rely on consolidated, standardized date handling.

Tag 450: TotalVolumeTraded Time (replaced)
Tag 450 (TotalVolumeTraded Time) was intended to specify the time of the TotalVolumeTraded (Tag 387) value but is replaced and no longer used in FIX 4.4. It has been deprecated due to redundancy with TransactTime (Tag 60) and MDEntryTime (Tag 273), which already provide precise timestamps for market data and trade events. Including a separate time field for volume data increases message complexity without benefit. The tag’s name contains a space, which violates FIX field naming conventions, further justifying its removal. Applications should avoid this field. Its functionality is fully supported by existing timestamp fields. Using deprecated or non-standard tags can cause parsing errors or message rejection. The deprecation of TotalVolumeTraded Time aligns with FIX’s goal of maintaining a clean, consistent, and efficient messaging standard. Users should rely on standard timing fields for volume reporting.

Tag 451: NetChgPrevDay
Tag 451 (NetChgPrevDay) represents the net change in a security’s price from the previous day’s closing price to the current price. It is typically expressed in currency units (e.g., USD) and is used in market data and quote messages to indicate intraday performance. For example, if a stock closed at $50 yesterday and is now trading at $51.25, NetChgPrevDay = 1.25. This field supports technical analysis, trader dashboards, and algorithmic decision-making by showing price momentum. It is often displayed alongside percentage change and is particularly useful for identifying trending securities. NetChgPrevDay is calculated using PrevClosePx (Tag 140) and the current LastPx (Tag 31). It enhances market transparency and helps investors assess short-term performance. The field is widely used in equity, futures, and ETF markets. While optional, it is a common feature in market data feeds and trading platforms.

Tag 452: PartyRole
Tag 452 (PartyRole) specifies the function or role of a party identified by PartyID (Tag 448) in a transaction. Valid roles include Executing Firm (1), Broker of Credit (3), Client ID (4), and Clearing Firm (7). This field enables a single message to convey multiple parties with distinct responsibilities, such as who initiated the trade, who executed it, and who cleared it. PartyRole is used in the NoPartyIDs repeating group and supports complex trading relationships, especially in routed or sponsored access scenarios. It enhances transparency for regulatory reporting, risk management, and commission allocation. By standardizing roles, it ensures consistent interpretation across systems. PartyRole is a key component of the modern FIX party model, replacing older, less flexible identification methods. It supports best execution analysis by clarifying the chain of responsibility in a trade.

Tag 453: NoPartyIDs
Tag 453 (NoPartyIDs) indicates the number of PartyID entries in the repeating group that follows it. It defines how many times the sequence PartyID (Tag 448), PartyIDSource (Tag 447), and PartyRole (Tag 452) repeats within a message. This field enables the identification of multiple parties involved in a transaction, such as the client, executing broker, clearing firm, and intermediary. NoPartyIDs supports flexible, scalable messaging and is essential for accurately representing complex trading relationships. It replaces older, single-purpose fields like ClearingFirm or OnBehalfOfCompID. The repeating group structure allows for any number of parties to be specified, enhancing clarity and auditability. NoPartyIDs is widely used in Execution Reports, Allocation messages, and Market Data. It is a foundational element of the FIX 4.4 party identification framework.

Tag 454: NoSecurityAltID
Tag 454 (NoSecurityAltID) specifies the number of alternative security identifiers in a repeating group. It defines how many times SecurityAltID (Tag 455) and SecurityAltIDSource (Tag 456) repeat. This field allows a security to be referenced by multiple identifiers from different sources, such as Bloomberg (S34567), Reuters (AAPL.OQ), or internal codes. NoSecurityAltID supports robust security identification in global markets where a single instrument may have many names. It enhances accuracy in routing, clearing, and reporting. The repeating group structure provides extensibility and avoids the need for multiple single-purpose fields. NoSecurityAltID is used in Security Definition and Market Data messages. It is essential for firms operating across multiple data vendors and exchanges.

Tag 455: SecurityAltID
Tag 455 (SecurityAltID) is an alternative identifier for a financial instrument, such as a vendor-specific ticker or internal code. It is used in conjunction with SecurityAltIDSource (Tag 456) to specify the namespace (e.g., Bloomberg, Reuters). For example, Apple might have SecurityAltID = “AAPL US Equity” with Source = Bloomberg. This field supports accurate identification when the primary Symbol (Tag 55) is ambiguous or unavailable. SecurityAltID is particularly useful in fixed income, derivatives, and international securities where naming conventions vary. It enhances data integration across systems and reduces misidentification risk. The field is repeated within the NoSecurityAltID group, allowing multiple alternative IDs per security. SecurityAltID is a key tool for data normalization in multi-vendor environments.

Tag 456: SecurityAltIDSource
Tag 456 (SecurityAltIDSource) identifies the source or namespace of the SecurityAltID (Tag 455). Valid values include Bloomberg (1), Reuters (2), and Proprietary (3). It ensures that the alternative identifier is interpreted correctly. For example, “C 12345” could mean different things on Bloomberg vs. Reuters. SecurityAltIDSource prevents ambiguity and supports accurate mapping across data providers. It is used in the NoSecurityAltID repeating group and is essential for global security identification. The field enables firms to reconcile instruments across different systems and vendors. SecurityAltIDSource enhances data quality and reduces operational risk in trading and clearing workflows.

Tag 457: NoUnderlyingSecurityAltID
Tag 457 (NoUnderlyingSecurityAltID) specifies the number of alternative identifiers for the underlying security in a derivative. It defines the size of the repeating group containing UnderlyingSecurityAltID (Tag 458) and UnderlyingSecurityAltIDSource (Tag 459). This field supports precise identification of the underlying asset when it has multiple vendor-specific or internal codes. It is particularly important in options, futures, and structured products where the underlying may be a bond, index, or foreign stock with non-unique symbols. NoUnderlyingSecurityAltID enhances clarity and reduces misidentification risk in complex instruments.

Tag 458: UnderlyingSecurityAltID
Tag 458 (UnderlyingSecurityAltID) is an alternative identifier for the underlying security in a derivative contract. It is used with UnderlyingSecurityAltIDSource (Tag 459) to specify vendor-specific or internal codes (e.g., “MSFT UW Equity” on Bloomberg). This field ensures accurate referencing of the underlying asset, especially when the primary symbol is ambiguous. It supports data integration and reduces errors in pricing, clearing, and reporting. UnderlyingSecurityAltID is repeated within the NoUnderlyingSecurityAltID group, allowing multiple identifiers per underlying.

Tag 459: UnderlyingSecurityAltIDSource
Tag 459 (UnderlyingSecurityAltIDSource) specifies the source of the UnderlyingSecurityAltID (Tag 458), such as Bloomberg (1) or Reuters (2). It ensures correct interpretation of the alternative identifier. This field prevents confusion when the same code appears in different vendor systems. It supports global trading and data normalization. UnderlyingSecurityAltIDSource is essential for accurate derivative valuation and risk management.

Tag 460: Product
Tag 460 (Product) specifies the broad asset class of a financial instrument: Equity (1), Debt (2), FX (3), or Commodity (4). It is used in order, quote, and market data messages to guide routing, pricing, and risk systems. Product helps determine the appropriate handling logic, such as margin requirements or trading rules. It supports regulatory reporting and best execution analysis by classifying instruments at a high level. The field is essential for multi-asset trading platforms and algorithmic strategies. Product enhances message clarity and ensures consistent processing across asset classes.

Tag 461: CFICode
Tag 461 (CFICode) is the Classification of Financial Instruments (CFI) code, an ISO 10962 standard that categorizes a financial instrument by type, structure, and features. It consists of six characters indicating the asset class, optionality, exercisability, and other attributes (e.g., ESVOFR for a standard equity call option). CFICode supports accurate instrument identification, regulatory reporting, and risk classification. It enables systems to apply correct trading, margin, and clearing rules. CFICode is used in Security Definition, Execution Reports, and market data messages. It enhances transparency in complex instruments and ensures consistency across global markets. Unlike Symbol or SecurityType, CFICode provides granular structural detail. It is essential for derivatives, structured products, and compliance with MiFID II, EMIR, and other regulations requiring standardized instrument classification. CFICode reduces ambiguity and supports automation in trading, clearing, and surveillance systems.

Tag 462: UnderlyingProduct
Tag 462 (UnderlyingProduct) specifies the broad asset class of the underlying security in a derivative contract, such as Equity (1), Fixed Income (2), or Commodity (3). It complements Product (Tag 460) by providing context for the referenced asset. This field supports correct handling of pricing, margining, and regulatory requirements. For example, an option on a bond would have Product = Option and UnderlyingProduct = Debt. UnderlyingProduct enables trading systems to apply appropriate logic based on the underlying’s characteristics. It is particularly useful in multi-asset derivatives and structured products. The field enhances risk modeling and ensures accurate classification in clearing and reporting workflows. UnderlyingProduct is used in Security Definition and Execution messages. It supports transparency in complex instruments and helps prevent misclassification in automated trading environments.

Tag 463: UnderlyingCFICode
Tag 463 (UnderlyingCFICode) is the ISO 10962 CFI code for the underlying security in a derivative instrument. It provides detailed structural classification of the underlying, such as whether it is a bond, equity, or index, and its specific features. This field ensures precise identification beyond Symbol or SecurityType. For example, an option on a convertible bond would have an UnderlyingCFICode reflecting the bond’s convertibility. UnderlyingCFICode supports accurate risk assessment, margin calculation, and regulatory reporting. It is essential for derivatives where the underlying’s structure affects valuation. The field enhances transparency in OTC and exchange-traded derivatives. It is used in Security Definition and Execution Reports. UnderlyingCFICode ensures that both parties have a consistent understanding of the referenced asset, reducing operational risk and supporting compliance with global standards.

Tag 464: TestMessageIndicator
Tag 464 (TestMessageIndicator) indicates whether a message is a test (Y) or live (N). When set to ‘Y’, it signals that the message should not be processed as a real trade or order. This field is used during system testing, integration, or failover drills to prevent unintended executions. It allows counterparties to validate connectivity, message formats, and workflows without market impact. TestMessageIndicator is critical for operational safety and is typically set at the session or message level. It supports regulatory compliance by ensuring test traffic is isolated from production. The field is used in all message types and is validated by receiving systems. Its use prevents costly errors during upgrades or onboarding. TestMessageIndicator is a fundamental control mechanism in FIX 4.4, enabling safe and reliable testing in live environments.

Tag 465: QuantityType (Deprecated)
Tag 465 (QuantityType) was used to specify the type of order quantity—e.g., shares, contracts, or cash—but is deprecated in FIX 4.4. It has been replaced by more specific fields like OrderQty (Tag 38) for units and CashOrderQty (Tag 152) for monetary amounts. The deprecation was due to ambiguity and lack of consistent implementation. Applications should not use this tag. Its functionality is now handled through dedicated quantity fields. Continuing to use deprecated tags can lead to parsing errors or rejection. Modern FIX implementations rely on explicit, well-defined quantity fields to ensure clarity in order submission. The removal of QuantityType reflects FIX’s evolution toward precise, unambiguous messaging. Users are encouraged to adopt the current standard fields for quantity specification.

Tag 466: BookingRefID
Tag 466 (BookingRefID) is a reference identifier assigned by the broker or client for internal booking and post-trade processing. It links the execution to back-office systems, such as portfolio management or accounting platforms. BookingRefID supports reconciliation, commission allocation, and performance attribution. It may correspond to a trader’s desk code, strategy ID, or internal ticket number. The field is optional but valuable in institutional workflows where multiple systems must align. BookingRefID enhances auditability and ensures accurate trade capture. It is included in Execution Reports and Allocation messages. While not used for routing, it plays a critical role in downstream processing. The identifier is typically generated before order submission and remains with the trade throughout its lifecycle.

Tag 467: IndividualAllocID
Tag 467 (IndividualAllocID) is a unique identifier assigned to a specific allocation within a larger allocation message. It distinguishes between multiple accounts receiving portions of a trade. IndividualAllocID supports granular tracking and reconciliation of allocations. It is used in Allocation (MsgType J) and Allocation Report (MsgType AS) messages. Each repeating block for AllocAccount (Tag 79) and AllocQty (Tag 80) can have its own IndividualAllocID. This field ensures that each beneficiary’s allocation is uniquely identifiable, reducing errors in settlement and accounting. IndividualAllocID is essential for institutional investors managing multiple portfolios or sub-accounts. It enhances transparency in post-trade workflows and supports regulatory reporting on fund-level allocations.

Tag 468: RoundingDirection
Tag 468 (RoundingDirection) specifies how a price or quantity should be rounded: Round to Nearest (0), Round Up (1), or Round Down (2). It ensures consistent handling of fractional values in order pricing, allocation, or commission calculations. This field prevents discrepancies due to different rounding conventions across systems. For example, a broker may be instructed to round a price down to be conservative. RoundingDirection is used in conjunction with RoundingModulus (Tag 469), which defines the increment (e.g., 0.01). The combination supports precise price formatting in equities, bonds, and derivatives. RoundingDirection enhances fairness and transparency in execution and is particularly important in cross-border or multi-system environments where rounding rules may vary.

Tag 469: RoundingModulus
Tag 469 (RoundingModulus) defines the increment to which a price or quantity should be rounded, such as 0.01 for cents or 1 for whole shares. It is used with RoundingDirection (Tag 468) to control rounding behavior. For example, a price of 12.347 with RoundingModulus = 0.01 and RoundingDirection = 0 becomes 12.35. This field ensures consistency in price formatting across trading, clearing, and reporting systems. It is particularly useful in markets with tick size rules or when aggregating partial fills. RoundingModulus supports accurate cost basis calculation and prevents small discrepancies in allocations or commissions. The field enhances precision in financial calculations and is essential for compliance with exchange pricing rules.

Tag 470: CountryOfIssue
Tag 470 (CountryOfIssue) identifies the country that issued a security, using ISO 3166-1 alpha-2 codes (e.g., US, DE). It is used for bonds, equities, and structured products to determine tax treatment, regulatory jurisdiction, and credit risk. For example, a German government bond would have CountryOfIssue = DE. This field supports withholding tax calculations and compliance with local regulations. It is particularly important in cross-border investing and clearing. CountryOfIssue is used in Security Definition and Execution messages. It enhances transparency in international portfolios and helps investors assess sovereign risk. The field is essential for accurate reporting under MiFID II, FATCA, and other global regulatory frameworks.

Tag 471: StateOrProvinceOfIssue
Tag 471 (StateOrProvinceOfIssue) specifies the sub-national jurisdiction that issued a security, such as a U.S. state or Canadian province. It is used primarily for municipal bonds, where the issuer’s location affects tax status and credit risk. For example, a California municipal bond would have StateOrProvinceOfIssue = CA. This field supports tax-exempt status determination and investor eligibility checks. It is used in conjunction with CountryOfIssue (Tag 470) and SecurityDesc (Tag 107). StateOrProvinceOfIssue enhances precision in fixed-income trading and ensures correct handling of local regulations. The field is essential for institutional investors managing tax-sensitive portfolios.

Tag 472: LocaleOfIssue
Tag 472 (LocaleOfIssue) specifies the city or local region where a security was issued, such as “New York” or “Tokyo.” It provides additional geographic context beyond CountryOfIssue and StateOrProvinceOfIssue. This field is used for municipal bonds, local government securities, or region-specific instruments. LocaleOfIssue supports investor research, risk analysis, and regulatory reporting. It helps identify exposure to local economic conditions. While optional, it enhances granularity in portfolio management. The field is particularly relevant in markets with numerous local issuers. LocaleOfIssue contributes to comprehensive security identification in complex fixed-income environments.

Tag 473: NoRegistDtls
Tag 473 (NoRegistDtls) indicates the number of registration detail entries in a repeating group. It defines how many times RegistDtls (Tag 474) and related fields repeat. This field supports the transmission of multiple registration instructions for a single security, such as for different accounts or beneficiaries. NoRegistDtls enables structured, batch processing of registration data in corporate actions, new issues, or fund subscriptions. It enhances efficiency in back-office operations and ensures complete instruction delivery. The repeating group structure allows for flexibility in specifying diverse registration requirements. NoRegistDtls is essential for accurate and scalable registration workflows.

Tag 474: MailingDtls
Tag 474 (MailingDtls) contains instructions for physical mail delivery, such as address, method, or special handling. It is used in registration and corporate action messages to specify where certificates or documents should be sent. MailingDtls supports investor communication in non-electronic environments. It includes details like street address, city, and postal code. While less common in digital trading, it remains relevant for physical securities or legacy systems. The field ensures that investors receive required materials. MailingDtls is used with MailingInst (Tag 482) to define delivery preferences. It enhances service quality in client-facing operations.

Tag 475: InvestorCountryOfResidence
Tag 475 (InvestorCountryOfResidence) specifies the country where the investor resides, using ISO 3166 codes. It is used for tax withholding, regulatory reporting, and investor eligibility. For example, a U.S. resident investing in foreign securities may be subject to different tax rules. This field supports FATCA, CRS, and other cross-border compliance regimes. InvestorCountryOfResidence is critical for accurate tax treatment and reporting. It is used in registration, allocation, and distribution messages. The field ensures that payments are processed correctly and helps prevent penalties for non-compliance.

Tag 476: PaymentRef
Tag 476 (PaymentRef) is a reference identifier for a cash payment, such as a dividend, coupon, or redemption. It supports reconciliation and tracking of distributions. PaymentRef may correspond to a check number, wire ID, or internal transaction code. The field ensures that payments can be matched to accounts and reported accurately. It is used in distribution messages and confirmations. PaymentRef enhances transparency in cash flow management and supports auditability. It is essential for institutional investors monitoring income streams.

Tag 477: DistribPaymentMethod
Tag 477 (DistribPaymentMethod) specifies how a distribution (e.g., dividend) will be paid: Direct Credit (1), Check (2), or Reinvest (3). It guides the payment processor on handling instructions. This field supports investor preferences and account setup. For example, some investors choose to reinvest dividends into additional shares. DistribPaymentMethod ensures correct execution of distribution elections. It is used in corporate action and registration messages. The field enhances client service and operational accuracy in payout processing.

Tag 478: CashDistribCurr
Tag 478 (CashDistribCurr) specifies the currency in which a cash distribution (e.g., dividend) will be paid, using ISO 4217 codes. It may differ from the security’s trading currency. For example, a EUR-denominated bond may pay coupons in USD. CashDistribCurr ensures correct payment processing and accounting. It supports multi-currency portfolios and cross-border investing. The field is used in distribution and corporate action messages. It enhances clarity in international transactions and ensures accurate FX handling.

Tag 479: CommCurrency
Tag 479 (CommCurrency) specifies the currency in which commission is charged, which may differ from the trade or settlement currency. For example, a trade in EUR may incur commission in USD. CommCurrency ensures accurate billing and accounting. It supports global brokers charging in their base currency. The field is used in Execution Reports and Allocation messages. It enhances transparency in fee structures and supports multi-currency cost reporting.

Tag 480: CancellationRights
Tag 480 (CancellationRights) indicates whether an investor has the right to cancel a subscription or trade (Y/N). It is used in fund offerings and private placements to convey contractual terms. This field supports regulatory compliance and investor protection rules. It helps brokers disclose material terms. CancellationRights is particularly relevant in UCITS or retail fund distributions. The field enhances transparency in subscription workflows.

Tag 481: MoneyLaunderingStatus
Tag 481 (MoneyLaunderingStatus) indicates the AML verification status of an investor: Exempt (1), Verified (2), or Not Checked (3). It supports compliance with anti-money laundering regulations. This field helps brokers document due diligence. It is used in onboarding and registration messages. MoneyLaunderingStatus enhances auditability and ensures adherence to KYC requirements.

Tag 482: MailingInst
Tag 482 (MailingInst) specifies mailing instructions: Physical (1), Electronic (2), or Both (3). It guides how communications should be delivered. This field supports investor preferences and operational efficiency. MailingInst is used in registration and corporate action messages. It ensures timely and preferred delivery of materials.

Tag 483: TransBkdTime
Tag 483 (TransBkdTime) is the time a trade was booked in the back-office system, in UTC. It supports audit trails and operational reporting. TransBkdTime ensures accurate record-keeping and helps measure trade processing latency. The field is used in confirmations and internal reports.

Tag 484: ExecPriceType
Tag 484 (ExecPriceType) specifies the type of execution price: Bid (1), Offer (2), or Midpoint (3). It provides context for the execution level. This field supports best execution analysis and pricing transparency. It is used in Execution Reports. ExecPriceType enhances fairness in execution reporting.

Tag 485: ExecPriceAdjustment
Tag 485 (ExecPriceAdjustment) specifies an adjustment applied to the execution price in an Execution Report, typically to reflect fees, rebates, or internal transfer pricing. It allows brokers to report a net execution price that accounts for incentives or costs not reflected in the trade price. For example, a broker may adjust the price downward to reflect a payment for order flow. This field supports transparency in execution quality reporting and is used in institutional and agency trading environments. ExecPriceAdjustment ensures that the effective cost of execution is accurately conveyed to the client. It is particularly relevant under MiFID II, which requires detailed disclosure of inducements. The adjustment is usually expressed as a currency amount and can be positive or negative. When combined with ExecPriceType (Tag 484), it provides full context on pricing. While optional, it enhances trust and compliance by revealing economic terms beyond the visible trade price.

Tag 486: DateOfBirth
Tag 486 (DateOfBirth) specifies the investor’s date of birth in YYYYMMDD format. It is used in registration, onboarding, and compliance messages to support Know Your Customer (KYC) and anti-money laundering (AML) requirements. DateOfBirth helps verify identity, assess eligibility (e.g., for retirement accounts), and meet regulatory mandates like FATCA or CRS. It is particularly important for individual investors and trust accounts. The field supports age-based investment rules and tax treatment, such as required minimum distributions from retirement accounts. DateOfBirth is typically collected during account setup and may be validated against government-issued IDs. It is transmitted securely and often subject to data privacy protections. While not used in trading logic, it plays a critical role in back-office compliance and reporting. Its inclusion ensures accurate investor profiling and regulatory adherence.

Tag 487: TradeReportTransType
Tag 487 (TradeReportTransType) specifies the type of action being performed on a trade report: New (0), Cancel (1), Replace (2), or Restate (3). It is used in trade reporting messages (e.g., Trade Capture Report) to manage the lifecycle of a trade submission to a trade repository or regulator. When a trade is first reported, the value is 0; if an error is found, a replacement (2) or cancellation (1) is sent. This field ensures accurate and auditable trade reporting under regulations like MiFID II, Dodd-Frank, or EMIR. TradeReportTransType enables regulators to track changes and maintain a complete history. It supports reconciliation between counterparties and reduces disputes. The tag is essential for compliance and is widely used in post-trade infrastructure.

Tag 488: CardHolderName
Tag 488 (CardHolderName) contains the name of the individual or entity associated with a payment card, such as a credit or debit card used in financial transactions. It is used in secure payment or subscription messages where card-based payments are involved. The field supports identity verification and fraud prevention by confirming the cardholder matches the account holder. CardHolderName is typically transmitted in encrypted form (e.g., within SecureData) to protect sensitive information. It is used in conjunction with CardNumber (Tag 489) and CardExpDate (Tag 490) for payment validation. While not common in core trading messages, it may appear in fund subscription, fee payment, or retail brokerage workflows. Its use is limited to secure, authenticated channels.

Tag 489: CardNumber
Tag 489 (CardNumber) contains the primary account number (PAN) of a payment card used for financial transactions. It is used in secure messaging environments where card-based payments are processed, such as for subscription fees or retail investor transactions. Due to its sensitivity, CardNumber must be protected using encryption (e.g., SecureData fields) and should never be stored or transmitted in plain text. It is validated using standard checks like Luhn algorithm and expiry date. The field is used with CardHolderName (Tag 488) and CardExpDate (Tag 490) for payment processing. Its use in FIX is rare and typically restricted to proprietary or secure workflows. Compliance with PCI DSS is required when handling this data.

Tag 490: CardExpDate
Tag 490 (CardExpDate) specifies the expiration date of a payment card in YYYYMM format. It is used to validate that the card is still active at the time of transaction. CardExpDate prevents the use of expired cards in payment processing workflows, such as for subscription renewals or fee payments. It is used in conjunction with CardNumber (Tag 489) and CardHolderName (Tag 488) to authenticate the payment method. The field supports automated validation and reduces transaction failures. Like other card data, it should be transmitted securely and in compliance with data protection standards. Its use in FIX is limited to specific secure payment scenarios and is not part of standard trading messages.

Tag 491: CardIssNum
Tag 491 (CardIssNum) specifies the issue number of a payment card, primarily used in certain regions (e.g., UK) for Maestro or Switch cards. The issue number identifies the version of the card if it has been reissued. It supports payment validation in legacy or regional payment systems. While not universally used, it may be required for specific acquiring banks or payment processors. CardIssNum is typically a one- or two-digit number and is used alongside CardNumber (Tag 489) and CardExpDate (Tag 490). Due to its limited scope, it is rarely used in global trading systems. When present, it should be handled securely. Its inclusion ensures compatibility with regional payment infrastructures.

Tag 492: PaymentMethod
Tag 492 (PaymentMethod) specifies the method used for a cash payment or distribution: ACH (1), SWIFT (2), Check (3), or CHIPS (4). It guides the payment processor on how to execute the transfer. This field supports accurate and efficient settlement of dividends, redemptions, or fees. PaymentMethod ensures the correct network is used based on geography, currency, and recipient preferences. For example, domestic USD payments may use ACH, while international transfers use SWIFT. The field enhances clarity in distribution instructions and reduces processing errors. It is used in corporate action, allocation, and cash management messages. PaymentMethod is essential for operational efficiency and client service in post-trade workflows.

Tag 493: RegistAcctType
Tag 493 (RegistAcctType) specifies the type of investor account for registration purposes: Individual (1), Joint (2), Corporate (3), or IRA (4). It supports accurate account setup, tax treatment, and regulatory reporting. RegistAcctType determines documentation requirements, ownership rights, and distribution rules. For example, joint accounts may require signatures from all parties. The field is used in subscription, corporate action, and registration messages. It ensures that securities are registered correctly and that communications and payments are handled appropriately. RegistAcctType is critical for compliance with securities laws and investor protection rules. It enhances operational accuracy in back-office processing.

Tag 494: Designation
Tag 494 (Designation) specifies a special label or purpose for an account, such as “Retirement,” “Education,” or “Trust.” It provides additional context beyond the account type. Designation supports tax-advantaged account tracking and investor intent. For example, a designation of “529 Plan” indicates a college savings account. The field is used in registration and corporate action messages. It helps brokers apply correct rules for contributions, withdrawals, and reporting. Designation enhances client service by preserving investor goals in the account structure. While optional, it improves accuracy in long-term portfolio management.

Tag 495: TaxAdvantageType
Tag 495 (TaxAdvantageType) specifies the tax status of an account: IRA (1), 401K (2), Roth IRA (3), or other. It supports compliance with tax regulations and determines contribution limits, withdrawal rules, and reporting requirements. This field is critical for retirement and tax-deferred accounts. It ensures that distributions and contributions are processed correctly. TaxAdvantageType is used in registration, corporate actions, and distribution messages. It helps prevent tax penalties and supports investor education. The field enhances transparency in tax-sensitive investing and is essential for institutional and retail wealth management platforms.

Tag 496: RegistRejReasonText
Tag 496 (RegistRejReasonText) provides a free-text explanation for why a registration request was rejected. It complements RegistRejReasonCode (Tag 507) by offering detailed, human-readable context. For example, “Missing W-9 form” or “Invalid tax ID.” This field supports client communication and enables quick correction of errors. RegistRejReasonText is used in Registration Instructions and responses. It enhances operational efficiency by reducing back-and-forth. While not parsed algorithmically, it is valuable for customer service and compliance teams. The field ensures transparency in account onboarding and corporate action participation.

Tag 497: FundRenewWaiv
Tag 497 (FundRenewWaiv) indicates whether the renewal of a fund subscription is waived (Y/N). It is used in fund distribution messages to convey investor elections. For example, an investor may choose not to auto-renew their monthly investment plan. FundRenewWaiv supports flexible subscription management and client preferences. The field ensures that renewal actions align with investor intent. It is used in registration and corporate action workflows. FundRenewWaiv enhances service quality and reduces unintended transactions in automated investment programs.

Tag 498: CashDistribAgentName
Tag 498 (CashDistribAgentName) specifies the name of the entity responsible for distributing cash payments, such as dividends or interest. It identifies the paying agent or transfer agent. This field supports transparency and accountability in corporate actions. Investors and intermediaries can verify the source of payments. CashDistribAgentName is used in distribution and corporate action messages. It enhances trust and ensures correct processing. The field is particularly relevant in global securities where multiple agents may be involved.

Tag 499: CashDistribAgentCode
Tag 499 (CashDistribAgentCode) is a unique identifier for the cash distribution agent, such as a BIC or proprietary code. It enables precise routing and validation of payment instructions. CashDistribAgentCode is used with CashDistribAgentName (Tag 498) to ensure the correct entity is designated. It supports automation in payment processing and reduces errors. The field is essential for accurate and efficient distribution workflows in multi-agent environments.

Tag 500: CashDistribAgentAcctNumber
Tag 500 (CashDistribAgentAcctNumber) specifies the account number used by the cash distribution agent to fund payments. It ensures that dividends or coupons are drawn from the correct source account. This field supports reconciliation and auditability in corporate action processing. CashDistribAgentAcctNumber is used in distribution instructions and is critical for accurate settlement. It enhances operational control and reduces the risk of payment delays or failures.

Tag 501: CashDistribPayRef
Tag 501 (CashDistribPayRef) specifies a reference identifier for a cash distribution payment, such as a dividend or interest payout. It is used to uniquely identify the payment transaction for reconciliation, auditing, and tracking purposes. This field may correspond to an internal batch ID, wire reference, or clearing system transaction number. CashDistribPayRef ensures that payments can be matched to accounts and reported accurately across systems. It supports transparency in corporate actions and enhances operational efficiency in back-office processing. The field is particularly useful when multiple distributions occur simultaneously or when cross-referencing with bank statements. It is typically used in conjunction with CashDistribAgentName (Tag 498) and PaymentDate (Tag 504). CashDistribPayRef is essential for institutional investors and custodians managing large volumes of income transactions.

Tag 502: CashDistribAgentAcctName
Tag 502 (CashDistribAgentAcctName) specifies the name associated with the bank account used by the cash distribution agent to disburse funds. It provides human-readable context for the funding account, such as “Dividend Payout Account – Apple Inc.” This field enhances transparency and verification in payment workflows. When combined with CashDistribAgentAcctNumber (Tag 500), it ensures that the correct account is identified for audit and reconciliation. CashDistribAgentAcctName is used in corporate action and distribution messages. It supports operational clarity, especially in environments with multiple accounts for different securities or currencies. While not used for routing, it improves data quality and trust in automated distribution systems.

Tag 503: CardStartDate
Tag 503 (CardStartDate) specifies the issue date of a payment card in YYYYMM format, primarily used for certain UK and European cards like Maestro that include a start date. It supports validation of older card types where the start date is part of the authentication process. CardStartDate is used alongside CardNumber (Tag 489) and CardExpDate (Tag 490) to verify card legitimacy. Its use is limited to specific regional payment systems and is not common in global trading environments. When present, it should be transmitted securely and in compliance with data protection standards. The field ensures compatibility with legacy payment infrastructures and reduces transaction failures in retail or subscription-based brokerage services.

Tag 504: PaymentDate
Tag 504 (PaymentDate) specifies the scheduled date on which a cash payment, such as a dividend, coupon, or redemption, will be made. It is formatted as YYYYMMDD and is used in corporate action, distribution, and allocation messages. PaymentDate enables investors and intermediaries to plan cash flows and reconcile transactions. It distinguishes from the ex-date or record date by indicating when funds will be credited. The field supports accounting, performance measurement, and tax reporting. PaymentDate is critical for accurate income tracking and is widely used in custodial and asset management systems. It enhances transparency and client communication in investment operations.

Tag 505: PaymentRemitterID
Tag 505 (PaymentRemitterID) identifies the entity initiating a payment, such as a broker, transfer agent, or clearinghouse. It provides traceability in distribution workflows and supports reconciliation. PaymentRemitterID may be a BIC, LEI, or proprietary code, used with PaymentRemitterIDSource for clarity. This field ensures that the source of funds is documented, which is important for audit and regulatory reporting. It is particularly relevant in cross-border payments where multiple intermediaries are involved. PaymentRemitterID enhances accountability and reduces ambiguity in cash movement tracking. It is used in conjunction with PaymentMethod (Tag 492) and PaymentDate (Tag 504) for complete payment instruction.

Tag 506: RegistStatus
Tag 506 (RegistStatus) indicates the processing status of a registration request: Accepted (1), Rejected (2), or Pending (3). It is used in Registration Instructions and responses to inform the submitter of the outcome. RegistStatus supports operational transparency in account setup, corporate actions, and fund subscriptions. It enables timely follow-up on rejected or pending requests. The field is essential for back-office coordination and ensures that securities are registered correctly. When combined with RegistRejReasonText (Tag 496), it provides full feedback. RegistStatus enhances efficiency in investor servicing and compliance workflows.

Tag 507: RegistRejReasonCode
Tag 507 (RegistRejReasonCode) specifies a standardized numeric reason for rejecting a registration request: Invalid Account (1), Missing Information (2), or Invalid Tax ID (3). It provides structured feedback that can be processed programmatically. This field works with RegistRejReasonText (Tag 496) to offer both coded and descriptive rejection details. RegistRejReasonCode supports automation in onboarding and corporate action processing. It enables systems to route or escalate issues based on the code. The field enhances consistency in rejection handling and reduces manual intervention. It is essential for scalable investor registration and compliance with KYC/AML requirements.

Tag 508: RegistRefID
Tag 508 (RegistRefID) is a reference identifier assigned to a registration request, used to link requests and responses. It ensures message correlation in Registration Instructions and acknowledgments. RegistRefID enables tracking of registration lifecycle events and supports reconciliation. It is particularly useful in high-volume environments like corporate actions or IPO allocations. The field enhances auditability and helps prevent duplicate submissions. RegistRefID is generated by the requester and echoed by the responder. It is a critical control in automated registration workflows.

Tag 509: RegistDtls
Tag 509 (RegistDtls) contains free-form text with additional registration instructions, such as special handling notes or investor comments. It supports communication of non-structured information not captured by coded fields. RegistDtls is used in Registration Instructions and responses. While not parsed algorithmically, it provides valuable context for operations teams. The field enhances clarity in complex registration scenarios and supports client-specific requirements. It is particularly useful in manual or exception-based processing.

Tag 510: NoDistribInsts
Tag 510 (NoDistribInsts) specifies the number of distribution instruction entries in a repeating group. It defines how many times DistribPaymentMethod (Tag 477), CashDistribCurr (Tag 478), and related fields repeat. This field supports the transmission of multiple payment instructions for a single security or investor. NoDistribInsts enables flexible, granular control over how dividends or interest are distributed across accounts. It is essential for investors with complex payout preferences. The repeating group structure ensures scalability and clarity in distribution messaging.

Tag 511: RegistEmail
Tag 511 (RegistEmail) specifies the email address to be used for registration-related communications, such as confirmations or status updates. It supports electronic delivery of investor notices and reduces reliance on physical mail. RegistEmail is used in onboarding, corporate actions, and account maintenance. It enhances client service and operational efficiency. The field must be handled in compliance with data privacy regulations. RegistEmail ensures timely and preferred communication with investors.

Tag 512: DistribPercentage
Tag 512 (DistribPercentage) specifies the portion of a distribution allocated to a specific account, expressed as a percentage. It supports partial or pro-rata distributions in multi-account portfolios. For example, 50% of a dividend may be reinvested, 50% paid in cash. DistribPercentage is used in conjunction with DistribPaymentMethod (Tag 477) and CashDistribCurr (Tag 478). It enables customized income handling and supports investor preferences. The field enhances flexibility in wealth management and corporate action processing.

Tag 513: RegistID
Tag 513 (RegistID) is a unique identifier assigned to a registration record, such as for a corporate action or new issue. It enables tracking and referencing of specific registration events. RegistID supports reconciliation and auditability. It is used in Registration Instructions and responses. The field ensures that each registration is uniquely identifiable, reducing errors in high-volume environments. RegistID is essential for accurate and scalable investor servicing.

Tag 514: RegistTransType
Tag 514 (RegistTransType) specifies the type of registration transaction: New (0), Cancel (1), or Replace (2). It controls the lifecycle of a registration instruction. For example, a Cancel request removes a prior instruction. This field supports dynamic updates and corrections. RegistTransType ensures correct processing and prevents duplication. It is used in Registration Instructions and is critical for maintaining accurate investor records.

Tag 515: ExecValuationPoint
Tag 515 (ExecValuationPoint) specifies the time used to value an execution, typically in complex or delayed settlements. It may differ from TransactTime (Tag 60) if valuation occurs later. ExecValuationPoint supports accurate performance measurement and accounting. It is used in Execution Reports and allocations. The field ensures consistency in pricing across systems and is particularly relevant in cross-border or OTC trades.

Tag 516: OrderPercent
Tag 516 (OrderPercent) specifies the order quantity as a percentage of a reference value, such as available liquidity or float. It supports relative sizing in algorithmic trading. For example, “10% of average daily volume.” OrderPercent enables dynamic order sizing based on market conditions. It is used in conjunction with order instructions and enhances execution strategy flexibility.

Tag 517: OwnershipType
Tag 517 (OwnershipType) specifies the legal structure of ownership: Joint Tenants (J), Tenants in Common (T), or Community Property (C). It determines rights of survivorship and inheritance. OwnershipType is used in registration and account setup. It ensures correct legal treatment and documentation. The field is critical for estate planning and compliance.

Tag 518: NoContAmts
Tag 518 (NoContAmts) specifies the number of contingent amount entries in a repeating group. It defines how many times ContAmtType (Tag 519), ContAmtValue (Tag 520), and ContAmtCurr (Tag 521) repeat. This field supports the transmission of multiple conditional fees or commissions. NoContAmts enhances clarity in complex pricing structures.

Tag 519: ContAmtType
Tag 519 (ContAmtType) specifies the type of contingent amount: Commission (1), Fee (2), or Tax (3). It categorizes conditional payments in allocations or executions. ContAmtType supports transparent cost reporting and compliance with MiFID II. It is used with ContAmtValue and ContAmtCurr.

Tag 520: ContAmtValue
Tag 520 (ContAmtValue) specifies the monetary value of a contingent amount, such as a performance fee or rebate. It is used in allocations to reflect variable costs. ContAmtValue ensures accurate net performance calculation. It is essential for institutional investors requiring detailed expense reporting.

Tag 521: ContAmtCurr
Tag 521 (ContAmtCurr) specifies the currency of a contingent amount using ISO 4217. It ensures correct valuation and accounting, especially in cross-border transactions. ContAmtCurr is used with ContAmtValue and supports multi-currency fee reporting.

Tag 522: OwnerType
Tag 522 (OwnerType) specifies the investor type: Individual (1), Organization (2), or Trust (3). It supports KYC, tax, and regulatory reporting. OwnerType ensures correct handling of ownership rules and documentation. It is used in registration and allocation messages.

Tag 523: PartySubID
Tag 523 (PartySubID) specifies a sub-identifier for a party, such as a trader ID, desk, or algorithm. It complements PartyID (Tag 448) for granular identification. PartySubID supports internal tracking and performance attribution. It is used in execution and market data messages.

Tag 524: NestedPartyID
Tag 524 (NestedPartyID) identifies a party within a nested repeating group, such as a broker within a broker chain. It supports multi-level routing and attribution. NestedPartyID is used with NestedPartyIDSource and NestedPartyRole.

Tag 525: NestedPartyIDSource
Tag 525 (NestedPartyIDSource) specifies the source namespace of NestedPartyID, such as BIC (1) or Proprietary (3). It ensures unambiguous identification in nested structures. NestedPartyIDSource enhances clarity in complex counterparty hierarchies.

Tag 526: SecondaryClOrdID
Tag 526 (SecondaryClOrdID) is an alternate client order identifier, often used by exchanges or clearinghouses. It supports cross-referencing between systems. SecondaryClOrdID enhances traceability and is used in Execution Reports.

Tag 527: SecondaryExecID
Tag 527 (SecondaryExecID) is an alternate execution identifier assigned by a third party. It supports audit and reconciliation. SecondaryExecID is used in Execution Reports and allocations.

Tag 528: OrderCapacity
Tag 528 (OrderCapacity) specifies the role of the firm in an order: Agency (1), Principal (2), or Riskless Principal (3). It supports regulatory reporting and best execution. OrderCapacity ensures transparency in execution quality.

Tag 529: OrderRestrictions
Tag 529 (OrderRestrictions) specifies execution constraints: Program Trade (1), Index Arbitrage (2). It supports regulatory categorization. OrderRestrictions is used in order and execution messages.

Tag 530: MassCancelRequestType
Tag 530 (MassCancelRequestType) specifies the scope of a mass cancel: Cancel for Symbol (1), Security Type (2), or All Orders (3). It controls broad order cancellation. MassCancelRequestType supports efficient order book management.

Tag 531: MassCancelResponse
Tag 531 (MassCancelResponse) indicates the result of a Mass Cancel Request (MsgType q), such as Successful Completion (1), Rejected (2), or Partial Cancellation (3). It is returned in a Mass Cancel Report message to inform the requester of the outcome. This field supports bulk order management, allowing traders to cancel multiple orders based on criteria like symbol or side. MassCancelResponse ensures transparency in large-scale order book adjustments. It enables clients to verify which orders were affected and take follow-up actions if needed. The response code helps identify processing issues, such as permission errors or market-specific restrictions. MassCancelResponse is essential for algorithmic and high-frequency trading systems that dynamically manage order exposure. It enhances operational control and reduces manual intervention in volatile markets.

Tag 532: MassCancelRejectReason
Tag 532 (MassCancelRejectReason) specifies why a Mass Cancel Request was rejected: Invalid Cancel Request (0), Too Late to Cancel (1), or Unknown Symbol (2). It is used in Mass Cancel Report messages when the response indicates rejection. This field provides actionable feedback for troubleshooting. It helps clients understand whether the failure was due to timing, permissions, or data errors. MassCancelRejectReason supports reliable order management and ensures clients can correct and resubmit requests. The tag is particularly important in fast-moving markets where timely cancellation is critical. It enhances transparency and operational efficiency in bulk trading workflows.

Tag 533: TotalAffectedOrders
Tag 533 (TotalAffectedOrders) specifies the total number of orders impacted by a Mass Cancel Request. It includes orders that were successfully canceled or rejected. This field provides a summary count for reconciliation and audit purposes. TotalAffectedOrders helps clients assess the scope of the cancellation and verify system behavior. It is included in the Mass Cancel Report and supports post-event analysis. The count may be zero if no orders matched the criteria. TotalAffectedOrders enhances transparency in bulk operations and ensures confidence in order book management.

Tag 534: NoAffectedOrders
Tag 534 (NoAffectedOrders) indicates the number of individual orders detailed in a repeating group within a Mass Cancel Report. It defines how many times AffectedOrderID (Tag 535) and AffectedSecondaryOrderID (Tag 536) repeat. This field supports granular reporting of which specific orders were canceled or rejected. NoAffectedOrders enables precise tracking and reconciliation, especially when only a subset of orders is affected. It enhances auditability and supports exception handling in automated trading systems. The repeating group structure ensures scalability and clarity.

Tag 535: AffectedOrderID
Tag 535 (AffectedOrderID) is the OrderID (Tag 37) of an order impacted by a mass cancellation. It is used in the repeating group of a Mass Cancel Report to list each affected order. This field enables clients to identify exactly which broker-assigned orders were canceled or rejected. AffectedOrderID supports detailed reconciliation and helps prevent disputes. It is essential for institutional traders managing large portfolios. When combined with ExecID (Tag 17), it provides full lifecycle tracking.

Tag 536: AffectedSecondaryOrderID
Tag 536 (AffectedSecondaryOrderID) is an alternate identifier for an order affected by a mass cancellation, often used by exchanges or clearing systems. It complements AffectedOrderID (Tag 535) and supports cross-system referencing. This field enhances traceability in multi-venue or multi-broker environments. AffectedSecondaryOrderID is particularly useful in regulatory reporting and trade affirmation workflows.

Tag 537: QuoteType
Tag 537 (QuoteType) specifies the type of quote being submitted: Indicative (0), Firm (1), or Restricted (2). It defines the binding nature of the quote. A Firm quote implies commitment to trade at the stated price and size, while Indicative is non-binding. QuoteType is used in Quote (MsgType S) and Quote Response (MsgType AQ) messages. It supports RFQ workflows in fixed income, derivatives, and OTC markets. The field ensures correct handling and response expectations between counterparties.

Tag 538: NestedPartyRole
Tag 538 (NestedPartyRole) specifies the role of a party within a nested repeating group, such as a sub-broker or executing trader. It is used with NestedPartyID (Tag 524) to define responsibilities in multi-hop messaging. NestedPartyRole supports complex routing chains and attribution. Valid roles include Executing Firm (1), Broker (3), or Clearing Firm (7). The field enhances transparency in routed orders and supports regulatory reporting.

Tag 539: NoNestedPartyIDs
Tag 539 (NoNestedPartyIDs) indicates the number of nested party entries in a repeating group. It defines how many times NestedPartyID (Tag 524), NestedPartyIDSource (Tag 525), and NestedPartyRole (Tag 538) repeat. This field supports hierarchical party structures, such as broker networks or agency chains. NoNestedPartyIDs enables flexible, scalable identification of multiple intermediaries. It is essential for accurate attribution in multi-firm trading relationships.

Tag 540: TotalAccruedInterestAmt (Deprecated)
Tag 540 (TotalAccruedInterestAmt) was used to specify the total accrued interest on a bond trade but is deprecated in FIX 4.4. It has been replaced by AccruedInterestAmt (Tag 159), which serves the same purpose with broader adoption. Applications should not use this tag. Its inclusion may cause parsing issues or be ignored. The deprecation reflects FIX’s effort to consolidate redundant fields. Users are encouraged to migrate to the standard AccruedInterestAmt for accurate bond settlement reporting.

Tag 541: MaturityDate
Tag 541 (MaturityDate) specifies the date on which a security matures and principal is repaid, formatted as YYYYMMDD. It is used for bonds, futures, options, and other time-bound instruments. MaturityDate is critical for pricing, yield calculation, and risk modeling. It determines the instrument’s life and affects accrued interest, duration, and volatility. The field is used in Security Definition, Execution Reports, and market data. MaturityDate ensures correct handling of expiration and settlement.

Tag 542: UnderlyingMaturityDate
Tag 542 (UnderlyingMaturityDate) specifies the maturity date of the underlying security in a derivative contract, such as an option or future. It is formatted as YYYYMMDD and supports accurate valuation and risk assessment. This field is essential when the underlying is a bond, future, or other maturity-based instrument. UnderlyingMaturityDate ensures correct modeling of cash flows and expiration alignment. It is used in Security Definition and Execution messages.

Tag 543: InstrRegistry
Tag 543 (InstrRegistry) identifies the official registry or authority responsible for maintaining the security’s data, such as a national numbering agency (e.g., CUSIP Bureau). It supports data integrity and standardization. InstrRegistry enhances transparency in security identification and is used in Security Definition messages. It ensures that instrument data is sourced from a trusted authority, reducing misidentification risk.

Tag 544: CashMargin
Tag 544 (CashMargin) indicates whether an order is for a Cash (1) or Margin (2) account. It informs the broker of the funding method and affects settlement, leverage, and regulatory reporting. CashMargin supports correct handling of collateral and credit checks. The field is used in order submission and is critical for compliance with margin rules and investor suitability.

Tag 545: NestedPartySubID
Tag 545 (NestedPartySubID) specifies a sub-identifier for a nested party, such as a trader ID or desk code within a broker chain. It complements NestedPartyID (Tag 524) for granular attribution. NestedPartySubID supports detailed tracking in multi-level routing environments. It enhances transparency in execution workflows and supports performance measurement across hierarchical trading structures.

Tag 546: Scope
Tag 546 (Scope) specifies the geographical or operational scope of a quote or market data request: Local (1), National (2), Regional (3), or Global (4). It is used in Quote messages to indicate where the quoted liquidity is available. For example, a dealer may provide a firm quote for U.S. clients only (National), or across all regions (Global). Scope supports transparency in liquidity provision and helps requesters understand the reach of a quote. It is particularly relevant in multi-venue or cross-border trading environments. The field enhances decision-making in RFQ workflows by clarifying the availability of pricing. Scope also aids in regulatory reporting, where trade execution must align with jurisdictional rules. It ensures that counterparties have consistent expectations about the binding nature and coverage of a quote.

Tag 547: MDImplicitDelete
Tag 547 (MDImplicitDelete) indicates whether entries not included in a Market Data Incremental Refresh message should be considered deleted (Y) or remain unchanged (N). When set to ‘Y’, it signals that only entries explicitly listed are valid, and all others are implicitly removed from the book. This field optimizes bandwidth by avoiding full refreshes while maintaining book integrity. MDImplicitDelete is essential for efficient delta-based market data feeds, especially in fast-moving markets. It enables clients to reconstruct the order book accurately from incremental updates. The field supports both snapshot and streaming models and is widely used in equity and derivatives exchanges. Proper handling of MDImplicitDelete prevents stale data and ensures reliable execution decisions.

Tag 548: CrossID
Tag 548 (CrossID) is a unique identifier assigned by the sender to a cross order, such as a block trade or simultaneous buy/sell. It is used in Cross Order messages (e.g., Cross Order Cancel Replace Request) to reference the cross trade throughout its lifecycle. CrossID enables tracking, modification, and cancellation of cross orders. It ensures message linkage across submissions and responses. This field is critical in dark pools, internal crossing networks, and exchange-for-physical (EFP) transactions. CrossID supports auditability and reconciliation, ensuring both sides of the cross can be matched. It enhances transparency in non-transparent execution venues.

Tag 549: CrossType
Tag 549 (CrossType) specifies the type of cross order: Cross AON (1), Cross IOC (2), or Cross One Side (3). It defines the execution rules for a simultaneous buy/sell order. For example, Cross AON requires both sides to execute fully or not at all. CrossType controls matching logic and ensures correct handling by the exchange or broker. The field supports various block trading strategies and is used in Cross Order messages. It enables precise execution control in large-scale or risk-balancing trades. CrossType enhances flexibility in algorithmic and institutional trading workflows.

Tag 550: CrossPrioritization
Tag 550 (CrossPrioritization) specifies how a cross order should be prioritized relative to other orders: None (0), Buy Side is Prioritized (1), or Sell Side is Prioritized (2). It guides the matching engine when multiple crosses or resting orders compete for liquidity. For example, if the buy side is prioritized, the cross will execute only if the buy order can be filled. CrossPrioritization supports risk management and execution certainty. It is used in Cross Order messages and is particularly relevant in EFPs and internal crosses. The field ensures alignment with trading objectives and enhances execution control.

Tag 551: OrigCrossID
Tag 551 (OrigCrossID) references the original CrossID (Tag 548) when modifying or canceling a cross order. It links the new request to the prior cross, enabling brokers or exchanges to locate and update the correct order. OrigCrossID is mandatory in Cross Order Cancel/Replace and Cancel Request messages. It prevents errors in order management and supports accurate lifecycle tracking. The field ensures message linkage and consistency in cross-order processing, especially in high-frequency environments where multiple versions may exist.

Tag 552: NoSides
Tag 552 (NoSides) specifies the number of sides (buy/sell) in a repeating group, typically used in multilateral or cross-order messages. It defines how many times Side (Tag 54), OrderQty (Tag 38), and related fields repeat. This field supports complex order types involving multiple parties or legs, such as block crosses or multilateral trades. NoSides enables structured transmission of multi-party instructions and ensures complete message parsing. It is essential for accurate handling of non-standard execution workflows in institutional trading.

Tag 553: Username
Tag 553 (Username) specifies the login name used for authenticating a FIX session. It is often used in conjunction with Password (Tag 554) for basic session-level security. Username identifies the user or application connecting to the counterparty. While SenderCompID (Tag 49) identifies the firm, Username may identify a specific desk, algorithm, or individual. It supports granular access control and audit logging. However, due to security limitations, username/password authentication is typically used in low-risk environments or supplemented with stronger methods like SSL/TLS or digital certificates.

Tag 554: Password
Tag 554 (Password) provides the password for authenticating a FIX session. Used with Username (Tag 553), it supports basic login security. Password is typically included in the Logon message (MsgType A). Due to security risks, it should only be used over encrypted connections (e.g., SSL/TLS). Plaintext passwords are vulnerable to interception. Modern implementations often replace this with certificate-based or API-key authentication. Despite its limitations, Password remains in use for legacy systems. It supports initial authentication but should be combined with other security measures.

Tag 555: NoLegs
Tag 555 (NoLegs) specifies the number of legs in a multi-leg instrument, such as an option spread, convertible bond, or swap. It defines how many times LegSymbol (implied), LegSide, and other leg-specific fields repeat. NoLegs enables structured representation of complex derivatives. It is used in Security Definition, Execution Reports, and quotes. The repeating group supports accurate pricing, risk modeling, and clearing. NoLegs is essential for trading strategies involving multiple underlying components.

Tag 556: LegCurrency
Tag 556 (LegCurrency) specifies the currency of a leg in a multi-currency or multi-leg instrument. It allows each leg to have its own denomination, such as USD for one leg and EUR for another in a cross-currency swap. LegCurrency supports accurate valuation and settlement. It is used in conjunction with NoLegs (Tag 555) and enhances flexibility in structured products. The field ensures correct FX handling and is critical for international derivatives trading.

Tag 557: TotNoSecurityTypes
Tag 557 (TotNoSecurityTypes) specifies the total number of security types returned in a Security List message. It is used to confirm completeness when multiple messages are sent. TotNoSecurityTypes ensures all requested types have been processed and supports reconciliation. It is particularly useful in batch security inquiries. This field enhances reliability in security master data distribution.

Tag 558: NoSecurityTypes
Tag 558 (NoSecurityTypes) indicates the number of security type entries in a repeating group within a Security List Request or Response. It defines how many times SecurityType (Tag 167) and Product (Tag 460) repeat. NoSecurityTypes supports filtering and discovery of available instrument classes. It is used in market data and security definition workflows. The field enables efficient capability exchange between counterparties.

Tag 559: SecurityListRequestType
Tag 559 (SecurityListRequestType) specifies the type of security list requested: Symbol (0), Security Type (1), or Product (2). It controls the scope of a Security List Request (MsgType x). For example, requesting all equities (Product=1) or all options on a symbol. SecurityListRequestType supports dynamic security discovery and onboarding. It is essential for trading systems initializing instrument catalogs.

Tag 560: SecurityRequestResult
Tag 560 (SecurityRequestResult) indicates the outcome of a Security Request: Valid Request (0), Invalid Request (1), or No Instruments Found (2). It is returned in Security Definition messages. SecurityRequestResult provides feedback on the success of a security inquiry. It supports troubleshooting and ensures clients receive accurate instrument data. The field is essential for reliable security discovery.

Tag 561: RoundLot
Tag 561 (RoundLot) specifies the standard trading unit for a security, such as 100 shares. It supports order validation and display logic. Brokers may require orders in multiples of the round lot. RoundLot is used in market data and security definitions. It enhances consistency in order entry and execution.

Tag 562: MinTradeVol
Tag 562 (MinTradeVol) specifies the minimum tradable quantity for a security. Orders below this size may be rejected. MinTradeVol supports market structure rules and is used in fixed income or wholesale markets. It ensures efficient trading and is included in market data messages.

Tag 563: MultiLegRptTypeReq
Tag 563 (MultiLegRptTypeReq) specifies the requested reporting format for multi-leg trades: Single Security (1) or Individual Legs (2). It guides how the trade should be reported to regulators. This field supports compliance with MiFID II and other regimes.

Tag 564: LegPositionEffect
Tag 564 (LegPositionEffect) indicates whether a leg opens (O) or closes (C) a position. It is used in multi-leg orders to manage margin and accounting. LegPositionEffect ensures correct position tracking per leg in complex strategies.

Tag 565: LegCoveredOrUncovered
Tag 565 (LegCoveredOrUncovered) indicates whether a leg in a multi-leg options strategy is covered (1) or uncovered (0). This is particularly relevant for option legs where the underlying position determines margin and risk exposure. For example, a covered call implies the trader owns the underlying stock, while an uncovered (naked) call does not. This field supports accurate margin calculation, risk management, and regulatory reporting. It is used in Security Definition and Execution messages for complex derivatives like spreads or straddles. LegCoveredOrUncovered ensures that clearing systems and risk engines apply the correct capital requirements. The field enhances transparency in options trading and helps prevent excessive risk-taking. It is essential for institutional and proprietary trading desks managing large option portfolios.

Tag 566: LegPrice
Tag 566 (LegPrice) specifies the price of an individual leg in a multi-leg instrument, such as an option spread or convertible bond. It allows each leg to have its own valuation within a composite trade. LegPrice supports accurate pricing, profit/loss calculation, and performance attribution. It is used in conjunction with NoLegs (Tag 555) and other leg-specific fields. The field is essential for correct execution and clearing of complex strategies. LegPrice ensures that traders and systems can assess the economic terms of each component. It is particularly important in non-linear derivatives where the aggregate price does not reflect individual leg values. LegPrice enhances precision in algorithmic and institutional trading workflows.

Tag 567: TradSesStatusRejReason
Tag 567 (TradSesStatusRejReason) specifies the reason a request for trading session status was rejected: Invalid Trading Session (1) or Unauthorized Request (2). It is used in Trading Session Status Request (MsgType g) responses to provide feedback. This field supports troubleshooting and ensures clients understand why they cannot access session state information. TradSesStatusRejReason enhances transparency in market data and connectivity workflows. It helps prevent repeated failed requests and supports operational efficiency. The tag is particularly relevant in environments with multiple sessions or restricted access.

Tag 568: TradeRequestID
Tag 568 (TradeRequestID) is a unique identifier assigned by the requester in a Trade Capture Report Request (MsgType AQ). It links the request to its response and supports message correlation. TradeRequestID enables tracking of trade retrieval or affirmation workflows. It is echoed in the Trade Capture Report (MsgType AE) and ensures accurate handling of multiple concurrent requests. The field is essential for post-trade processing, reconciliation, and regulatory reporting. TradeRequestID enhances auditability and supports automated trade affirmation systems.

Tag 569: TradeRequestType
Tag 569 (TradeRequestType) specifies the type of trade request: Trade (0), Previous Day Trade (1), or Unreported Trade (2). It controls the scope of a Trade Capture Report Request. For example, requesting only unreported trades helps identify missing submissions for regulatory compliance. TradeRequestType supports flexible trade retrieval and reconciliation. It is used in post-trade workflows and is critical for MiFID II and Dodd-Frank reporting. The field enhances operational control and ensures completeness in trade reporting.

Tag 570: PreviouslyReported
Tag 570 (PreviouslyReported) indicates whether a trade has already been reported to a regulator or trade repository (Y/N). It is used in Trade Capture Report messages to prevent duplicate submissions. PreviouslyReported supports compliance with trade reporting regimes by signaling the reporting status. It helps counterparties coordinate submissions and avoid penalties. The field is essential in environments where either side can report the trade. It enhances efficiency and reduces reconciliation burden.

Tag 571: TradeReportID
Tag 571 (TradeReportID) is a unique identifier assigned to a trade report submission, typically by a trade repository or exchange. It serves as a receipt and reference for the reported trade. TradeReportID supports audit trails, dispute resolution, and regulatory compliance. It is used in Trade Capture Report messages and responses. The field ensures that each trade has a verifiable reporting record. TradeReportID is critical for MiFID II, EMIR, and other post-trade transparency frameworks.

Tag 572: TradeReportRefID
Tag 572 (TradeReportRefID) references a prior trade report, such as when canceling or replacing a previously submitted report. It enables lifecycle management of trade submissions. TradeReportRefID ensures correct linkage between original and corrected reports. It is used in Trade Capture Report messages with TradeReportTransType (Tag 487) = Replace or Cancel. The field supports accurate regulatory reporting and prevents duplication.

Tag 573: MatchStatus
Tag 573 (MatchStatus) indicates the matching status of a trade: Matched (0), Unmatched (1), or Pending Match (2). It is used in Trade Capture Report messages to convey affirmation status. MatchStatus supports post-trade affirmation workflows between counterparties. It helps identify trades requiring reconciliation. The field enhances operational efficiency and reduces settlement risk. It is particularly relevant in OTC and bilateral markets.

Tag 574: MatchType
Tag 574 (MatchType) specifies the type of match in a trade comparison: Exact Match (A1), Partial Match (A2), or Proposed Match (A3). It provides context on the level of agreement between counterparties. MatchType supports automated affirmation and exception handling. It is used in Trade Capture Report messages and helps resolve discrepancies. The field enhances transparency in trade matching and supports timely settlement.

Tag 575: OddLot
Tag 575 (OddLot) indicates whether a trade is an odd lot (Y/N), meaning the quantity is less than the standard round lot (e.g., 99 shares instead of 100). Odd lots may be handled differently in terms of pricing, routing, or reporting. This field supports market structure rules and is used in Execution Reports. It helps brokers and exchanges apply correct handling logic. OddLot enhances transparency in order execution and supports compliance with exchange-specific rules.

Tag 576: NoClearingInstructions
Tag 576 (NoClearingInstructions) specifies the number of clearing instruction entries in a repeating group. It defines how many times ClearingInstruction (Tag 577) repeats. This field supports the transmission of multiple clearing preferences for a single trade. NoClearingInstructions enables granular control over clearing venue, method, or account. It is used in Allocation and Execution messages. The field enhances flexibility in post-trade processing.

Tag 577: ClearingInstruction
Tag 577 (ClearingInstruction) specifies how a trade should be cleared: Process Normally (0), Exclude from Central Counterparty (1), or Manual Clear (2). It guides the clearing broker or CCP on handling. ClearingInstruction supports regulatory compliance and risk management. It is used in OTC derivatives and complex trades. The field ensures correct clearing path selection and is critical for EMIR and Dodd-Frank compliance.

Tag 578: TradeInputSource
Tag 578 (TradeInputSource) identifies the source of a trade entry: Broker (1), Client (2), or Market Maker (3). It supports audit and regulatory reporting by indicating how the order was submitted. TradeInputSource helps distinguish between agency and principal activity. It is used in Execution Reports and enhances transparency in execution quality reporting.

Tag 579: TradeInputDevice
Tag 579 (TradeInputDevice) specifies the device used to enter a trade: Terminal (1), Mobile (2), or API (3). It supports operational analysis and client behavior tracking. TradeInputDevice helps brokers understand trading patterns and improve service. It is used in Execution Reports and is particularly relevant in retail and digital brokerage platforms.

Tag 580: NoDates
Tag 580 (NoDates) specifies the number of dates in a repeating group, such as in a multi-date order or corporate action. It defines how many times a date field (e.g., PaymentDate) repeats. NoDates supports batch processing of time-based instructions. The field enhances scalability in distribution and scheduling workflows.

Tag 581: AccountType
Tag 581 (AccountType) specifies the type of account: Cash (1), Margin (2), or Retirement (3). It informs the broker of the account structure and affects margin, settlement, and regulatory handling. AccountType supports correct execution and compliance with investor rules. It is used in order submission and is essential for accurate trade processing.

Tag 582: CustOrderCapacity
Tag 582 (CustOrderCapacity) specifies the capacity of the customer in a trade: Agency (1), Principal (2), or Riskless Principal (3). It is used in Execution Reports to support regulatory reporting under MiFID II. CustOrderCapacity ensures transparency in execution quality and commission disclosure. It helps distinguish between agency and proprietary trading.

Tag 583: ClOrdLinkID
Tag 583 (ClOrdLinkID) is a user-defined identifier used to link related orders, such as parent and child orders in a bracket or OCO setup. It supports strategy tracking and reconciliation. ClOrdLinkID enables systems to group orders logically. It is used in order submission and Execution Reports. The field enhances visibility into algorithmic and complex trading strategies.

Tag 584: MassStatusReqID
Tag 584 (MassStatusReqID) is a unique identifier assigned by the requester in a Mass Order Status Request (MsgType AF). It ensures message correlation and supports tracking of bulk status inquiries. MassStatusReqID is echoed in the Mass Order Status Response. It enables clients to monitor the status of multiple orders efficiently. The field is essential for portfolio-level order management.

Tag 585: MassStatusReqType
Tag 585 (MassStatusReqType) specifies the scope of a Mass Order Status Request: Status for Orders (1), Status for Security (2), or Status for Market (3). It controls which orders are included in the response. MassStatusReqType supports flexible monitoring of order books and execution progress. It is used in institutional and algorithmic trading to manage large-scale order exposure.

Tag 586: OrigOrdModTime
Tag 586 (OrigOrdModTime) specifies the original time an order was modified, in UTC (YYYYMMDD-HH:MM:SS.sss). It is used in Order Cancel/Replace Request messages to prevent processing stale modifications. When multiple changes are in flight, OrigOrdModTime ensures the broker applies updates in the correct sequence. This field enhances message integrity and prevents race conditions in high-frequency environments. It works with OrigClOrdID (Tag 41) to uniquely identify the version of the order being updated. OrigOrdModTime supports robust order lifecycle management and is critical for algorithmic trading systems that dynamically adjust orders. The timestamp must match the time of the prior modification to be accepted. Its use improves reliability in fast-moving markets where order adjustments occur rapidly.

Tag 587: LegSettlType
Tag 587 (LegSettlType) specifies the settlement period for a leg in a multi-leg instrument, such as a swap or convertible bond. Valid values include Regular (0), Cash (1), or Next Day (2). It defines the standard settlement cycle for that leg’s component. LegSettlType supports accurate clearing and accounting when legs have different delivery terms. It is used in conjunction with NoLegs (Tag 555) and enhances precision in complex derivatives. The field ensures correct handling of each leg’s lifecycle and supports regulatory reporting. LegSettlType is essential for instruments with mixed settlement conventions.

Tag 588: LegSettlDate
Tag 588 (LegSettlDate) specifies the actual settlement date for a leg in a multi-leg instrument, formatted as YYYYMMDD. It overrides LegSettlType (Tag 587) when a custom settlement date is required. LegSettlDate ensures precise control over delivery timing, particularly in forward-settling or OTC derivatives. It supports accurate position management and reconciliation. The field is used in Execution Reports and Allocations. LegSettlDate is critical for cross-border trades or structured products with non-standard settlement terms.

Tag 589: DayBookingInst
Tag 589 (DayBookingInst) specifies how day trades should be booked: Auto (0), Request Not Allowed (1), or Request Allowed (2). It guides the back office on whether to automatically close intraday positions. DayBookingInst supports operational policies in proprietary and agency trading. It ensures alignment between execution and accounting systems. The field is used in Execution Reports and Allocation messages. It enhances consistency in trade processing and reduces manual intervention.

Tag 590: BookingUnit
Tag 590 (BookingUnit) specifies the minimum tradable or bookable quantity for an order, such as 100 shares or 1 contract. It supports order validation and allocation logic. BookingUnit ensures that allocations are made in valid increments. It is used in Allocations and Execution messages. The field prevents fractional or invalid bookings and supports compliance with exchange or fund rules. BookingUnit enhances operational efficiency in post-trade processing.

Tag 591: PreallocMethod
Tag 591 (PreallocMethod) indicates how pre-allocated accounts are specified: Proportion (0) or Fixed Amount (1). It controls the allocation logic in pre-trade allocation workflows. For example, Proportion distributes fills based on percentage weights. PreallocMethod supports flexible allocation strategies and is used in Execution and Allocation messages. The field ensures correct distribution of trades across accounts. It is essential for institutional investors managing multiple portfolios.

Tag 592: UnderlyingCountryOfIssue
Tag 592 (UnderlyingCountryOfIssue) specifies the country that issued the underlying security in a derivative, using ISO 3166 codes (e.g., US, DE). It supports tax, regulatory, and credit analysis. This field is used for options, futures, or swaps on bonds or equities. UnderlyingCountryOfIssue determines withholding tax treatment and jurisdictional compliance. It enhances transparency in cross-border derivatives and supports FATCA and MiFID II reporting.

Tag 593: UnderlyingStateOrProvinceOfIssue
Tag 593 (UnderlyingStateOrProvinceOfIssue) specifies the sub-national jurisdiction of the underlying security’s issuer, such as a U.S. state or Canadian province. It is used for municipal bonds or regional debt. This field supports tax-exempt status determination and investor eligibility. UnderlyingStateOrProvinceOfIssue is used with UnderlyingCountryOfIssue (Tag 592) for precise identification. It enhances accuracy in fixed-income trading.

Tag 594: UnderlyingLocaleOfIssue
Tag 594 (UnderlyingLocaleOfIssue) specifies the city or local region where the underlying security was issued. It provides additional geographic context beyond country and state. This field is relevant for local government securities or region-specific instruments. UnderlyingLocaleOfIssue supports investor research and risk assessment. It enhances granularity in portfolio analysis and reporting.

Tag 595: UnderlyingInstrRegistry
Tag 595 (UnderlyingInstrRegistry) identifies the official registry responsible for the underlying security, such as a national numbering agency. It ensures data integrity and standardization. UnderlyingInstrRegistry supports accurate identification and is used in Security Definition messages. It enhances trust in instrument data sourcing.

Tag 596: LegCountryOfIssue
Tag 596 (LegCountryOfIssue) specifies the country of issue for a leg in a multi-leg instrument. It supports tax and regulatory handling when legs involve different sovereign issuers. LegCountryOfIssue ensures correct withholding and compliance. It is used in complex derivatives and structured products.

Tag 597: LegStateOrProvinceOfIssue
Tag 597 (LegStateOrProvinceOfIssue) specifies the sub-national issuer of a leg in a multi-leg instrument. It supports tax treatment for municipal or regional bonds. LegStateOrProvinceOfIssue enhances precision in multi-jurisdictional trades.

Tag 598: LegLocaleOfIssue
Tag 598 (LegLocaleOfIssue) specifies the local region or city of issue for a leg. It provides detailed geographic context for local securities. LegLocaleOfIssue supports investor analysis and reporting.

Tag 599: LegInstrRegistry
Tag 599 (LegInstrRegistry) identifies the registration authority for a leg in a multi-leg instrument. It ensures accurate data sourcing and standardization. LegInstrRegistry enhances transparency and supports compliance in complex derivatives.

Tag 600: LegSymbol
Tag 600 (LegSymbol) specifies the ticker symbol of a security within a leg of a multi-leg instrument, such as an option spread, convertible bond, or swap. It identifies the underlying or referenced asset for that specific leg, enabling correct pricing, routing, and execution. LegSymbol is used within the NoLegs (Tag 555) repeating group, allowing each leg to be uniquely defined. For example, in a calendar spread, two legs may share the same underlying but have different expirations, requiring distinct identification. This field supports complex trading strategies by ensuring accurate representation of each component. LegSymbol is essential for algorithmic systems, risk engines, and clearing platforms that must process multi-leg trades. While human-readable, it should be used with LegSecurityID (Tag 602) for unambiguous identification. The field enhances transparency and reduces operational risk in structured product trading.

Tag 601: LegSymbolSfx
Tag 601 (LegSymbolSfx) is a suffix appended to the LegSymbol (Tag 600) to denote special characteristics of a security, such as “WS” for warrants or “PR” for preferred shares. Though rarely used in modern markets, it supports legacy exchange conventions where symbols alone are insufficient. LegSymbolSfx provides additional context for non-standard instruments and helps distinguish between different share classes or derivatives. It is used in multi-leg security definitions and execution messages. The field enhances precision in identification but is largely historical. Its use is optional and primarily limited to specific regional or exchange-specific implementations. Modern systems rely more on SecurityID and CFICode for unambiguous classification. Despite its limited scope, LegSymbolSfx remains part of the FIX 4.4 standard for backward compatibility.

Tag 602: LegSecurityID
Tag 602 (LegSecurityID) is the unique identifier (e.g., CUSIP, ISIN, SEDOL) assigned to a security within a leg of a multi-leg instrument. It ensures unambiguous identification beyond the potentially ambiguous LegSymbol (Tag 600). LegSecurityID is used in conjunction with LegSecurityIDSource (Tag 603) to specify the namespace. This field is critical for accurate clearing, settlement, and regulatory reporting, especially in global or fixed-income markets where ticker symbols may overlap. It prevents misidentification and supports automated processing. LegSecurityID is essential for derivatives, structured products, and OTC instruments where precise asset mapping is required. The field enhances reliability in multi-venue trading and ensures consistency across data providers and execution systems.

Tag 603: LegSecurityIDSource
Tag 603 (LegSecurityIDSource) identifies the source or namespace of the LegSecurityID (Tag 602), such as ISIN (4), CUSIP (1), SEDOL (2), or Proprietary (3). It ensures that the identifier is interpreted correctly across systems. Without this context, the same ID might refer to different securities in different databases. LegSecurityIDSource is used in the NoLegs repeating group and supports accurate routing, matching, and clearing. It enhances data integrity in multi-jurisdictional and multi-vendor environments. The field is essential for global trading, where instruments are referenced using different coding systems. LegSecurityIDSource enables robust security identification and reduces operational risk in complex financial workflows.

Tag 604: NoLegSecurityAltID
Tag 604 (NoLegSecurityAltID) specifies the number of alternative identifiers associated with a leg in a multi-leg instrument. It defines how many times the repeating group containing LegSecurityAltID (Tag 605) and LegSecurityAltIDSource (Tag 606) is repeated. This field supports comprehensive identification by allowing multiple vendor-specific codes (e.g., Bloomberg, Reuters) for the same leg. NoLegSecurityAltID enables data normalization across systems and reduces misidentification risk. It is particularly useful in environments where different platforms use different naming conventions. The repeating group structure provides flexibility and scalability. NoLegSecurityAltID enhances accuracy in pricing, risk, and clearing systems that rely on multiple data sources.

Tag 605: LegSecurityAltID
Tag 605 (LegSecurityAltID) is an alternative identifier for a leg in a multi-leg instrument, such as a Bloomberg or Reuters ticker. It supports cross-referencing across different data vendors and internal systems. LegSecurityAltID is used with LegSecurityAltIDSource (Tag 606) to specify the source namespace. This field enhances accuracy in global trading by ensuring consistent mapping across platforms. It is particularly valuable in fixed income, derivatives, and international equities where naming conventions vary. LegSecurityAltID reduces ambiguity and supports integration between trading, risk, and back-office systems. The field enables firms to reconcile instruments across multiple data feeds and ensures reliable execution and reporting.

Tag 606: LegSecurityAltIDSource
Tag 606 (LegSecurityAltIDSource) specifies the source of the LegSecurityAltID (Tag 605), such as Bloomberg (1), Reuters (2), or Proprietary (3). It ensures the alternative identifier is interpreted correctly and prevents confusion when the same code appears in different systems. For example, “C 12345” may mean different things on Bloomberg vs. Reuters. LegSecurityAltIDSource supports data normalization and enhances reliability in multi-vendor environments. It is essential for accurate security mapping in algorithmic trading and risk systems. The field ensures that all parties have a consistent understanding of the referenced instrument.

Tag 607: LegProduct
Tag 607 (LegProduct) specifies the broad asset class of a leg in a multi-leg instrument: Equity (1), Fixed Income (2), FX (3), or Commodity (4). It supports correct handling of pricing, margining, and regulatory requirements. LegProduct enables trading systems to apply appropriate logic based on the leg’s characteristics. For example, a bond leg requires different risk treatment than an equity leg. The field is used in Security Definition and Execution messages. LegProduct enhances transparency in complex derivatives and ensures accurate classification in clearing and reporting workflows. It is essential for multi-asset strategies and institutional trading.

Tag 608: LegCFICode
Tag 608 (LegCFICode) is the ISO 10962 Classification of Financial Instruments (CFI) code for a leg, providing detailed structural classification (e.g., ESVOFR for a standard equity call). It specifies optionality, exercisability, and other attributes. LegCFICode supports accurate risk assessment, margin calculation, and regulatory reporting. It ensures consistent interpretation of complex instruments across systems. The field is essential for derivatives where the structure affects valuation. LegCFICode enhances transparency and supports compliance with MiFID II, EMIR, and other global standards.

Tag 609: LegSecurityType
Tag 609 (LegSecurityType) specifies the type of a leg: Common Stock (CS), Corporate Bond (CB), Option (OPT), or Future (FUT). It guides execution, clearing, and risk systems on how to handle the leg. LegSecurityType ensures correct matching and pricing logic. It is used in conjunction with LegProduct (Tag 607) for granular classification. The field is essential for accurate processing of multi-leg instruments and supports regulatory reporting. LegSecurityType enhances clarity in complex trading strategies.

Tag 610: LegMaturityMonthYear
Tag 610 (LegMaturityMonthYear) specifies the maturity of a leg in YYYYMM format, used for futures, options, or bonds. It identifies the contract series and supports accurate pricing and expiration handling. This field is critical in derivatives trading where multiple expirations exist. LegMaturityMonthYear ensures correct identification of the specific contract and prevents misexecution. It is used in Security Definition and Execution messages. The field supports automated trading and risk systems.

Tag 611: LegMaturityDate
Tag 611 (LegMaturityDate) is the exact maturity date of a leg, formatted as YYYYMMDD. It provides greater precision than LegMaturityMonthYear (Tag 610) and is used when exact settlement timing matters. LegMaturityDate supports accurate cash flow modeling, accrual calculations, and lifecycle management. It is essential for fixed-income derivatives and structured products. The field ensures correct handling of principal repayment and interest payments.

Tag 612: LegStrikePrice
Tag 612 (LegStrikePrice) is the exercise price of an option leg in a multi-leg strategy. It defines the price at which the underlying can be bought (call) or sold (put). LegStrikePrice is essential for valuation, margining, and profit/loss calculation. It is used in spreads, straddles, and other option strategies. The field supports accurate risk modeling and ensures correct execution. LegStrikePrice enhances transparency in complex derivatives.

Tag 613: LegOptAttribute
Tag 613 (LegOptAttribute) specifies the exercise style of an option leg: American (A) or European (E). It affects early exercise rights and pricing models. American options can be exercised anytime, while European only at expiry. LegOptAttribute ensures correct Greeks calculation and risk treatment. It is essential for accurate valuation in multi-leg options. The field supports compliance with exchange rules and clearing requirements.

Tag 614: LegContractMultiplier
Tag 614 (LegContractMultiplier) defines the multiplier applied to a futures or option leg, such as 100 shares per contract. It determines the notional value and supports accurate P&L and margining. For example, a $1 move on a contract with multiplier 250 equals $250. LegContractMultiplier is critical for correct exposure calculation. The field is used in index and commodity futures.

Tag 615: LegCouponRate
Tag 615 (LegCouponRate) specifies the annual interest rate (as a percentage) of a bond leg in a multi-leg instrument. It supports yield calculation, accrued interest, and fair value assessment. LegCouponRate is essential for fixed-income derivatives and structured notes. It ensures correct pricing and margining. The field enhances accuracy in risk and accounting systems.

Tag 616: LegSecurityExchange
Tag 616 (LegSecurityExchange) identifies the exchange where the underlying of a leg is listed, using a Market Identifier Code (MIC). It supports correct routing, market data handling, and regulatory reporting. LegSecurityExchange ensures the leg is associated with the right trading venue. It is used in options, futures, and ETFs. The field enhances transparency in multi-leg instruments.

Tag 617: LegIssuer
Tag 617 (LegIssuer) specifies the name of the entity that issued the underlying security of a leg. It supports credit analysis, compliance, and investor research. LegIssuer provides context beyond the symbol and is used in fixed-income and equity derivatives. The field enhances transparency in complex instruments.

Tag 618: EncodedLegIssuerLen
Tag 618 (EncodedLegIssuerLen) specifies the byte length of the data in EncodedLegIssuer (Tag 619). It enables correct parsing of encoded issuer names that contain non-ASCII characters (e.g., Japanese, Cyrillic). This field is used when the issuer name cannot be transmitted in plain ASCII. EncodedLegIssuerLen ensures data integrity and prevents truncation.

Tag 619: EncodedLegIssuer
Tag 619 (EncodedLegIssuer) contains the LegIssuer (Tag 617) in encoded format (e.g., Base64) when it includes non-Latin characters. It ensures safe transmission of multilingual issuer names. Used with EncodedLegIssuerLen (Tag 618), it supports global trading. The field enhances inclusivity and operational clarity.

Tag 620: LegSecurityDesc
Tag 620 (LegSecurityDesc) provides a free-text description of a leg’s security, such as “Apple Inc. 5% Bond 2030.” It enhances trader recognition and supports compliance. LegSecurityDesc is used in quotes and orders. While not parsed algorithmically, it improves clarity in complex instruments.

Tag 621: EncodedLegSecurityDescLen
Tag 621 (EncodedLegSecurityDescLen) specifies the length of EncodedLegSecurityDesc (Tag 622). It supports parsing of encoded descriptions with non-ASCII content. This field ensures accurate handling of multilingual security names.

Tag 622: EncodedLegSecurityDesc
Tag 622 (EncodedLegSecurityDesc) contains LegSecurityDesc in encoded format for non-Latin scripts. Used with Tag 621, it ensures safe transmission of complex descriptions. The field supports global market participation.

Tag 623: LegRatioQty
Tag 623 (LegRatioQty) specifies the quantity ratio for a leg, such as 100 shares per option contract. It supports correct sizing in spreads and baskets. LegRatioQty ensures accurate notional exposure and is used in multi-leg order definitions.

Tag 624: LegSide
Tag 624 (LegSide) indicates the trading side of a leg: Buy (1) or Sell (2). It defines the direction of each component in a multi-leg trade. LegSide is essential for accurate execution and risk modeling. The field supports complex strategies like straddles and risk reversals.

Tag 625: TradingSessionSubID
Tag 625 (TradingSessionSubID) identifies a sub-session within a trading day, such as “Pre-Market” (1), “Core” (2), or “Closing Auction” (5). It provides granular session tracking beyond TradingSessionID (Tag 336). This field supports time-based strategies and regulatory reporting. TradingSessionSubID enhances precision in execution and market data analysis.

Tag 626: AllocType
Tag 626 (AllocType) specifies the type of allocation being transmitted: New (1), Replace (2), or Cancel (3). It controls how the allocation message is processed by the receiver. A “New” creates a fresh allocation, “Replace” updates a prior one, and “Cancel” removes it. AllocType is used in Allocation (MsgType J) and Allocation Report (MsgType AS) messages. It supports lifecycle management of trade allocations across multiple accounts. The field ensures correct handling and prevents duplication or misapplication. AllocType is essential for institutional investors, brokers, and custodians managing post-trade processing. It enhances auditability and supports regulatory compliance in multi-account environments. When used with AllocID (Tag 70), it enables precise tracking of allocation events.

Tag 627: NoHops
Tag 627 (NoHops) indicates the number of intermediate parties (hops) in a message routing chain. It defines how many times the repeating group containing HopCompID (Tag 628), HopSendingTime (Tag 629), and HopRefID (Tag 630) repeats. NoHops supports multi-hop messaging in routed or sponsored access environments. It enables auditability by recording each intermediary that handled the message. The field enhances transparency in complex trading networks and supports best execution reporting. NoHops is particularly relevant in global markets where orders pass through multiple brokers or gateways.

Tag 628: HopCompID
Tag 628 (HopCompID) identifies the SenderCompID of an intermediate party in a message routing chain. It is used within the NoHops repeating group to record each hop. HopCompID supports audit trails and ensures accountability in multi-firm workflows. It allows the final recipient to trace the message path. This field is essential for compliance and operational transparency in routed order scenarios.

Tag 629: HopSendingTime
Tag 629 (HopSendingTime) specifies the SendingTime (Tag 52) of a message when it was transmitted by an intermediate party. It is recorded in the NoHops group and supports latency analysis. HopSendingTime enables end-to-end timing measurement across multiple systems. It enhances best execution reporting and helps identify bottlenecks in routing chains.

Tag 630: HopRefID
Tag 630 (HopRefID) is a sequence number assigned by an intermediate party to track message hops. It corresponds to the MsgSeqNum at that hop. HopRefID supports reconciliation and gap detection in multi-hop environments. It ensures message integrity across routing intermediaries. The field enhances reliability in distributed trading architectures.

Tag 631: MidPx
Tag 631 (MidPx) represents the midpoint between the best bid and offer prices in the market. It is calculated as (BidPx + OfferPx) / 2 and is used in market data and valuation messages. MidPx supports fair value assessment, benchmarking, and algorithmic pricing. It is particularly useful in low-liquidity environments or for marking positions to market. MidPx enhances transparency in execution quality analysis.

Tag 632: BidYield
Tag 632 (BidYield) specifies the yield corresponding to the bid price of a fixed-income security, such as a bond. It is derived from the bid price, coupon, and maturity. BidYield supports yield-based trading and analysis. It enables traders to compare bonds on a consistent basis. The field is used in quotes and market data messages. BidYield is essential for fixed-income portfolio management.

Tag 633: MidYield
Tag 633 (MidYield) is the yield calculated from the MidPx (Tag 631) of a bond. It represents the yield at the midpoint of the bid-offer spread. MidYield supports fair value pricing and performance measurement. It is used in valuation and risk systems. The field enhances accuracy in fixed-income analytics.

Tag 634: OfferYield
Tag 634 (OfferYield) is the yield corresponding to the offer (ask) price of a bond. It reflects the return if purchased at the asking price. OfferYield supports trading decisions and cost analysis. It is used in quotes and market data. The field enables yield-based comparisons across securities.

Tag 635: ClearingFeeIndicator
Tag 635 (ClearingFeeIndicator) specifies the category of clearing fee applicable to a trade, such as “1st Year” (1) or “2nd Year” (2). It is used in futures and derivatives to determine fee structure. ClearingFeeIndicator supports accurate billing and regulatory reporting. It ensures correct fee application by clearinghouses.

Tag 636: WorkingIndicator
Tag 636 (WorkingIndicator) indicates whether an order is currently active and visible in the market (Y/N). It is used in Execution Reports to reflect order status. WorkingIndicator helps clients monitor order exposure and execution progress. The field enhances transparency in order lifecycle management.

Tag 637: LegLastPx
Tag 637 (LegLastPx) is the execution price of a specific leg in a multi-leg trade. It supports accurate P&L calculation and performance attribution per leg. LegLastPx is used in Execution Reports and Allocations. The field ensures correct cost basis assignment in complex strategies.

Tag 638: PriorityIndicator
Tag 638 (PriorityIndicator) specifies the priority level of an order in the book, such as time-priority or price-time. It is used in market data to show queue position. PriorityIndicator supports execution analysis and latency-sensitive strategies. The field enhances fairness in matching logic.

Tag 639: PriceImprovement
Tag 639 (PriceImprovement) indicates whether a trade was executed at a better price than the prevailing market (Y/N). It supports best execution reporting and regulatory compliance. PriceImprovement demonstrates value-added execution. The field is used in Execution Reports.

Tag 640: Price2
Tag 640 (Price2) is an alternate price field, often used for secondary pricing in dual-currency or complex instruments. It may represent a forward price or adjusted value. Price2 supports accurate valuation in structured products. The field enhances flexibility in pricing models.

Tag 641: LastForwardPoints2
Tag 641 (LastForwardPoints2) specifies the forward points for a second currency pair in a multi-leg FX trade. It supports accurate forward rate calculation. Used with LastSpotRate (Tag 194), it defines the full forward price. The field is essential for FX derivatives.

Tag 642: BidForwardPoints2
Tag 642 (BidForwardPoints2) is the forward points for the bid side of a second FX leg. It supports multi-leg FX quotes. When combined with BidSpotRate (Tag 188), it determines the forward bid price. The field enhances precision in wholesale FX trading.

Tag 643: OfferForwardPoints2
Tag 643 (OfferForwardPoints2) specifies the forward points for the offer side of a second FX leg. It supports accurate pricing in multi-leg FX transactions. Used with OfferSpotRate (Tag 190), it defines the forward offer price. The field is critical for FX market makers.

Tag 644: RFQReqID
Tag 644 (RFQReqID) is a unique identifier assigned to a Request-for-Quote message. It links the request to responses and supports RFQ workflows. RFQReqID ensures message correlation and is echoed in Quote (MsgType S) and Quote Response (MsgType AQ) messages. The field enhances efficiency in dealer-to-client pricing.

Tag 645: MktBidPx
Tag 645 (MktBidPx) is the best bid price available in the market for a security. It reflects current buy-side liquidity. MktBidPx is used in Execution Reports and market data to indicate execution quality. The field supports best execution analysis and benchmarking.

Tag 646: MktOfferPx
Tag 646 (MktOfferPx) is the best offer (ask) price in the market. It represents the lowest price at which a seller is willing to trade. MktOfferPx supports execution quality assessment. It is used in Execution Reports to compare execution price to market.

Tag 647: MinBidSize
Tag 647 (MinBidSize) specifies the minimum quantity available at the bid price. It supports liquidity analysis and execution strategy. MinBidSize helps assess market depth and order book strength. The field is used in market data messages.

Tag 648: MinOfferSize
Tag 648 (MinOfferSize) is the minimum quantity available at the offer price. It indicates sell-side depth. MinOfferSize supports execution planning and liquidity assessment. The field enhances transparency in market conditions.

Tag 649: QuoteStatusReqID
Tag 649 (QuoteStatusReqID) is a unique identifier for a Quote Status Request (MsgType AI). It links the request to its response. QuoteStatusReqID supports tracking of quote lifecycle events. The field ensures accurate status reporting in RFQ workflows.

Tag 650: LegalConfirm
Tag 650 (LegalConfirm) indicates whether a trade requires a legal confirmation (Y/N). It is used in post-trade messaging to signal documentation needs. LegalConfirm supports operational workflows in OTC and derivatives markets. The field enhances compliance and settlement readiness.

Tag 651: UnderlyingLastPx
Tag 651 (UnderlyingLastPx) is the last traded price of the underlying security in a derivative. It supports valuation and risk modeling. UnderlyingLastPx is used in options and futures to assess intrinsic value. The field enhances accuracy in pricing engines.

Tag 652: UnderlyingLastQty
Tag 652 (UnderlyingLastQty) is the quantity of the last trade in the underlying security. It supports volume analysis and market impact assessment. UnderlyingLastQty is used in derivatives pricing and execution reports. The field provides context for underlying activity.

Tag 653: SecDefStatus (replaced)
Tag 653 (SecDefStatus) was used to indicate the status of a security definition request but is replaced in FIX 4.4. Its functionality is now handled by SecurityResponseType (Tag 323). Applications should not use this tag. It has been deprecated to streamline messaging. Use the current standard for security status feedback.

Tag 654: LegRefID
Tag 654 (LegRefID) is a reference identifier for a leg in a multi-leg instrument, used to link related messages. It supports lifecycle tracking of individual legs. LegRefID enhances traceability in complex trading strategies and is used in Execution and Allocation messages.

Tag 655: ContraLegRefID
Tag 655 (ContraLegRefID) is a reference identifier used to link the contra-side leg of a multi-leg trade, particularly in matched or crossed transactions involving derivatives or complex instruments. It enables both counterparties to correlate their respective legs in a bilateral trade, ensuring accurate reconciliation and affirmation. ContraLegRefID supports transparency in internal crossing networks, exchange-for-physical (EFP) trades, and OTC derivatives. It is especially useful when each side of the trade uses different internal identifiers. The field enhances auditability and reduces settlement risk by confirming that both parties are referencing the same economic leg. ContraLegRefID is typically used in Execution Reports and Trade Capture messages. It plays a critical role in post-trade workflows where precise matching is required for clearing and regulatory reporting.

Tag 656: SettlCurrBidFxRate
Tag 656 (SettlCurrBidFxRate) specifies the foreign exchange rate used to convert the bid price into the settlement currency for cross-currency trades. It ensures accurate valuation when the bid price is quoted in a different currency than the settlement currency. SettlCurrBidFxRate is used in quotes and execution messages to support transparent pricing. When combined with SettlCurrency (Tag 120), it enables correct cost basis calculation. The field is essential in global fixed income, ETFs, and multi-currency portfolios. It supports best execution analysis and regulatory compliance by documenting the FX conversion applied to bid-side pricing.

Tag 657: SettlCurrOfferFxRate
Tag 657 (SettlCurrOfferFxRate) specifies the FX rate used to convert the offer (ask) price into the settlement currency. It ensures accurate pricing when the offer is denominated in a different currency. SettlCurrOfferFxRate supports fair value assessment and cost transparency. It is used in market data, quotes, and execution reports. The field enhances consistency in cross-border trading and supports compliance with MiFID II pricing disclosure rules. When paired with SettlCurrency (Tag 120), it enables precise execution cost analysis.

Tag 658: QuoteRequestRejectReason
Tag 658 (QuoteRequestRejectReason) specifies why a Request-for-Quote (RFQ) was rejected: Invalid Symbol (1), Unknown Counterparty (2), or Market Closed (3). It is returned in Quote Request Reject (MsgType AQ) messages. This field provides actionable feedback for troubleshooting. QuoteRequestRejectReason supports efficient RFQ workflows by helping clients understand rejection causes. It enhances transparency in dealer-to-client communication and reduces repeated errors in pricing requests.

Tag 659: SideComplianceID
Tag 659 (SideComplianceID) is a compliance identifier assigned to a specific side (buy or sell) of an order. It links the trade to pre-trade compliance checks, risk approvals, or regulatory filings. SideComplianceID supports auditability and ensures adherence to investment mandates. It is generated by compliance systems and included in Execution Reports. The field is essential for institutional firms managing complex regulatory requirements.

Tag 660: AcctIDSource
Tag 660 (AcctIDSource) identifies the namespace of the Account (Tag 1) field: BIC (1), SID (2), or Proprietary (3). It ensures unambiguous identification of client accounts, especially in cross-border or multi-vendor environments. AcctIDSource prevents misattribution and supports accurate clearing and reporting. The field enhances data integrity in global trading and is used in orders and allocations.

Tag 661: AllocAcctIDSource
Tag 661 (AllocAcctIDSource) specifies the source namespace of the AllocAccount (Tag 79) in an allocation message. It ensures correct interpretation of account identifiers across systems. AllocAcctIDSource supports accurate post-trade processing and reduces reconciliation errors. The field is essential for institutional investors with accounts across multiple custodians or regions.

Tag 662: BenchmarkPrice
Tag 662 (BenchmarkPrice) specifies the price of a benchmark security used for comparison in execution quality reporting. It supports best execution analysis by showing how the execution price compares to a reference. BenchmarkPrice is used in Execution Reports and is critical under MiFID II. The field enhances transparency in trading performance.

Tag 663: BenchmarkPriceType
Tag 663 (BenchmarkPriceType) indicates the type of benchmark price: Midpoint (1), Last Sale (2), or VWAP (3). It defines how the benchmark was calculated. BenchmarkPriceType ensures correct interpretation of BenchmarkPrice (Tag 662). The field supports standardized execution quality reporting.

Tag 664: ConfirmID
Tag 664 (ConfirmID) is a unique identifier assigned to a trade confirmation message. It enables tracking and referencing of confirmations in post-trade workflows. ConfirmID supports reconciliation between broker and client. The field is used in Confirmation (MsgType AK) messages and enhances auditability.

Tag 665: ConfirmStatus
Tag 665 (ConfirmStatus) indicates the status of a trade confirmation: Accepted (1), Rejected (2), or Partially Accepted (3). It is used in Confirmation messages to communicate processing outcomes. ConfirmStatus supports operational clarity and helps resolve discrepancies. The field enhances efficiency in affirmation processes.

Tag 666: ConfirmTransType
Tag 666 (ConfirmTransType) specifies the action on a confirmation: New (0), Cancel (1), or Replace (2). It controls the lifecycle of the confirmation message. ConfirmTransType ensures correct handling and prevents duplication. The field is essential for accurate post-trade record-keeping.

Tag 667: ContractSettlMonth
Tag 667 (ContractSettlMonth) specifies the settlement month of a futures or options contract in YYYYMM format. It identifies the delivery cycle and supports accurate contract mapping. ContractSettlMonth is used in derivatives trading and is essential for correct pricing and clearing.

Tag 668: DeliveryForm
Tag 668 (DeliveryForm) indicates the form of delivery: Physical (1) or Electronic (2). It is used in commodity and futures markets to specify settlement method. DeliveryForm supports clearing and logistics planning. The field ensures correct handling of deliverable obligations.

Tag 669: LastParPx
Tag 669 (LastParPx) is the last traded price expressed as a percentage of par value, commonly used for bonds. It supports yield and performance analysis. LastParPx enables consistent pricing comparison across fixed-income securities. The field is used in market data and execution reports.

Tag 670: NoLegAllocs
Tag 670 (NoLegAllocs) specifies the number of allocation entries for a leg in a multi-leg instrument. It defines how many times LegAllocAccount (Tag 671) and LegAllocQty (Tag 673) repeat. NoLegAllocs supports granular allocation of complex trades. The field is essential for accurate post-trade processing.

Tag 671: LegAllocAccount
Tag 671 (LegAllocAccount) specifies the account to which a portion of a leg’s execution is allocated. It supports multi-account distribution in structured products. LegAllocAccount ensures correct position attribution. The field is used in Allocation messages.

Tag 672: LegIndividualAllocID
Tag 672 (LegIndividualAllocID) is a unique identifier for an allocation to a specific account within a leg. It supports traceability and reconciliation. LegIndividualAllocID enhances auditability in multi-leg allocations.

Tag 673: LegAllocQty
Tag 673 (LegAllocQty) specifies the quantity allocated to a specific account for a leg. It supports accurate distribution of multi-leg trade fills. LegAllocQty is used in Allocation messages and ensures correct position updates.

Tag 674: LegAllocAcctIDSource
Tag 674 (LegAllocAcctIDSource) identifies the namespace of LegAllocAccount (Tag 671). It ensures correct interpretation of account identifiers. The field enhances data accuracy in global allocation workflows.

Tag 675: LegSettlCurrency
Tag 675 (LegSettlCurrency) specifies the settlement currency for a leg in a multi-currency trade. It supports accurate FX handling and accounting. LegSettlCurrency is essential for cross-border derivatives.

Tag 676: LegBenchmarkCurveCurrency
Tag 676 (LegBenchmarkCurveCurrency) specifies the currency of the benchmark yield curve used to price a leg. It supports accurate fixed-income valuation. The field is used in derivatives and structured products.

Tag 677: LegBenchmarkCurveName
Tag 677 (LegBenchmarkCurveName) identifies the benchmark curve (e.g., LIBOR, Treasury) used for pricing a leg. It supports yield-based pricing models. The field enhances transparency in derivative valuation.

Tag 678: LegBenchmarkCurvePoint
Tag 678 (LegBenchmarkCurvePoint) specifies the maturity point on the benchmark curve used for a leg (e.g., “3M”). It supports precise yield curve referencing. The field is essential for accurate pricing.

Tag 679: LegBenchmarkPrice
Tag 679 (LegBenchmarkPrice) is the reference price used to evaluate the execution of a leg. It supports best execution reporting. The field enhances transparency in multi-leg trading.

Tag 680: LegBenchmarkPriceType
Tag 680 (LegBenchmarkPriceType) specifies the type of benchmark price for a leg: Midpoint (1), Last (2). It ensures correct interpretation. The field supports standardized execution analysis.

Tag 681: LegBidPx
Tag 681 (LegBidPx) is the bid price for a leg in a multi-leg instrument. It supports pricing and market data dissemination. LegBidPx enhances transparency in complex quotes.

Tag 682: LegIOIQty
Tag 682 (LegIOIQty) specifies the quantity in an IOI for a leg. It supports pre-trade interest signaling. The field is used in Indication of Interest messages.

Tag 683: NoLegStipulations
Tag 683 (NoLegStipulations) specifies the number of stipulations for a leg. It defines how many times LegStipulationType (Tag 688) repeats. The field supports detailed leg-specific conditions.

Tag 684: LegOfferPx
Tag 684 (LegOfferPx) is the offer price for a leg. It supports bid-offer spread analysis. LegOfferPx is used in quotes and market data.

Tag 685: LegOrderQty
Tag 685 (LegOrderQty) is the order quantity for a leg. It defines the size of that component. LegOrderQty is essential for accurate multi-leg order definition.

Tag 686: LegPriceType
Tag 686 (LegPriceType) specifies how a leg’s price should be interpreted: Percentage (1), Per Unit (2). It prevents misinterpretation in pricing.

Tag 687: LegQty
Tag 687 (LegQty) is the executed quantity for a leg. It supports fill tracking and P&L calculation. LegQty is used in Execution Reports.

Tag 688: LegStipulationType
Tag 688 (LegStipulationType) specifies the type of stipulation for a leg: Maturity (1), Coupon Range (2). It supports customized trading terms.

Tag 689: LegStipulationValue
Tag 689 (LegStipulationValue) is the value associated with a leg stipulation. It defines the specific requirement. The field supports structured product terms.

Tag 690: LegSwapType
Tag 690 (LegSwapType) specifies the type of swap for a leg: Par For Par (1), Modified Duration (2). It guides clearing and valuation. The field is used in interest rate swaps.

Tag 691: Pool
Tag 691 (Pool) identifies the pool or tranche of a mortgage-backed or asset-backed security. It supports accurate identification and pricing. Pool is essential in fixed-income markets.

Tag 692: QuotePriceType
Tag 692 (QuotePriceType) specifies how the quoted price is expressed: Percentage (1), Yield (2). It ensures correct interpretation of quotes. The field supports fixed-income trading.

Tag 693: QuoteRespID
Tag 693 (QuoteRespID) is a unique identifier for a quote response. It links the response to the original request. QuoteRespID supports RFQ tracking.

Tag 694: QuoteRespType
Tag 694 (QuoteRespType) specifies the type of quote response: Hit (1), Lift (2), or No Bid (3). It conveys counterparty intent. The field supports execution workflow.

Tag 695: QuoteQualifier
Tag 695 (QuoteQualifier) adds context to a quote: Aggressive (A), Passive (B). It supports trading strategy interpretation. The field enhances communication.

Tag 696: YieldRedemptionDate
Tag 696 (YieldRedemptionDate) is the date used for yield-to-redemption calculation. It supports bond valuation. The field is used in fixed-income analytics.

Tag 697: YieldRedemptionPrice
Tag 697 (YieldRedemptionPrice) is the price at which a bond is redeemed for yield calculation. It supports accurate yield-to-call or put analysis.

Tag 698: YieldRedemptionPriceType
Tag 698 (YieldRedemptionPriceType) specifies how the redemption price is expressed: Clean (1), Dirty (2). It ensures correct yield modeling.

Tag 699: BenchmarkSecurityID
Tag 699 (BenchmarkSecurityID) is the identifier of the benchmark security used in execution comparison. It supports best execution reporting. The field enhances transparency.

Tag 700: ReversalIndicator
Tag 700 (ReversalIndicator) indicates whether a trade is a reversal of a prior trade (Y/N). It supports position accounting and tax reporting. ReversalIndicator helps track wash sales and cost basis adjustments. The field is used in Execution Reports and is critical for accurate portfolio management.

Tag 701: YieldCalcDate
Tag 701 (YieldCalcDate) specifies the date used as the reference point for yield calculations on a fixed-income security, such as a bond or note. It may differ from the trade or settlement date and is critical for accurate yield-to-maturity, yield-to-call, or accrued interest computations. YieldCalcDate ensures consistent valuation across systems, particularly when pricing is delayed or adjusted. It supports fair value assessment and performance measurement. The field is used in quotes, executions, and market data messages involving debt instruments. YieldCalcDate enhances transparency in fixed-income trading and ensures alignment between pricing models and accounting systems. It is especially relevant in markets where bonds trade with complex day-count conventions or when valuing positions for reporting.

Tag 702: NoPositions
Tag 702 (NoPositions) specifies the number of position entries in a repeating group within a Position Report or Request message. It defines how many times PosType (Tag 703), LongQty (Tag 704), ShortQty (Tag 705), and related fields repeat. This field supports the transmission of multiple positions for a single account or instrument. NoPositions enables efficient batch reporting of holdings across asset classes. It is essential for margin calculations, risk management, and regulatory compliance. The repeating group structure allows for flexible, scalable position messaging. NoPositions enhances accuracy in portfolio reconciliation and supports automated position monitoring.

Tag 703: PosType
Tag 703 (PosType) identifies the type of position being reported: Transaction (0), Allocation (1), or Exercise (2). It specifies the origin or nature of the position update. PosType supports accurate accounting and lifecycle tracking. For example, a Transaction-based position results from a trade, while an Exercise reflects option assignment. The field is used in Position Maintenance and Position Report messages. It ensures correct processing and prevents misclassification. PosType enhances transparency in position management and supports auditability in back-office systems.

Tag 704: LongQty
Tag 704 (LongQty) specifies the quantity of a security held in a long position. It represents ownership and upside exposure to price increases. LongQty is used in Position Reports and allocations to reflect buy-side holdings. The field supports portfolio valuation, risk analysis, and margining. When combined with ShortQty (Tag 705), it enables net position calculation. LongQty is essential for accurate position tracking and is widely used in institutional trading and clearing workflows.

Tag 705: ShortQty
Tag 705 (ShortQty) specifies the quantity of a security held in a short position, indicating borrowed shares sold with the obligation to repurchase. ShortQty supports risk management, margin calculation, and compliance with short-selling regulations. It is used in Position Reports and clearing messages. When paired with LongQty (Tag 704), it enables net exposure analysis. ShortQty is critical for accurate position reconciliation and regulatory reporting under rules like Regulation SHO.

Tag 706: PosQtyStatus
Tag 706 (PosQtyStatus) indicates the processing status of a position quantity: Submitted (0), Accepted (1), or Rejected (2). It is used in Position Maintenance messages to provide feedback on position updates. PosQtyStatus supports operational transparency and enables timely resolution of discrepancies. The field enhances auditability and ensures that position changes are properly acknowledged. It is essential for reliable position management in multi-firm environments.

Tag 707: PosAmtType
Tag 707 (PosAmtType) specifies the type of position amount being reported: Final (1), Adjusted (2), or Projected (3). It defines the nature of the value in PosAmt (Tag 708). For example, “Final” indicates a settled amount, while “Projected” is an estimate. PosAmtType supports accurate financial reporting and reconciliation. The field enhances clarity in position valuation and supports compliance with accounting standards.

Tag 708: PosAmt
Tag 708 (PosAmt) specifies the monetary value associated with a position, such as market value or cost basis. It is used in Position Reports and allocations. PosAmt supports portfolio valuation, P&L calculation, and margining. When combined with PosAmtType (Tag 707), it provides context for the amount. The field is essential for accurate financial reporting and risk assessment.

Tag 709: PosTransType
Tag 709 (PosTransType) specifies the type of position transaction: New (0), Replace (1), or Cancel (2). It controls the lifecycle of a position update. PosTransType ensures correct handling of position changes and prevents duplication. The field is used in Position Maintenance Request messages. It supports reliable position management and reconciliation.

Tag 710: PosReqID
Tag 710 (PosReqID) is a unique identifier assigned by the requester in a Position Request message. It links the request to its response and supports message correlation. PosReqID enables tracking of position inquiries and ensures accurate handling. The field is essential for portfolio reconciliation and regulatory reporting. It enhances auditability in position management workflows.

Tag 711: NoUnderlyings
Tag 711 (NoUnderlyings) specifies the number of underlying securities in a repeating group, typically used in derivatives or structured products. It defines how many times UnderlyingSymbol (Tag 311), UnderlyingSecurityID (Tag 309), and related fields repeat. NoUnderlyings supports complex instrument definitions. The field enhances precision in multi-underlying strategies and supports accurate clearing.

Tag 712: PosMaintAction
Tag 712 (PosMaintAction) specifies the action to be taken on a position: New (1), Replace (2), or Cancel (3). It controls the update type in a Position Maintenance Request. PosMaintAction ensures correct processing and prevents unintended changes. The field supports robust position lifecycle management.

Tag 713: OrigPosReqRefID
Tag 713 (OrigPosReqRefID) references the original PosReqID (Tag 710) when responding to a position request. It ensures message linkage and supports reconciliation. OrigPosReqRefID enhances traceability in position reporting workflows.

Tag 714: PosMaintRptRefID
Tag 714 (PosMaintRptRefID) references a prior Position Maintenance Report. It is used when canceling or replacing a previous report. PosMaintRptRefID ensures correct lifecycle management and prevents duplication.

Tag 715: ClearingBusinessDate
Tag 715 (ClearingBusinessDate) specifies the business date used by the clearing organization for processing trades. It may differ from TradeDate (Tag 75) due to time zones or settlement cycles. ClearingBusinessDate supports accurate clearing and accounting. The field is essential for global trade processing.

Tag 716: SettlSessID
Tag 716 (SettlSessID) identifies the settlement session, such as “Regular” or “Delayed.” It supports multi-session clearing environments. SettlSessID ensures correct handling of trades based on settlement timing.

Tag 717: SettlSessSubID
Tag 717 (SettlSessSubID) specifies a sub-session within a settlement session, such as “Intraday” or “End-of-Day.” It provides granular control over settlement timing. SettlSessSubID enhances precision in clearing workflows.

Tag 718: AdjustmentType
Tag 718 (AdjustmentType) specifies the type of position adjustment: Process Request (0), Exercise (1), or Assignment (2). It supports accurate position updates due to corporate actions. The field enhances transparency in lifecycle events.

Tag 719: ContraryInstructionIndicator
Tag 719 (ContraryInstructionIndicator) indicates opposing trading intent in a block or RFQ (Y/N). It helps identify potential internal matches. The field supports internal crossing and best execution.

Tag 720: PriorSpreadIndicator
Tag 720 (PriorSpreadIndicator) indicates if a quote is based on a prior spread trade (Y/N). It supports context in wholesale pricing. The field enhances transparency in dealer quotes.

Tag 721: PosMaintRptID
Tag 721 (PosMaintRptID) is a unique identifier for a Position Maintenance Report. It enables tracking and referencing. PosMaintRptID supports auditability in position workflows.

Tag 722: PosMaintStatus
Tag 722 (PosMaintStatus) indicates the processing status of a position maintenance request: Accepted (0), Rejected (1). It provides feedback on submission outcomes.

Tag 723: PosMaintResult
Tag 723 (PosMaintResult) specifies the result of a position maintenance action: Successful (0), Rejected (1). It supports troubleshooting and reconciliation.

Tag 724: PosReqType
Tag 724 (PosReqType) specifies the type of position request: Positions (0), Trades (1). It controls the scope of the inquiry. The field supports flexible position reporting.

Tag 725: ResponseTransportType
Tag 725 (ResponseTransportType) specifies how a response should be delivered: Inband (0), Out-of-Band (1). It supports messaging efficiency and reliability.

Tag 726: ResponseDestination
Tag 726 (ResponseDestination) specifies the destination for a response, such as an email or system address. It ensures correct delivery of replies.

Tag 727: TotalNumPosReports
Tag 727 (TotalNumPosReports) specifies the total number of position reports in a multi-message sequence. It supports reconciliation of batch responses.

Tag 728: PosReqResult
Tag 728 (PosReqResult) indicates the outcome of a position request: Valid Request (0), Invalid (1). It provides feedback on request processing.

Tag 729: PosReqStatus
Tag 729 (PosReqStatus) indicates the status of a position request: Completed (0), In Progress (1). It supports tracking of long-running inquiries.

Tag 730: SettlPrice
Tag 730 (SettlPrice) specifies the official settlement price of a security, typically determined by an exchange or clearinghouse. It is used for marking positions to market, margin calculations, and final valuation. SettlPrice may differ from the last traded price and is critical for futures, options, and daily close reporting. The field supports accurate accounting and risk management. It is disseminated in market data and used in clearing workflows. SettlPrice ensures consistency across counterparties.

Tag 731: SettlPriceType
Tag 731 (SettlPriceType) specifies the method used to determine the settlement price: Final (1), Preliminary (2), or Theoretical (3). It provides context for how the SettlPrice (Tag 730) was derived. For example, a “Final” price is official and binding, while “Preliminary” may be subject to adjustment. SettlPriceType supports accurate valuation, margining, and accounting. It is used in market data and clearing messages. The field enhances transparency in futures and options markets where settlement prices are critical for daily P&L and risk calculations. It ensures that all parties interpret the price consistently and is essential for regulatory and audit purposes.

Tag 732: UnderlyingSettlPrice
Tag 732 (UnderlyingSettlPrice) is the official settlement price of the underlying security in a derivative contract, such as an option or future. It is used to calculate the final value or payoff of the derivative at expiration. UnderlyingSettlPrice ensures accurate exercise and settlement logic. It is typically determined by the exchange or clearinghouse and disseminated in market data. The field is essential for correct valuation of options and futures, especially in cash-settled instruments. It supports margining, accounting, and regulatory reporting. UnderlyingSettlPrice enhances consistency between counterparties.

Tag 733: UnderlyingSettlPriceType
Tag 733 (UnderlyingSettlPriceType) specifies how the UnderlyingSettlPrice (Tag 732) was determined: Final (1), Preliminary (2), or Theoretical (3). It provides transparency into the pricing methodology. This field ensures that both parties understand the reliability and finality of the underlying price. It is used in derivatives and structured products to support accurate payoff calculation. UnderlyingSettlPriceType enhances auditability and supports dispute resolution in settlement workflows.

Tag 734: PriorSettlPrice
Tag 734 (PriorSettlPrice) is the previous day’s settlement price for a security. It supports performance measurement, margin calculations, and volatility analysis. PriorSettlPrice enables day-over-day comparisons and is used in risk and accounting systems. The field ensures continuity in position valuation and supports accurate P&L attribution. It is particularly relevant in futures and options markets.

Tag 735: NoQuoteQualifiers
Tag 735 (NoQuoteQualifiers) specifies the number of qualifiers in a repeating group within a Quote message. It defines how many times QuoteQualifier (Tag 695) repeats. This field supports rich context in quotes, such as indicating aggressiveness or market conditions. NoQuoteQualifiers enhances transparency in dealer-to-client pricing and supports algorithmic interpretation.

Tag 736: AllocSettlCurrency
Tag 736 (AllocSettlCurrency) specifies the settlement currency for an allocation when it differs from the trade currency. It supports accurate cross-currency handling in post-trade processing. AllocSettlCurrency ensures correct payment instructions and accounting. The field is essential for global institutional investors.

Tag 737: AllocSettlCurrAmt
Tag 737 (AllocSettlCurrAmt) is the amount in the settlement currency for a specific allocation. It is used when the allocation is settled in a currency different from the trade currency. AllocSettlCurrAmt supports accurate FX conversion and payment processing. The field enhances clarity in multi-currency allocations.

Tag 738: InterestAtMaturity
Tag 738 (InterestAtMaturity) specifies the total interest payable at maturity for a debt instrument, such as a zero-coupon bond. It supports final settlement and accounting. InterestAtMaturity ensures correct payment to the holder and is used in fixed-income processing.

Tag 739: LegDatedDate
Tag 739 (LegDatedDate) is the dated date of a bond leg in a multi-leg instrument, which may differ from the issue date. It marks when interest begins to accrue. LegDatedDate supports accurate accrued interest and yield calculations. The field is essential for fixed-income derivatives.

Tag 740: LegPool
Tag 740 (LegPool) identifies the pool or tranche of a mortgage-backed or asset-backed security leg. It ensures precise identification and pricing. LegPool is critical in structured credit markets.

Tag 741: AllocInterestAtMaturity
Tag 741 (AllocInterestAtMaturity) is the interest amount at maturity allocated to a specific account. It supports accurate distribution of income in fixed-income allocations. The field enhances transparency in post-trade processing.

Tag 742: AllocAccruedInterestAmt
Tag 742 (AllocAccruedInterestAmt) is the accrued interest amount allocated to a specific account. It ensures correct cost basis and tax reporting. AllocAccruedInterestAmt is used in bond trade allocations.

Tag 743: DeliveryDate
Tag 743 (DeliveryDate) specifies the date physical delivery of a security is expected. It is used in commodities, futures, and securities lending. DeliveryDate supports logistics and settlement planning.

Tag 744: AssignmentMethod
Tag 744 (AssignmentMethod) specifies how option assignments are allocated: Pro Rata (P), Random (R), or First In First Out (F). It ensures fair and transparent exercise distribution. The field is used by clearinghouses.

Tag 745: AssignmentUnit
Tag 745 (AssignmentUnit) specifies the minimum unit for option assignment, such as one contract. It supports precise allocation logic. AssignmentUnit ensures consistent handling across accounts.

Tag 746: OpenInterest
Tag 746 (OpenInterest) is the total number of outstanding derivative contracts, such as options or futures, that have not been settled. It measures market activity and liquidity. OpenInterest is used in market data and supports technical analysis.

Tag 747: ExerciseMethod
Tag 747 (ExerciseMethod) specifies how an option can be exercised: Automatic (A) or Manual (M). It defines the process at expiration. ExerciseMethod supports correct handling by clearing systems.

Tag 748: TotNumTradeReports
Tag 748 (TotNumTradeReports) specifies the total number of trade reports in a multi-message sequence. It supports reconciliation of batch trade reporting. The field ensures completeness in regulatory submissions.

Tag 749: TradeRequestResult
Tag 749 (TradeRequestResult) indicates the outcome of a Trade Capture Report Request: Successful (0), Invalid Request (1). It provides feedback for troubleshooting.

Tag 750: TradeRequestStatus
Tag 750 (TradeRequestStatus) indicates the processing status of a trade request: Completed (0), In Progress (1). It supports tracking of long-running inquiries.

Tag 751: TradeReportRejectReason
Tag 751 (TradeReportRejectReason) specifies why a trade report was rejected: Invalid Trade (1), Duplicate (2). It supports compliance and correction.

Tag 752: SideMultiLegReportingType
Tag 752 (SideMultiLegReportingType) specifies how a multi-leg trade should be reported per side: Single Security (1), Individual Legs (2). It supports regulatory compliance.

Tag 753: NoPosAmt
Tag 753 (NoPosAmt) specifies the number of position amount entries in a repeating group. It defines how many times PosAmtType (Tag 707) and PosAmt (Tag 708) repeat. The field supports multiple valuation methods per position.

Tag 754: AutoAcceptIndicator
Tag 754 (AutoAcceptIndicator) indicates whether a quote or trade should be auto-accepted (Y/N). It supports algorithmic and high-speed trading workflows.

Tag 755: AllocReportID
Tag 755 (AllocReportID) is a unique identifier for an allocation report. It supports tracking and reconciliation. AllocReportID enhances auditability.

Tag 756: NoNested2PartyIDs
Tag 756 (NoNested2PartyIDs) specifies the number of second-level nested parties. It defines the size of a nested repeating group for deeper hierarchy support.

Tag 757: Nested2PartyID
Tag 757 (Nested2PartyID) identifies a party within a second-level nested group, such as a sub-broker. It supports multi-tier routing.

Tag 758: Nested2PartyIDSource
Tag 758 (Nested2PartyIDSource) specifies the namespace of Nested2PartyID (Tag 757), such as BIC or Proprietary. It ensures correct identification.

Tag 759: Nested2PartyRole
Tag 759 (Nested2PartyRole) specifies the role of a second-level nested party: Executing Firm (1), Clearing Firm (7). It supports detailed attribution.

Tag 760: Nested2PartySubID
Tag 760 (Nested2PartySubID) is a sub-identifier for a second-level nested party, such as a trader or desk. It enhances granularity.

Tag 761: BenchmarkSecurityIDSource
Tag 761 (BenchmarkSecurityIDSource) specifies the namespace of BenchmarkSecurityID (Tag 699), such as ISIN (4) or CUSIP (1). It ensures correct benchmark mapping.

Tag 762: SecuritySubType
Tag 762 (SecuritySubType) provides a detailed classification of a security beyond SecurityType (Tag 167), such as “Convertible” or “Preferred.” It supports precise identification and risk modeling.

Tag 763: UnderlyingSecuritySubType
Tag 763 (UnderlyingSecuritySubType) specifies the sub-type of the underlying security, such as “Callable Bond.” It enhances accuracy in derivative valuation.

Tag 764: LegSecuritySubType
Tag 764 (LegSecuritySubType) specifies the sub-type of a leg in a multi-leg instrument. It supports granular classification and correct handling.

Tag 765: AllowableOneSidednessPct
Tag 765 (AllowableOneSidednessPct) specifies the maximum allowable imbalance as a percentage in a crossing algorithm. It controls risk in internal matching.

Tag 766: AllowableOneSidednessValue
Tag 766 (AllowableOneSidednessValue) is the maximum allowable imbalance in quantity for a cross. It supports risk management in algorithmic crossing.

Tag 767: AllowableOneSidednessCurr
Tag 767 (AllowableOneSidednessCurr) specifies the currency of AllowableOneSidednessValue (Tag 766). It ensures correct interpretation in multi-currency environments.

Tag 768: NoTrdRegTimestamps
Tag 768 (NoTrdRegTimestamps) specifies the number of regulatory timestamp entries in a repeating group within a Trade Capture Report message. It defines how many times TrdRegTimestamp (Tag 769), TrdRegTimestampType (Tag 770), and TrdRegTimestampOrigin (Tag 771) are repeated. This field supports comprehensive audit trails by allowing multiple timestamps to be recorded for a single trade, such as order entry, execution, and reporting times. NoTrdRegTimestamps is essential for compliance with regulations like MiFID II, which mandate detailed time tracking across the trade lifecycle. It enables firms to demonstrate best execution and meet transaction reporting obligations. The repeating group structure ensures flexibility and completeness in timestamp capture, enhancing transparency and regulatory readiness.

Tag 769: TrdRegTimestamp
Tag 769 (TrdRegTimestamp) specifies a timestamp associated with a specific stage in the trade lifecycle, such as order receipt, execution, or reporting. It is formatted in UTC as YYYYMMDD-HH:MM:SS.sss and is used in Trade Capture messages to meet regulatory requirements. TrdRegTimestamp supports auditability and best execution analysis. Multiple timestamps can be included using NoTrdRegTimestamps (Tag 768). The field is critical for demonstrating compliance with MiFID II, Dodd-Frank, and other regimes requiring precise time tracking. TrdRegTimestamp enhances transparency in trading workflows and supports dispute resolution.

Tag 770: TrdRegTimestampType
Tag 770 (TrdRegTimestampType) identifies the type of regulatory timestamp being reported: Order Arrival (1), Order Execution (2), or Trade Reporting (3). It provides context for TrdRegTimestamp (Tag 769), ensuring correct interpretation of timing data. This field is essential for regulatory reporting under MiFID II, where different phases of the trade lifecycle must be clearly distinguished. TrdRegTimestampType supports best execution analysis and operational transparency. It enables regulators and firms to verify compliance with latency and execution quality rules. The field enhances the reliability of trade reporting.

Tag 771: TrdRegTimestampOrigin
Tag 771 (TrdRegTimestampOrigin) identifies the system or entity that generated the TrdRegTimestamp (Tag 769), such as a client trading platform, broker gateway, or exchange. It supports auditability by tracing the source of timing data. TrdRegTimestampOrigin enhances accountability in multi-party trading environments and helps resolve discrepancies. The field is used in Trade Capture messages and is critical for regulatory compliance. It ensures that timestamps are not only accurate but also attributable.

Tag 772: ConfirmRefID
Tag 772 (ConfirmRefID) is a reference identifier for a prior confirmation message, used when canceling or replacing a confirmation. It ensures message linkage and supports lifecycle management of trade affirmations. ConfirmRefID prevents duplication and enhances accuracy in post-trade processing. The field is used in Confirmation (MsgType AK) messages and enables reliable tracking of confirmation status. It supports reconciliation between counterparties.

Tag 773: ConfirmType
Tag 773 (ConfirmType) specifies the type of confirmation being sent: Full (1), Partial (2), or Status Report (3). It controls how the confirmation is processed by the receiver. ConfirmType supports flexible affirmation workflows and ensures correct handling in allocation and settlement. The field is essential for accurate trade reconciliation and supports regulatory reporting requirements.

Tag 774: ConfirmRejReason
Tag 774 (ConfirmRejReason) specifies the reason a confirmation was rejected: Invalid Account (1), Mismatched Quantity (2), or Mismatched Price (3). It provides actionable feedback for troubleshooting. ConfirmRejReason supports efficient resolution of discrepancies in affirmation processes. The field enhances transparency in post-trade workflows.

Tag 775: BookingType
Tag 775 (BookingType) specifies how a trade should be booked: Regular Booking (0), Request Not Allowed (1), or Request Allowed (2). It guides back-office systems on whether to automatically book the trade or await instructions. BookingType supports operational policies and ensures alignment between execution and accounting. The field is used in Execution Reports and supports GT (Good Till) order handling.

Tag 776: IndividualAllocRejCode
Tag 776 (IndividualAllocRejCode) specifies the reason a specific allocation was rejected: Unknown Account (0), Incorrect Quantity (1), or Mismatched Data (2). It provides granular feedback in Allocation messages when only part of a multi-account allocation fails. IndividualAllocRejCode supports reconciliation and error correction. The field enhances clarity in complex allocation workflows.

Tag 777: SettlInstMsgID
Tag 777 (SettlInstMsgID) is a unique identifier assigned to a Settlement Instruction message. It enables tracking, referencing, and reconciliation of delivery instructions. SettlInstMsgID supports auditability and ensures that settlement details are correctly applied. The field is used in SettlInst (MsgType V) messages and is essential for accurate post-trade processing.

Tag 778: NoSettlInst
Tag 778 (NoSettlInst) specifies the number of settlement instruction entries in a repeating group. It defines how many times SettlPartyID (Tag 782), SettlPartyRole (Tag 784), and related fields repeat. NoSettlInst supports multiple delivery instructions for a single trade. The field is essential for complex settlement scenarios involving multiple custodians or accounts.

Tag 779: LastUpdateTime
Tag 779 (LastUpdateTime) is the UTC timestamp (YYYYMMDD-HH:MM:SS.sss) of the last modification to a record, such as an order, allocation, or position. It supports audit trails, change tracking, and reconciliation. LastUpdateTime enables systems to detect updates and maintain data consistency. The field is used in Execution Reports, Allocations, and Position messages.

Tag 780: AllocSettlInstType
Tag 780 (AllocSettlInstType) specifies how settlement instructions are applied to allocations: Use Allocations (0), Use Settlement Instructions (1), or Use Broker Instructions (2). It controls whether delivery details come from the allocation or a separate instruction. The field supports flexible settlement workflows.

Tag 781: NoSettlPartyIDs
Tag 781 (NoSettlPartyIDs) specifies the number of settlement party entries in a repeating group. It defines how many times SettlPartyID (Tag 782), SettlPartyIDSource (Tag 783), and SettlPartyRole (Tag 784) repeat. NoSettlPartyIDs supports multiple settlement parties in a single instruction.

Tag 782: SettlPartyID
Tag 782 (SettlPartyID) identifies a party involved in the settlement process, such as a custodian, depository, or beneficiary. It is used in Settlement Instructions to specify who is responsible for delivery. SettlPartyID supports accurate instruction routing and is essential for global clearing.

Tag 783: SettlPartyIDSource
Tag 783 (SettlPartyIDSource) specifies the namespace of SettlPartyID (Tag 782), such as BIC (1), Proprietary (3), or ISIN (4). It ensures the identifier is interpreted correctly. The field prevents misidentification in multi-jurisdictional environments.

Tag 784: SettlPartyRole
Tag 784 (SettlPartyRole) specifies the role of a settlement party: Custodian (1), Beneficiary (2), or Intermediary (3). It defines responsibilities in the delivery chain. SettlPartyRole supports clear accountability and accurate instruction processing.

Tag 785: SettlPartySubID
Tag 785 (SettlPartySubID) is a sub-identifier for a settlement party, such as a desk, trader, or account number. It enhances granularity in identification. SettlPartySubID supports detailed tracking within large institutions.

Tag 786: SettlPartySubIDType
Tag 786 (SettlPartySubIDType) specifies the type of SettlPartySubID (Tag 785), such as Firm (1), Desk (2), or Individual (3). It ensures correct interpretation of the sub-ID. The field enhances precision in party identification.

Tag 787: DlvyInstType
Tag 787 (DlvyInstType) specifies the type of delivery instruction: Securities (0), Cash (1), or Both (2). It guides the settlement system on how to handle the trade. DlvyInstType supports accurate processing and reduces operational risk.

Tag 788: TerminationType
Tag 788 (TerminationType) indicates how a derivative contract, such as a swap, terminates: Maturity (1), Cancellation (2), or Exercise (3). It supports lifecycle management and reporting. The field is used in Trade Capture messages.

Tag 789: NextExpectedMsgSeqNum
Tag 789 (NextExpectedMsgSeqNum) is the next MsgSeqNum (Tag 34) expected by the receiver. It is used in Logon and Resend Request messages to detect gaps. The field supports reliable message delivery and session recovery.

Tag 790: OrdStatusReqID
Tag 790 (OrdStatusReqID) is a unique identifier assigned by the requester in an Order Status Request (MsgType H). It enables tracking and response correlation. OrdStatusReqID supports order monitoring and reconciliation.

Tag 791: SettlInstReqID
Tag 791 (SettlInstReqID) is a unique identifier for a Settlement Instruction Request (MsgType AM). It supports message linkage and tracking. SettlInstReqID enhances auditability.

Tag 792: SettlInstReqRejCode
Tag 792 (SettlInstReqRejCode) specifies why a settlement instruction request was rejected: Invalid Settlement Type (1), Unknown Account (2). It provides feedback for correction.

Tag 793: SecondaryAllocID
Tag 793 (SecondaryAllocID) is an alternate identifier for an allocation, often assigned by a clearinghouse or exchange. It supports cross-system referencing and traceability.

Tag 794: AllocReportType
Tag 794 (AllocReportType) specifies the type of allocation report: Submit (2), Acknowledge (5), or Reject (6). It controls processing logic and supports lifecycle management.

Tag 795: AllocReportRefID
Tag 795 (AllocReportRefID) references a prior allocation report, such as when replacing or canceling. It ensures correct lifecycle handling and prevents duplication.

Tag 796: AllocCancReplaceReason
Tag 796 (AllocCancReplaceReason) specifies why an allocation was canceled or replaced: Original Details Incorrect (1), Cancel on Trade Break (2). It supports transparency.

Tag 797: CopyMsgIndicator
Tag 797 (CopyMsgIndicator) indicates whether a message is a copy (Y/N). It prevents duplicate processing. The field supports audit and reconciliation in multi-hop environments.

Tag 798: AllocAccountType
Tag 798 (AllocAccountType) specifies the type of allocated account: Individual (1), Joint (2), Corporate (3). It supports correct tax and regulatory handling.

Tag 799: OrderAvgPx
Tag 799 (OrderAvgPx) is the average execution price for an entire order, calculated as total value divided by total quantity. It supports performance measurement and commission calculation. The field is used in Execution Reports.

Tag 800: OrderBookingQty
Tag 800 (OrderBookingQty) is the portion of an order intended for immediate booking, particularly in GT (Good Till) orders. It supports partial booking logic and back-office workflows.

Tag 801: NoSettlPartySubIDs
Tag 801 (NoSettlPartySubIDs) specifies the number of sub-identifiers for a settlement party. It defines how many times SettlPartySubID (Tag 785) and SettlPartySubIDType (Tag 786) repeat. The field supports granular identification.

Tag 802: NoPartySubIDs
Tag 802 (NoPartySubIDs) specifies the number of sub-identifiers for a party. It defines the size of the repeating group for PartySubID (Tag 523). The field enhances granularity in party identification.

Tag 803: PartySubIDType
Tag 803 (PartySubIDType) specifies the type of PartySubID (Tag 523), such as Desk (2) or Trader (3). It ensures correct interpretation of sub-identifiers.

Tag 804: NoNestedPartySubIDs
Tag 804 (NoNestedPartySubIDs) specifies the number of sub-IDs for a nested party. It supports granular identification in multi-level routing.

Tag 805: NestedPartySubIDType
Tag 805 (NestedPartySubIDType) specifies the type of NestedPartySubID (Tag 545). It ensures correct interpretation in nested structures.

Tag 806: NoNested2PartySubIDs
Tag 806 (NoNested2PartySubIDs) specifies the number of sub-IDs for a second-level nested party. It supports deep hierarchy tracking.

Tag 807: Nested2PartySubIDType
Tag 807 (Nested2PartySubIDType) specifies the type of Nested2PartySubID (Tag 760). It ensures clarity in multi-tier identification.

Tag 808: AllocIntermedReqType
Tag 808 (AllocIntermedReqType) specifies the type of intermediate allocation request: Pending Accept (1), Pending Release (2). It supports workflow control.

Tag 810: UnderlyingPx
Tag 810 (UnderlyingPx) is the current market price of the underlying security in a derivative. It supports valuation and risk modeling. The field is used in options and futures.

Tag 811: PriceDelta
Tag 811 (PriceDelta) is the sensitivity of an option’s price to changes in the underlying (delta). It supports risk management and hedging. The field is used in derivatives.

Tag 812: ApplQueueMax
Tag 812 (ApplQueueMax) is the maximum number of messages allowed in the application-level message queue. It supports flow control and system stability.

Tag 813: ApplQueueDepth
Tag 813 (ApplQueueDepth) is the current number of messages in the application queue. It supports monitoring and congestion management.

Tag 814: ApplQueueResolution
Tag 814 (ApplQueueResolution) specifies how queue overflow is handled: Suspend (1), Discard (2). It supports message delivery policies.

Tag 815: ApplQueueAction
Tag 815 (ApplQueueAction) indicates the current queue action: No Action (0), Suspend (1). It supports flow control signaling.

Tag 816: NoAltMDSource
Tag 816 (NoAltMDSource) specifies the number of alternate market data sources. It supports redundancy and failover planning.

Tag 817: AltMDSourceID
Tag 817 (AltMDSourceID) identifies an alternate market data source. It supports backup routing in case of primary source failure.

Tag 818: SecondaryTradeReportID
Tag 818 (SecondaryTradeReportID) is an alternate identifier for a trade report. It supports cross-system referencing.

Tag 819: AvgPxIndicator
Tag 819 (AvgPxIndicator) specifies how AvgPx (Tag 6) is calculated: No Avg Pricing (0), Trade is Avg Price (1). It supports transparency.

Tag 820: TradeLinkID
Tag 820 (TradeLinkID) links related trades, such as legs of a spread. It supports strategy tracking.

Tag 821: OrderInputDevice
Tag 821 (OrderInputDevice) specifies the device used to enter an order: Terminal (1), Mobile (2). It supports client behavior analysis.

Tag 822: UnderlyingTradingSessionID
Tag 822 (UnderlyingTradingSessionID) identifies the trading session of the underlying security. It supports accurate session mapping.

Tag 823: UnderlyingTradingSessionSubID
Tag 823 (UnderlyingTradingSessionSubID) specifies the sub-session of the underlying. It enhances session granularity.

Tag 824: TradeLegRefID
Tag 824 (TradeLegRefID) references a leg in a multi-leg trade. It supports lifecycle tracking.

Tag 825: ExchangeRule
Tag 825 (ExchangeRule) specifies the exchange rule under which a trade was executed. It supports regulatory reporting.

Tag 826: TradeAllocIndicator
Tag 826 (TradeAllocIndicator) indicates whether a trade has been allocated (Y/N). It supports post-trade tracking.

Tag 827: ExpirationCycle
Tag 827 (ExpirationCycle) specifies the expiration pattern: Not Applicable (0), Daily (1). It supports derivatives handling.

Tag 828: TrdType
Tag 828 (TrdType) specifies the trade type: Regular Trade (0), Block Trade (1). It supports regulatory categorization.

Tag 829: TrdSubType
Tag 829 (TrdSubType) specifies the trade sub-type: EFP (1), Exchange-for-Related (2). It supports detailed classification.

Tag 830: TransferReason
Tag 830 (TransferReason) specifies the reason for a position transfer: Account Consolidation (1), Client Request (2). It supports audit and compliance.

Tag 831: AsgnReqID
Tag 831 (AsgnReqID) is a unique identifier assigned by the requester in an Assignment Report Request message. It links the request to its response and supports message correlation in option exercise or assignment workflows. AsgnReqID enables tracking of assignment inquiries and ensures accurate handling of responses. The field is used in clearing and post-trade processes where options are exercised or assigned. It enhances auditability and supports reconciliation between brokers, clearinghouses, and clients. AsgnReqID is essential for managing lifecycle events in derivatives trading.

Tag 832: TotNumAssignmentReports
Tag 832 (TotNumAssignmentReports) specifies the total number of assignment reports in a multi-message sequence. It supports reconciliation of batch responses in option exercise or assignment workflows. TotNumAssignmentReports ensures that all expected reports have been received and prevents data loss. The field is used in Assignment Report messages and enhances reliability in high-volume clearing environments. It supports regulatory and operational completeness.

Tag 833: AsgnRptID
Tag 833 (AsgnRptID) is a unique identifier assigned to an Assignment Report. It enables tracking, referencing, and reconciliation of option exercise or assignment events. AsgnRptID supports auditability and ensures correct lifecycle management. The field is used in clearing and settlement workflows and is critical for accurate position updates.

Tag 834: ThresholdAmount
Tag 834 (ThresholdAmount) specifies a monetary threshold used in algorithmic or risk-based trading logic. It may trigger actions such as order cancellation, reporting, or adjustment when exceeded. ThresholdAmount supports dynamic trading strategies and risk controls. The field is used in order and execution messages to define behavioral limits.

Tag 835: PegMoveType
Tag 835 (PegMoveType) specifies the trigger for a pegged order adjustment: Immediate (0) or Widen Only (1). It controls how the order price responds to market movements. PegMoveType supports intelligent order execution and is used in algorithmic trading strategies.

Tag 836: PegOffsetType
Tag 836 (PegOffsetType) defines the unit of the peg offset: Price (0), Basis Points (1), or Ticks (2). It ensures correct interpretation of PegOffsetValue (Tag 211). PegOffsetType enhances precision in pegged order strategies.

Tag 837: PegLimitType
Tag 837 (PegLimitType) specifies whether a pegged order has a relative (0) or absolute (1) limit price. It controls how the limit is applied relative to the reference price. PegLimitType supports flexible execution logic.

Tag 838: PegRoundDirection
Tag 838 (PegRoundDirection) specifies rounding direction for a pegged price: Round to Nearest (0), Up (1), or Down (2). It ensures consistent price formatting.

Tag 839: PeggedPrice
Tag 839 (PeggedPrice) is the current reference price to which a pegged order is tied, such as the midpoint or best bid. It supports algorithmic execution and is updated in real time.

Tag 840: PegScope
Tag 840 (PegScope) defines the scope of the peg: Local (1), National (2), or Global (3). It controls where the reference price is sourced from.

Tag 841: DiscretionMoveType
Tag 841 (DiscretionMoveType) specifies when the discretion price is adjusted: Immediate (0) or Widen Only (1). It supports dynamic pricing strategies.

Tag 842: DiscretionOffsetType
Tag 842 (DiscretionOffsetType) defines the unit of the discretion offset: Price (0), Basis Points (1), or Ticks (2). It ensures correct interpretation of DiscretionOffsetValue.

Tag 843: DiscretionLimitType
Tag 843 (DiscretionLimitType) specifies whether the discretion price has a relative (0) or absolute (1) limit. It controls execution flexibility.

Tag 844: DiscretionRoundDirection
Tag 844 (DiscretionRoundDirection) specifies rounding direction for the discretion price: Nearest (0), Up (1), Down (2). It ensures consistent pricing.

Tag 845: DiscretionPrice
Tag 845 (DiscretionPrice) is the price at which a broker may improve execution within a reserve or pegged order. It supports aggressive or passive strategies.

Tag 846: DiscretionScope
Tag 846 (DiscretionScope) defines the scope of discretion: Local (1), National (2), or Global (3). It controls pricing flexibility.

Tag 847: TargetStrategy
Tag 847 (TargetStrategy) specifies the algorithmic execution strategy: VWAP (1), TWAP (2), or Implementation Shortfall (3). It guides execution logic and supports best execution reporting.

Tag 848: TargetStrategyParameters
Tag 848 (TargetStrategyParameters) contains custom parameters for a target strategy, such as time windows or volume limits. It supports flexible algorithm configuration.

Tag 849: ParticipationRate
Tag 849 (ParticipationRate) specifies the desired participation rate in market volume, expressed as a percentage. It supports volume-based algorithms like POV.

Tag 850: TargetStrategyPerformance
Tag 850 (TargetStrategyPerformance) is the achieved performance of a target strategy, such as slippage or VWAP deviation. It supports post-trade analysis.

Tag 851: LastLiquidityInd
Tag 851 (LastLiquidityInd) indicates the liquidity provision role in the last trade: Added (1), Removed (2), or Routed (3). It supports MiFID II reporting.

Tag 852: PublishTrdIndicator
Tag 852 (PublishTrdIndicator) indicates whether a trade should be publicly reported (Y/N). It supports transparency and regulatory compliance.

Tag 853: ShortSaleReason
Tag 853 (ShortSaleReason) specifies the reason for a short sale: Dealer (0), Financing (1), or Customer (2). It supports regulatory reporting.

Tag 854: QtyType
Tag 854 (QtyType) specifies the type of quantity: Units (0), Contracts (1), or Lots (2). It ensures correct interpretation of order size.

Tag 855: SecondaryTrdType
Tag 855 (SecondaryTrdType) is an alternate classification of the trade type, used for internal or regulatory categorization.

Tag 856: TradeReportType
Tag 856 (TradeReportType) specifies the type of trade report: Submit (0), Cancel (1), or Replace (2). It controls lifecycle management.

Tag 857: AllocNoOrdersType
Tag 857 (AllocNoOrdersType) specifies how NoOrders (Tag 73) is interpreted: None (0), Includes (1). It supports allocation logic.

Tag 858: SharedCommission
Tag 858 (SharedCommission) is a commission amount shared across multiple accounts in an allocation. It supports fair cost distribution.

Tag 859: ConfirmReqID
Tag 859 (ConfirmReqID) is a unique ID for a Confirmation Request. It supports tracking and response linkage.

Tag 860: AvgParPx
Tag 860 (AvgParPx) is the average price expressed as a percentage of par, used in fixed-income allocations. It supports consistent valuation.

Tag 861: ReportedPx
Tag 861 (ReportedPx) is the price reported for regulatory purposes, which may differ from execution price. It supports best execution.

Tag 862: NoCapacities
Tag 862 (NoCapacities) specifies the number of order capacity entries. It defines how many times OrderCapacityQty (Tag 863) repeats.

Tag 863: OrderCapacityQty
Tag 863 (OrderCapacityQty) specifies the quantity associated with a specific OrderCapacity (Tag 528). It supports multi-capacity orders.

Tag 864: NoEvents
Tag 864 (NoEvents) specifies the number of corporate or market events in a repeating group. It supports event-based pricing.

Tag 865: EventType
Tag 865 (EventType) specifies the type of event: Put (1), Call (2), or Tender (3). It supports corporate action handling.

Tag 866: EventDate
Tag 866 (EventDate) is the date of a corporate or market event. It supports lifecycle tracking.

Tag 867: EventPx
Tag 867 (EventPx) is the price associated with an event, such as a call price. It supports valuation.

Tag 868: EventText
Tag 868 (EventText) provides free-text details about an event. It supports transparency.

Tag 869: PctAtRisk
Tag 869 (PctAtRisk) is the percentage of portfolio value at risk. It supports risk management and VaR calculations.

Tag 870: NoInstrAttrib
Tag 870 (NoInstrAttrib) specifies the number of instrument attributes. It defines the size of the repeating group.

Tag 871: InstrAttribType
Tag 871 (InstrAttribType) specifies the type of instrument attribute: Flat (1), Zero Coupon (2). It supports detailed classification.

Tag 872: InstrAttribValue
Tag 872 (InstrAttribValue) is the value of an instrument attribute. It provides context for InstrAttribType.

Tag 873: DatedDate
Tag 873 (DatedDate) is the date from which interest begins to accrue on a bond. It may differ from the issue date. DatedDate supports accurate yield calculations.

Tag 874: InterestAccrualDate
Tag 874 (InterestAccrualDate) is the date interest starts accruing on a bond. It supports accrued interest and pricing.

Tag 875: CPProgram
Tag 875 (CPProgram) specifies the commercial paper program under which a security was issued. It supports fixed-income identification.

Tag 876: CPRegType
Tag 876 (CPRegType) specifies the registration type of a commercial paper, such as Rule 144A. It supports compliance.

Tag 877: UnderlyingCPProgram
Tag 877 (UnderlyingCPProgram) specifies the CP program of the underlying security in a derivative. It supports accurate classification.

Tag 878: UnderlyingCPRegType
Tag 878 (UnderlyingCPRegType) specifies the registration type of the underlying CP. It supports regulatory reporting.

Tag 879: UnderlyingQty
Tag 879 (UnderlyingQty) is the quantity of the underlying security in a derivative trade. It supports correct sizing and valuation.

Tag 880: TrdMatchID
Tag 880 (TrdMatchID) is a unique identifier assigned by a matching system to confirm a trade match. It supports affirmation and clearing.

Tag 881: SecondaryTradeReportRefID
Tag 881 (SecondaryTradeReportRefID) references a prior trade report for cancellation or replacement. It supports lifecycle management.

Tag 882: UnderlyingDirtyPrice
Tag 882 (UnderlyingDirtyPrice) is the full price of the underlying bond, including accrued interest. It supports accurate valuation.

Tag 883: UnderlyingEndPrice
Tag 883 (UnderlyingEndPrice) is the final price of the underlying at expiration. It supports derivative settlement.

Tag 884: UnderlyingStartValue
Tag 884 (UnderlyingStartValue) is the initial value of the underlying in a structured product. It supports performance tracking.

Tag 885: UnderlyingCurrentValue
Tag 885 (UnderlyingCurrentValue) is the current market value of the underlying. It supports risk and P&L calculations.

Tag 886: UnderlyingEndValue
Tag 886 (UnderlyingEndValue) is the final value of the underlying at maturity. It supports payoff calculation.

Tag 887: NoUnderlyingStips
Tag 887 (NoUnderlyingStips) specifies the number of stipulations for the underlying. It defines the repeating group size.

Tag 888: UnderlyingStipType
Tag 888 (UnderlyingStipType) specifies the type of underlying stipulation: Maturity (1), Coupon Range (2). It supports customized terms.

Tag 889: UnderlyingStipValue
Tag 889 (UnderlyingStipValue) is the value of an underlying stipulation. It defines specific requirements.

Tag 890: MaturityNetMoney
Tag 890 (MaturityNetMoney) is the net cash flow at maturity of a security. It supports settlement and accounting.

Tag 891: MiscFeeBasis
Tag 891 (MiscFeeBasis) specifies how a miscellaneous fee is calculated: Absolute (0), Percentage (1). It supports accurate cost reporting.

Tag 892: TotNoAllocs
Tag 892 (TotNoAllocs) specifies the total number of allocation blocks in a multi-message sequence. It supports reconciliation.

Tag 893: LastFragment
Tag 893 (LastFragment) indicates whether a message is the last in a sequence (Y/N). It supports message assembly.

Tag 894: CollReqID
Tag 894 (CollReqID) is a unique ID for a Collateral Request. It supports tracking and response linkage.

Tag 895: CollAsgnReason
Tag 895 (CollAsgnReason) specifies why collateral is assigned: Initial (0), Variation (1). It supports margin workflows.

Tag 896: CollInquiryQualifier
Tag 896 (CollInquiryQualifier) specifies the scope of a collateral inquiry: Specific (0), All (1). It controls response content.

Tag 897: NoTrades
Tag 897 (NoTrades) specifies the number of trades in a repeating group. It defines how many times TrdMatchID (Tag 880) repeats.

Tag 898: MarginRatio
Tag 898 (MarginRatio) is the ratio of margin to total exposure. It supports margin monitoring and calls.

Tag 899: MarginExcess
Tag 899 (MarginExcess) is the surplus margin above the required amount. It supports credit and risk assessment.

Tag 900: TotalNetValue
Tag 900 (TotalNetValue) is the net value of a portfolio or collateral pool. It supports margin and clearing.

Tag 901: CashOutstanding
Tag 901 (CashOutstanding) is the amount of cash owed or due. It supports settlement and accounting.

Tag 902: CollAsgnID
Tag 902 (CollAsgnID) is a unique ID for a Collateral Assignment. It supports tracking and reconciliation.

Tag 903: CollAsgnTransType
Tag 903 (CollAsgnTransType) specifies the type of collateral assignment: New (0), Replace (1). It controls lifecycle.

Tag 904: CollRespID
Tag 904 (CollRespID) is a unique ID for a Collateral Response. It supports message linkage.

Tag 905: CollAsgnRespType
Tag 905 (CollAsgnRespType) specifies the response type: Received (0), Accepted (1). It supports workflow.

Tag 906: CollAsgnRejectReason
Tag 906 (CollAsgnRejectReason) specifies why a collateral assignment was rejected. It supports troubleshooting.

Tag 907: CollAsgnRefID
Tag 907 (CollAsgnRefID) references a prior collateral assignment. It supports lifecycle management.

Tag 908: CollRptID
Tag 908 (CollRptID) is a unique ID for a Collateral Report. It supports auditability.

Tag 909: CollInquiryID
Tag 909 (CollInquiryID) is a unique ID for a Collateral Inquiry. It supports tracking.

Tag 910: CollStatus
Tag 910 (CollStatus) indicates the status of a collateral assignment: Received (0), Accepted (1). It supports processing.

Tag 911: TotNumReports
Tag 911 (TotNumReports) specifies the total number of reports in a sequence. It supports reconciliation.

Tag 912: LastRptRequested
Tag 912 (LastRptRequested) indicates if the last report in a sequence was requested (Y/N). It supports completeness.

Tag 913: AgreementDesc
Tag 913 (AgreementDesc) is a description of a legal agreement, such as an ISDA. It supports documentation.

Tag 914: AgreementID
Tag 914 (AgreementID) is a unique identifier for a legal agreement. It supports referencing.

Tag 915: AgreementDate
Tag 915 (AgreementDate) is the date a legal agreement was signed. It supports compliance.

Tag 916: StartDate
Tag 916 (StartDate) is the effective start date of an agreement or trade. It supports lifecycle tracking.

Tag 917: EndDate
Tag 917 (EndDate) is the termination date of an agreement or trade. It supports maturity handling.

Tag 918: AgreementCurrency
Tag 918 (AgreementCurrency) is the currency of a legal agreement. It supports accurate settlement.

Tag 919: DeliveryType
Tag 919 (DeliveryType) specifies the delivery method: Physical (1), Cash (2). It supports settlement.

Tag 920: EndAccruedInterestAmt
Tag 920 (EndAccruedInterestAmt) is the accrued interest at maturity. It supports final settlement.

Tag 921: StartCash
Tag 921 (StartCash) is the initial cash balance in a collateral or financing arrangement. It supports accounting.

Tag 922: EndCash
Tag 922 (EndCash) is the final cash balance. It supports reconciliation and settlement.

Tag 923: UserRequestID
Tag 923 (UserRequestID) is a unique ID for a user-related request, such as password change. It supports tracking.

Tag 924: UserRequestType
Tag 924 (UserRequestType) specifies the type of user request: New (1), Password Change (2). It controls processing.

Tag 925: NewPassword
Tag 925 (NewPassword) is the new password in a password change request. It supports authentication updates.

Tag 926: UserStatus
Tag 926 (UserStatus) indicates the status of a user: Logged In (1), Logged Out (2). It supports access control.

Tag 927: UserStatusText
Tag 927 (UserStatusText) provides free-text details about user status. It supports communication.

Tag 928: StatusValue
Tag 928 (StatusValue) is a coded status value. It supports standardized status reporting.

Tag 929: StatusText
Tag 929 (StatusText) provides free-text status details. It supports clarity.

Tag 930: RefCompID
Tag 930 (RefCompID) references a counterparty in a network message. It supports routing.

Tag 931: RefSubID
Tag 931 (RefSubID) references a sub-entity within a counterparty. It supports granular identification.

Tag 932: NetworkResponseID
Tag 932 (NetworkResponseID) is a unique ID for a network response. It supports message tracking.

Tag 933: NetworkRequestID
Tag 933 (NetworkRequestID) is a unique ID for a network request. It supports correlation.

Tag 934: LastNetworkResponseID
Tag 934 (LastNetworkResponseID) references the last network response. It supports sequencing.

Tag 935: NetworkRequestType
Tag 935 (NetworkRequestType) specifies the type of network request: Broadcast (1), Directed (2). It controls delivery.

Tag 936: NoCompIDs
Tag 936 (NoCompIDs) specifies the number of company IDs in a repeating group. It supports multi-entity messaging.

Tag 937: NetworkStatusResponseType
Tag 937 (NetworkStatusResponseType) specifies the type of network status: Full (1), Incremental (2). It controls updates.

Tag 938: NoCollInquiryQualifier
Tag 938 (NoCollInquiryQualifier) specifies the number of collateral inquiry qualifiers. It defines the group size.

Tag 939: TrdRptStatus
Tag 939 (TrdRptStatus) indicates the status of a trade report: Accepted (0), Rejected (1). It supports compliance.

Tag 940: AffirmStatus
Tag 940 (AffirmStatus) indicates the affirmation status: Received (1), Accepted (2). It supports trade matching.

Tag 941: UnderlyingStrikeCurrency
Tag 941 (UnderlyingStrikeCurrency) is the currency of the strike price of the underlying in a multi-currency option. It supports accurate valuation.

Tag 942: LegStrikeCurrency
Tag 942 (LegStrikeCurrency) is the currency of the strike price for an option leg. It supports multi-currency derivatives.

Tag 943: TimeBracket
Tag 943 (TimeBracket) specifies a time interval for reporting or aggregation, such as “09:00-10:00”. It supports time-based analysis.

Tag 944: CollAction
Tag 944 (CollAction) specifies the action on collateral: Add (1), Remove (2). It controls margin workflows.

Tag 945: CollInquiryStatus
Tag 945 (CollInquiryStatus) indicates the status of a collateral inquiry: Accepted (0), Rejected (1). It supports feedback.

Tag 946: CollInquiryResult
Tag 946 (CollInquiryResult) specifies the result of a collateral inquiry: Success (0), Invalid (1). It supports troubleshooting.

Tag 947: StrikeCurrency
Tag 947 (StrikeCurrency) is the currency in which the strike price is denominated. It supports cross-currency options.

Tag 948: NoNested3PartyIDs
Tag 948 (NoNested3PartyIDs) specifies the number of third-level nested parties. It supports deep hierarchy tracking.

Tag 949: Nested3PartyID
Tag 949 (Nested3PartyID) identifies a party in a third-level nested group. It supports multi-tier routing.

Tag 950: Nested3PartyIDSource
Tag 950 (Nested3PartyIDSource) specifies the namespace of Nested3PartyID. It ensures correct identification.

Tag 951: Nested3PartyRole
Tag 951 (Nested3PartyRole) specifies the role of a third-level nested party. It supports detailed attribution.

Tag 952: NoNested3PartySubIDs
Tag 952 (NoNested3PartySubIDs) specifies the number of sub-IDs for a third-level nested party. It enhances granularity.

Tag 953: Nested3PartySubID
Tag 953 (Nested3PartySubID) is a sub-identifier for a third-level nested party. It supports detailed tracking.

Tag 954: Nested3PartySubIDType
Tag 954 (Nested3PartySubIDType) specifies the type of Nested3PartySubID. It ensures correct interpretation.

Tag 955: LegContractSettlMonth
Tag 955 (LegContractSettlMonth) is the settlement month of a futures or options leg in YYYYMM format. It supports accurate contract mapping.

Tag 956: LegInterestAccrualDate
Tag 956 (LegInterestAccrualDate) is the date interest begins to accrue on a bond leg. It supports accurate yield and pricing calculations.

Explore More

FIX Protocol > FIX tag 46 meaning RelatdSym in FIX Standard

There’s a significant aspect of the FIX Protocol that every trader and financial analyst should grasp, particularly when it comes to FIX tag 46. This tag represents the RelatdSym, which plays an important role in conveying information about related financial instruments within your trading strategies and transactions. In the context

FIX Protocol > FIX tag 1 meaning Account in FIX Standard. What is FIX tag 1 Acct in FIX Dictionary? How is it used in trading? What FIX messages use FIX tag 1?

Just as you navigate the world of electronic trading, understanding the FIX Protocol and its components becomes crucial. In this post, you will explore FIX tag 1, which represents the Account field in the FIX Standard. We’ll examine into what FIX tag 1 signifies in the FIX Dictionary, its applications

FIX Protocol > FIX tag 66 meaning ListID in FIX Standard

Just like any other communication protocol used in trading, understanding the FIX Protocol is necessary for anyone involved in electronic trading. Within this framework, FIX tag 66, also known as ListID, serves a pivotal role in the exchange of information between trading parties. Let’s investigate into what FIX tag 66

FIX Tag Reference: Professional Guide to FIX 4.4 Protocol Tags

Oh hi there
It’s nice to meet you.

Sign up to get access and receive our gift: FIX Standard introductory book.

Explore More

FIX Protocol > FIX tag 46 meaning RelatdSym in FIX Standard

FIX Protocol > FIX tag 1 meaning Account in FIX Standard. What is FIX tag 1 Acct in FIX Dictionary? How is it used in trading? What FIX messages use FIX tag 1?

FIX Protocol > FIX tag 66 meaning ListID in FIX Standard

Recent Fin-Tech Articles

Categories

FIX Tag Reference: Professional Guide to FIX 4.4 Protocol Tags

Oh hi there It’s nice to meet you.

Sign up to get access and receive our gift: FIX Standard introductory book.

Explore More

FIX Protocol > FIX tag 46 meaning RelatdSym in FIX Standard

FIX Protocol > FIX tag 1 meaning Account in FIX Standard. What is FIX tag 1 Acct in FIX Dictionary? How is it used in trading? What FIX messages use FIX tag 1?

FIX Protocol > FIX tag 66 meaning ListID in FIX Standard

Recent Fin-Tech Articles

Categories

Oh hi there
It’s nice to meet you.