FIX Tags That Decide Fill vs Re-Quote: The Protocol Detail That Matters

Most FIX integrations are written once, fixed twice, and never opened again. They handle 99% of normal-conditions flow correctly. The remaining 1% — the sessions in which the protocol genuinely matters — is overwhelmingly where the avoidable execution problems happen. This post is a tour of the tags whose default values are wrong often enough to be worth checking before your next stress event.

The tags that almost always default wrong

TimeInForce (59)

TimeInForce decides what happens when your order cannot fill immediately. A default of GTC (Good Till Cancel) is a leftover from the equities default and is the wrong default for most FX execution: a partially-filled GTC will sit in the venue's book until your OMS cancels it, and during that wait your residual size is visible to anyone consuming the venue's market data.

The correct default for institutional FX flow is IOC (Immediate Or Cancel) for the aggressive child, with FOK (Fill Or Kill) reserved for the case where you cannot tolerate any residual leak. GTC has a role for resting institutional bids and offers; it has no role inside a parent execution algorithm.

ExecInst (18)

ExecInst is the bag of execution hints. The two values that matter most are 'g' (All Or None) and 'M' (Mid-price peg). Both are honoured inconsistently across venues. A 'g' that one venue treats as a hard constraint another venue treats as a routing preference, and your fill behaviour will quietly differ across venues for no reason that shows up in your TCA.

Drovix honours 'g' as a hard constraint on the wholesale book and as a routing preference on the streaming book, and our documentation says so explicitly. When you integrate against a new venue, ask the question in writing.

MinQty (110)

MinQty is the partial-fill floor. A common bug pattern is to set MinQty equal to the full order quantity, which is equivalent to FOK and forecloses any partial. The opposite bug pattern is to leave MinQty at zero, which allows arbitrarily small fills and produces the 'thousand one-lot fills' problem that destroys your post-trade reporting and inflates your clearing cost.

The right floor depends on your downstream cost of an individual fill — clearing fees, ticket fees, your own OMS processing — and on your willingness to accept residual signalling. For most desks running aggressive children, MinQty between 5% and 20% of the parent quantity is the right band.

PriceProtectionScope (1092) and OrderRestrictions (529)

These are the tags that, on stress sessions, decide whether you get a clean reject or an opportunistic fill at a price you did not expect. PriceProtectionScope set incorrectly — or, more often, omitted because the OMS does not bother — means a marketable order can fill several ticks worse than your intended price because the venue followed the price up while your message was in flight.

Drovix enforces a default price protection scope of 1 pip on majors, 3 pips on crosses, and 10 pips on exotics, regardless of whether the incoming order carries the tag. Most institutional OMSes also set the tag explicitly, in which case the OMS value wins; for OMSes that omit it, our default catches the common bad outcomes. Confirm what your own OMS sends; the assumption that 'the default will do something reasonable' is the assumption that fails at 14:30 on a Wednesday.

The tags whose absence hurts most

TransactTime (60) precision

TransactTime is the timestamp on the order message. Most OMSes send millisecond precision. Some send second precision, which means that on a stress session the venue's ordering of your messages is effectively arbitrary within any one-second window. If you are running an algo that issues children faster than once per second, the lack of precision is a silent bug that converts a deterministic execution into a probabilistic one.

Microsecond precision is supported in FIX 5.0SP2 and is what we recommend. Drovix accepts nanosecond precision on the wholesale book; we use it for journal sequencing. The point is not the absolute precision; the point is that you have enough to disambiguate the messages your own algo issues in close succession.

PartyID and OnBehalfOfCompID

These tags identify the originator of a trade in a multi-leg setup — for example, a regulated retail broker hedging on behalf of its end-customer book, or a fund of funds executing on behalf of a sub-strategy. Setting them correctly is the difference between a clean post-trade attribution and a manual reconciliation. Setting them incorrectly — or, more often, not setting them at all — is the difference between a clean MAR audit and a series of awkward emails.

The operational layer that makes per-counterparty attribution trivial is the subject of Risk Without Friction. The short version: every event in our journal carries the originating PartyID, the operating PartyID, and the EnteringTrader; the absence of any of those is treated as a reject.

The behaviour that surprises desks most

The single behaviour that surprises sophisticated desks most when they first integrate with an institutional FX venue is that the venue can — and should — reject orders that are technically valid but operationally suspect. An order whose price is more than five pips outside the prevailing market is, on most institutional venues, rejected at the gateway, not filled. An order whose quantity is many multiples of recent average is paused and confirmed, not blasted into the book.

If you have been trained on equities-style venues that fill anything within the book, the institutional FX behaviour can feel adversarial. It is not. It is the venue protecting you from your own typos on the days when typos matter most. Drovix's gate behaviour is documented in the developer guide; the gates are conservative by default and tunable per-counterparty on request.

Where to go next

→ Last Look in 2026 — the protocol-level mechanics of how a last-look rejection actually reaches your OMS, and which tags carry the reason code.

→ Microseconds Matter — what the FIX-to-engine path looks like inside Drovix, and why the median round-trip is what it is.

Methodology and data

The session-design conventions are drawn from the same 47-integration sample as the twelve-tag piece, but filtered for decisions that survive the entire session lifecycle — initial onboarding, the first regulatory reporting cycle, and at least one venue-side upgrade. This narrows the discussion to conventions that don't need to be re-litigated quarterly. Each convention is annotated with the failure mode it prevents.

Limitations and scope

The conventions assume FIX 4.4 in the FX/CFD space. They are not directly applicable to fixed-income or listed-derivative integrations, which carry different regulatory tape obligations and different counterparty topologies. The discussion is operational, not normative — venues are free to vary, and several major venues do.

Further reading

→ FIX Spec — Twelve Tag Decisions That Matter — The tag-by-tag detail behind the session conventions. See /blog/fix-spec-12-tag-decisions.

→ Market Data Handle Discipline — The inbound counterpart to a well-designed session. See /blog/market-data-handle-discipline.

Drovix Research is the in-house institutional desk of Drovix MU Ltd, regulated by the Financial Services Commission of Mauritius. All notes are informational only and do not constitute investment advice, a solicitation, or a recommendation to transact in any financial instrument.