FIX 4.2 Standard FIX Tags

Tag 1 (Account)

Description: Account number or identifier.
The Account (1) tag specifies the client’s account identifier used for order routing and position management. In FIX 4.2 environments, this alphanumeric field is critical for proper order allocation, especially in prime brokerage relationships where multiple sub-accounts may trade through a single clearing entity. Trading professionals must ensure accurate account mapping during onboarding, as mismatches can lead to regulatory violations or position errors. While not mandatory for all order types, it’s required for institutional trading and often used for commission calculation, tax treatment, and regulatory reporting. Best practice dictates validating account numbers against counterparty’s approved list before order submission.

Tag 2 (AdvId)

Description: Identifier for an advertisement message.
AdvId (2) serves as the unique reference for advertisement messages (MsgType=l), which communicate trading interest in non-order-book markets. This identifier enables tracking and referencing of advertising activity across multiple messages, allowing counterparties to respond to specific advertisements. In FIX 4.2, AdvId must be unique per advertising session and is critical for maintaining the integrity of the advertisement lifecycle. Trading professionals working in block trading or dark pool environments rely on this tag to correlate IOIs with subsequent executions, though its usage has diminished with the rise of electronic order book trading.

Tag 3 (AdvRefID)

Description: Reference identifier for an advertisement message.
AdvRefID (3) provides a cross-reference to a previously sent advertisement message, creating a chain of related advertising activity. When used in conjunction with AdvId, it enables sophisticated advertising workflows where multiple advertisements build upon or modify previous ones. In FIX 4.2 implementations, this tag is essential for maintaining context in complex advertising sequences, particularly in institutional block trading scenarios. Trading professionals must track these references carefully to avoid processing advertisements out of sequence, which could lead to misinterpretation of trading interest.

Tag 4 (AdvSide)

Description: Side of the market for an advertisement.
AdvSide (4) specifies the trading side (buy, sell, or cross) associated with an advertisement message. The tag uses single-character codes: B=Buy, S=Sell, X=Cross. In FIX 4.2, this field is mandatory for advertisement messages and directly impacts how counterparties interpret the advertising party’s intent. Trading professionals must ensure accurate side designation, as errors can lead to inappropriate matching or regulatory issues. The cross (X) designation is particularly important for block traders seeking anonymity while indicating willingness to both buy and sell.

Tag 5 (AdvTransType)

Description: Type of advertisement transaction.
AdvTransType (5) defines the action being taken on an advertisement: N=New, C=Cancel, R=Replace. This critical tag governs the lifecycle of advertisement messages in FIX 4.2, determining whether a message initiates new interest, withdraws existing interest, or modifies previous terms. Trading professionals must implement robust state management to handle these transitions correctly, as improper sequencing (e.g., replacing a non-existent advertisement) will trigger rejections. The replace functionality is particularly valuable for updating price or size without creating new advertisement identifiers.

Tag 6 (AvgPx)

Description: Average price of executed shares.
AvgPx (6) represents the calculated average execution price for an order or allocation, derived from total value divided by total quantity. In FIX 4.2, this field appears in ExecutionReports (MsgType=8) and Allocation instructions (MsgType=J), serving as the definitive price for settlement and P&L calculations. Trading professionals rely on this value for accurate position valuation, especially for orders that fill in multiple increments. Precision considerations are critical—most implementations use 8 decimal places to prevent rounding errors in high-value instruments. Discrepancies between reported AvgPx and calculated values are a common source of reconciliation breaks.

Tag 7 (BeginSeqNo)

Description: Starting sequence number for a range of messages.
BeginSeqNo (7) specifies the first message sequence number in a range request, primarily used in resend requests (MsgType=2). In FIX 4.2, this tag works with EndSeqNo to define the exact subset of messages requiring retransmission. Trading professionals must implement precise sequence number tracking to generate accurate resend requests during communication interruptions. Incorrect BeginSeqNo values can lead to unnecessary message floods or gaps in message recovery. This tag is foundational to FIX’s reliable message delivery mechanism, ensuring no orders or executions are lost during network disruptions.

Tag 8 (BeginString)

Description: Identifies the FIX protocol version being used.
BeginString (8) serves as the foundational identifier in every FIX message, specifying the exact protocol version in use. In FIX 4.2 environments, this tag must appear as “FIX.4.2” (case-sensitive) as the very first field in the message header. This seemingly simple tag is critically important as it determines how the entire message will be parsed and validated by the receiving system. A mismatch in BeginString values between counterparties will immediately terminate the session, making this the first diagnostic point when connectivity issues arise. Trading professionals must ensure their systems correctly identify and respond to this version indicator, as attempting to process FIX 4.2 messages with a FIX 5.0+ dictionary (or vice versa) will cause systematic field interpretation errors.

Tag 9 (BodyLength)

Description: Length of message body, measured in bytes.
BodyLength (9) specifies the byte count from after the BodyLength field to the beginning of the CheckSum field. In FIX 4.2, this numeric tag is critical for proper message parsing, allowing the receiver to determine where the message ends before checksum validation. Trading professionals working at the protocol level must ensure accurate calculation of this value, as errors prevent proper message interpretation. While most FIX engines handle this automatically, understanding its function is essential for debugging raw message streams and developing custom parsers. Incorrect BodyLength values are a common cause of “invalid message format” errors during connectivity setup.

Tag 10 (CheckSum)

Description: Three-digit numeric checksum.
CheckSum (10) provides a basic error-detection mechanism through a three-digit numeric value calculated from the sum of all bytes between the Start of Heading and the CheckSum field itself. In FIX 4.2, this tag serves as the final field in every message and is mandatory for protocol integrity. Trading professionals rely on checksum validation to detect transmission errors, though it’s not foolproof against certain error patterns. Systems must recalculate and verify this value for every incoming message, rejecting those with invalid checksums. While modern networks have reduced transmission errors, checksum validation remains a critical first line of defense against corrupted messages.

Tag 11 (ClOrdID)

Description: Unique identifier for an order assigned by the client.
ClOrdID (11) represents the cornerstone of order lifecycle management in FIX 4.2, serving as the unique client-assigned identifier for each order. This alphanumeric string must be unique within a trading session and is used to track orders from submission through execution, modification, and cancellation. Trading professionals rely on ClOrdID for reconciliation, troubleshooting, and state management—it’s the primary key that connects NewOrderSingle messages with subsequent ExecutionReports and OrderCancelRequests. Critical considerations include: maintaining strict uniqueness per session (duplicates trigger rejection), proper handling during session resets, and the nuanced relationship with OrigClOrdID during cancel/replace workflows. In high-frequency environments, ClOrdID generation strategies must balance uniqueness requirements with performance constraints.

Tag 12 (Commission)

Description: Commission amount.
Commission (12) specifies the monetary value of commission associated with an order execution. In FIX 4.2, this numeric field appears in ExecutionReports and Allocation instructions, supporting both explicit commission reporting and net-of-commission pricing models. Trading professionals use this value for accurate cost accounting, particularly in institutional brokerage relationships where commission structures may be complex. The field requires careful handling of currency conversion when dealing with cross-border trades. Regulatory requirements (such as MiFID II) often mandate precise commission reporting, making accurate transmission of this value essential for compliance.

Tag 13 (CommType)

Description: Type of commission.
CommType (13) defines the commission structure using single-character codes: 1=per share, 2=percentage, 3=absolute, 4=10 basis points, etc. In FIX 4.2, this tag works with Commission to properly interpret the commission amount. Trading professionals must ensure consistent interpretation of these codes between counterparties, as mismatches can lead to billing disputes. The tag is particularly important in multi-asset environments where different commission structures apply to different instrument types. Proper handling requires maintaining a reference table of CommType values and their business meanings.

Tag 14 (CumQty)

Description: Total quantity filled.
CumQty (14) represents the cumulative number of shares or contracts that have been filled for an order. In FIX 4.2, this numeric field is critical for tracking order progress in ExecutionReports, updating with each partial fill. Trading professionals rely on CumQty for real-time position management and to calculate remaining quantity (OrderQty – CumQty). The field must increment monotonically—decreases indicate protocol violations. In high-frequency trading environments, precise CumQty tracking is essential for accurate risk management, as stale or incorrect values could lead to unintended overexposure.

Tag 15 (Currency)

Description: Currency for the order or quote.
Currency (15) specifies the three-letter ISO currency code (e.g., USD, EUR, JPY) for the financial instrument or transaction. In FIX 4.2, this tag is critical for multi-currency operations, appearing in order messages, execution reports, and market data. Trading professionals must ensure accurate currency designation to prevent costly settlement errors, particularly for cross-listed securities or forex-related products. The field impacts price interpretation, commission calculation, and regulatory reporting. Systems must validate against ISO 4217 standards and handle currency conversion appropriately when required.

Tag 16 (EndSeqNo)

Description: Ending sequence number for a range of messages.
EndSeqNo (16) specifies the last message sequence number in a range request, working with BeginSeqNo to define message subsets for resend requests. In FIX 4.2, setting EndSeqNo=0 requests all messages from BeginSeqNo to the current sequence number. Trading professionals use this mechanism during session recovery to efficiently retrieve missing messages after connectivity interruptions. Incorrect EndSeqNo values can cause unnecessary message floods or incomplete recovery. This tag is fundamental to FIX’s reliable message delivery, ensuring no critical order or execution information is lost during network disruptions.

Tag 17 (ExecID)

Description: Unique identifier for an execution report.
ExecID (17) serves as the unique identifier assigned by the sell-side for each execution event or status update. In FIX 4.2, this alphanumeric field appears in all ExecutionReports (MsgType=8) and is critical for tracking the sequence of events related to an order. Trading professionals use ExecID to correlate multiple reports for the same order, ensuring proper state transitions (e.g., from NEW to PARTIALLY FILLED to FILLED). The identifier must be unique per execution venue and is essential for reconciliation processes. Systems must maintain ExecID history to prevent duplicate processing of execution reports.

Tag 18 (ExecInst)

Description: Execution instructions.
ExecInst (18) specifies special handling instructions for order execution using a string of single-character codes (e.g., “L”=not held, “M”=work, “6”=strict limit). In FIX 4.2, this field enables sophisticated order routing behavior, allowing clients to express preferences regarding how their orders should be handled. Trading professionals must understand the specific meaning of each code as implemented by their counterparties, as interpretations can vary. The tag is particularly important for algorithmic trading strategies that require precise control over order handling. Proper validation requires maintaining a reference of supported execution instructions for each trading venue.

Tag 19 (ExecRefID)

Description: Reference identifier for an execution report.
ExecRefID (19) provides a link back to a previous execution report, creating a chain of related execution events. In FIX 4.2, this tag appears in subsequent ExecutionReports to reference the original execution that triggered the current event (e.g., a fill report referencing the initial order acceptance). Trading professionals use this field to reconstruct the complete execution history for an order, which is critical for accurate position management and reconciliation. Systems must maintain proper references to avoid broken execution chains that could lead to position discrepancies.

Tag 20 (ExecTransType)

Description: Type of execution report.
ExecTransType (20) defines the nature of the execution report using single-character codes: 0=New, 1=Cancel, 2=Correct, 3=Status. In FIX 4.2, this tag indicates whether the report represents a new execution, cancellation of a previous report, correction of an error, or unsolicited status update. Trading professionals must implement appropriate handling for each type—particularly distinguishing between genuine cancellations and corrections. The status type (3) is often used for manual interventions or system-generated updates. Proper interpretation prevents erroneous state transitions in order management systems.

Tag 21 (HandlInst)

Description: Instructions for order handling.
HandlInst (21) specifies how the broker should handle the order using single-character codes: 1=Auto, 2=Auto/Intervention, 3=Manual. In FIX 4.2, this critical field determines the level of automation versus human oversight applied to order routing. Trading professionals use this to express their preference for automated execution (typical for algorithmic strategies) versus manual handling (for complex or large orders). The tag impacts regulatory requirements, as certain order types may require human intervention. Systems must validate against supported handling instructions for each counterparty, as not all venues support all options.

Tag 22 (IDSource)

Description: Source of security identifier.
IDSource (22) specifies the methodology used to identify a security, using codes like CUSIP, SEDOL, ISIN, or exchange symbol. In FIX 4.2, this tag is critical for unambiguous security identification, particularly for cross-border trading where multiple identifier systems coexist. Trading professionals must ensure consistent mapping between identifier types and maintain reference data to translate between systems. The tag appears in security definition requests and order messages, preventing misidentification of instruments. Proper handling requires maintaining a reference table of IDSource codes and their business meanings.

Tag 23 (IOIid)

Description: Identifier for an indication of interest.
IOIid (23) serves as the unique reference for Indications of Interest (IOIs), which communicate trading interest without creating firm orders. In FIX 4.2, this identifier enables tracking and referencing of IOIs across multiple messages, allowing counterparties to respond to specific indications. Trading professionals working in block trading or dark pool environments rely on this tag to correlate IOIs with subsequent executions, though its usage has diminished with the rise of electronic order book trading. The identifier must be unique per session to maintain IOI integrity.

Tag 24 (IOIOthSvc)

Description: No longer used.
IOIOthSvc (24) was previously used to indicate other services related to Indications of Interest but has been deprecated in FIX 4.2 and later versions. Modern implementations should not use this tag, and systems should ignore it if encountered. Trading professionals should be aware of this deprecated field to avoid confusion during message analysis, but no active handling is required. The presence of this tag in messages typically indicates legacy system usage or improper message construction.

Tag 25 (IOIQltyInd)

Description: Quality of indication.
IOIQltyInd (25) specifies the quality or reliability of an Indication of Interest using single-character codes like “H”=high, “L”=low, or “M”=medium. In FIX 4.2, this tag provides context for how seriously counterparties should treat an IOI. Trading professionals use this information to prioritize responses to indications, with high-quality IOIs typically receiving more immediate attention. The interpretation of quality levels may vary between institutions, requiring clear communication of expectations during connectivity setup.

Tag 26 (IOIRefID)

Description: Reference identifier for an IOI.
IOIRefID (26) provides a cross-reference to a previously sent Indication of Interest, creating a chain of related IOI activity. In FIX 4.2, this tag enables sophisticated IOI workflows where multiple indications build upon or modify previous ones. Trading professionals must track these references carefully to avoid processing IOIs out of sequence, which could lead to misinterpretation of trading interest. The reference mechanism is particularly valuable for updating price or size without creating new IOI identifiers.

Tag 27 (IOIShares)

Description: Number of shares in an IOI.
IOIShares (27) specifies the quantity of shares indicated in an Indication of Interest. In FIX 4.2, this numeric field defines the scale of trading interest being communicated, using standard quantity conventions. Trading professionals rely on this value to assess the significance of an IOI and determine appropriate response strategies. The field must be validated against minimum and maximum quantity rules for the specific instrument. Systems should handle fractional shares appropriately where supported by the trading venue.

Tag 28 (IOITransType)

Description: Type of IOI transaction.
IOITransType (28) defines the action being taken on an IOI: N=New, C=Cancel, R=Replace. In FIX 4.2, this tag governs the lifecycle of IOI messages, determining whether a message initiates new interest, withdraws existing interest, or modifies previous terms. Trading professionals must implement robust state management to handle these transitions correctly, as improper sequencing will trigger rejections. The replace functionality is particularly valuable for updating price or size without creating new IOI identifiers.

Tag 29 (LastCapacity)

Description: Capacity of the last agent.
LastCapacity (29) specifies the role of the agent in the last trade using codes like 1=Agent, 2=Principal, 3=Riskless Principal. In FIX 4.2, this tag provides transparency into the nature of the counterparty in a transaction, which has regulatory and compliance implications. Trading professionals use this information for proper trade reporting, particularly under regulations like MiFID II that require disclosure of trade capacity. The field must be validated against supported capacity types for each instrument and venue.

Tag 30 (LastMkt)

Description: Market of the last trade.
LastMkt (30) identifies the trading venue where the most recent transaction occurred, using exchange codes like NYSE, NASDAQ, or XPAR. In FIX 4.2, this tag provides context for execution quality analysis and best execution compliance. Trading professionals rely on accurate LastMkt reporting to assess routing effectiveness and meet regulatory requirements for trade transparency. The field must conform to standard exchange code conventions, requiring proper mapping between internal and external exchange identifiers.

Tag 31 (LastPx)

Description: Price of the last trade.
LastPx (31) specifies the price at which the most recent transaction occurred. In FIX 4.2, this numeric field is critical for execution quality assessment, position valuation, and mark-to-market calculations. Trading professionals use LastPx to evaluate fill quality against benchmarks and to update position values in real-time. Precision considerations are paramount—most implementations use 8 decimal places to prevent rounding errors in high-value instruments. The field appears in ExecutionReports for fill events and in market data messages.

Tag 32 (LastShares)

Description: Quantity of the last trade.
LastShares (32) indicates the number of shares or contracts executed in the most recent transaction. In FIX 4.2, this numeric field works with LastPx to define the complete fill details. Trading professionals rely on accurate LastShares reporting for position updates, trade reconciliation, and commission calculations. The field must increment CumQty appropriately and update LeavesQty accordingly. Systems should handle fractional shares where supported by the trading venue.

Tag 33 (LinesOfText)

Description: Number of lines in text message.
LinesOfText (33) specifies the count of text lines following in a message, primarily used in News (MsgType=B) and Email (MsgType=C) messages. In FIX 4.2, this tag enables proper parsing of multi-line textual content by indicating how many Text fields to expect. Trading professionals working with news feeds or compliance communications must ensure accurate line counting to prevent message truncation or misinterpretation. While less critical for order execution workflows, this tag remains important for regulatory communication channels.

Tag 34 (MsgSeqNum)

Description: Message sequence number.
MsgSeqNum (34) serves as the sequential identifier for messages within a FIX session, incrementing with each transmitted message. In FIX 4.2, this numeric tag is fundamental to the protocol’s reliability mechanism, enabling detection of missing or out-of-order messages. Trading professionals monitor sequence numbers closely during connectivity issues, as gaps indicate potential message loss. Systems must validate incoming sequence numbers against expected values and initiate resend requests when necessary. Proper sequence management is critical for maintaining order integrity during network disruptions.

Tag 35 (MsgType)

Description: Message type.
MsgType (35) defines the specific type of FIX message using standardized codes like D=NewOrderSingle, 8=ExecutionReport, or 0=Heartbeat. In FIX 4.2, this single-character or multi-character tag determines how the entire message should be parsed and processed. Trading professionals rely on accurate MsgType identification to route messages to the appropriate handling logic. The tag must conform to the FIX specification, with invalid types triggering immediate rejection. Systems must maintain a comprehensive mapping of MsgType codes to their business meanings.

Tag 36 (NewSeqNo)

Description: New sequence number after a gap fill.
NewSeqNo (36) specifies the next expected sequence number following a gap fill or sequence reset. In FIX 4.2, this tag appears in SequenceReset messages (MsgType=4) to synchronize sequence numbers between counterparties after a resend request or session reset. Trading professionals use this mechanism to recover from connectivity interruptions without losing message integrity. The value must be validated against the current sequence state to prevent accidental skipping of messages. Proper handling is critical for maintaining continuous trading operations during network disruptions.

Tag 37 (OrderID)

Description: Unique identifier for an order assigned by the sell-side.
OrderID (37) represents the exchange or broker-assigned unique identifier for an order, distinct from the client’s ClOrdID. In FIX 4.2, this alphanumeric field appears in ExecutionReports following order acceptance and serves as the authoritative reference for the order’s existence on the sell-side system. Trading professionals use OrderID for precise order tracking when ClOrdID alone is insufficient (such as after order modifications), and it’s mandatory when referencing orders in cancel/replace requests. Unlike ClOrdID, OrderID remains constant throughout the order’s lifecycle on the exchange.

Tag 38 (OrderQty)

Description: Quantity ordered.
OrderQty (38) specifies the total number of shares or contracts in an order. In FIX 4.2, this numeric field is mandatory for most order types and serves as the baseline for execution reporting (CumQty, LeavesQty). Trading professionals must ensure accurate quantity specification, as errors can lead to significant position mismatches. The field supports fractional shares where permitted by the trading venue, requiring proper precision handling. Systems should validate against minimum and maximum quantity rules for each instrument.

Tag 39 (OrdStatus)

Description: Order status.
OrdStatus (39) indicates the current state of an order using single-character codes: 0=New, 1=Partially Filled, 2=Filled, 4=Cancelled, etc. In FIX 4.2, this critical tag provides the definitive status for order management systems, driving state transitions and business logic. Trading professionals rely on accurate status reporting for position management, risk control, and reconciliation. The field must align with ExecType values in ExecutionReports, with specific status transitions permitted by the protocol. Misreported statuses are a common source of reconciliation breaks.

Tag 40 (OrdType)

Description: Order type.
OrdType (40) specifies the order type using single-character codes: 1=Market, 2=Limit, 3=Stop, 4=Stop Limit. In FIX 4.2, this fundamental tag determines how the order will be handled by the exchange’s matching engine. Trading professionals must ensure correct type specification, as mismatches between order type and associated fields (e.g., Price for Limit orders) trigger immediate rejection. The tag impacts execution behavior, risk parameters, and regulatory reporting requirements. Systems must validate order types against venue-specific capabilities.

Tag 41 (OrigClOrdID)

Description: Original ClOrdID for cancel/replace requests.
OrigClOrdID (41) references the ClOrdID of the original order being modified in cancel/replace requests. In FIX 4.2, this tag is mandatory for OrderCancelRequest (MsgType=F) and OrderCancelReplaceRequest (MsgType=G) messages. Trading professionals must ensure accurate OrigClOrdID specification, as errors prevent proper order modification. The field creates the critical link between new cancel/replace requests and the original order, enabling proper state management. Systems must validate that OrigClOrdID references an active order.

Tag 42 (OrigTime)

Description: Time of the original request.
OrigTime (42) specifies the timestamp of the original message being referenced, typically used in resend requests or corrections. In FIX 4.2, this tag provides temporal context for message relationships, helping systems determine the sequence of events. Trading professionals use this information for audit trails and to resolve timing ambiguities during reconciliation. The timestamp must conform to FIX datetime format (YYYYMMDD-HH:MM:SS.sss) and be validated against session time windows.

Tag 43 (PossDupFlag)

Description: Indicates possible duplicate message.
PossDupFlag (43) signals that a message may be a duplicate, set to ‘Y’ when resending messages after a gap fill. In FIX 4.2, this critical flag requires careful handling—receiving systems must check against processed messages rather than rejecting outright. Trading professionals must implement robust duplicate detection logic based on ClOrdID and MsgSeqNum, as improper handling can cause order processing errors. The flag is essential for reliable message delivery during network interruptions but is often misinterpreted by naive implementations.

Tag 44 (Price)

Description: Price of the order.
Price (44) specifies the limit price for limit orders or stop price for stop orders. In FIX 4.2, this numeric field is mandatory for order types requiring a price (Limit, Stop, Stop Limit) and must be validated against venue-specific price rules. Trading professionals rely on precise price specification for accurate execution, with rounding errors potentially causing order rejection. The field requires careful handling of price precision rules for each instrument, typically supporting 8 decimal places. Systems must validate price direction relative to market conditions.

Tag 45 (RefSeqNum)

Description: Reference message sequence number.
RefSeqNum (45) references the sequence number of a previous message, used in reject messages to identify the problematic message. In FIX 4.2, this numeric tag creates the critical link between reject notifications and the original message that caused the issue. Trading professionals use this information to diagnose and correct message errors efficiently. The field must reference a valid sequence number within the current session window. Systems should maintain message history to support proper reference handling.

Tag 46 (RelatdSym)

Description: Related symbol.
RelatdSym (46) specifies a symbol related to the primary instrument, often used for multi-leg strategies or spread trading. In FIX 4.2, this tag enables complex order routing where multiple instruments are involved in a single strategy. Trading professionals use this field to express relationships between instruments in algorithmic trading strategies. The tag requires proper security definition handling to ensure correct instrument identification. Systems must validate related symbols against supported strategy components.

Tag 47 (Rule80A)

Description: Order capacity (formerly Rule 80A).
Rule80A (47) specifies the order capacity using codes like A=Agency, G=Principal, I=Individual. In FIX 4.2, this tag (formerly tied to NYSE Rule 80A) provides regulatory context for order execution, impacting how orders are handled during market volatility. Trading professionals must ensure accurate capacity designation to comply with exchange rules and regulatory requirements. The field is particularly important for institutional versus retail order differentiation. Systems should validate against supported capacity types for each venue.

Tag 48 (SecurityID)

Description: Security identifier.
SecurityID (48) provides the actual identifier value corresponding to the IDSource specification. In FIX 4.2, this alphanumeric field works with IDSource (22) to unambiguously identify financial instruments. Trading professionals rely on accurate SecurityID mapping to prevent instrument misidentification, which could lead to catastrophic execution errors. The field requires robust reference data management to translate between different identifier systems. Systems must validate SecurityID format against IDSource rules.

Tag 49 (SenderCompID)

Description: Sender company ID.
SenderCompID (49) identifies the sending application or firm in the FIX session. In FIX 4.2, this alphanumeric tag is critical for message routing and authentication, appearing in every message header. Trading professionals must ensure accurate SenderCompID configuration during connectivity setup, as mismatches prevent session establishment. The identifier typically corresponds to a pre-negotiated value in connectivity agreements. Systems should validate incoming SenderCompID against approved counterparties.

Tag 50 (SenderSubID)

Description: Sender sub-entity ID.
SenderSubID (50) provides additional identification for sub-components within the sending firm, such as specific trading desks or applications. In FIX 4.2, this optional tag enables more granular message routing and auditing within complex organizations. Trading professionals use this field to distinguish between multiple logical senders operating through a single physical connection. The identifier should follow organizational naming conventions and be documented in connectivity agreements. Systems may use this for access control or message filtering.

Tag 51 (SendingTime)

Description: No longer used.
SendingTime (51) was previously used for message timestamping but has been superseded by TransactTime (60) in FIX 4.2. Modern implementations should not use this tag, and systems should ignore it if encountered. Trading professionals should be aware of this deprecated field to avoid confusion during message analysis, but no active handling is required. The presence of this tag typically indicates legacy system usage.

Tag 52 (TransactTime)

Description: Transaction time.
TransactTime (60) specifies the exact UTC timestamp when the business transaction occurred. In FIX 4.2, this mandatory tag provides the authoritative time for order submission, execution, and other critical events. Trading professionals rely on precise TransactTime for best execution analysis, trade reconstruction, and regulatory reporting. The timestamp must conform to FIX datetime format (YYYYMMDD-HH:MM:SS.sss) and be synchronized to UTC with millisecond precision. Systems must validate timestamps against session time windows.

Tag 53 (Shares)

Description: Number of shares.
Shares (53) specifies a quantity of shares, similar to OrderQty but used in different contexts like allocation instructions. In FIX 4.2, this numeric field appears in various message types requiring quantity specification outside of order messages. Trading professionals must ensure consistent interpretation of this field across different message types. The field supports fractional shares where permitted, requiring proper precision handling. Systems should validate against minimum and maximum quantity rules.

Tag 54 (Side)

Description: Side of the order.
Side (54) specifies the trading direction using codes: 1=Buy, 2=Sell, 3=Sell Short. In FIX 4.2, this fundamental tag determines the order’s impact on positions and is mandatory for all order messages. Trading professionals must ensure accurate side specification, as errors can lead to catastrophic position mismatches. The field impacts commission calculation, regulatory reporting, and risk parameters. Systems must validate against supported side types for each instrument and venue.

Tag 55 (Symbol)

Description: Instrument symbol.
Symbol (55) provides the primary trading symbol for the financial instrument, such as “MSFT” for Microsoft. In FIX 4.2, this alphanumeric tag is critical for instrument identification in order routing and market data. Trading professionals rely on consistent symbol mapping across systems to prevent execution errors. The field requires robust reference data management to handle symbol changes and corporate actions. Systems must validate symbols against venue-specific naming conventions.

Tag 56 (TargetCompID)

Description: Target company ID.
TargetCompID (56) identifies the intended recipient application or firm in the FIX session. In FIX 4.2, this alphanumeric tag is critical for message routing and authentication, appearing in every message header. Trading professionals must ensure accurate TargetCompID configuration during connectivity setup, as mismatches prevent session establishment. The identifier typically corresponds to a pre-negotiated value in connectivity agreements. Systems should validate incoming messages against the expected TargetCompID.

Tag 57 (TargetSubID)

Description: Target sub-entity ID.
TargetSubID (57) provides additional identification for sub-components within the target firm, such as specific trading desks or applications. In FIX 4.2, this optional tag enables more granular message routing and auditing within complex organizations. Trading professionals use this field to direct messages to specific logical recipients within a counterparty’s infrastructure. The identifier should follow organizational naming conventions and be documented in connectivity agreements. Systems may use this for message filtering.

Tag 58 (Text)

Description: Free-form text message.
Text (58) provides human-readable explanatory text for messages, used in rejection notifications, execution reports, and other communications. In FIX 4.2, this variable-length field is critical for operational clarity, conveying reasons for rejections or special execution conditions. Trading professionals rely on accurate Text content for troubleshooting and exception handling. The field supports multi-line content through LinesOfText (33). Systems should log and potentially alert on significant Text content.

Tag 59 (TimeInForce)

Description: Time in force.
TimeInForce (59) specifies how long the order remains active using codes: 0=Day, 1=IOC, 3=GTC, 4=OPG, etc. In FIX 4.2, this critical tag determines the order’s lifespan and execution behavior. Trading professionals must select appropriate time in force based on strategy requirements, as mismatches can lead to unintended order persistence or premature cancellation. The field impacts risk management and regulatory reporting. Systems must validate against supported time in force types for each venue.

Tag 60 (TransactTime)

Description: Transaction time (duplicate entry – see Tag 52).
Note: This appears to be a duplicate of Tag 52 in the provided list. In standard FIX 4.2, TransactTime is Tag 60, not Tag 52. Tag 52 is SendingTime, which is deprecated.

Tag 61 (Urgency)

Description: Order urgency.
Urgency (61) specifies the priority of the order using codes: 0=Normal, 1=Flash, 2=Background. In FIX 4.2, this tag allows clients to express relative priority for order execution within their own order flow. Trading professionals use this field to manage order queue positioning, particularly during high-volatility periods. The interpretation may vary between brokers, requiring clear communication of expectations. Systems should honor urgency designations where supported by the execution venue.

Tag 62 (ValidUntilTime)

Description: Time order is valid until.
ValidUntilTime (62) specifies the absolute UTC time when a Good-Til-Date (GTD) order expires. In FIX 4.2, this tag works with TimeInForce=6 to define precise order expiration. Trading professionals must ensure accurate timestamp specification, as errors can cause premature cancellation or unintended persistence. The timestamp must conform to FIX datetime format (YYYYMMDD-HH:MM:SS) without milliseconds. Systems should validate against current time and session rules.

Tag 63 (SettlmntTyp)

Description: Settlement type.
SettlmntTyp (63) specifies the settlement period using codes: 0=Regular, 1=Cash, 2=Next Day, etc. In FIX 4.2, this tag determines the standard settlement cycle for the transaction. Trading professionals must ensure accurate settlement type designation to prevent failed settlements. The field impacts trade date calculations and regulatory reporting. Systems should validate against supported settlement types for each instrument and venue.

Tag 64 (FutSettDate)

Description: Future settlement date.
FutSettDate (64) specifies the explicit settlement date for transactions with non-standard settlement cycles. In FIX 4.2, this tag works with SettlmntTyp to define precise settlement dates, particularly for forward transactions. Trading professionals rely on accurate settlement date specification to manage cash and position flows. The date must conform to YYYYMMDD format and be validated against business calendars. Systems should calculate settlement dates correctly based on SettlmntTyp when FutSettDate is absent.

Tag 65 (SymbolSfx)

Description: Symbol suffix.
SymbolSfx (65) provides additional qualifier for the symbol, such as price indicator suffixes. In FIX 4.2, this tag is rarely used in modern implementations but remains for legacy compatibility. Trading professionals should be aware of its existence but typically don’t need to handle it actively. The field may appear in certain market data contexts but is generally superseded by more robust security identification mechanisms.

Tag 66 (ListID)

Description: Identifier for a list.
ListID (66) serves as the unique reference for order lists in List Execute (MsgType=E) and related messages. In FIX 4.2, this alphanumeric field enables coordinated execution of multiple orders as a single strategy. Trading professionals use this tag to manage complex order lists, such as basket trading or portfolio replication. The identifier must be unique per session and properly tracked throughout the list execution lifecycle. Systems must maintain list state to prevent partial execution issues.

Tag 67 (ListSeqNo)

Description: Sequence number within a list.
ListSeqNo (67) specifies the position of an order within an order list. In FIX 4.2, this numeric tag works with ListID to define the sequence of orders in a coordinated execution strategy. Trading professionals rely on proper sequencing for correct list execution behavior. The field must increment sequentially from 1 to TotNoOrders. Systems should validate list sequencing to prevent execution order errors.

Tag 68 (TotNoOrders)

Description: Total number of orders in a list.
TotNoOrders (68) specifies the complete count of orders in an order list. In FIX 4.2, this numeric tag appears in List Execute messages to indicate the full scope of the coordinated strategy. Trading professionals use this value to validate list completeness and track execution progress. The field must match the actual number of orders referenced in the list. Systems should validate against the actual order count to prevent partial list processing.

Tag 69 (ListExecInst)

Description: Instructions for list execution.
ListExecInst (69) provides special handling instructions for order lists using free-form text. In FIX 4.2, this field enables customization of list execution behavior, such as sequencing preferences or algorithm selection. Trading professionals use this tag to express nuanced list execution requirements. The interpretation is typically firm-specific, requiring clear documentation in connectivity agreements. Systems should validate against supported list execution instructions.

Tag 70 (AllocID)

Description: Identifier for an allocation instruction.
AllocID (70) serves as the unique reference for allocation instructions in Allocation messages (MsgType=J). In FIX 4.2, this alphanumeric field enables tracking and reconciliation of post-trade allocation activities. Trading professionals rely on AllocID to match allocation instructions with corresponding executions. The identifier must be unique per session and properly maintained throughout the allocation lifecycle. Systems must prevent duplicate allocation processing.

Tag 71 (AllocTransType)

Description: Type of allocation transaction.
AllocTransType (71) specifies the action for allocation instructions using codes: 0=New, 1=Replace, 2=Cancel. In FIX 4.2, this tag governs the lifecycle of allocation instructions, determining whether a message creates new allocations, modifies existing ones, or cancels previous instructions. Trading professionals must implement proper state management for allocation transactions to prevent position errors. Systems should validate transition sequences to ensure business logic integrity.

Tag 72 (RefAllocID)

Description: Reference identifier for an allocation.
RefAllocID (72) provides a cross-reference to a previous allocation instruction, enabling modification or cancellation of existing allocations. In FIX 4.2, this tag works with AllocTransType to create a chain of related allocation activities. Trading professionals use this field to maintain allocation history and ensure proper state transitions. Systems must validate that RefAllocID references an active allocation instruction.

Tag 73 (NoOrders)

Description: Number of orders in a list.
NoOrders (73) specifies the count of orders referenced in a list-related message. In FIX 4.2, this numeric tag appears in list status and confirmation messages to indicate how many orders are included in the list execution. Trading professionals use this value to validate list completeness and track execution progress. The field must match the actual number of orders processed. Systems should validate against the actual order count to prevent partial list processing issues.

Tag 74 (AvgPrxPrecision)

Description: Precision of average price.
AvgPrxPrecision (74) specifies the number of decimal places in average price calculations. In FIX 4.2, this numeric tag provides context for interpreting AvgPx values, particularly for instruments with non-standard price precision. Trading professionals rely on this information for accurate position valuation and P&L calculations. The field helps prevent rounding errors in high-precision instruments. Systems should apply the specified precision when processing average price values.

Tag 75 (TradeDate)

Description: Date of the trade.
TradeDate (75) specifies the business date when the trade occurred, typically in YYYYMMDD format. In FIX 4.2, this tag is critical for trade date accounting, regulatory reporting, and settlement calculations. Trading professionals must ensure accurate trade date specification to prevent settlement failures. The field may differ from TransactTime date due to time zone considerations or after-hours trading. Systems should validate against business calendars.

Tag 76 (ExecBroker)

Description: Executing broker ID.
ExecBroker (76) identifies the broker responsible for executing the trade. In FIX 4.2, this alphanumeric tag provides transparency into execution quality and best execution compliance. Trading professionals use this information for broker performance evaluation and regulatory reporting. The identifier typically corresponds to a pre-negotiated value in connectivity agreements. Systems should maintain broker reference data for accurate reporting.

Tag 77 (OpenClose)

Description: Open/Close indicator.
OpenClose (77) specifies whether the order is for opening or closing a position using codes: O=Open, C=Close. In FIX 4.2, this tag is particularly important for futures and options trading, where position direction matters for margin and risk calculations. Trading professionals must ensure accurate designation to prevent incorrect position management. The field impacts regulatory reporting requirements. Systems should validate against supported position types for each instrument.

Tag 78 (NoAllocs)

Description: Number of allocation groups.
NoAllocs (78) specifies the count of allocation instructions within an allocation message. In FIX 4.2, this numeric tag defines how many repeating allocation groups follow in the message. Trading professionals rely on this value to properly parse allocation instructions for multi-account scenarios. The field must match the actual number of allocation groups. Systems should validate against the actual group count to prevent allocation errors.

Tag 79 (AllocAccount)

Description: Allocation account.
AllocAccount (79) specifies the account identifier for an allocation instruction. In FIX 4.2, this alphanumeric tag appears within allocation groups to define where portions of an execution should be allocated. Trading professionals use this field for proper position distribution across multiple accounts. The identifier must match approved account values. Systems should validate against account reference data.

Tag 80 (AllocShares)

Description: Allocation quantity.
AllocShares (80) specifies the quantity to allocate to a specific account. In FIX 4.2, this numeric tag works with AllocAccount to define the distribution of executed quantities. Trading professionals rely on accurate allocation quantities to ensure proper position management across accounts. The sum of AllocShares must equal the total execution quantity. Systems should validate allocation totals against executed quantities.

Tag 81 (ProcessCode)

Description: Process code.
ProcessCode (81) specifies special processing instructions using codes: 0=Regular, 1=Soft Dollar, 2=Step-in, etc. In FIX 4.2, this tag enables nuanced execution handling for specialized order types. Trading professionals use this field to express requirements for soft dollar arrangements or other special processing needs. The interpretation is typically firm-specific, requiring clear documentation in connectivity agreements. Systems should validate against supported process codes.

Tag 82 (NoRpts)

Description: Number of reports.
NoRpts (82) specifies the count of reports in a repeating group, primarily used in List Status messages. In FIX 4.2, this numeric tag defines how many execution reports follow for orders within a list. Trading professionals rely on this value to properly parse list execution status. The field must match the actual number of report groups. Systems should validate against the actual report count.

Tag 83 (RptSeq)

Description: Report sequence number.
RptSeq (83) specifies the sequence number within a series of reports, such as multiple execution reports for a list. In FIX 4.2, this numeric tag enables proper ordering of related reports. Trading professionals use this field to reconstruct the complete execution sequence for complex orders. The field must increment sequentially. Systems should validate report sequencing to ensure proper state transitions.

Tag 84 (CxlQty)

Description: Quantity canceled.
CxlQty (84) specifies the quantity being canceled in a partial cancel request. In FIX 4.2, this numeric tag enables reduction of order size without full cancellation. Trading professionals use this field for dynamic order management, adjusting order size based on market conditions. The canceled quantity must not exceed the current leaves quantity. Systems should validate against available quantity.

Tag 85 (NoDlvyInst)

Description: No longer used.
NoDlvyInst (85) was previously used for delivery instructions but has been deprecated in FIX 4.2. Modern implementations should not use this tag, and systems should ignore it if encountered. Trading professionals should be aware of this deprecated field to avoid confusion during message analysis, but no active handling is required.

Tag 86 (DlvyInst)

Description: No longer used.
DlvyInst (86) was previously used for delivery instructions but has been deprecated in FIX 4.2. Modern implementations should not use this tag, and systems should ignore it if encountered. Trading professionals should be aware of this deprecated field to avoid confusion during message analysis, but no active handling is required.

Tag 87 (AllocStatus)

Description: Allocation status.
AllocStatus (87) specifies the status of an allocation instruction using codes: 0=Accepted, 1=Rejected, 2=Partial Accept, etc. In FIX 4.2, this tag provides feedback on allocation processing success. Trading professionals rely on this information for reconciliation and exception handling. The field must align with business logic for allocation processing. Systems should trigger appropriate workflows based on allocation status.

Tag 88 (AllocRejCode)

Description: Allocation rejection code.
AllocRejCode (88) specifies the reason for allocation rejection using numeric codes. In FIX 4.2, this tag works with AllocStatus to provide detailed rejection reasons for allocation instructions. Trading professionals use this information to diagnose and correct allocation errors. The codes must conform to standard rejection reasons. Systems should map rejection codes to actionable error messages.

Tag 89 (Signature)

Description: Digital signature.
Signature (89) contains the digital signature for message authentication. In FIX 4.2, this field supports secure message transmission, though its usage is limited compared to modern security protocols. Trading professionals working in highly secure environments may implement this for additional message integrity verification. The field requires cryptographic infrastructure for generation and validation. Systems should validate signatures where implemented.

Tag 90 (SecureDataLen)

Description: Length of encrypted data.
SecureDataLen (90) specifies the byte length of encrypted data in the SecureData field. In FIX 4.2, this numeric tag enables proper parsing of encrypted message components. Trading professionals working with secure implementations use this field to handle encrypted payloads correctly. The field is typically used with EncryptMethod to define secure communication channels. Systems must validate against actual data length.

Tag 91 (SecureData)

Description: Encrypted data.
SecureData (91) contains the actual encrypted message payload. In FIX 4.2, this field supports secure message transmission for sensitive information. Trading professionals working in highly secure environments implement this for confidential order routing. The field requires cryptographic infrastructure for encryption and decryption. Systems must process encrypted data according to the specified EncryptMethod.

Tag 92 (BrokerOfCredit)

Description: Broker of credit (for third-party executions).
BrokerOfCredit (92) identifies the executing broker in third-party execution arrangements. In FIX 4.2, this tag provides transparency into execution relationships for regulatory reporting. Trading professionals use this information for best execution compliance and broker performance evaluation. The identifier typically corresponds to a pre-negotiated value. Systems should maintain broker reference data.

Tag 93 (SignatureLength)

Description: Length of signature.
SignatureLength (93) specifies the byte length of the digital signature. In FIX 4.2, this numeric tag enables proper parsing of signature components. Trading professionals working with secure implementations use this field to handle signatures correctly. The field is typically used with Signature to define secure message authentication. Systems must validate against actual signature length.

Tag 94 (EmailType)

Description: Type of email message.
EmailType (94) specifies the purpose of an email message using codes: 0=New, 1=Reply, 2=Admin Reply. In FIX 4.2, this tag defines the context for email communications within the FIX protocol. Trading professionals use this field to categorize email traffic for proper handling. The field is primarily used for operational communications rather than order execution. Systems should route emails based on type.

Tag 95 (RawDataLength)

Description: Length of raw data.
RawDataLength (95) specifies the byte length of raw data in the RawData field. In FIX 4.2, this numeric tag enables proper parsing of binary data payloads. Trading professionals working with custom extensions use this field to handle non-standard data correctly. The field is typically used with RawData for proprietary information exchange. Systems must validate against actual data length.

Tag 96 (RawData)

Description: Raw data.
RawData (96) contains binary data for custom extensions or proprietary information. In FIX 4.2, this field supports specialized functionality beyond standard FIX messages. Trading professionals use this for firm-specific enhancements or legacy system integration. The interpretation is mutually agreed between counterparties. Systems must handle binary data correctly according to pre-negotiated specifications.

Tag 97 (PossResend)

Description: Indicates possible resend.
PossResend (97) signals that a message is being resent, set to ‘Y’ in resend requests. In FIX 4.2, this tag provides explicit indication of message resends, complementing PossDupFlag. Trading professionals use this information for proper duplicate handling logic. The field requires coordinated handling between counterparties to prevent duplicate processing. Systems should implement state tracking to distinguish true resends from duplicates.

Tag 98 (EncryptMethod)

Description: Encryption method.
EncryptMethod (98) specifies the algorithm used for message encryption. In FIX 4.2, this numeric tag defines how SecureData should be processed. Trading professionals working with secure implementations must ensure compatible encryption methods between counterparties. The field requires cryptographic infrastructure configuration. Systems should validate against supported encryption methods.

Tag 99 (StopPx)

Description: Stop price.
StopPx (99) specifies the trigger price for stop orders. In FIX 4.2, this numeric field is mandatory for stop and stop-limit orders, defining the price level that activates the order. Trading professionals rely on precise stop price specification for risk management. The field requires careful handling of price precision rules. Systems must validate against market conditions and venue-specific rules.

Tag 100 (ExDestination)

Description: Execution destination.
ExDestination (100) specifies the intended trading venue for order execution. In FIX 4.2, this alphanumeric tag enables directed order routing to specific exchanges or liquidity pools. Trading professionals use this field for sophisticated routing strategies and best execution compliance. The identifier must conform to venue naming conventions. Systems should validate against supported execution destinations.

Tag 102 (CxlRejReason)

Description: Reason for cancel rejection.
CxlRejReason (102) specifies why a cancel request was rejected using numeric codes. In FIX 4.2, this tag provides detailed feedback on cancel request processing failures. Trading professionals rely on this information to diagnose and correct cancel request errors. The codes must conform to standard rejection reasons. Systems should map rejection codes to actionable error messages.

Tag 103 (OrdRejReason)

Description: Reason for order rejection.
OrdRejReason (103) specifies why an order was rejected using numeric codes. In FIX 4.2, this critical tag provides detailed feedback on order processing failures. Trading professionals use this information to diagnose and correct order submission errors. Common reasons include invalid price (3), invalid quantity (4), and duplicate ClOrdID (7). Systems should implement specific handling for each rejection reason.

Tag 104 (IOIQualifier)

Description: Qualifier for indication of interest.
IOIQualifier (104) specifies additional characteristics of an IOI using single-character codes. In FIX 4.2, this tag provides context for how seriously counterparties should treat an indication of interest. Trading professionals use this information to prioritize responses to IOIs. The interpretation may vary between institutions, requiring clear communication of expectations. Systems should validate against supported qualifier codes.

Tag 105 (WaveNo)

Description: Wave number.
WaveNo (105) specifies the sequence number within a series of related messages, such as partial executions. In FIX 4.2, this numeric tag enables proper sequencing of related execution events. Trading professionals use this field to reconstruct complete execution sequences for large orders. The field must increment sequentially. Systems should validate wave sequencing to ensure proper state transitions.

Tag 106 (Issuer)

Description: Issuer of the security.
Issuer (106) provides the name of the security’s issuing entity. In FIX 4.2, this alphanumeric tag offers additional context for security identification, particularly for bonds and structured products. Trading professionals use this information for reference data management and regulatory reporting. The field supports free-form issuer names, requiring normalization for consistent processing. Systems should validate against reference data.

Tag 107 (SecurityDesc)

Description: Security description.
SecurityDesc (107) provides a human-readable description of the security. In FIX 4.4.2, this field offers additional context for instrument identification, particularly for complex products. Trading professionals rely on this information for operational clarity and exception handling. The field supports free-form text, requiring consistent formatting for reliable processing. Systems should log and potentially use for display purposes.

Tag 108 (HeartBtInt)

Description: Heartbeat interval.
HeartBtInt (108) specifies the maximum time between heartbeat messages in seconds. In FIX 4.2, this numeric tag defines the session’s liveness monitoring parameters during logon negotiation. Trading professionals must configure compatible heartbeat intervals with counterparties to prevent false session terminations. The value typically ranges from 10-30 seconds for production systems. Systems should enforce heartbeat monitoring according to this interval.

Tag 109 (ClientID)

Description: Client identifier.
ClientID (109) provides an additional identifier for the client, often used for sub-accounting. In FIX 4.2, this alphanumeric tag complements Account for more granular client identification. Trading professionals use this field for sophisticated account management structures. The identifier should follow organizational naming conventions. Systems should validate against approved client identifiers.

Tag 110 (MinQty)

Description: Minimum quantity.
MinQty (110) specifies the minimum execution quantity for an order. In FIX 4.2, this numeric field enables “all-or-none” or “minimum fill” order types. Trading professionals use this for orders requiring substantial fills to be economically viable. The minimum quantity must not exceed the total order quantity. Systems should validate against order quantity and venue rules.

Tag 111 (MaxFloor)

Description: Maximum order quantity.
MaxFloor (111) specifies the maximum quantity to display in the order book for iceberg orders. In FIX 4.2, this numeric field enables hidden order functionality, revealing only a portion of the total order. Trading professionals use this for large orders to minimize market impact. The displayed quantity must not exceed the total order quantity. Systems should validate against venue-specific iceberg rules.

Tag 112 (TestReqID)

Description: Test request identifier.
TestReqID (112) serves as the unique reference for test request messages. In FIX 4.2, this alphanumeric tag enables verification of session connectivity without disrupting trading. Trading professionals use this for routine session health checks and connectivity validation. The identifier should be echoed in the resulting heartbeat message. Systems should handle test requests promptly to maintain session health.

Tag 113 (ReportToExch)

Description: Indicates reporting to exchange.
ReportToExch (113) signals whether the order should be reported to the exchange using ‘Y’ or ‘N’. In FIX 4.2, this tag controls visibility of orders in the public order book. Trading professionals use this for dark pool or non-displayed orders. The field impacts order execution behavior and regulatory reporting. Systems should validate against venue-specific display rules.

Tag 114 (LocateReqd)

Description: Indicates locate required.
LocateReqd (114) signals whether stock borrow confirmation is required for short sales using ‘Y’ or ‘N’. In FIX 4.2, this critical tag ensures compliance with short sale regulations. Trading professionals must set this correctly for short sale orders to prevent fails. The field impacts order routing and execution eligibility. Systems should validate against short sale rules and inventory availability.

Tag 115 (OnBehalfOfCompID)

Description: Company ID of the originator.
OnBehalfOfCompID (115) identifies the ultimate sender when messages are routed through intermediaries. In FIX 4.2, this alphanumeric tag enables proper attribution in multi-hop FIX networks. Trading professionals use this for accurate audit trails and regulatory reporting. The identifier should correspond to a pre-negotiated value. Systems should validate against approved originators.

Tag 116 (OnBehalfOfSubID)

Description: Sub-entity ID of the originator.
OnBehalfOfSubID (116) provides additional identification for sub-components within the originator firm. In FIX 4.2, this optional tag enables more granular attribution in complex routing scenarios. Trading professionals use this field to distinguish between multiple logical originators operating through a single intermediary. The identifier should follow organizational naming conventions. Systems may use this for access control.

Tag 117 (QuoteID)

Description: Identifier for a quote.
QuoteID (117) serves as the unique reference for quote messages. In FIX 4.2, this alphanumeric field enables tracking and referencing of quotes across multiple messages. Trading professionals rely on QuoteID to correlate quote requests with responses and subsequent executions. The identifier must be unique per session. Systems must prevent duplicate quote processing.

Tag 118 (NetMoney)

Description: Net money amount.
NetMoney (118) specifies the total monetary value of an execution, including commissions. In FIX 4.2, this numeric field provides the definitive value for settlement calculations. Trading professionals use this for accurate position valuation and P&L calculations. The field must align with price and quantity calculations. Systems should validate against expected values to prevent settlement errors.

Tag 119 (SettlCurrAmt)

Description: Settlement currency amount.
SettlCurrAmt (119) specifies the amount in the settlement currency for cross-currency transactions. In FIX 4.2, this numeric field enables proper handling of foreign exchange components in trades. Trading professionals rely on this for accurate settlement in multi-currency environments. The field works with SettlCurrency to define the complete settlement value. Systems should validate against FX rates.

Tag 120 (SettlCurrency)

Description: Settlement currency.
SettlCurrency (120) specifies the currency for settlement using three-letter ISO codes. In FIX 4.2, this tag defines the currency in which the transaction will settle, particularly for cross-border trades. Trading professionals must ensure accurate currency designation to prevent settlement failures. The field impacts regulatory reporting requirements. Systems should validate against ISO 4217 standards.

Tag 121 (ForexReq)

Description: Indicates forex accommodation requested.
ForexReq (121) signals whether foreign exchange accommodation is requested using ‘Y’ or ‘N’. In FIX 4.2, this tag enables coordinated handling of currency conversion for cross-border trades. Trading professionals use this for transactions requiring simultaneous FX execution. The field impacts settlement processing and regulatory reporting. Systems should validate against supported FX services.

Tag 122 (OrigSendingTime)

Description: Original sending time.
OrigSendingTime (122) specifies the timestamp of the original message being referenced. In FIX 4.2, this tag provides temporal context for message relationships, helping systems determine event sequences. Trading professionals use this for audit trails and to resolve timing ambiguities. The timestamp must conform to FIX datetime format. Systems should validate against session time windows.

Tag 123 (GapFillFlag)

Description: Indicates gap fill message.
GapFillFlag (123) signals that a message is part of a gap fill sequence using ‘Y’ or ‘N’. In FIX 4.2, this critical tag distinguishes normal message flow from gap recovery sequences. Trading professionals use this information for proper sequence number handling during connectivity interruptions. The field requires coordinated handling between counterparties to prevent sequence errors. Systems should process gap fill messages differently from normal messages.

Tag 124 (NoExecs)

Description: Number of execution reports.
NoExecs (124) specifies the count of execution reports in a repeating group. In FIX 4.2, this numeric tag defines how many execution reports follow in messages containing multiple executions. Trading professionals rely on this value to properly parse complex execution scenarios. The field must match the actual number of execution reports. Systems should validate against the actual report count.

Tag 125 (CxlType)

Description: No longer used.
CxlType (125) was previously used for cancel type specification but has been deprecated in FIX 4.2. Modern implementations should not use this tag, and systems should ignore it if encountered. Trading professionals should be aware of this deprecated field to avoid confusion during message analysis.

Tag 126 (ExpireTime)

Description: Absolute expiration time.
ExpireTime (126) specifies the exact UTC time when a time-based order expires. In FIX 4.2, this tag provides precise expiration control beyond standard TimeInForce options. Trading professionals use this for orders requiring exact expiration timing. The timestamp must conform to FIX datetime format (YYYYMMDD-HH:MM:SS.sss). Systems should validate against current time.

Tag 127 (DKReason)

Description: Reason for delivery delay.
DKReason (127) specifies why a message was delayed using single-character codes. In FIX 4.2, this tag provides diagnostic information for operational issues. Trading professionals use this for troubleshooting connectivity problems. The field is primarily informational and may not be consistently implemented. Systems should log but typically don’t require active handling.

Tag 128 (DeliverToCompID)

Description: Company ID of final destination.
DeliverToCompID (128) identifies the ultimate recipient when messages are routed through intermediaries. In FIX 4.2, this alphanumeric tag enables proper message routing in multi-hop FIX networks. Trading professionals use this for accurate message delivery in complex infrastructure. The identifier should correspond to a pre-negotiated value. Systems should validate against approved destinations.

Tag 129 (DeliverToSubID)

Description: Sub-entity ID of final destination.
DeliverToSubID (129) provides additional identification for sub-components within the final destination firm. In FIX 4.2, this optional tag enables more granular routing in complex FIX networks. Trading professionals use this field to direct messages to specific logical recipients within multi-hop architectures. The identifier should follow organizational naming conventions. Systems may use this for message filtering.

Tag 130 (IOINaturalFlag)

Description: Indicates natural person IOI.
IOINaturalFlag (130) signals whether an IOI represents a natural person’s interest using ‘Y’ or ‘N’. In FIX 4.2, this tag provides context for IOI interpretation in regulatory contexts. Trading professionals use this for compliance with rules regarding natural person trading interests. The field impacts how IOIs are processed and reported. Systems should validate according to regulatory requirements.

Tag 131 (QuoteReqID)

Description: Identifier for a quote request.
QuoteReqID (131) serves as the unique reference for quote request messages. In FIX 4.2, this alphanumeric field enables tracking and referencing of quote requests across multiple messages. Trading professionals rely on QuoteReqID to correlate requests with responses and subsequent actions. The identifier must be unique per session. Systems must prevent duplicate request processing.

Tag 132 (BidPx)

Description: Bid price.
BidPx (132) specifies the price of a bid quote. In FIX 4.2, this numeric field is critical for quote dissemination and market making. Trading professionals use this for accurate price representation in bid-side liquidity. The field requires careful handling of price precision rules. Systems should validate against venue-specific price rules.

Tag 133 (OfferPx)

Description: Offer price.
OfferPx (133) specifies the price of an offer quote. In FIX 4.2, this numeric field is critical for quote dissemination and market making. Trading professionals use this for accurate price representation in offer-side liquidity. The field requires careful handling of price precision rules. Systems should validate against venue-specific price rules.

Tag 134 (BidSize)

Description: Bid quantity.
BidSize (134) specifies the quantity available at the bid price. In FIX 4.2, this numeric field defines the depth of bid-side liquidity. Trading professionals rely on accurate size reporting for market analysis and execution decisions. The field must conform to venue-specific minimum and maximum size rules. Systems should validate against instrument-specific size constraints.

Tag 135 (OfferSize)

Description: Offer quantity.
OfferSize (135) specifies the quantity available at the offer price. In FIX 4.2, this numeric field defines the depth of offer-side liquidity. Trading professionals rely on accurate size reporting for market analysis and execution decisions. The field must conform to venue-specific minimum and maximum size rules. Systems should validate against instrument-specific size constraints.

Tag 136 (NoMiscFees)

Description: Number of miscellaneous fees.
NoMiscFees (136) specifies the count of miscellaneous fee groups in a message. In FIX 4.2, this numeric tag defines how many fee components follow in allocation or execution messages. Trading professionals use this for accurate cost accounting in complex fee structures. The field must match the actual number of fee groups. Systems should validate against the actual fee count.

Tag 137 (MiscFeeAmt)

Description: Miscellaneous fee amount.
MiscFeeAmt (137) specifies the monetary value of a miscellaneous fee. In FIX 4.2, this numeric field appears within fee groups to define individual fee components. Trading professionals rely on accurate fee reporting for cost accounting and regulatory compliance. The field requires proper currency handling. Systems should validate against expected fee structures.

Tag 138 (MiscFeeCurr)

Description: Currency for miscellaneous fee.
MiscFeeCurr (138) specifies the currency for a miscellaneous fee using three-letter ISO codes. In FIX 4.2, this tag defines the currency in which a fee is denominated. Trading professionals must ensure accurate currency designation for proper fee accounting. The field impacts regulatory reporting requirements. Systems should validate against ISO 4217 standards.

Tag 139 (MiscFeeType)

Description: Type of miscellaneous fee.
MiscFeeType (139) specifies the nature of a miscellaneous fee using single-character codes. In FIX 4.2, this tag categorizes fee components for proper accounting and reporting. Trading professionals use this for detailed cost analysis and regulatory compliance. Common types include regulatory fees, taxes, and clearing fees. Systems should validate against supported fee types.

Tag 140 (PrevClosePx)

Description: Previous closing price.
PrevClosePx (140) specifies the previous day’s closing price for reference. In FIX 4.2, this numeric field provides context for current price levels in market data and order messages. Trading professionals use this for relative price analysis and order pricing. The field requires proper historical data management. Systems should validate against actual closing prices.

Tag 141 (ResetSeqNumFlag)

Description: Indicates sequence number reset.
ResetSeqNumFlag (141) signals that sequence numbers should be reset to 1 using ‘Y’ or ‘N’. In FIX 4.2, this critical tag enables clean session restarts after extended interruptions. Trading professionals use this during planned maintenance or recovery from severe connectivity issues. The field requires coordinated handling between counterparties to prevent message loss. Systems should implement sequence reset procedures carefully.

Tag 142 (SenderLocationID)

Description: Location ID of the sender.
SenderLocationID (142) specifies the physical or logical location of the sending application. In FIX 4.2, this alphanumeric tag enables geographically distributed systems to identify message sources. Trading professionals use this for latency optimization and regulatory reporting. The identifier should follow organizational naming conventions. Systems may use this for routing decisions.

Tag 143 (TargetLocationID)

Description: Location ID of the target.
TargetLocationID (143) specifies the physical or logical location of the target application. In FIX 4.2, this alphanumeric tag enables geographically distributed systems to direct messages appropriately. Trading professionals use this for latency optimization and regulatory reporting. The identifier should follow organizational naming conventions. Systems may use this for routing decisions.

Tag 144 (OnBehalfOfLocationID)

Description: Location ID of the originator.
OnBehalfOfLocationID (144) specifies the location of the ultimate sender in multi-hop networks. In FIX 4.2, this tag enables precise attribution in complex routing scenarios. Trading professionals use this for accurate audit trails and regulatory reporting. The identifier should correspond to a pre-negotiated value. Systems should validate against approved locations.

Tag 145 (DeliverToLocationID)

Description: Location ID of the final destination.
DeliverToLocationID (145) specifies the location of the ultimate recipient in multi-hop networks. In FIX 4.2, this tag enables precise message routing in complex infrastructure. Trading professionals use this for accurate message delivery in geographically distributed systems. The identifier should correspond to a pre-negotiated value. Systems should validate against approved locations.

Tag 146 (NoRelatedSym)

Description: Number of related symbols.
NoRelatedSym (146) specifies the count of related symbols in a repeating group. In FIX 4.2, this numeric tag defines how many related instruments follow in multi-leg strategy messages. Trading professionals use this for complex order routing involving multiple instruments. The field must match the actual number of related symbols. Systems should validate against the actual symbol count.

Tag 147 (Subject)

Description: Subject of email message.
Subject (147) provides the subject line for email messages. In FIX 4.2, this alphanumeric field enables categorization of email communications within the FIX protocol. Trading professionals use this for operational clarity in email-based communications. The field supports free-form text, requiring consistent formatting. Systems should use for email routing and display.

Tag 148 (Headline)

Description: Headline of news message.
Headline (148) provides the subject line for news messages. In FIX 4.2, this alphanumeric field enables categorization of news content within the FIX protocol. Trading professionals use this for quick assessment of news relevance. The field supports free-form text, requiring consistent formatting. Systems should use for news filtering and display.

Tag 149 (URLLink)

Description: URL reference.
URLLink (149) provides a web address reference, typically for additional news content. In FIX 4.2, this alphanumeric field enables linking to external resources from news or email messages. Trading professionals use this to access detailed information referenced in communications. The field should contain valid URL syntax. Systems may validate and potentially use for automated content retrieval.

Tag 150 (ExecType)

Description: Execution type.
ExecType (150) specifies the specific type of execution report using single-character codes: 0=NEW, 4=CANCELED, F=PARTIAL FILL. In FIX 4.2, this critical tag defines the precise business event triggering the report, distinct from the order status. Trading professionals rely on accurate ExecType interpretation for proper state machine transitions—confusing ExecType=I (PENDING CANCEL) with ExecType=4 (CANCELED) causes catastrophic errors. The field must align with OrdStatus values according to FIX specification rules.

Tag 151 (LeavesQty)

Description: Quantity remaining.
LeavesQty (151) specifies the quantity remaining to be filled for an order. In FIX 4.2, this numeric field is critical for real-time order monitoring, calculated as OrderQty – CumQty. Trading professionals use this for position management and execution quality assessment. The field must decrement monotonically with fills. Systems should validate against order quantity and fill history.

Tag 152 (CashOrderQty)

Description: Cash order quantity.
CashOrderQty (152) specifies the monetary value of the order rather than share quantity. In FIX 4.2, this numeric field enables dollar-based order entry, particularly for mutual funds and certain ETFs. Trading professionals use this for strategies targeting specific dollar amounts rather than share counts. The field works with SettlCurrency to define the complete order value. Systems should convert to share quantity using current prices.

Tag 153 (AllocAvgPx)

Description: Average price for allocation.
AllocAvgPx (153) specifies the average execution price for an allocation instruction. In FIX 4.2, this numeric field provides the definitive price for settlement calculations within allocation messages. Trading professionals rely on accurate average price reporting for position valuation. The field must align with execution price calculations. Systems should validate against expected price values.

Tag 154 (AllocNetMoney)

Description: Net money for allocation.
AllocNetMoney (154) specifies the total monetary value for an allocation instruction. In FIX 4.2, this numeric field provides the definitive value for settlement calculations within allocation messages. Trading professionals use this for accurate position valuation and P&L calculations. The field must align with price and quantity calculations. Systems should validate against expected values.

Tag 155 (SettlCurrFxRate)

Description: FX rate for settlement currency.
SettlCurrFxRate (155) specifies the exchange rate used for settlement currency conversion. In FIX 4.2, this numeric field enables accurate calculation of cross-currency settlement values. Trading professionals rely on precise FX rates for correct settlement amounts. The field works with SettlCurrFxRateCalc to define the rate direction. Systems should validate against market FX rates.

Tag 156 (SettlCurrFxRateCalc)

Description: FX rate calculation type.
SettlCurrFxRateCalc (156) specifies how the FX rate should be applied using codes: M=Multiply, D=Divide. In FIX 4.2, this tag defines the mathematical operation for currency conversion. Trading professionals must ensure correct calculation type to prevent settlement errors. The field impacts how SettlCurrFxRate is applied to transaction values. Systems should implement the correct calculation logic.

Tag 157 (NumDaysInterest)

Description: Number of days for interest calculation.
NumDaysInterest (157) specifies the day count for accrued interest calculations. In FIX 4.2, this numeric field is critical for fixed income transactions, determining interest accrual periods. Trading professionals use this for accurate bond pricing and settlement calculations. The field must conform to standard day count conventions. Systems should validate against instrument-specific conventions.

Tag 158 (AccruedInterestRate)

Description: Accrued interest rate.
AccruedInterestRate (158) specifies the interest rate used for accrued interest calculations. In FIX 4.2, this numeric field is critical for fixed income transactions, determining interest accrual amounts. Trading professionals rely on accurate rate specification for correct settlement values. The field impacts regulatory reporting for bond trades. Systems should validate against instrument-specific rates.

Tag 159 (AccruedInterestAmt)

Description: Accrued interest amount.
AccruedInterestAmt (159) specifies the monetary value of accrued interest. In FIX 4.2, this numeric field is critical for fixed income settlement, representing the interest component of the trade price. Trading professionals use this for accurate settlement calculations and regulatory reporting. The field must align with accrued interest rate and day count. Systems should validate against expected values.

Tag 160 (SettlInstMode)

Description: Settlement instruction mode.
SettlInstMode (160) specifies the method for providing settlement instructions using codes: 0=Default, 1=Standing Instructions, etc. In FIX 4.2, this tag determines how settlement details are communicated for the transaction. Trading professionals must ensure correct mode selection to prevent settlement failures. The field impacts post-trade processing workflows. Systems should validate against supported modes.

Tag 161 (AllocText)

Description: Allocation free-form text.
AllocText (161) provides human-readable explanatory text for allocation instructions. In FIX 4.2, this variable-length field enables operational clarity for complex allocation scenarios. Trading professionals use this for exception handling and audit trails. The field supports multi-line content through EncodedAllocTextLen. Systems should log and potentially alert on significant allocation text.

Tag 162 (SettlInstID)

Description: Settlement instruction identifier.
SettlInstID (162) serves as the unique reference for settlement instructions. In FIX 4.2, this alphanumeric field enables tracking and referencing of settlement instructions across messages. Trading professionals rely on SettlInstID for reconciliation of settlement details. The identifier must be unique per session. Systems must prevent duplicate settlement instruction processing.

Tag 163 (SettlInstTransType)

Description: Settlement instruction transaction type.
SettlInstTransType (163) specifies the action for settlement instructions using codes: N=New, C=Cancel, R=Replace. In FIX 4.2, this tag governs the lifecycle of settlement instructions. Trading professionals must implement proper state management for settlement instruction transactions. Systems should validate transition sequences to ensure business logic integrity.

Tag 164 (EmailThreadID)

Description: Identifier for email thread.
EmailThreadID (164) serves as the unique reference for email message threads. In FIX 4.2, this alphanumeric field enables correlation of related email communications. Trading professionals use this for maintaining context in email-based discussions. The identifier should be consistent across related messages. Systems should use for email threading and display.

Tag 165 (SettlInstSource)

Description: Source of settlement instructions.
SettlInstSource (165) specifies where settlement instructions originate using codes: 1=BROKERINSTRUCT, 2=INSTITUTION, etc. In FIX 4.2, this tag provides context for settlement instruction authority. Trading professionals use this to determine which party’s instructions take precedence. The field impacts settlement processing workflows. Systems should validate against supported sources.

Tag 166 (SettlLocation)

Description: Settlement location.
SettlLocation (166) specifies the settlement location using codes like ISO country codes. In FIX 4.2, this tag determines the settlement system and rules applicable to the transaction. Trading professionals must ensure accurate location designation to prevent settlement failures. The field impacts regulatory reporting requirements. Systems should validate against supported settlement locations.

Tag 167 (SecurityType)

Description: Type of security.
SecurityType (167) specifies the instrument type using codes: COMMON=Common Stock,. In FIX 4.2, this tag is critical for proper instrument handling, as different security types have different trading rules. Trading professionals rely on accurate security type designation for correct order routing and regulatory compliance. The field impacts price and quantity conventions. Systems should validate against supported security types.

Tag 168 (EffectiveTime)

Description: Time when instruction becomes effective.
EffectiveTime (168) specifies when a message or instruction becomes valid. In FIX 4.2, this timestamp field enables delayed execution of instructions. Trading professionals use this for time-based order strategies or delayed allocations. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 169 (StandInstDbType)

Description: Database type for standing instructions.
StandInstDbType (169) specifies the database type for standing settlement instructions using codes: 0=Other, 1=DTD, etc. In FIX 4.2, this tag provides context for settlement instruction sources. Trading professionals use this to interpret standing instruction references. The field impacts settlement processing workflows. Systems should validate against supported database types.

Tag 170 (StandInstDbName)

Description: Database name for standing instructions.
StandInstDbName (170) specifies the name of the database containing standing instructions. In FIX 4.2, this alphanumeric field enables precise identification of settlement instruction sources. Trading professionals use this for accurate settlement instruction lookup. The field should correspond to pre-negotiated database names. Systems should validate against approved databases.

Tag 171 (StandInstDbID)

Description: Database ID for standing instructions.
StandInstDbID (171) specifies the unique identifier for standing instructions within a database. In FIX 4.2, this alphanumeric field enables precise retrieval of settlement instructions. Trading professionals use this for accurate settlement processing. The identifier should correspond to pre-negotiated values. Systems should validate against approved instruction IDs.

Tag 172 (SettlDeliveryType)

Description: Settlement delivery type.
SettlDeliveryType (172) specifies the delivery method for settlement using codes: 0=Versus Payment, 1=Free, etc. In FIX 4.2, this tag determines the settlement mechanics for the transaction. Trading professionals must ensure correct delivery type to prevent settlement failures. The field impacts settlement processing workflows. Systems should validate against supported delivery types.

Tag 173 (SettlDepositoryCode)

Description: Settlement depository code.
SettlDepositoryCode (173) specifies the depository for settlement using standard codes. In FIX 4.2, this alphanumeric tag identifies the central securities depository for the transaction. Trading professionals use this for accurate settlement routing. The field impacts regulatory reporting requirements. Systems should validate against supported depositories.

Tag 174 (SettlBrkrCode)

Description: Settlement broker code.
SettlBrkrCode (174) specifies the broker handling settlement using standard codes. In FIX 4.2, this alphanumeric tag identifies the settlement broker for the transaction. Trading professionals use this for accurate settlement processing and regulatory reporting. The field should correspond to pre-negotiated broker codes. Systems should validate against approved brokers.

Tag 175 (SettlInstCode)

Description: Settlement instruction code.
SettlInstCode (175) specifies a shorthand code for settlement instructions. In FIX 4.2, this alphanumeric field enables concise representation of complex settlement details. Trading professionals use this for efficient communication of standard settlement patterns. The code should correspond to pre-negotiated instruction sets. Systems should validate against approved instruction codes.

Tag 176 (SecuritySettlAgentName)

Description: Name of security settlement agent.
SecuritySettlAgentName (176) specifies the name of the security settlement agent. In FIX 4.2, this alphanumeric field provides contact information for settlement issues. Trading professionals use this for operational clarity in settlement workflows. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 177 (SecuritySettlAgentCode)

Description: Code of security settlement agent.
SecuritySettlAgentCode (177) specifies the identifier for the security settlement agent. In FIX 4.2, this alphanumeric field enables precise identification of settlement agents. Trading professionals use this for accurate settlement routing. The code should correspond to pre-negotiated values. Systems should validate against approved agents.

Tag 178 (SecuritySettlAgentAcctNum)

Description: Account number for security settlement agent.
SecuritySettlAgentAcctNum (178) specifies the account number with the security settlement agent. In FIX 4.2, this alphanumeric field enables precise settlement instructions. Trading professionals use this for accurate position allocation. The account number should correspond to pre-negotiated values. Systems should validate against approved accounts.

Tag 179 (SecuritySettlAgentAcctName)

Description: Account name for security settlement agent.
SecuritySettlAgentAcctName (179) specifies the account name with the security settlement agent. In FIX 4.2, this alphanumeric field provides additional context for settlement accounts. Trading professionals use this for operational clarity. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 180 (SecuritySettlAgentContactName)

Description: Contact name for security settlement agent.
SecuritySettlAgentContactName (180) specifies the contact person at the security settlement agent. In FIX 4.2, this alphanumeric field provides operational contact information. Trading professionals use this for resolving settlement issues. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 181 (SecuritySettlAgentContactPhone)

Description: Contact phone for security settlement agent.
SecuritySettlAgentContactPhone (181) specifies the contact phone at the security settlement agent. In FIX 4.2, this alphanumeric field provides operational contact information. Trading professionals use this for resolving settlement issues. The field should conform to standard phone number formats. Systems should log for reference.

Tag 182 (CashSettlAgentName)

Description: Name of cash settlement agent.
CashSettlAgentName (182) specifies the name of the cash settlement agent. In FIX 4.2, this alphanumeric field provides contact information for cash settlement issues. Trading professionals use this for operational clarity in settlement workflows. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 183 (CashSettlAgentCode)

Description: Code of cash settlement agent.
CashSettlAgentCode (183) specifies the identifier for the cash settlement agent. In FIX 4.2, this alphanumeric field enables precise identification of cash settlement agents. Trading professionals use this for accurate settlement routing. The code should correspond to pre-negotiated values. Systems should validate against approved agents.

Tag 184 (CashSettlAgentAcctNum)

Description: Account number for cash settlement agent.
CashSettlAgentAcctNum (184) specifies the account number with the cash settlement agent. In FIX 4.2, this alphanumeric field enables precise cash settlement instructions. Trading professionals use this for accurate cash allocation. The account number should correspond to pre-negotiated values. Systems should validate against approved accounts.

Tag 185 (CashSettlAgentAcctName)

Description: Account name for cash settlement agent.
CashSettlAgentAcctName (185) specifies the account name with the cash settlement agent. In FIX 4.2, this alphanumeric field provides additional context for cash settlement accounts. Trading professionals use this for operational clarity. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 186 (CashSettlAgentContactName)

Description: Contact name for cash settlement agent.
CashSettlAgentContactName (186) specifies the contact person at the cash settlement agent. In FIX 4.2, this alphanumeric field provides operational contact information. Trading professionals use this for resolving settlement issues. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 187 (CashSettlAgentContactPhone)

Description: Contact phone for cash settlement agent.
CashSettlAgentContactPhone (187) specifies the contact phone at the cash settlement agent. In FIX 4.2, this alphanumeric field provides operational contact information. Trading professionals use this for resolving settlement issues. The field should conform to standard phone number formats. Systems should log for reference.

Tag 188 (BidSpotRate)

Description: Spot rate for bid.
BidSpotRate (188) specifies the spot exchange rate for bid-side FX quotes. In FIX 4.2, this numeric field is critical for foreign exchange trading. Trading professionals use this for accurate FX price representation. The field requires careful handling of FX rate precision. Systems should validate against market rates.

Tag 189 (BidForwardPoints)

Description: Forward points for bid.
BidForwardPoints (189) specifies the forward points for bid-side FX forward quotes. In FIX 4.2, this numeric field enables precise forward rate calculation. Trading professionals use this for accurate FX forward pricing. The field works with BidSpotRate to define the complete forward rate. Systems should validate against market forward points.

Tag 190 (OfferSpotRate)

Description: Spot rate for offer.
OfferSpotRate (190) specifies the spot exchange rate for offer-side FX quotes. In FIX 4.2, this numeric field is critical for foreign exchange trading. Trading professionals use this for accurate FX price representation. The field requires careful handling of FX rate precision. Systems should validate against market rates.

Tag 191 (OfferForwardPoints)

Description: Forward points for offer.
OfferForwardPoints (191) specifies the forward points for offer-side FX forward quotes. In FIX 4.2, this numeric field enables precise forward rate calculation. Trading professionals use this for accurate FX forward pricing. The field works with OfferSpotRate to define the complete forward rate. Systems should validate against market forward points.

Tag 192 (OrderQty2)

Description: Order quantity decimal format.
OrderQty2 (192) specifies the order quantity using a decimal format. In FIX 4.2, this numeric field supports fractional share orders where permitted. Trading professionals use this for precise order sizing in markets supporting fractional shares. The field provides an alternative to integer-based OrderQty. Systems should validate against venue-specific fractional share rules.

Tag 193 (FutSettDate2)

Description: Second settlement date.
FutSettDate2 (193) specifies an additional settlement date for complex transactions. In FIX 4.2, this tag supports transactions with multiple settlement dates, such as certain derivatives. Trading professionals use this for accurate settlement scheduling. The date must conform to YYYYMMDD format. Systems should validate against business calendars.

Tag 194 (LastSpotRate)

Description: Last spot rate.
LastSpotRate (194) specifies the spot rate for the last FX transaction. In FIX 4.2, this numeric field provides context for FX execution quality. Trading professionals use this for FX execution analysis. The field requires careful handling of FX rate precision. Systems should validate against market rates.

Tag 195 (LastForwardPoints)

Description: Last forward points.
LastForwardPoints (195) specifies the forward points for the last FX forward transaction. In FIX 4.2, this numeric field enables precise execution quality analysis for FX forwards. Trading professionals use this for FX forward execution analysis. The field works with LastSpotRate to define the complete forward rate. Systems should validate against market forward points.

Tag 196 (AllocLinkID)

Description: Identifier linking allocations.
AllocLinkID (196) serves as the reference for related allocation instructions. In FIX 4.2, this alphanumeric field enables correlation of multiple allocation messages for complex scenarios. Trading professionals use this for accurate position distribution across multiple accounts and strategies. The identifier must be consistent across related allocations. Systems should validate linkage consistency.

Tag 197 (AllocLinkType)

Description: Type of allocation link.
AllocLinkType (197) specifies the relationship between linked allocations using codes: 1=Forward, 2=Reverse. In FIX 4.2, this tag defines how allocation instructions should be processed relative to each other. Trading professionals use this for sophisticated allocation strategies. The field impacts allocation processing workflows. Systems should validate against supported link types.

Tag 198 (SecondaryOrderID)

Description: Secondary order identifier.
SecondaryOrderID (198) provides an additional identifier for an order, often used for internal tracking. In FIX 4.2, this alphanumeric field enables supplementary order identification beyond ClOrdID and OrderID. Trading professionals use this for enhanced audit trails and reconciliation. The identifier should follow organizational naming conventions. Systems should log for reference.

Tag 199 (NoIOIQualifiers)

Description: Number of IOI qualifiers.
NoIOIQualifiers (199) specifies the count of qualifiers in an IOI message. In FIX 4.2, this numeric tag defines how many IOIQualifier fields follow. Trading professionals use this for proper parsing of complex IOI messages. The field must match the actual number of qualifiers. Systems should validate against the actual qualifier count.

Tag 200 (MaturityMonthYear)

Description: Maturity month and year.
MaturityMonthYear (200) specifies the maturity date for derivatives using YYYYMM format. In FIX 4.2, this alphanumeric field is critical for options and futures identification. Trading professionals rely on accurate maturity specification for correct instrument handling. The field must conform to standard date formats. Systems should validate against exchange contract calendars.

Tag 201 (PutOrCall)

Description: Put/call indicator.
PutOrCall (201) specifies the option type using 0=Put, 1=Call. In FIX 4.2, this numeric tag is fundamental for options trading, determining payoff structure. Trading professionals must ensure accurate designation to prevent catastrophic execution errors. The field impacts pricing models and risk calculations. Systems should validate against instrument definitions.

Tag 202 (StrikePrice)

Description: Option strike price.
StrikePrice (202) specifies the exercise price for options. In FIX 4.2, this numeric field is critical for options pricing and execution. Trading professionals rely on precise strike price specification for accurate order handling. The field requires careful handling of price precision rules. Systems should validate against exchange strike price rules.

Tag 203 (CoveredOrUncovered)

Description: Covered/uncovered indicator.
CoveredOrUncovered (203) specifies whether an option position is covered using 0=Uncovered, 1=Covered. In FIX 4.2, this numeric tag impacts margin requirements and risk parameters. Trading professionals must ensure accurate designation for proper risk management. The field affects regulatory reporting requirements. Systems should validate against position status.

Tag 204 (CustomerOrFirm)

Description: Customer/firm indicator.
CustomerOrFirm (204) specifies whether the order is for a customer or firm account using 0=Customer, 1=Firm. In FIX 4.2, this numeric tag is critical for regulatory compliance and execution priority rules. Trading professionals must ensure accurate designation to comply with exchange rules. The field impacts best execution requirements and reporting. Systems should validate against account types.

Tag 205 (MaturityDay)

Description: Maturity day.
MaturityDay (205) specifies the day of maturity for derivatives. In FIX 4.2, this numeric field works with MaturityMonthYear to define precise maturity dates. Trading professionals use this for accurate instrument identification. The field must conform to calendar constraints. Systems should validate against exchange contract calendars.

Tag 206 (OptAttribute)

Description: Option attribute.
OptAttribute (206) specifies the style of an option using codes: A=American, E=European. In FIX 4.2, this alphanumeric tag determines exercise rules for options. Trading professionals must ensure accurate attribute specification for correct order handling. The field impacts pricing models and risk calculations. Systems should validate against instrument definitions.

Tag 207 (SecurityExchange)

Description: Trading venue for the security.
SecurityExchange (207) specifies the primary listing exchange for the security. In FIX 4.2, this alphanumeric tag provides context for security identification and routing. Trading professionals use this for accurate instrument handling and regulatory reporting. The field must conform to exchange code conventions. Systems should validate against exchange reference data.

Tag 208 (NotifyBrokerOfCredit)

Description: Indicates credit notification required.
NotifyBrokerOfCredit (208) signals whether credit approval is required using ‘Y’ or ‘N’. In FIX 4.2, this tag impacts order routing for credit-sensitive instruments. Trading professionals use this for proper handling of margin and credit requirements. The field affects order eligibility and execution. Systems should validate against credit limits.

Tag 209 (AllocHandlInst)

Description: Allocation handling instruction.
AllocHandlInst (209) specifies how allocations should be processed using codes: 1=Match, 2=Forward, 3=Forward and Match. In FIX 4.2, this numeric tag determines the allocation workflow. Trading professionals use this for sophisticated allocation strategies. The field impacts post-trade processing timelines. Systems should validate against supported handling instructions.

Tag 210 (MaxShow)

Description: Maximum quantity to display.
MaxShow (210) specifies the maximum visible quantity for iceberg orders. In FIX 4.2, this numeric field enables hidden order functionality similar to MaxFloor. Trading professionals use this for large orders to minimize market impact. The displayed quantity must not exceed the total order quantity. Systems should validate against venue-specific iceberg rules.

Tag 211 (PegDifference)

Description: Peg offset value.
PegDifference (211) specifies the offset for pegged orders. In FIX 4.2, this numeric field enables dynamic order pricing relative to market prices. Trading professionals use this for sophisticated execution algorithms. The field requires careful handling of price precision rules. Systems should validate against venue-specific pegging rules.

Tag 212 (XmlDataLen)

Description: Length of XML data.
XmlDataLen (212) specifies the byte length of XML data in the XmlData field. In FIX 4.2, this numeric tag enables proper parsing of XML payloads. Trading professionals working with custom extensions use this field to handle XML content correctly. The field is typically used with XmlData for structured data exchange. Systems must validate against actual data length.

Tag 213 (XmlData)

Description: XML data.
XmlData (213) contains XML content for custom extensions or structured data. In FIX 4.2, this field supports sophisticated data exchange beyond standard FIX fields. Trading professionals use this for firm-specific enhancements or complex instrument definitions. The interpretation is mutually agreed between counterparties. Systems must parse XML according to pre-negotiated schemas.

Tag 214 (SettlInstRefID)

Description: Reference identifier for settlement instructions.
SettlInstRefID (214) serves as the unique reference for settlement instructions. In FIX 4.2, this alphanumeric field enables tracking and referencing of settlement instructions across messages. Trading professionals rely on SettlInstRefID for reconciliation of settlement details. The identifier must be unique per session. Systems must prevent duplicate settlement instruction processing.

Tag 215 (NoRoutingIDs)

Description: Number of routing IDs.
NoRoutingIDs (215) specifies the count of routing instructions in a message. In FIX 4.2, this numeric tag defines how many routing groups follow in order messages. Trading professionals use this for sophisticated order routing strategies. The field must match the actual number of routing groups. Systems should validate against the actual routing count.

Tag 216 (RoutingType)

Description: Type of routing instruction.
RoutingType (216) specifies the routing methodology using codes: 1=Target Firm, 2=Target ID, etc. In FIX 4.2, this numeric tag determines how routing instructions should be interpreted. Trading professionals use this for precise order routing control. The field impacts order execution paths and best execution compliance. Systems should validate against supported routing types.

Tag 217 (RoutingID)

Description: Routing identifier.
RoutingID (217) specifies the destination for routing instructions. In FIX 4.2, this alphanumeric field works with RoutingType to define order routing paths. Trading professionals use this for directed order routing to specific venues or algorithms. The identifier must conform to venue naming conventions. Systems should validate against supported routing destinations.

Tag 218 (SpreadToBenchmark)

Description: Spread to benchmark.
SpreadToBenchmark (218) specifies the spread relative to a benchmark rate. In FIX 4.2, this numeric field is used in fixed income trading to express pricing relative to benchmarks. Trading professionals use this for accurate bond pricing. The field requires careful handling of spread precision. Systems should validate against instrument-specific conventions.

Tag 219 (Benchmark)

Description: Benchmark rate.
Benchmark (219) specifies the reference rate for spread calculations. In FIX 4.2, this alphanumeric tag identifies the benchmark used in SpreadToBenchmark calculations. Trading professionals use this for accurate fixed income pricing. The field must conform to standard benchmark names. Systems should validate against supported benchmarks.

Tag 223 (CouponRate)

Description: Coupon rate.
CouponRate (223) specifies the interest rate for fixed income instruments. In FIX 4.2, this numeric field is critical for bond identification and pricing. Trading professionals rely on accurate coupon specification for correct valuation. The field impacts accrued interest calculations. Systems should validate against instrument definitions.

Tag 231 (ContractMultiplier)

Description: Contract multiplier.
ContractMultiplier (231) specifies the multiplier for derivative contracts. In FIX 4.2, this numeric field is critical for options and futures pricing, converting prices to monetary values. Trading professionals use this for accurate position valuation and risk calculations. The field must conform to exchange contract specifications. Systems should validate against instrument definitions.

Tag 262 (MDReqID)

Description: Market data request identifier.
MDReqID (262) serves as the unique reference for market data requests. In FIX 4.2, this alphanumeric field enables tracking and correlation of market data requests with responses. Trading professionals use this for efficient market data handling and troubleshooting. The identifier must be unique per session. Systems must prevent duplicate request processing.

Tag 263 (SubscriptionRequestType)

Description: Type of market data subscription.
SubscriptionRequestType (263) specifies the subscription action using codes: 1=Snapshot, 2=Snapshot+Updates, 3=Disable. In FIX 4.2, this numeric tag determines how market data should be delivered. Trading professionals use this to control market data flow based on strategy requirements. The field impacts bandwidth usage and data freshness. Systems should validate against supported subscription types.

Tag 264 (MarketDepth)

Description: Market depth level.
MarketDepth (264) specifies the depth of market data to return. In FIX 4.2, this numeric field controls how many price levels should be included in market data responses. Trading professionals use this to balance data detail with bandwidth requirements. The field must conform to venue-specific depth limits. Systems should validate against supported depth levels.

Tag 265 (MDUpdateType)

Description: Type of market data update.
MDUpdateType (265) specifies the update methodology using codes: 0=Full Refresh, 1=Incremental. In FIX 4.2, this numeric tag determines how market data changes are communicated. Trading professionals use this to optimize market data processing efficiency. The field impacts how market data should be applied to the order book. Systems should validate against supported update types.

Tag 266 (AggregatedBook)

Description: Indicates aggregated book.
AggregatedBook (266) signals whether market data is aggregated using ‘Y’ or ‘N’. In FIX 4.2, this tag indicates if price levels combine multiple orders at the same price. Trading professionals use this to interpret market depth correctly. The field impacts order book reconstruction logic. Systems should handle aggregated and non-aggregated data appropriately.

Tag 267 (NoMDEntryTypes)

Description: Number of entry types in market data.
NoMDEntryTypes (267) specifies the count of entry types in a market data message. In FIX 4.2, this numeric tag defines how many MDEntryType fields follow. Trading professionals use this for proper parsing of market data messages. The field must match the actual number of entry types. Systems should validate against the actual entry count.

Tag 268 (NoMDEntries)

Description: Number of market data entries.
NoMDEntries (268) specifies the count of market data entries in a message. In FIX 4.2, this numeric tag defines how many market data records follow. Trading professionals rely on this value to properly parse market data messages. The field must match the actual number of entries. Systems should validate against the actual entry count.

Tag 269 (MDEntryType)

Description: Type of market data entry.
MDEntryType (269) specifies the nature of a market data entry using codes: 0=Bid, 1=Offer, 2=Trade, etc. In FIX 4.2, this critical tag defines what each market data record represents. Trading professionals use this to correctly interpret market data for trading decisions. The field must conform to standard entry types. Systems should validate against supported entry types.

Tag 270 (MDEntryPx)

Description: Price of market data entry.
MDEntryPx (270) specifies the price for a market data entry. In FIX 4.2, this numeric field is critical for market data interpretation. Trading professionals rely on accurate price reporting for execution decisions. The field requires careful handling of price precision rules. Systems should validate against venue-specific price rules.

Tag 271 (MDEntrySize)

Description: Size of market data entry.
MDEntrySize (271) specifies the quantity for a market data entry. In FIX 4.2, this numeric field defines the depth at a specific price level. Trading professionals use this for market analysis and execution decisions. The field must conform to venue-specific size rules. Systems should validate against instrument-specific size constraints.

Tag 272 (MDEntryDate)

Description: Date of market data entry.
MDEntryDate (272) specifies the business date for a market data entry. In FIX 4.2, this tag provides temporal context for market data records. Trading professionals use this for accurate market analysis across trading sessions. The date must conform to YYYYMMDD format. Systems should validate against business calendars.

Tag 273 (MDEntryTime)

Description: Time of market data entry.
MDEntryTime (273) specifies the timestamp for a market data entry. In FIX 4.2, this tag provides precise timing for market data records. Trading professionals rely on accurate timestamps for latency-sensitive strategies. The time must conform to HH:MM:SS format. Systems should validate against current time.

Tag 274 (TickDirection)

Description: Direction of price movement.
TickDirection (274) specifies the price movement direction using codes: 0=Plus Tick, 1=Zero-Plus Tick, etc. In FIX 4.2, this tag provides context for trade interpretation relative to previous prices. Trading professionals use this for market analysis and regulatory reporting. The field impacts tick rule implementation. Systems should validate against standard tick directions.

Tag 275 (MDMkt)

Description: Market of the market data entry.
MDMkt (275) specifies the trading venue for a market data entry. In FIX 4.2, this alphanumeric tag identifies the source of market data. Trading professionals use this for venue-specific analysis and routing decisions. The field must conform to exchange code conventions. Systems should validate against exchange reference data.

Tag 276 (QuoteCondition)

Description: Condition of the quote.
QuoteCondition (276) specifies the status of a quote using codes: S=Synthetic, R=Restricted. In FIX 4.2, this tag provides context for quote interpretation. Trading professionals use this to assess quote reliability and execution likelihood. The field impacts quote handling logic. Systems should validate against supported quote conditions.

Tag 277 (TradeCondition)

Description: Condition of the trade.
TradeCondition (277) specifies the status of a trade using codes: 1=Imbalance More Buyers, 2=Imbalance More Sellers. In FIX 4.2, this tag provides context for trade interpretation. Trading professionals use this for market analysis and regulatory reporting. The field impacts trade handling logic. Systems should validate against supported trade conditions.

Tag 278 (MDEntryID)

Description: Identifier for market data entry.
MDEntryID (278) serves as the unique reference for a market data entry. In FIX 4.2, this alphanumeric field enables tracking of individual market data records. Trading professionals use this for sophisticated market data processing. The identifier should be consistent for the same price level. Systems should use for order book management.

Tag 279 (MDUpdateAction)

Description: Action for market data update.
MDUpdateAction (279) specifies the update action using codes: 0=New, 1=Change, 2=Delete. In FIX 4.2, this critical tag determines how market data should be applied to the order book. Trading professionals rely on accurate update actions for correct order book reconstruction. The field must align with market data processing rules. Systems should validate against supported update actions.

Tag 280 (MDEntryRefID)

Description: Reference identifier for market data entry.
MDEntryRefID (280) provides a cross-reference to a previous market data entry. In FIX 4.2, this alphanumeric field enables modification or deletion of existing market data records. Trading professionals use this for proper order book maintenance. The field must reference an active market data entry. Systems should validate against existing entries.

Tag 281 (MDReqRejReason)

Description: Reason for market data request rejection.
MDReqRejReason (281) specifies why a market data request was rejected using codes: 0=Unknown Symbol, 1=Exchange closed. In FIX 4.2, this tag provides diagnostic information for market data connectivity issues. Trading professionals use this to diagnose and correct market data request errors. The field must conform to standard rejection reasons. Systems should map to actionable error messages.

Tag 282 (MDEntryOriginator)

Description: Originator of market data entry.
MDEntryOriginator (282) identifies the source of a market data entry. In FIX 4.2, this alphanumeric tag provides transparency into market data provenance. Trading professionals use this for venue-specific analysis and reliability assessment. The identifier should correspond to a known market participant. Systems should validate against approved sources.

Tag 283 (LocationID)

Description: Location identifier.
LocationID (283) specifies the physical or logical location of a trading system. In FIX 4.2, this alphanumeric tag enables geographically distributed systems to identify message sources. Trading professionals use this for latency optimization and regulatory reporting. The identifier should follow organizational naming conventions. Systems may use this for routing decisions.

Tag 284 (DeskID)

Description: Desk identifier.
DeskID (284) specifies the trading desk within an organization. In FIX 4.2, this alphanumeric tag enables granular attribution of trading activity. Trading professionals use this for performance measurement and regulatory reporting. The identifier should follow organizational naming conventions. Systems should validate against approved desks.

Tag 285 (DeleteReason)

Description: Reason for deletion.
DeleteReason (285) specifies why a market data entry was deleted using codes: 0=Cancelation, 1=Error. In FIX 4.2, this tag provides context for market data deletions. Trading professionals use this for order book maintenance and analysis. The field must conform to standard deletion reasons. Systems should validate against supported deletion reasons.

Tag 286 (OpenCloseSettleFlag)

Description: Open/close/settlement indicator.
OpenCloseSettleFlag (286) specifies the session context using codes: 0=Daily Open, 1=Session Open, 2=Delivery Settle, etc. In FIX 4.2, this tag provides context for price interpretation. Trading professionals use this for accurate session management and regulatory reporting. The field impacts how prices are treated in calculations. Systems should validate against supported flags.

Tag 287 (SellerDays)

Description: Number of days for seller.
SellerDays (287) specifies the settlement period for the seller. In FIX 4.2, this numeric field is used in certain fixed income transactions. Trading professionals use this for accurate settlement scheduling. The field must conform to standard settlement conventions. Systems should validate against instrument-specific rules.

Tag 288 (MDEntryBuyer)

Description: Buyer of market data entry.
MDEntryBuyer (288) identifies the buyer in a market data entry. In FIX 4.2, this alphanumeric tag provides transparency into trade counterparties. Trading professionals use this for market analysis and regulatory reporting. The identifier should correspond to a known market participant. Systems should validate against approved participants.

Tag 289 (MDEntrySeller)

Description: Seller of market data entry.
MDEntrySeller (289) identifies the seller in a market data entry. In FIX 4.2, this alphanumeric tag provides transparency into trade counterparties. Trading professionals use this for market analysis and regulatory reporting. The identifier should correspond to a known market participant. Systems should validate against approved participants.

Tag 290 (MDEntryPositionNo)

Description: Position number in market depth.
MDEntryPositionNo (290) specifies the position in the market depth for an entry. In FIX 4.2, this numeric field enables precise ordering of price levels. Trading professionals use this for accurate order book reconstruction. The field must conform to market depth sequencing rules. Systems should validate against position constraints.

Tag 291 (FinancialStatus)

Description: Financial status of the instrument.
FinancialStatus (291) specifies the financial condition using codes: 1=Bankrupt, 2=Pending delisting. In FIX 4.2, this tag provides context for instrument risk assessment. Trading professionals use this for risk management and regulatory compliance. The field impacts trading eligibility and margin requirements. Systems should validate against supported status codes.

Tag 292 (CorporateAction)

Description: Corporate action indicator.
CorporateAction (292) specifies corporate actions using codes: A=Ex-Dividend, B=Ex-Distribution. In FIX 4.2, this tag provides context for instrument adjustments. Trading professionals use this for accurate position management during corporate events. The field impacts pricing and contract specifications. Systems should validate against supported action codes.

Tag 293 (DefBidSize)

Description: Default bid size.
DefBidSize (293) specifies the default bid quantity for market making. In FIX 4.2, this numeric field provides context for market maker obligations. Trading professionals use this for liquidity assessment. The field must conform to venue-specific requirements. Systems should validate against exchange rules.

Tag 294 (DefOfferSize)

Description: Default offer size.
DefOfferSize (294) specifies the default offer quantity for market making. In FIX 4.2, this numeric field provides context for market maker obligations. Trading professionals use this for liquidity assessment. The field must conform to venue-specific requirements. Systems should validate against exchange rules.

Tag 295 (NoQuoteEntries)

Description: Number of quote entries.
NoQuoteEntries (295) specifies the count of quote entries in a message. In FIX 4.2, this numeric tag defines how many quote components follow. Trading professionals use this for proper parsing of complex quotes. The field must match the actual number of entries. Systems should validate against the actual entry count.

Tag 296 (NoQuoteSets)

Description: Number of quote sets.
NoQuoteSets (296) specifies the count of quote sets in a message. In FIX 4.2, this numeric tag defines how many quote groups follow. Trading professionals use this for proper parsing of multi-instrument quotes. The field must match the actual number of sets. Systems should validate against the actual set count.

Tag 297 (QuoteAckStatus)

Description: Quote acknowledgment status.
QuoteAckStatus (297) specifies the status of quote processing using codes: 0=Accepted, 1=Cancelled, 2=Rejected. In FIX 4.2, this tag provides feedback on quote handling. Trading professionals use this for quote management and troubleshooting. The field must align with business logic for quote processing. Systems should trigger appropriate workflows.

Tag 298 (QuoteCancelType)

Description: Type of quote cancellation.
QuoteCancelType (298) specifies the cancellation scope using codes: 1=Cancel for Symbol, 2=Cancel for Security Type. In FIX 4.2, this tag determines how broadly a quote cancellation applies. Trading professionals use this for precise quote management. The field impacts which quotes are affected by cancellation requests. Systems should validate against supported cancellation types.

Tag 299 (QuoteEntryID)

Description: Identifier for a quote entry.
QuoteEntryID (299) serves as the unique reference for a quote component. In FIX 4.2, this alphanumeric field enables tracking of individual quote elements. Trading professionals use this for accurate quote management. The identifier must be unique per quote set. Systems must prevent duplicate quote processing.

Tag 300 (QuoteRejectReason)

Description: Reason for quote rejection.
QuoteRejectReason (300) specifies why a quote was rejected using codes: 1=Unknown Symbol, 2=Exchange closed. In FIX 4.2, this tag provides diagnostic information for quote processing failures. Trading professionals use this to diagnose and correct quote submission errors. The field must conform to standard rejection reasons. Systems should map to actionable error messages.

Tag 301 (QuoteResponseLevel)

Description: Level of quote response required.
QuoteResponseLevel (301) specifies the expected response using codes: 1=Always Respond, 2=No Ack on Trade. In FIX 4.2, this tag determines how quote responses should be handled. Trading professionals use this to optimize quote processing efficiency. The field impacts bandwidth usage and response handling. Systems should validate against supported response levels.

Tag 302 (QuoteSetID)

Description: Identifier for a quote set.
QuoteSetID (302) serves as the unique reference for a group of related quotes. In FIX 4.2, this alphanumeric field enables tracking of quote collections. Trading professionals use this for managing multi-instrument quote strategies. The identifier must be unique per session. Systems must prevent duplicate quote set processing.

Tag 303 (QuoteRequestType)

Description: Type of quote request.
QuoteRequestType (303) specifies the request purpose using codes: 1=Manual, 2=Automatic. In FIX 4.2, this tag provides context for quote request handling. Trading professionals use this to prioritize quote requests based on origin. The field impacts quote processing workflows. Systems should validate against supported request types.

Tag 304 (TotQuoteEntries)

Description: Total number of quote entries.
TotQuoteEntries (304) specifies the complete count of quotes in a set. In FIX 4.2, this numeric tag enables validation of quote set completeness. Trading professionals use this to ensure all expected quotes are received. The field must match the actual number of quote entries. Systems should validate against the actual entry count.

Tag 305 (UnderlyingIDSource)

Description: Source of underlying security identifier.
UnderlyingIDSource (305) specifies the methodology for identifying underlying securities. In FIX 4.2, this tag works with SecurityIDSource for multi-leg instruments. Trading professionals use this for accurate complex instrument identification. The field must conform to standard identifier sources. Systems should validate against supported sources.

Tag 306 (UnderlyingIssuer)

Description: Issuer of underlying security.
UnderlyingIssuer (306) provides the name of the underlying security’s issuer. In FIX 4.2, this alphanumeric tag offers additional context for complex instruments. Trading professionals use this for reference data management. The field supports free-form issuer names, requiring normalization. Systems should validate against reference data.

Tag 307 (UnderlyingSecurityDesc)

Description: Description of underlying security.
UnderlyingSecurityDesc (307) provides a human-readable description of the underlying security. In FIX 4.2, this field offers additional context for complex instruments. Trading professionals use this for operational clarity. The field supports free-form text, requiring consistent formatting. Systems should log for reference.

Tag 308 (UnderlyingSecurityExchange)

Description: Exchange of underlying security.
UnderlyingSecurityExchange (308) specifies the primary listing exchange for the underlying security. In FIX 4.2, this alphanumeric tag provides context for complex instrument routing. Trading professionals use this for accurate instrument handling. The field must conform to exchange code conventions. Systems should validate against exchange reference data.

Tag 309 (UnderlyingSecurityID)

Description: Identifier for underlying security.
UnderlyingSecurityID (309) provides the actual identifier value for the underlying security. In FIX 4.2, this alphanumeric field works with UnderlyingIDSource to unambiguously identify underlying instruments. Trading professionals rely on accurate mapping to prevent instrument misidentification. The field requires robust reference data management. Systems must validate format against IDSource rules.

Tag 310 (UnderlyingSecurityType)

Description: Type of underlying security.
UnderlyingSecurityType (310) specifies the instrument type of the underlying security. In FIX 4.2, this tag is critical for proper handling of complex instruments. Trading professionals rely on accurate specification for correct order routing. The field impacts price and quantity conventions. Systems should validate against supported security types.

Tag 311 (UnderlyingSymbol)

Description: Symbol of underlying security.
UnderlyingSymbol (311) provides the primary trading symbol for the underlying security. In FIX 4.2, this alphanumeric tag is critical for underlying instrument identification. Trading professionals rely on consistent symbol mapping to prevent execution errors. The field requires robust reference data management. Systems must validate against venue-specific naming conventions.

Tag 312 (UnderlyingSymbolSfx)

Description: Symbol suffix of underlying security.
UnderlyingSymbolSfx (312) provides additional qualifier for the underlying symbol. In FIX 4.2, this tag is rarely used but remains for legacy compatibility. Trading professionals should be aware of its existence but typically don’t need to handle it actively. The field may appear in certain market data contexts.

Tag 313 (UnderlyingMaturityMonthYear)

Description: Maturity of underlying security.
UnderlyingMaturityMonthYear (313) specifies the maturity date for underlying derivatives. In FIX 4.2, this alphanumeric field is critical for options and futures identification. Trading professionals rely on accurate maturity specification for correct instrument handling. The field must conform to standard date formats. Systems should validate against exchange contract calendars.

Tag 314 (UnderlyingMaturityDay)

Description: Maturity day of underlying security.
UnderlyingMaturityDay (314) specifies the day of maturity for underlying derivatives. In FIX 4.2, this numeric field works with UnderlyingMaturityMonthYear. Trading professionals use this for accurate instrument identification. The field must conform to calendar constraints. Systems should validate against exchange contract calendars.

Tag 315 (UnderlyingPutOrCall)

Description: Put/call of underlying security.
UnderlyingPutOrCall (315) specifies the option type of the underlying security. In FIX 4.2, this numeric tag is fundamental for options-based derivatives. Trading professionals must ensure accurate designation to prevent execution errors. The field impacts pricing models and risk calculations. Systems should validate against instrument definitions.

Tag 316 (UnderlyingStrikePrice)

Description: Strike price of underlying security.
UnderlyingStrikePrice (316) specifies the exercise price for underlying options. In FIX 4.2, this numeric field is critical for options-based derivatives. Trading professionals rely on precise strike price specification for accurate order handling. The field requires careful handling of price precision rules. Systems should validate against exchange strike price rules.

Tag 317 (UnderlyingOptAttribute)

Description: Option attribute of underlying security.
UnderlyingOptAttribute (317) specifies the style of the underlying option. In FIX 4.2, this alphanumeric tag determines exercise rules for underlying options. Trading professionals must ensure accurate attribute specification. The field impacts pricing models and risk calculations. Systems should validate against instrument definitions.

Tag 318 (UnderlyingCurrency)

Description: Currency of underlying security.
UnderlyingCurrency (318) specifies the currency for the underlying security. In FIX 4.2, this tag defines the currency in which the underlying instrument is denominated. Trading professionals must ensure accurate currency designation for proper valuation. The field impacts regulatory reporting requirements. Systems should validate against ISO 4217 standards.

Tag 319 (RatioQty)

Description: Ratio quantity.
RatioQty (319) specifies the quantity ratio for multi-leg instruments. In FIX 4.2, this numeric field defines the component proportions in complex strategies. Trading professionals use this for accurate basket and spread trading. The field must conform to strategy-specific ratio rules. Systems should validate against supported ratio constraints.

Tag 320 (SecurityReqID)

Description: Security request identifier.
SecurityReqID (320) serves as the unique reference for security definition requests. In FIX 4.2, this alphanumeric field enables tracking of security inquiries. Trading professionals use this for instrument reference data management. The identifier must be unique per session. Systems must prevent duplicate request processing.

Tag 321 (SecurityRequestType)

Description: Type of security request.
SecurityRequestType (321) specifies the request purpose using codes: 0=Request Security Identity, 1=Request Market Depth. In FIX 4.2, this numeric tag determines how security requests should be handled. Trading professionals use this to obtain instrument reference data. The field impacts data retrieval workflows. Systems should validate against supported request types.

Tag 322 (SecurityResponseID)

Description: Security response identifier.
SecurityResponseID (322) serves as the unique reference for security definition responses. In FIX 4.2, this alphanumeric field enables correlation of requests with responses. Trading professionals use this for reference data management. The identifier must match the corresponding request ID. Systems must prevent duplicate response processing.

Tag 323 (SecurityResponseType)

Description: Type of security response.
SecurityResponseType (323) specifies the response nature using codes: 1=Accept Security Proposal, 2=Reject Security Proposal. In FIX 4.2, this numeric tag provides feedback on security requests. Trading professionals use this to diagnose reference data issues. The field must align with request processing logic. Systems should trigger appropriate workflows.

Tag 324 (SecurityStatusReqID)

Description: Security status request identifier.
SecurityStatusReqID (324) serves as the unique reference for security status requests. In FIX 4.2, this alphanumeric field enables tracking of instrument status inquiries. Trading professionals use this for real-time instrument monitoring. The identifier must be unique per session. Systems must prevent duplicate request processing.

Tag 325 (UnsolicitedIndicator)

Description: Indicates unsolicited message.
UnsolicitedIndicator (325) signals whether a message is unsolicited using ‘Y’ or ‘N’. In FIX 4.2, this tag identifies system-generated notifications rather than request responses. Trading professionals use this to distinguish between solicited and unsolicited information. The field impacts message handling logic. Systems should process unsolicited messages appropriately.

Tag 326 (SecurityTradingStatus)

Description: Current trading status of security.
SecurityTradingStatus (326) specifies the instrument’s trading state using codes: 1=Opening Delay, 2=Trading Halt. In FIX 4.2, this numeric tag provides critical context for order eligibility. Trading professionals use this to prevent orders during trading restrictions. The field impacts order routing and execution. Systems should validate against current trading status.

Tag 327 (HaltReason)

Description: Reason for trading halt.
HaltReason (327) specifies why trading is halted using codes: 0=News Dissemination, 1=Order Influx. In FIX 4.2, this tag provides context for trading status changes. Trading professionals use this for market analysis and risk management. The field impacts trading decisions during market disruptions. Systems should validate against supported halt reasons.

Tag 328 (InViewOfCommon)

Description: Indicates halt due to common stock issue.
InViewOfCommon (328) signals whether a halt affects related securities using ‘Y’ or ‘N’. In FIX 4.2, this tag provides context for trading halts impacting multiple instruments. Trading professionals use this for comprehensive risk management. The field impacts how halts are interpreted for complex instruments. Systems should validate according to exchange rules.

Tag 329 (DueToRelated)

Description: Indicates halt due to related security.
DueToRelated (329) signals whether a halt is caused by a related security using ‘Y’ or ‘N’. In FIX 4.2, this tag provides context for trading halts impacting multiple instruments. Trading professionals use this for comprehensive risk management. The field impacts how halts are interpreted for complex instruments. Systems should validate according to exchange rules.

Tag 330 (BuyVolume)

Description: Total buy volume.
BuyVolume (330) specifies the cumulative buy-side trading volume. In FIX 4.2, this numeric field provides market context for volume analysis. Trading professionals use this for liquidity assessment and execution strategies. The field must conform to venue-specific reporting rules. Systems should validate against expected volume patterns.

Tag 331 (SellVolume)

Description: Total sell volume.
SellVolume (331) specifies the cumulative sell-side trading volume. In FIX 4.2, this numeric field provides market context for volume analysis. Trading professionals use this for liquidity assessment and execution strategies. The field must conform to venue-specific reporting rules. Systems should validate against expected volume patterns.

Tag 332 (HighPx)

Description: High price.
HighPx (332) specifies the highest traded price during a period. In FIX 4.2, this numeric field provides context for price range analysis. Trading professionals use this for volatility assessment and execution strategies. The field requires careful handling of price precision rules. Systems should validate against current market prices.

Tag 333 (LowPx)

Description: Low price.
LowPx (333) specifies the lowest traded price during a period. In FIX 4.2, this numeric field provides context for price range analysis. Trading professionals use this for volatility assessment and execution strategies. The field requires careful handling of price precision rules. Systems should validate against current market prices.

Tag 334 (Adjustment)

Description: Price adjustment indicator.
Adjustment (334) specifies price adjustment type using codes: 1=Cancel, 2=Error, 3=Correction. In FIX 4.2, this tag provides context for price changes. Trading professionals use this to interpret price movements correctly. The field impacts how prices are treated in calculations. Systems should validate against supported adjustment types.

Tag 335 (TradSesReqID)

Description: Trading session request identifier.
TradSesReqID (335) serves as the unique reference for trading session inquiries. In FIX 4.2, this alphanumeric field enables tracking of session status requests. Trading professionals use this for session monitoring and connectivity management. The identifier must be unique per session. Systems must prevent duplicate request processing.

Tag 336 (TradingSessionID)

Description: Identifier for a trading session.
TradingSessionID (336) specifies the trading session using venue-specific codes. In FIX 4.2, this alphanumeric tag identifies the current market phase (e.g., pre-market, regular, after-hours). Trading professionals use this for session-aware trading strategies. The field must conform to venue-specific session codes. Systems should validate against supported session IDs.

Tag 337 (ContraTrader)

Description: Counterparty trader identifier.
ContraTrader (337) identifies the counterparty’s trader in an execution. In FIX 4.2, this alphanumeric tag provides transparency into trade counterparties. Trading professionals use this for relationship management and regulatory reporting. The identifier should correspond to a known market participant. Systems should validate against approved participants.

Tag 338 (TradSesMethod)

Description: Trading session method.
TradSesMethod (338) specifies the trading method using codes: 1=Electronic, 2=Open Outcry. In FIX 4.2, this numeric tag provides context for execution venue. Trading professionals use this for best execution analysis and regulatory reporting. The field impacts how trades are categorized. Systems should validate against supported methods.

Tag 339 (TradSesMode)

Description: Trading session mode.
TradSesMode (339) specifies the session mode using codes: 1=Testing, 2=Simulated, 3=Production. In FIX 4.2, this numeric tag identifies the operational context of the session. Trading professionals use this to distinguish between test and production environments. The field impacts how messages are processed. Systems should validate against expected mode.

Tag 340 (TradSesStatus)

Description: Trading session status.
TradSesStatus (340) specifies the current state of the trading session using codes: 1=Halted, 2=Open, 3=Closed. In FIX 4.2, this numeric tag provides critical context for order eligibility. Trading professionals use this to prevent orders during inactive sessions. The field impacts order routing and execution. Systems should validate against current session status.

Tag 341 (TradSesStartTime)

Description: Trading session start time.
TradSesStartTime (341) specifies the scheduled start time for a trading session. In FIX 4.2, this timestamp field enables session timing awareness. Trading professionals use this for session-aware trading strategies. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 342 (TradSesOpenTime)

Description: Actual trading session open time.
TradSesOpenTime (342) specifies the actual start time of a trading session. In FIX 4.2, this timestamp field provides precise session timing information. Trading professionals use this for accurate session monitoring. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 343 (TradSesPreCloseTime)

Description: Pre-close time for trading session.
TradSesPreCloseTime (343) specifies the pre-close period start time. In FIX 4.2, this timestamp field enables session phase awareness. Trading professionals use this for session-phase-specific strategies. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 344 (TradSesCloseTime)

Description: Trading session close time.
TradSesCloseTime (344) specifies the scheduled close time for a trading session. In FIX 4.2, this timestamp field enables session timing awareness. Trading professionals use this for session-aware trading strategies. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 345 (TradSesEndTime)

Description: Trading session end time.
TradSesEndTime (345) specifies the actual end time of a trading session. In FIX 4.2, this timestamp field provides precise session timing information. Trading professionals use this for accurate session monitoring. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 346 (NumberOfOrders)

Description: Number of orders in the market.
NumberOfOrders (346) specifies the total number of orders in the market. In FIX 4.2, this numeric field provides context for market depth analysis. Trading professionals use this for liquidity assessment. The field must conform to venue-specific reporting rules. Systems should validate against expected order count patterns.

Tag 347 (MessageEncoding)

Description: Encoding of message fields.
MessageEncoding (347) specifies the character encoding used for message fields. In FIX 4.2, this tag defines how non-ASCII characters should be interpreted. Trading professionals working with international markets use this for proper character handling. The field impacts how message content is processed. Systems should validate against supported encodings.

Tag 348 (EncodedIssuerLen)

Description: Length of encoded issuer field.
EncodedIssuerLen (348) specifies the byte length of encoded issuer data. In FIX 4.2, this numeric tag enables proper parsing of encoded issuer information. Trading professionals use this for handling issuer names with special characters. The field works with EncodedIssuer for international character support. Systems must validate against actual data length.

Tag 349 (EncodedIssuer)

Description: Encoded issuer field.
EncodedIssuer (349) contains the issuer name in encoded format. In FIX 4.2, this field supports issuer names with non-ASCII characters. Trading professionals use this for accurate reference data in international markets. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 350 (EncodedSecurityDescLen)

Description: Length of encoded security description.
EncodedSecurityDescLen (350) specifies the byte length of encoded security description data. In FIX 4.2, this numeric tag enables proper parsing of encoded security descriptions. Trading professionals use this for handling security descriptions with special characters. The field works with EncodedSecurityDesc for international character support. Systems must validate against actual data length.

Tag 351 (EncodedSecurityDesc)

Description: Encoded security description field.
EncodedSecurityDesc (351) contains the security description in encoded format. In FIX 4.2, this field supports security descriptions with non-ASCII characters. Trading professionals use this for accurate reference data in international markets. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 352 (EncodedListExecInstLen)

Description: Length of encoded list execution instructions.
EncodedListExecInstLen (352) specifies the byte length of encoded list execution instructions. In FIX 4.2, this numeric tag enables proper parsing of encoded list instructions. Trading professionals use this for handling complex list instructions with special characters. The field works with EncodedListExecInst for international character support. Systems must validate against actual data length.

Tag 353 (EncodedListExecInst)

Description: Encoded list execution instructions field.
EncodedListExecInst (353) contains list execution instructions in encoded format. In FIX 4.2, this field supports list instructions with non-ASCII characters. Trading professionals use this for accurate list processing in international contexts. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 354 (EncodedTextLen)

Description: Length of encoded text field.
EncodedTextLen (354) specifies the byte length of encoded text data. In FIX 4.2, this numeric tag enables proper parsing of encoded text messages. Trading professionals use this for handling text with special characters. The field works with EncodedText for international character support. Systems must validate against actual data length.

Tag 355 (EncodedText)

Description: Encoded text field.
EncodedText (355) contains text content in encoded format. In FIX 4.2, this field supports text messages with non-ASCII characters. Trading professionals use this for accurate communication in international contexts. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 356 (EncodedSubjectLen)

Description: Length of encoded subject field.
EncodedSubjectLen (356) specifies the byte length of encoded subject data. In FIX 4.2, this numeric tag enables proper parsing of encoded email subjects. Trading professionals use this for handling subjects with special characters. The field works with EncodedSubject for international character support. Systems must validate against actual data length.

Tag 357 (EncodedSubject)

Description: Encoded subject field.
EncodedSubject (357) contains email subject content in encoded format. In FIX 4.2, this field supports subjects with non-ASCII characters. Trading professionals use this for accurate email communication in international contexts. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 358 (EncodedHeadlineLen)

Description: Length of encoded headline field.
EncodedHeadlineLen (358) specifies the byte length of encoded news headline data. In FIX 4.2, this numeric tag enables proper parsing of encoded news headlines. Trading professionals use this for handling headlines with special characters. The field works with EncodedHeadline for international character support. Systems must validate against actual data length.

Tag 359 (EncodedHeadline)

Description: Encoded headline field.
EncodedHeadline (359) contains news headline content in encoded format. In FIX 4.2, this field supports headlines with non-ASCII characters. Trading professionals use this for accurate news dissemination in international contexts. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 360 (EncodedAllocTextLen)

Description: Length of encoded allocation text.
EncodedAllocTextLen (360) specifies the byte length of encoded allocation text data. In FIX 4.2, this numeric tag enables proper parsing of encoded allocation instructions. Trading professionals use this for handling allocation text with special characters. The field works with EncodedAllocText for international character support. Systems must validate against actual data length.

Tag 361 (EncodedAllocText)

Description: Encoded allocation text field.
EncodedAllocText (361) contains allocation text in encoded format. In FIX 4.2, this field supports allocation instructions with non-ASCII characters. Trading professionals use this for accurate allocation processing in international contexts. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 362 (EncodedUnderlyingIssuerLen)

Description: Length of encoded underlying issuer.
EncodedUnderlyingIssuerLen (362) specifies the byte length of encoded underlying issuer data. In FIX 4.2, this numeric tag enables proper parsing of encoded underlying issuer information. Trading professionals use this for handling issuer names with special characters in complex instruments. The field works with EncodedUnderlyingIssuer for international character support. Systems must validate against actual data length.

Tag 363 (EncodedUnderlyingIssuer)

Description: Encoded underlying issuer field.
EncodedUnderlyingIssuer (363) contains the underlying issuer name in encoded format. In FIX 4.2, this field supports issuer names with non-ASCII characters for complex instruments. Trading professionals use this for accurate reference data in international markets. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 364 (EncodedUnderlyingSecurityDescLen)

Description: Length of encoded underlying security description.
EncodedUnderlyingSecurityDescLen (364) specifies the byte length of encoded underlying security description data. In FIX 4.2, this numeric tag enables proper parsing of encoded underlying security descriptions. Trading professionals use this for handling descriptions with special characters. The field works with EncodedUnderlyingSecurityDesc for international character support. Systems must validate against actual data length.

Tag 365 (EncodedUnderlyingSecurityDesc)

Description: Encoded underlying security description field.
EncodedUnderlyingSecurityDesc (365) contains the underlying security description in encoded format. In FIX 4.2, this field supports descriptions with non-ASCII characters for complex instruments. Trading professionals use this for accurate reference data in international markets. The interpretation depends on MessageEncoding. Systems must decode according to specified encoding.

Tag 366 (AllocPrice)

Description: Allocation price.
AllocPrice (366) specifies the price for allocation instructions. In FIX 4.2, this numeric field provides the definitive price for settlement calculations within allocation messages. Trading professionals rely on accurate price reporting for position valuation. The field must align with execution price calculations. Systems should validate against expected price values.

Tag 367 (QuoteSetValidUntilTime)

Description: Validity time for quote set.
QuoteSetValidUntilTime (367) specifies when a quote set expires. In FIX 4.2, this timestamp field enables time-limited quote offers. Trading professionals use this for precise quote management. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 368 (QuoteEntryRejectReason)

Description: Reason for quote entry rejection.
QuoteEntryRejectReason (368) specifies why a quote entry was rejected using codes: 1=Unknown Symbol, 2=Invalid Price. In FIX 4.2, this tag provides diagnostic information for quote processing failures. Trading professionals use this to diagnose and correct quote submission errors. The field must conform to standard rejection reasons. Systems should map to actionable error messages.

Tag 369 (LastMsgSeqNumProcessed)

Description: Last processed message sequence number.
LastMsgSeqNumProcessed (369) specifies the highest sequence number successfully processed. In FIX 4.2, this numeric tag enables efficient gap detection and recovery. Trading professionals use this for session synchronization during connectivity interruptions. The field must reflect the actual processing state. Systems should update this value accurately.

Tag 370 (OnBehalfOfSendingTime)

Description: Sending time of originator.
OnBehalfOfSendingTime (370) specifies the timestamp from the original sender in multi-hop networks. In FIX 4.2, this timestamp field provides accurate timing context for messages routed through intermediaries. Trading professionals use this for precise latency measurement and regulatory reporting. The timestamp must conform to FIX datetime format. Systems should validate against current time.

Tag 371 (RefTagID)

Description: Reference tag ID for rejection.
RefTagID (371) specifies the tag number that caused a rejection. In FIX 4.2, this numeric field enables precise identification of problematic fields in rejected messages. Trading professionals use this to diagnose and correct message errors efficiently. The field must reference a valid tag number. Systems should use for targeted error correction.

Tag 372 (RefMsgType)

Description: Reference message type for rejection.
RefMsgType (372) specifies the message type that caused a rejection. In FIX 4.2, this alphanumeric field enables precise identification of problematic message types. Trading professionals use this to diagnose and correct message errors efficiently. The field must reference a valid message type. Systems should use for targeted error correction.

Tag 373 (SessionRejectReason)

Description: Reason for session-level rejection.
SessionRejectReason (373) specifies why a message was rejected at the session level using codes: 0=Invalid Tag Number, 1=Required Tag Missing. In FIX 4.2, this critical tag provides diagnostic information for fundamental message errors. Trading professionals use this to diagnose connectivity and protocol issues. The field must conform to standard rejection reasons. Systems should map to actionable error messages.

Tag 374 (BidRequestTransType)

Description: Transaction type for bid request.
BidRequestTransType (374) specifies the bid request action using codes: N=New, C=Cancel. In FIX 4.2, this tag governs the lifecycle of bid requests. Trading professionals must implement proper state management for bid request transactions. Systems should validate transition sequences to ensure business logic integrity.

Tag 375 (ContraBroker)

Description: Counterparty broker.
ContraBroker (375) identifies the counterparty’s broker in an execution. In FIX 4.2, this alphanumeric tag provides transparency into execution relationships. Trading professionals use this for broker performance evaluation and regulatory reporting. The identifier typically corresponds to a pre-negotiated value. Systems should maintain broker reference data.

Tag 376 (ComplianceID)

Description: Compliance identifier.
ComplianceID (376) serves as the reference for compliance checks. In FIX 4.2, this alphanumeric field enables tracking of regulatory compliance activities. Trading professionals use this for audit trails and regulatory reporting. The identifier should follow organizational naming conventions. Systems should validate against approved compliance IDs.

Tag 377 (SolicitedFlag)

Description: Indicates solicited message.
SolicitedFlag (377) signals whether a message was solicited using ‘Y’ or ‘N’. In FIX 4.2, this tag distinguishes between requested responses and unsolicited notifications. Trading professionals use this to manage message handling workflows. The field impacts how messages are processed and validated. Systems should handle solicited and unsolicited messages appropriately.

Tag 378 (ExecRestatementReason)

Description: Reason for execution restatement.
ExecRestatementReason (378) specifies why an execution report is being restated using codes: 1=GT Corporate Action, 2=GT Reconstruction. In FIX 4.2, this tag provides context for corrected execution reports. Trading professionals use this to interpret restatements correctly. The field must conform to standard restatement reasons. Systems should validate against supported reasons.

Tag 379 (BusinessRejectRefID)

Description: Reference ID for business reject.
BusinessRejectRefID (379) serves as the reference for business-level rejection notifications. In FIX 4.2, this alphanumeric field enables correlation of rejection notifications with original requests. Trading professionals use this to diagnose business rule violations. The identifier must match the rejected message’s reference. Systems should maintain rejection context.

Tag 380 (BusinessRejectReason)

Description: Reason for business-level rejection.
BusinessRejectReason (380) specifies why a message was rejected at the business level using codes: 0=Other, 1=Unknown ID, 2=Unknown Security. In FIX 4.2, this critical tag provides diagnostic information for business rule violations. Trading professionals use this

Tag 381 (GrossTradeAmt)

Description: Gross trade amount.
GrossTradeAmt (381) specifies the total monetary value of a trade before commissions, fees, and taxes. In FIX 4.2, this numeric field is critical for accurate trade valuation, regulatory reporting, and settlement calculations. Trading professionals rely on this value for precise P&L calculations and to distinguish between gross and net trade values. The field must align with price and quantity calculations (Price × Quantity), and discrepancies often indicate reconciliation issues. Systems should validate against expected values to prevent settlement errors, particularly in cross-currency transactions where FX rates impact the gross amount.

Tag 382 (NoContraBrokers)

Description: Number of contra brokers.
NoContraBrokers (382) specifies the count of counterparty brokers involved in a transaction. In FIX 4.2, this numeric tag defines how many ContraBroker fields follow in ExecutionReports, particularly for complex or multi-venue executions. Trading professionals use this to accurately attribute trades across multiple counterparties for regulatory reporting and commission allocation. The field must match the actual number of contra brokers reported. Systems should validate against the actual broker count to ensure complete counterparty identification, which is essential for MiFID II transparency requirements.

Tag 383 (MaxMessageSize)

Description: Maximum message size.
MaxMessageSize (383) specifies the largest message size a system can process, measured in bytes. In FIX 4.2, this numeric tag is exchanged during logon negotiation to prevent message fragmentation and processing failures. Trading professionals must configure compatible maximum sizes with counterparties to avoid rejected messages. The value typically ranges from 1,000-10,000 bytes depending on infrastructure capabilities. Systems should enforce this limit strictly to prevent denial-of-service vulnerabilities and ensure reliable message delivery across diverse network environments.

Tag 384 (NoMsgTypes)

Description: Number of message types.
NoMsgTypes (384) specifies the count of message types in a repeating group, primarily used in session management messages. In FIX 4.2, this numeric tag defines how many MsgType entries follow in messages like Business Message Reject. Trading professionals use this for precise protocol version compatibility checks and capability negotiation. The field must match the actual number of message types communicated. Systems should validate against the actual type count to ensure accurate session configuration and prevent misinterpretation of supported message types.

Tag 385 (MsgDirection)

Description: Message direction.
MsgDirection (385) specifies the direction of message flow using ‘S’=Send, ‘R’=Receive. In FIX 4.2, this tag enables precise tracking of message pathways in multi-hop FIX networks. Trading professionals use this for accurate audit trails and to verify message routing compliance. The field impacts how messages are processed in intermediary systems. Systems should validate against expected directions to prevent routing loops and ensure proper message handling according to network topology.

Tag 386 (NoTradingSessions)

Description: Number of trading sessions.
NoTradingSessions (386) specifies the count of trading session definitions in a repeating group. In FIX 4.2, this numeric tag defines how many TradingSessionID entries follow in security status or market data messages. Trading professionals use this to manage multi-session instruments like futures contracts with extended hours. The field must match the actual number of session definitions. Systems should validate against the actual session count to ensure comprehensive session awareness for time-sensitive trading strategies.

Tag 387 (TotalVolumeTraded)

Description: Total volume traded.
TotalVolumeTraded (387) specifies the cumulative trading volume for a security during a specific period. In FIX 4.2, this numeric field provides critical market context for liquidity assessment and execution quality analysis. Trading professionals use this for volume-based trading strategies and best execution compliance. The field must conform to venue-specific reporting rules and time windows. Systems should validate against expected volume patterns to detect anomalies or data feed issues.

Tag 388 (DiscretionInst)

Description: Discretion instructions.
DiscretionInst (388) specifies special handling for discretion orders using codes: 0=Related to displayed price, 1=Related to midpoint price. In FIX 4.2, this tag enables sophisticated order pricing strategies where the displayed price differs from the execution price. Trading professionals use this for implementation shortfall algorithms and dark liquidity access. The field impacts order execution behavior and regulatory reporting. Systems should validate against supported discretion instructions for each venue.

Tag 389 (DiscretionOffset)

Description: Discretion offset value.
DiscretionOffset (389) specifies the price offset for discretion orders from the displayed price. In FIX 4.2, this numeric field works with DiscretionInst to define dynamic order pricing. Trading professionals use this for precise control of discretion order execution. The field requires careful handling of price precision rules. Systems should validate against venue-specific offset constraints and ensure proper application to displayed prices.

Tag 390 (BidID)

Description: Bid identifier.
BidID (390) serves as the unique reference for a bid quote. In FIX 4.2, this alphanumeric field enables tracking and referencing of bid quotes across multiple messages. Trading professionals rely on BidID to correlate quote requests with responses and subsequent executions. The identifier must be unique per session. Systems must prevent duplicate bid processing and maintain proper bid state throughout the quote lifecycle.

Tag 391 (ClientBidID)

Description: Client bid identifier.
ClientBidID (391) provides a client-specific reference for bid quotes. In FIX 4.2, this alphanumeric field enables clients to track their own bid submissions across multiple counterparties. Trading professionals use this for enhanced audit trails and reconciliation of quote activity. The identifier should follow organizational naming conventions. Systems should log for reference but typically don’t require active processing beyond correlation.

Tag 392 (ListName)

Description: List name.
ListName (392) provides a descriptive identifier for order lists in list execution messages. In FIX 4.2, this alphanumeric field enables human-readable identification of complex order lists like baskets or portfolios. Trading professionals use this for operational clarity during list execution monitoring. The field supports free-form text, requiring consistent formatting. Systems should log for display purposes but typically don’t require active processing beyond identification.

Tag 393 (TotalNumSecurities)

Description: Total number of securities.
TotalNumSecurities (393) specifies the complete count of securities in a list or message. In FIX 4.2, this numeric field enables validation of list completeness for multi-security strategies. Trading professionals use this to ensure all expected securities are included in basket trades or portfolio replication. The field must match the actual number of securities referenced. Systems should validate against the actual security count to prevent partial list processing issues.

Tag 394 (BidType)

Description: Bid type.
BidType (394) specifies the nature of a bid using codes: 1=Competitive, 2=Not Competitive, 3=Non-Competitive. In FIX 4.2, this numeric tag provides context for bid interpretation in auction markets. Trading professionals use this to prioritize bid responses based on competitive status. The field impacts how bids are processed and matched. Systems should validate against supported bid types for each instrument and venue.

Tag 395 (NumTickets)

Description: Number of tickets.
NumTickets (395) specifies the count of order tickets associated with a trade. In FIX 4.2, this numeric field is used in allocation messages to indicate how many sub-orders comprise a larger execution. Trading professionals use this for accurate position distribution across multiple accounts. The field must match the actual number of tickets generated. Systems should validate against the actual ticket count to ensure proper allocation processing.

Tag 396 (SideValue1)

Description: Side value 1.
SideValue1 (396) provides additional value information for one side of a trade. In FIX 4.2, this numeric field is used in complex trading strategies like pairs trading to specify value metrics for the first leg. Trading professionals use this for sophisticated execution algorithms requiring dual-side value calculations. The field must align with strategy-specific value conventions. Systems should validate against expected value ranges for the specific strategy.

Tag 397 (SideValue2)

Description: Side value 2.
SideValue2 (397) provides additional value information for the second side of a trade. In FIX 4.2, this numeric field complements SideValue1 in multi-leg strategies, specifying value metrics for the second leg. Trading professionals use this for balanced execution in spread trading and statistical arbitrage. The field must align with strategy-specific value conventions. Systems should validate against expected value ranges and maintain proper relationship with SideValue1.

Tag 398 (NoBidDescriptors)

Description: Number of bid descriptors.
NoBidDescriptors (398) specifies the count of bid descriptors in a repeating group. In FIX 4.2, this numeric tag defines how many BidDescriptor fields follow in bid request messages. Trading professionals use this for proper parsing of complex bid requests with multiple descriptors. The field must match the actual number of descriptors. Systems should validate against the actual descriptor count to ensure complete bid request processing.

Tag 399 (BidDescriptorType)

Description: Bid descriptor type.
BidDescriptorType (399) specifies the category of a bid descriptor using codes: 1=SECTOR, 2=COUNTRY, 3=INDEX. In FIX 4.2, this numeric tag defines the context for bid descriptor values. Trading professionals use this to interpret bid descriptors correctly for sector-based or region-based liquidity assessment. The field must conform to standard descriptor types. Systems should validate against supported descriptor types to ensure proper bid interpretation.

Tag 400 (BidDescriptor)

Description: Bid descriptor.
BidDescriptor (400) provides the specific value for a bid descriptor. In FIX 4.2, this alphanumeric field works with BidDescriptorType to define the actual sector, country, or index reference. Trading professionals rely on accurate descriptor values for targeted liquidity access. The field must conform to standard naming conventions for the descriptor type. Systems should validate against reference data to ensure meaningful bid descriptor interpretation.

Tag 401 (SideValueInd)

Description: Side value indicator.
SideValueInd (401) specifies which side a value applies to using codes: 1=SideValue1, 2=SideValue2. In FIX 4.2, this numeric tag enables proper mapping of value metrics to specific legs in multi-leg strategies. Trading professionals use this for accurate position management in complex trading algorithms. The field must align with strategy-specific side conventions. Systems should validate against supported indicators to ensure correct value assignment.

Tag 402 (LiquidityPctLow)

Description: Low liquidity percentage.
LiquidityPctLow (402) specifies the lower bound of liquidity percentage for a security. In FIX 4.2, this numeric field provides context for liquidity assessment in market data messages. Trading professionals use this for execution quality analysis and venue selection. The field must conform to standard liquidity measurement conventions. Systems should validate against expected liquidity ranges to detect anomalies.

Tag 403 (LiquidityPctHigh)

Description: High liquidity percentage.
LiquidityPctHigh (403) specifies the upper bound of liquidity percentage for a security. In FIX 4.2, this numeric field complements LiquidityPctLow to define the liquidity range. Trading professionals use this for comprehensive liquidity assessment and execution strategy selection. The field must be greater than or equal to LiquidityPctLow. Systems should validate the relationship between high and low bounds to ensure meaningful liquidity representation.

Tag 404 (LiquidityValue)

Description: Liquidity value.
LiquidityValue (404) specifies the absolute liquidity value for a security. In FIX 4.2, this numeric field provides quantitative liquidity measurement in monetary terms. Trading professionals use this for position sizing and risk management decisions. The field must conform to standard liquidity calculation methodologies. Systems should validate against expected value ranges to ensure accurate liquidity assessment.

Tag 405 (EFPTrackingError)

Description: EFP tracking error.
EFPTrackingError (405) specifies the tracking error for Exchange for Physical transactions. In FIX 4.2, this numeric field measures the deviation between the futures and cash markets in EFP trades. Trading professionals use this for EFP execution quality assessment and strategy optimization. The field requires precise calculation methodology. Systems should validate against expected error thresholds to detect execution issues.

Tag 406 (FairValue)

Description: Fair value.
FairValue (406) specifies the theoretical fair value of a security. In FIX 4.2, this numeric field provides context for price deviation analysis, particularly for derivatives. Trading professionals use this for arbitrage opportunities and execution quality assessment. The field must align with accepted pricing models. Systems should validate against market prices to detect significant deviations.

Tag 407 (OutsideIndexPct)

Description: Outside index percentage.
OutsideIndexPct (407) specifies the percentage of a portfolio outside the main index. In FIX 4.2, this numeric field is used in portfolio management and rebalancing strategies. Trading professionals use this for tracking error management and compliance monitoring. The field must conform to portfolio construction conventions. Systems should validate against policy thresholds to ensure compliance.

Tag 408 (ValueOfFutures)

Description: Value of futures.
ValueOfFutures (408) specifies the monetary value of futures positions. In FIX 4.2, this numeric field provides context for futures-based strategies and risk management. Trading professionals use this for position valuation and margin calculations. The field must align with contract specifications and market prices. Systems should validate against expected value ranges to detect calculation errors.

Tag 409 (LiquidityIndType)

Description: Liquidity indicator type.
LiquidityIndType (409) specifies the methodology for liquidity measurement using codes: 1=5-Day Average, 2=20-Day Average, 3=Daily. In FIX 4.2, this tag provides context for interpreting liquidity values. Trading professionals use this to select appropriate liquidity metrics for different trading horizons. The field must conform to standard measurement methodologies. Systems should validate against supported types to ensure meaningful liquidity interpretation.

Tag 410 (WtAverageLiquidity)

Description: Weighted average liquidity.
WtAverageLiquidity (410) specifies the weighted average liquidity for a security or portfolio. In FIX 4.2, this numeric field provides a comprehensive liquidity measure accounting for different time horizons or venues. Trading professionals use this for sophisticated execution strategy selection. The field must align with accepted weighting methodologies. Systems should validate against component liquidity values to ensure calculation accuracy.

Tag 411 (ExchangeForPhysical)

Description: Exchange for physical indicator.
ExchangeForPhysical (411) signals whether an order is for Exchange for Physical using ‘Y’ or ‘N’. In FIX 4.2, this tag is critical for proper handling of EFP transactions in futures markets. Trading professionals must ensure accurate designation to comply with exchange rules for EFP execution. The field impacts order routing and execution mechanics. Systems should validate according to exchange EFP rules to prevent execution errors.

Tag 412 (OutMainCntryUIndex)

Description: Outside main country index.
OutMainCntryUIndex (412) specifies the index value outside the main country for international portfolios. In FIX 4.2, this numeric field provides context for global portfolio management. Trading professionals use this for country allocation monitoring and rebalancing. The field must conform to international indexing conventions. Systems should validate against policy thresholds to ensure compliance with country allocation limits.

Tag 413 (CrossPercent)

Description: Cross percentage.
CrossPercent (413) specifies the percentage for cross orders in block trading. In FIX 4.2, this numeric field defines the proportion of an order that may trade as a cross. Trading professionals use this for precise control of cross execution in dark pools. The field must be between 0-100. Systems should validate against venue-specific cross percentage rules to ensure proper order handling.

Tag 414 (ProgRptReqs)

Description: Progress report requests.
ProgRptReqs (414) specifies the frequency of progress reports using codes: 1=No Reports, 2=Daily, 3=Every Cumulative Trade. In FIX 4.2, this numeric tag determines how often execution progress should be reported for large orders. Trading professionals use this to balance monitoring needs with bandwidth usage. The field impacts reporting workflows and system resource allocation. Systems should validate against supported reporting frequencies to ensure proper report generation.

Tag 415 (ProgPeriodInterval)

Description: Progress period interval.
ProgPeriodInterval (415) specifies the time interval for progress reports in minutes. In FIX 4.2, this numeric field works with ProgRptReqs to define precise reporting schedules. Trading professionals use this for granular control of execution monitoring. The field must conform to venue-specific reporting rules. Systems should validate against minimum and maximum interval constraints to prevent excessive reporting.

Tag 416 (IncTaxInd)

Description: Include tax indicator.
IncTaxInd (416) specifies whether tax is included in price calculations using codes: 1=Include, 2=Exclude. In FIX 4.2, this numeric tag impacts price interpretation for tax-sensitive instruments. Trading professionals must ensure accurate designation to prevent valuation errors. The field affects regulatory reporting requirements. Systems should validate against instrument-specific tax conventions to ensure proper price handling.

Tag 417 (NumBidders)

Description: Number of bidders.
NumBidders (417) specifies the count of participants in an auction or bidding process. In FIX 4.2, this numeric field provides context for liquidity assessment in auction markets. Trading professionals use this for execution quality analysis in periodic auction venues. The field must conform to auction mechanics. Systems should validate against expected participant ranges to detect unusual auction conditions.

Tag 418 (TradeType)

Description: Trade type.
TradeType (418) specifies the nature of the trade using codes: G=VWAP Guarantee, J=Local Approximation. In FIX 4.2, this alphanumeric tag provides context for trade interpretation and regulatory reporting. Trading professionals use this to categorize trades for performance measurement and compliance. The field impacts how trades are processed in post-trade systems. Systems should validate against supported trade types to ensure proper categorization.

Tag 419 (BasisPxType)

Description: Basis price type.
BasisPxType (419) specifies the basis for price calculation using codes: 1=Modified Duration, 2=Risk. In FIX 4.2, this tag is critical for fixed income pricing, determining how yield-based prices are converted to monetary values. Trading professionals must ensure accurate designation to prevent valuation errors. The field impacts pricing models and risk calculations. Systems should validate against instrument definitions to ensure proper price conversion.

Tag 420 (NoBidComponents)

Description: Number of bid components.
NoBidComponents (420) specifies the count of components in a bid request. In FIX 4.2, this numeric tag defines how many bid component groups follow in complex bid messages. Trading professionals use this for proper parsing of multi-component bids. The field must match the actual number of components. Systems should validate against the actual component count to ensure complete bid request processing.

Tag 421 (Country)

Description: Country.
Country (421) specifies a country using ISO 3166 two-letter codes. In FIX 4.2, this alphanumeric field provides geographic context for instruments, accounts, and transactions. Trading professionals use this for regulatory reporting, tax treatment, and market segmentation. The field must conform to ISO 3166 standards. Systems should validate against approved country codes to ensure accurate geographic classification.

Tag 422 (TotNoStrikes)

Description: Total number of strikes.
TotNoStrikes (422) specifies the complete count of strike prices in an options chain message. In FIX 4.2, this numeric field enables validation of options chain completeness. Trading professionals use this to ensure all expected strike prices are included in market data feeds. The field must match the actual number of strikes reported. Systems should validate against exchange contract specifications to prevent incomplete options chain processing.

Tag 423 (PriceType)

Description: Price type.
PriceType (423) specifies the nature of a price using codes: 1=Percentage, 2=Per Unit, 3=Fixed Amount. In FIX 4.2, this numeric tag provides context for price interpretation, particularly for fixed income and derivatives. Trading professionals must ensure accurate designation to prevent valuation errors. The field impacts pricing models and settlement calculations. Systems should validate against instrument definitions to ensure proper price handling.

Tag 424 (DayOrderQty)

Description: Day order quantity.
DayOrderQty (424) specifies the quantity for day orders within a GTD (Good Till Date) context. In FIX 4.2, this numeric field enables partial day execution of longer-term orders. Trading professionals use this for sophisticated order management across multiple trading sessions. The field must not exceed the total order quantity. Systems should validate against order quantity and session rules to ensure proper day order handling.

Tag 425 (DayCumQty)

Description: Day cumulative quantity.
DayCumQty (425) specifies the cumulative quantity executed for day orders. In FIX 4.2, this numeric field tracks daily progress of GTD orders. Trading professionals use this for daily execution monitoring and compliance with time-based execution policies. The field must increment monotonically within the trading day. Systems should validate against order quantity and session rules to ensure accurate daily execution tracking.

Tag 426 (DayAvgPx)

Description: Day average price.
DayAvgPx (426) specifies the average execution price for day orders. In FIX 4.2, this numeric field provides the definitive price for daily execution assessment of GTD orders. Trading professionals rely on this for daily performance measurement and best execution analysis. The field must align with daily execution calculations. Systems should validate against expected price values to prevent daily execution reporting errors.

Tag 427 (GTBookingInst)

Description: GT booking instruction.
GTBookingInst (427) specifies how trades should be booked after the trading day using codes: 0=Book Out, 1=Accumulate, 2=Accumulate Quantity. In FIX 4.2, this numeric tag determines post-trade processing for GTD orders. Trading professionals use this for precise control of trade booking workflows. The field impacts allocation and settlement processing. Systems should validate against supported booking instructions to ensure proper post-trade handling.

Tag 428 (NoStrikes)

Description: Number of strikes.
NoStrikes (428) specifies the count of strike prices in a repeating group. In FIX 4.2, this numeric tag defines how many strike price entries follow in options chain messages. Trading professionals use this for proper parsing of options market data. The field must match the actual number of strikes. Systems should validate against the actual strike count to ensure complete options chain processing.

Tag 429 (ListStatusType)

Description: List status type.
ListStatusType (429) specifies the nature of a list status message using codes: 1=Acknowledgement, 2=Response, 3=Reports. In FIX 4.2, this numeric tag provides context for list execution status interpretation. Trading professionals use this to distinguish between different types of list status notifications. The field impacts how list status messages are processed. Systems should validate against supported status types to ensure proper list management.

Tag 430 (NetGrossInd)

Description: Net/gross indicator.
NetGrossInd (430) specifies whether amounts are net or gross of commissions using codes: 1=Net, 2=Gross. In FIX 4.2, this numeric tag impacts how trade values are interpreted for settlement and reporting. Trading professionals must ensure accurate designation to prevent valuation errors. The field affects regulatory reporting requirements. Systems should validate against instrument-specific conventions to ensure proper value interpretation.

Tag 431 (ListOrderStatus)

Description: List order status.
ListOrderStatus (431) specifies the status of individual orders within a list using codes: 1=Cancelled, 2=Replacing, 3=Add to List. In FIX 4.2, this numeric tag provides granular status information for complex order lists. Trading professionals use this for precise list execution monitoring. The field must align with list execution workflows. Systems should validate against supported status transitions to ensure proper list management.

Tag 432 (ExpireDate)

Description: Expiration date.
ExpireDate (432) specifies the date when a GTD (Good Till Date) order expires in YYYYMMDD format. In FIX 4.2, this tag works with TimeInForce=6 to define precise order expiration. Trading professionals must ensure accurate date specification to prevent premature cancellation or unintended persistence. The date must conform to calendar constraints and business days. Systems should validate against current date and session rules to ensure proper order expiration handling.

Tag 433 (ListExecInstType)

Description: List execution instruction type.
ListExecInstType (433) specifies the execution methodology for order lists using codes: 1=Immediate, 2=Wait, 3=Exchange for Physical. In FIX 4.2, this numeric tag determines how list execution instructions should be interpreted. Trading professionals use this for precise control of list execution behavior. The field impacts order routing and execution mechanics. Systems should validate against supported instruction types to ensure proper list handling.

Tag 434 (CxlRejResponseTo)

Description: Cancel rejection response to.
CxlRejResponseTo (434) specifies what the cancellation rejection refers to using codes: 1=Order Cancel Request, 2=Order Cancel/Replace Request. In FIX 4.2, this numeric tag provides context for cancellation rejection notifications. Trading professionals use this to diagnose and correct cancellation request errors. The field must align with the original cancellation request type. Systems should map to the appropriate request type for targeted error correction.

Tag 435 (UnderlyingCouponRate)

Description: Underlying coupon rate.
UnderlyingCouponRate (435) specifies the interest rate for underlying fixed income securities. In FIX 4.2, this numeric field is critical for accurate pricing of derivatives based on fixed income instruments. Trading professionals rely on precise coupon specification for correct valuation. The field impacts accrued interest calculations. Systems should validate against instrument definitions to ensure accurate derivative pricing.

Tag 436 (UnderlyingContractMultiplier)

Description: Underlying contract multiplier.
UnderlyingContractMultiplier (436) specifies the multiplier for underlying derivative contracts. In FIX 4.2, this numeric field is critical for accurate valuation of derivatives based on other derivatives. Trading professionals use this for precise position valuation and risk calculations. The field must conform to exchange contract specifications. Systems should validate against instrument definitions to ensure accurate valuation.

Tag 437 (ContraTradeQty)

Description: Contra trade quantity.
ContraTradeQty (437) specifies the quantity for the counterparty in a trade. In FIX 4.2, this numeric field provides transparency into trade details for both sides of a transaction. Trading professionals use this for reconciliation and regulatory reporting. The field must match the trade quantity from the counterparty’s perspective. Systems should validate against expected values to ensure accurate trade reporting.

Tag 438 (ContraTradeTime)

Description: Contra trade time.
ContraTradeTime (438) specifies when the counterparty executed the trade. In FIX 4.2, this timestamp field provides precise timing context for trade reconciliation. Trading professionals use this to resolve timing discrepancies between counterparties. The timestamp must conform to FIX datetime format. Systems should validate against current time and session rules to ensure accurate trade timing.

Tag 439 (ClearingFirm)

Description: Clearing firm.
ClearingFirm (439) specifies the clearing firm for a trade. In FIX 4.2, this alphanumeric field is critical for proper settlement routing and regulatory reporting. Trading professionals must ensure accurate designation to prevent settlement failures. The field impacts post-trade processing workflows. Systems should validate against approved clearing firms to ensure proper settlement handling.

Tag 440 (ClearingAccount)

Description: Clearing account.
ClearingAccount (440) specifies the clearing account for a trade. In FIX 4.2, this alphanumeric field is critical for precise position allocation during settlement. Trading professionals must ensure accurate designation to prevent position errors. The field impacts post-trade processing workflows. Systems should validate against approved clearing accounts to ensure proper settlement handling.

Tag 441 (LiquidityNumSecurities)

Description: Liquidity number of securities.
LiquidityNumSecurities (441) specifies how many securities contribute to liquidity calculations. In FIX 4.2, this numeric field provides context for liquidity metrics in basket trading. Trading professionals use this for accurate liquidity assessment of portfolios. The field must conform to liquidity measurement conventions. Systems should validate against portfolio composition to ensure meaningful liquidity representation.

Tag 442 (MultiLegReportingType)

Description: Multi-leg reporting type.
MultiLegReportingType (442) specifies how multi-leg trades should be reported using codes: 1=Single Security, 2=Individual Leg. In FIX 4.2, this numeric tag impacts regulatory reporting requirements for complex strategies. Trading professionals must ensure accurate designation to comply with MiFID II and other regulations. The field affects how trades are categorized in transaction reports. Systems should validate against regulatory requirements to ensure proper reporting.

Tag 443 (StrikeTime)

Description: Strike time.
StrikeTime (443) specifies when an option strike price was set. In FIX 4.2, this timestamp field provides context for option pricing and execution. Trading professionals use this for precise timing of option-related transactions. The timestamp must conform to FIX datetime format. Systems should validate against current time and session rules to ensure accurate strike timing.

Tag 444 (ListStatusText)

Description: List status text.
ListStatusText (444) provides human-readable explanatory text for order list status messages. In FIX 4.2, this variable-length field enables operational clarity for complex list execution scenarios. Trading professionals use this for exception handling and audit trails. The field supports multi-line content through EncodedListStatusTextLen. Systems should log and potentially alert on significant list status text.

Tag 445 (EncodedListStatusTextLen)

Description: Length of encoded list status text.
EncodedListStatusTextLen (445) specifies the byte length of encoded list status text. In FIX 4.2, this numeric tag enables proper parsing of international character sets in list status messages. Trading professionals working with global operations use this for accurate status communication across language barriers. The field works with EncodedListStatusText for multi-lingual support. Systems must validate against actual data length to ensure proper text handling.

Tag 446 (EncodedListStatusText)

Description: Encoded list status text.
EncodedListStatusText (446) contains list status text in encoded format for international character support. In FIX 4.2, this field enables multi-lingual communication of list execution status. Trading professionals use this for operational clarity in global trading environments. The interpretation depends on MessageEncoding (347). Systems must decode according to specified encoding to ensure accurate status interpretation across diverse language requirements.