FIX Protocol Tag 41: OrigClOrdID

Practical notes on OrigClOrdID

OrigClOrdID points a cancel or replace at the order it changes. It holds the ClOrdID of the last accepted request in the order's chain.

• After a replace is confirmed (ExecType 150=5), the replace's ClOrdID becomes the one to use as OrigClOrdID in the next cancel or replace.
• Execution Reports for cancels and replaces carry it too, so the client can link the new ClOrdID to the old one.

Common mistakes

• Using the first ClOrdID of the order after one or more replaces. The venue answers with an Order Cancel Reject, CxlRejReason 1 (Unknown order).

Changes between FIX versions

• Required on Order Cancel Request and Cancel/Replace in FIX 4.2 and 4.4. In FIX 5.0 SP2 it is optional, because the order can be identified by OrderID (37) instead.

See also:Unknown order (102=1)

Tag 41 in each FIX version

Values and message usage as defined in a specific version.

• FIX 4.0
• FIX 4.1
• FIX 4.2
• FIX 4.3
• FIX 4.4
• FIX 5.0
• FIX 5.0 SP1
• FIX 5.0 SP2

Data type

STRING: Text of printable characters. It cannot contain the SOH delimiter.

Example

41=ORD-20261020-0001

Illustrative value. In a message, fields are separated by the SOH character (0x01), often shown as | or ^ in logs.

Message types that use tag 41

• Execution Report 35=8
• Order Cancel Reject 35=9
• Order Cancel Request 35=F
• Order Cancel/Replace Request 35=G
• Multileg Order Cancel/Replace 35=AC
• Order Mass Action Report 35=BZ
• Mass Order 35=DJ
• Mass Order Ack 35=DK
• Order Mass Cancel Report 35=r
• New Order Cross 35=s
• Cross Order Cancel Replace Request 35=t
• Cross Order Cancel Request 35=u

Covers every version from FIX 4.0 to 5.0 SP2, including fields reached through components and repeating groups. The version pages above show whether the tag is required in each message.