Stop Losing Fills in Translation: 10 FIX Tags Every Broker Should Audit Weekly

Execution problems rarely announce themselves as “FIX tag issues.” They show up as partial fills that don’t reconcile, rejects that only happen on volatile ticks, or audit questions you can’t answer quickly.

If you run a forex brokerage or prop firm and you connect to LPs, bridges, or internal matching via FIX, there’s a short list of tags you must understand and log consistently. Below are the 10 tags from the brief—what they mean operationally, what to store for audit/replay, and the mistakes that cause the most pain.

1) Tag 11 (ClOrdID): your primary key for the client’s intent

Tag 11 (ClOrdID) is the client order identifier you generate on the order submission (e.g., NewOrderSingle). In practice, it’s the ID your internal systems should treat as the “source of truth” for the request.

What to log (minimum):

• Tag 11 as sent, and Tag 11 as echoed back on every response/report
• Timestamps (receive, route, ack, fill) tied to Tag 11
• Session identifiers (SenderCompID/TargetCompID), plus environment (demo/live)

Common mistakes:

• Reusing ClOrdID after cancel/replace cycles. Many venues require uniqueness per session/day; even when not required, reuse destroys your ability to reconstruct a clean timeline.
• Not persisting mapping between Tag 11 and your CRM/OMS order record. If your CRM ticket ID isn’t linked to Tag 11, support and compliance will chase ghosts.

2) Tag 37 (OrderID): the venue’s handle—don’t confuse it with ClOrdID

Tag 37 (OrderID) is assigned by the receiving side (LP/venue/bridge) and represents their order record. You typically receive it on execution reports.

Operationally:

• Use Tag 37 for downstream actions that require the venue’s reference (e.g., some cancel flows, post-trade queries, broker-to-bridge troubleshooting).
• Keep it distinct from Tag 11: Tag 11 = your request, Tag 37 = their accepted order.

Common mistakes:

• Overwriting Tag 11 with Tag 37 in databases or logs. This breaks reconciliation when one client order fans out into multiple venue orders (or when a bridge re-IDs orders).
• Not handling “missing OrderID” on rejects. If an order is rejected before acceptance, you may never get Tag 37—your support tooling must still work using Tag 11.

3) Tag 38 (OrderQty): define units and precision early

Tag 38 (OrderQty) is the requested quantity. For FX/CFDs, the tricky part is not the tag—it’s the unit convention: lots vs units vs contract size.

Practical logging/validation:

• Store Tag 38 exactly as sent, plus your normalized quantity (e.g., units)
• Validate against symbol contract spec: min/max, step, and precision

Common mistakes:

• Lot-to-unit conversion drift between CRM, platform, bridge, and LP. One system thinks 1.00 = 1 lot; another thinks 1.00 = 1 unit. This is how you get silent risk blowups.
• Rounding at the wrong layer (front-end vs bridge). Decide where rounding occurs and enforce it consistently.

4) Tag 40 (OrdType): market/limit is easy—until it isn’t

Tag 40 (OrdType) defines the order type (commonly Market or Limit). This tag heavily influences what other tags become mandatory (e.g., Tag 44 for limit price).

What to enforce:

• If OrdType=Limit, ensure Tag 44 (Price) is present and valid
• If your flow supports stop/stop-limit variants, validate required fields in your chosen FIX version/profile

Common mistakes:

• Sending OrdType=Limit without Tag 44, leading to rejects that look like “LP instability” but are actually schema violations.
• Assuming all LPs interpret order types the same way. Your bridge may need per-LP rules; document them and test in UAT.

5) Tag 44 (Price): log both requested and executed economics

Tag 44 (Price) is the order price for price-based orders (typically limit). Even if you mostly run market execution, Tag 44 still matters in edge cases (e.g., internalization logic, last-look simulations, or when clients submit pending orders).

What to log:

• Tag 44 as requested (for limits)
• Executed price(s) from execution reports (don’t assume it equals Tag 44)
• Any internal “price at receipt” snapshot you use for slippage metrics

Common mistakes:

• Comparing Tag 44 to fills and calling the difference “slippage” without considering partial fills, multiple execution reports, or different price sources.
• Not capturing the price context (symbol, timestamp, quote source). Without it, your best execution narrative is weak—check local regulations and your compliance framework.

6) Tag 54 (Side): buy/sell sounds trivial—until sign conventions leak

Tag 54 (Side) indicates Buy or Sell. The risk is not the tag; it’s how side interacts with:

• Position sign in your risk engine
• P&L calculation
• Hedging direction when routing to LPs

Common mistakes:

• Inverting side during platform-to-FIX mapping (especially when translating between “deal” records and “order” records).
• Mixing netting vs hedging assumptions. If your trading stack supports both (common in MT5 ecosystems), ensure the FIX-to-risk mapping is mode-aware.

7) Tag 55 (Symbol): normalize, alias, and never guess

Tag 55 (Symbol) identifies the instrument. In retail FX, your platform symbol (e.g., EURUSD.a, XAUUSDm) often differs from an LP symbol (e.g., EUR/USD, XAUUSD).

Best practice:

• Maintain a symbol mapping table (platform ↔ bridge ↔ LP) with versioning
• Log the raw Tag 55 received/sent and your normalized internal symbol ID

Common mistakes:

• Ad-hoc string replacements (“remove suffix”) instead of an explicit mapping. This breaks when you add new feeds, metals, or crypto CFDs.
• Not aligning contract specs per symbol alias (digits, tick size, min qty). Symbol mapping without spec mapping is incomplete.

8) Tag 59 (TimeInForce): where rejected orders and angry traders are born

Tag 59 (TimeInForce) defines how long an order remains active (e.g., Day, IOC, FOK, GTC depending on your profile). For brokers/props, this becomes a policy decision: what do you allow, and what do LPs accept?

Practical controls:

• Enforce allowed TIF per symbol group and client type
• Validate TIF compatibility per LP/venue profile before routing

Common mistakes:

• Defaulting TIF silently (e.g., forcing Day when client asked IOC). That can create execution behavior that looks like manipulation.
• Not logging the original TIF when you transform orders. If you must transform (bridge constraints), record both “requested” and “routed” values.

9) Tag 150 (ExecType): the truth about what happened

Tag 150 (ExecType) on ExecutionReport tells you the event type: new/acknowledged, partial fill, fill, canceled, rejected, replaced, etc. This is the backbone of your audit trail.

What to log:

• Every execution report in order, keyed by Tag 11 and Tag 37
• ExecType transitions (e.g., New → Partial Fill → Fill)
• Reject reasons and any free-text fields your counterparties use

Common mistakes:

• Treating ExecType as “final state only.” Many systems store only the latest status, losing the chain of events that explains disputes.
• Not reconciling multi-fill sequences. If you don’t ingest all execution reports, your P&L and exposure can diverge from reality.

10) Tag 151 (LeavesQty): reconcile partials without guesswork

Tag 151 (LeavesQty) indicates quantity remaining open. Combined with cumulated quantity (often Tag 14, CumQty) it lets you validate partial fill math and detect missing messages.

Operational uses:

• Detect dropped execution reports (LeavesQty jumps unexpectedly)
• Validate that final fills end at LeavesQty=0
• Drive client-facing order status in portals/CRM

Common mistakes:

• Computing LeavesQty yourself and ignoring the venue’s value. Your computed number may be wrong if you missed a report.
• Rounding inconsistently across partial fills, creating tiny residual LeavesQty that causes “order stuck open” incidents.

Common logging mistakes that hurt brokers and prop firms

Even if you “know the tags,” poor logging turns every incident into a forensic project. A practical baseline for FIX logging in a broker/prop environment:

• Log raw FIX messages (in/out) with timestamps and session IDs (and protect access—these logs can contain sensitive data).
• Store parsed fields for key tags (11, 37, 38, 40, 44, 54, 55, 59, 150, 151) so ops can query quickly.
• Keep an immutable event timeline (append-only) for audit and dispute handling.
• Record transformations (requested vs routed) when bridges normalize symbols, quantities, or TIF.

Compliance note: retention, access controls, and what constitutes an “audit trail” vary by regulator and jurisdiction—check local regulations and align with your compliance advisors.

The Bottom Line

If you only standardize one thing in your FIX stack, standardize identifiers, quantities, and execution-state logging around Tags 11, 37, 150, and 151.

Most recurring execution disputes come from preventable gaps: inconsistent symbol mapping (55), unit confusion (38), and silent policy transforms (59/40/44).

Want a clean, support-friendly FIX audit trail across CRM, bridge, and risk? Talk to Brokeret about implementation patterns at /get-started.