Order Rejects — FIXReader

Critical Warning

Do not resend a rejected order until you understand why it failed.

Blindly resubmitting may create:

duplicate orders
repeated rejects
unintended exposure
broken ClOrdID chains
inconsistent order state
additional risk or compliance breaches

Before resending:

confirm whether the order was accepted anywhere verify the rejecting message type identify the original ClOrdID review the rejection text correct the underlying field or entitlement issue use a new ClOrdID where required

Quick Triage

1 Identify the rejection message type. A session 35=3, a Business Message Reject 35=j, and an Execution Report 35=8 reject each point to a different layer.
2 Capture the rejecting text and reason code. Read Text (58) and the applicable reason tag — 103, 371, or 373 — before doing anything else.
3 Match the reject back to the original ClOrdID. Confirm exactly which outbound order was rejected and whether any order state was created at the counterparty.
4 Determine where the rejection came from. FIX engine validation, broker risk, or exchange rules each require a different fix.
5 Compare the rejected order with a known-good order. For the same venue, account, and symbol type — look for differences in required tags, enum values, or routing.
6 Correct the cause before resubmitting. Use a new ClOrdID if the original was consumed, even partially.

What Rejected the Order?

Message	Meaning	Typical Source
Reject 35=3	Session-level FIX problem	FIX engine
Business Message Reject 35=j	Unsupported or invalid application message	Counterparty FIX gateway
Execution Report 35=8, 150=8, 39=8	Order rejected	Broker, risk layer, or exchange
Order Cancel Reject 35=9	Cancel or replace rejected	Broker or exchange

The message type tells you which layer failed. Do not troubleshoot an exchange order reject the same way you troubleshoot a session Reject.

Common Problems

Symptom	Likely Cause	First Check
Missing required field	Required tag absent	Reject text and `RefTagID (371)`
Invalid field value	Unsupported enum or format	Tag value and venue rules
Unknown symbol	Invalid or unsupported instrument	Symbol, SecurityID, and venue
Duplicate ClOrdID	ID already used	ClOrdID history
Invalid price	Tick size, price band, or format	Price and exchange rules
Invalid account	Account not mapped or entitled	Account and permissions
Order type not supported	Unsupported OrdType or TIF	Tags `40` and `59`
Risk reject	Credit, fat-finger, position, or limit breach	Broker risk response
Session reject	Malformed FIX message	Tags `371`, `372`, and `373`

Key Reject Fields

Pull these fields from the reject message first. They identify what failed and where.

Tag	Purpose
11	ClOrdID — your original order identifier
37	OrderID — exchange-assigned identifier, if any was created
17	ExecID — unique execution identifier on the reject message
58	Text — human-readable rejection reason; read this first
103	OrdRejReason — coded reason for an Execution Report reject
371	RefTagID — points to the specific tag that caused a session Reject
372	RefMsgType — identifies the message type that was rejected
373	SessionRejectReason — coded reason for a session-level Reject
380	BusinessRejectReason — coded reason for a Business Message Reject
150	ExecType — `8` confirms this Execution Report is a reject
39	OrdStatus — `8` confirms the order is in a rejected state

Reading the Logs

Example 1 — Execution Report reject from the broker:

OUT 35=D|11=ABC123|55=AAPL|54=1|38=100|40=2|44=185.50| IN 35=8|11=ABC123|150=8|39=8|103=99|58=Account not authorized|

• The order reached the counterparty — a response was returned.
• It was rejected through an Execution Report — 150=8 and 39=8 confirm the order is in a rejected state.
• The ClOrdID matches the original outbound order.
• The cause is account authorization — not FIX syntax. Fix the account entitlement before resubmitting.

Example 2 — Session-level Reject pointing to a specific tag:

IN 35=3|371=54|372=D|373=5|58=Value is incorrect|

• The session rejected a New Order Single (372=D) before it reached the application layer.
• RefTagID (371) = 54 points directly to Side. Fix the malformed or unsupported Side value before resending.

Compare Against a Known-Good Order

When the rejection is unclear, compare the failed message with a recently accepted order for the same venue, account, symbol type, order type, TimeInForce, and session.

Look for differences in:

• required tags present vs. absent
• enum values — especially OrdType (40), Side (54), and TimeInForce (59)
• account or trader identifiers
• routing instructions
• price precision and tick size
• instrument identifiers — Symbol, SecurityID, and SecurityIDSource

Use Compare Messages to isolate the differences between the rejected order and a known-good order.

Recovery Checklist

5-Minute Diagnosis

Order Rejects — TL;DR

What message type was the reject — 35=3, 35=j, 35=8, or 35=9?
What does Text (58) say? What do the reason codes point to?
Does any order state exist at the counterparty?
Is the cause a FIX field, an entitlement, or a risk rule?
Is it safe to resend — and do you need a new ClOrdID?