ClOrdID (FIX tag 11)

StringFIX 4.4FIX 4.2

ClOrdID (tag 11) is a String field defined in FIX 4.4 and FIX 4.2. It appears in 34 message types and is required in 13 of them.

At a glance

Tag: 11
Name: ClOrdID
Datatype: String
Dialects: FIX 4.4 and FIX 4.2
Messages: 34

What the specification says

FIX 4.4

Unique identifier for Order as assigned by the buy-side (institution, broker, intermediary etc.) (identified by SenderCompID(49) or OnBehalfOfCompID(115) as appropriate). Uniqueness must be guaranteed within a single trading day. Firms, particularly those which electronically submit multi-day orders, trade globally or throughout market close periods, should ensure uniqueness across days, for example by embedding a date within the ClOrdID(11) field.

FIX 4.2

Unique identifier for Order as assigned by institution (identified by SenderCompID or OnBehalfOfCompID as appropriate). Uniqueness must be guaranteed within a single trading day. Firms, particularly those which electronically submit multi-day orders, trade globally or throughout market close periods,should ensure uniqueness across days, for example by embedding a date within the ClOrdID field.

Descriptions are quoted from the FIX Orchestra sources under the Apache 2.0 licence.

A real message using tag 11

ExecutionReport · FIX 4.4

Tag	Field	Wire value	Meaning
8	BeginString	FIX.4.4
9	BodyLength	146
35	MsgType	8	Execution Report
49	SenderCompID	BOARTEAM
56	TargetCompID	COUNTERPARTY
34	MsgSeqNum	2
52	SendingTime	20240101-12:00:00.000
37	OrderID	ORD-10042
11	ClOrdID	ORD-10042
17	ExecID	EXEC-88117
150	ExecType	0	New
39	OrdStatus	0	New
54	Side	1	Buy
151	LeavesQty	0
14	CumQty	1000000
6	AvgPx	1.09215
10	CheckSum	198

Edit and decode it yourself

Shown with | separators for readability. On the wire FIX uses SOH (0x01), an invisible control byte — and because BodyLength and CheckSum are computed over the actual bytes, the two forms have different checksums. Both are valid and both decode here.

Open in the full decoder →

Generated from the FIX 4.4 dictionary and verified at build time: it parses and validates with no issues. Open the decoder to try your own message.

Where tag 11 appears

Requiredness is a property of the message, not of the field: the same tag can be optional in one message and conditionally required in another.

Message	MsgType	FIX 4.4	FIX 4.2	Where in the message
AllocationInstruction	J	Conditional	Optional	inside the OrdAllocGrp component
AllocationReport	AS	Conditional	—	inside the OrdAllocGrp component
CollateralAssignment	AY	Optional	—	directly on the message body
CollateralInquiry	BB	Optional	—	directly on the message body
CollateralInquiryAck	BG	Optional	—	directly on the message body
CollateralReport	BA	Optional	—	directly on the message body
CollateralRequest	AX	Optional	—	directly on the message body
CollateralResponse	AZ	Optional	—	directly on the message body
Confirmation	AK	Conditional	—	inside the OrdAllocGrp component
ConfirmationRequest	BH	Conditional	—	inside the OrdAllocGrp component
CrossOrderCancelReplaceRequest	t	Required	—	inside the SideCrossOrdModGrp component
CrossOrderCancelRequest	u	Required	—	inside the SideCrossOrdCxlGrp component
Email	C	Optional	Optional	directly on the message body
ExecutionReport	8	Optional	Optional	directly on the message body
ListStatus	N	Required	Required	inside the OrdListStatGrp component
ListStrikePrice	m	Optional	Optional	inside the UndInstrmtStrkPxGrp component
MultilegOrderCancelReplace	AC	Required	—	directly on the message body
NewOrderCross	s	Required	—	inside the SideCrossOrdModGrp component
NewOrderList	E	Required	Required	inside the ListOrdGrp component
NewOrderMultileg	AB	Required	—	directly on the message body
NewOrderSingle	D	Required	Required	directly on the message body
OrderCancelReject	9	Required	Required	directly on the message body
OrderCancelReplaceRequest	G	Required	Required	directly on the message body
OrderCancelRequest	F	Required	Required	directly on the message body
OrderMassCancelReport	r	Optional	—	directly on the message body
OrderMassCancelRequest	q	Required	—	directly on the message body
OrderStatusRequest	H	Required	Required	directly on the message body
QuoteRequest	R	Conditional	—	directly on the message body
QuoteResponse	AJ	Conditional	—	directly on the message body
RegistrationInstructions	o	Optional	—	directly on the message body
RegistrationInstructionsResponse	p	Optional	—	directly on the message body
SettlementInstructions	T	Conditional	—	directly on the message body
TradeCaptureReport	AE	Optional	—	inside the TrdCapRptSideGrp component
TradeCaptureReportRequest	AD	Optional	—	directly on the message body

Wire format

Free-form text. Any byte except the SOH separator is legal, so values are not trimmed or case-folded on the wire. @boarteam/fix keeps the value as a string; format rules are checked by validate(), which reports validate/invalid-value rather than throwing.

Read tag 11 in TypeScript

decode.tsts

import { createFixEngine } from "@boarteam/fix";import { dictionary } from "@boarteam/fix-dict-fix44";const fix = createFixEngine(dictionary);const { message, issues } = fix.parse(raw);const field = message.fields[11];field?.name;   // "ClOrdID"field?.raw;    // the verbatim wire stringfield?.value;  // coerced to a string

Decode this in your own code

The same engine that produced the decoded example above is an Apache-2.0 npm package with zero runtime dependencies. It runs in Node and in the browser, and parse() returns problems as data instead of throwing.

npm i @boarteam/fix @boarteam/fix-dict-fix44

Try the decoder Source on GitHub