Inside the FIX Spec: 12 Tag Decisions That Cost Real Money

FIX 4.4 is a flexible protocol. The flexibility is a feature for the engineering teams that wrote it. It is also, occasionally, a hidden cost for the institutional desks whose flow is carried by it. Twelve specific tag-handling decisions, made (or unmade) at the boundary between the desk's OMS and the counterparty's session, account for most of the realised execution differences that show up in TCA as "venue choice" or "routing variance". This piece is a tour of those twelve decisions.

The point is not to teach FIX 4.4 to engineers who already write it for a living. It is to give risk officers and execution heads a model for asking the right questions of the engineering teams on both sides of the connection, so that the protocol decisions show up in TCA as known costs rather than unexplained variance.

Tag 1: TimeInForce (Tag 59) — the difference between DAY and IOC at depth

On a child clip of meaningful size, sending an IOC (Immediate-or-Cancel) order will produce a different realised cost than sending a DAY order with the same limit price. The IOC consumes available liquidity and cancels any unfilled balance immediately. The DAY rests at the limit for the trading session, exposing the desk to subsequent fills at the same price as conditions change.

Neither is universally better. IOC is correct for clips where the desk's urgency exceeds its tolerance for fill-price drift. DAY is correct for clips where the desk wants to accumulate at a price level and is willing to wait. The cost of getting this decision wrong, on a typical institutional clip, is meaningful — IOC where DAY was appropriate over-pays the queue-position premium; DAY where IOC was appropriate under-fills on a moving market.

Tag 2: ExecInst (Tag 18) — when participate-do-not-initiate matters

The ExecInst tag carries a long list of optional execution instructions. The one most relevant to institutional flow is the 'G' value — Participate Don't Initiate — which instructs the venue to fill the order only against an arriving aggressive order, never as the price-improving aggressor itself.

Participate-do-not-initiate is the right choice for resting flow that is intended to provide liquidity, not to take it. Omitting the instruction on a resting order means the venue may, under some matching rules, execute the order as an aggressor against a thin opposite side and crystallise a worse price than the desk expected. The instruction is two characters in the FIX message and one of the easier wins on the protocol side.

Tag 3: OrdType (Tag 40) and the discipline of stop-limit

OrdType is one of the few tags every implementation handles. The decision-cost issue is between OrdType=Stop and OrdType=StopLimit. A pure stop executes as a market order once the stop trigger is reached, consuming whatever liquidity exists at the moment the trigger fires. A stop-limit becomes a limit order at the configured limit, providing protection against an unexpected gap but introducing the risk that the order does not fill at all.

On institutional flow, stop is correct only for risk-management orders where the desk would rather execute at any reasonable price than not execute. For accumulation or rebalance orders, stop-limit is essentially always correct. The cost of confusing the two on a gap-trade morning is the entire difference between a controlled exit and a worst-case fill.

Tag 4: ClOrdID (Tag 11) — uniqueness and post-trade reconciliation

ClOrdID is the desk's own identifier for the order. The protocol requires uniqueness only within the desk's own session. The practical requirement, for post-trade reconciliation, is uniqueness across the desk's full order history — including across days, across symbols, and across the desk's full set of OMS instances.

Many implementations generate ClOrdIDs that are unique enough for the active session but collide on a historical lookup. The cost shows up in reconciliation breaks, settlement disputes, and TCA cross-references that fail to match. The fix is a globally-unique format — UUID-based, or a hierarchical date-strategy-sequence — agreed between the desk and the counterparty at session setup.

Tag 5: TransactTime (Tag 60) — the desk's authoritative timestamp

The counterparty's order-acknowledgment timestamp is the counterparty's record. The desk's TransactTime in the original order is the desk's record. Reconciling the two — and proving the desk's intent at a specific moment for compliance and best-execution audit purposes — depends on both timestamps being accurate to a stable precision.

Many OMS implementations stamp TransactTime with system clock precision, which is millisecond at best. Institutional execution requires microsecond precision, which means either a hardware time source or NTP-disciplined kernel time with a documented synchronisation policy. The decision should be explicit, not assumed.

Tag 6: SenderSubID (Tag 50) — the desk's trader attribution

On a desk where multiple traders submit through a shared OMS, SenderSubID carries the individual trader's identifier alongside the firm-level SenderCompID. Post-trade attribution, compliance review, and per-trader TCA all depend on the SubID being populated correctly. The cost of skipping it shows up in inability to attribute realised costs back to specific traders or strategies, which makes TCA a firm-level instead of trader-level instrument.

Tag 7: HandlInst (Tag 21) — automated execution discipline

HandlInst was originally designed to distinguish trader-supervised orders from auto-routed orders. Modern institutional flow is essentially all auto-routed; HandlInst=2 (Automated execution, no broker intervention) is the universal default. The decision-cost issue is when a counterparty's default differs — some legacy venues treat HandlInst=1 (manual) as an instruction to route the order to a human trader desk, with attendant latency. The desk should verify the value its session sends.

Tag 8: TargetSubID (Tag 57) and counterparty-side routing

If the counterparty offers multiple execution destinations through the same session — say, a streaming-aggregator destination and an RFQ destination — TargetSubID carries the desk's choice of destination. The decision-cost issue is whether the desk's OMS populates the SubID correctly per clip. Many do; some treat it as a session-level default and miss per-clip optimisation that the counterparty's destination split would otherwise provide.

Tag 9: MinQty (Tag 110) — the floor on partial fills

On large clips, MinQty allows the desk to specify a floor below which the venue should not partial-fill. A clip with MinQty=0 (default) accepts any partial; a clip with MinQty=X requires the venue to fill at least X units or none. MinQty matters when the desk's strategy requires a meaningful inventory move from each clip; it costs the desk fill probability in exchange for fill-size discipline.

Most institutional flow leaves MinQty at default. The improvement from explicit MinQty discipline shows up on the largest clips, where partial-fill chains can produce a meaningfully worse realised price than a single decisive fill.

Tag 10: Price (Tag 44) — the seemingly obvious one

The price field is obvious; the decision-cost issue is around precision. Most major FX pairs settle to 5 decimal places; some venues quote to 6 or 7. The desk's limit price truncation to the wrong decimal place produces orders that hit the venue at a price slightly different from the desk's intended price. The cost is small per clip and compounds with frequency.

Tag 11: SettlType (Tag 63) and the value-date discipline

On FX flow, SettlType carries the value date (spot, T+1, T+2, or forward). The decision-cost issue is when the desk's OMS defaults to T+2 (the standard FX spot value) but the counterparty expects an explicit value date for all forwards and crosses. Misalignment produces settlement breaks that are operationally expensive to resolve and erode the desk's funding-cost forecast.

Tag 12: Account (Tag 1) and the unified-margin question

On counterparties that offer unified margin across multiple sub-accounts, the Account tag determines which sub-account books the trade. The decision-cost issue is whether the desk's OMS routes correctly per strategy or treats Account as a session default. The cost of treating it as a default is that strategy-level P&L attribution becomes a manual reconciliation rather than a system-of-record output.

How Drovix configures the session

Drovix supports the full FIX 4.4 spec with the twelve tag-handling decisions above explicit at session setup. The session-spec document — issued to the counterparty at ISA execution — lists the expected value of each tag in each common scenario, with the desk's freedom to override per-clip explicitly documented.

The point of the explicit documentation is not to constrain the desk's flow. It is to ensure that when a particular tag's handling produces a realised cost that is different from the desk's expectation, the cost is traceable to the configuration rather than to an undocumented assumption on the counterparty's side. Twelve tags is a small number; the cost of getting any one of them wrong, over a year of institutional flow, is large.

Protocol discipline at the FIX boundary is the operational complement to the routing discipline in queue-position economics and the LP-management discipline in the capacity curve.