FIX Protocol Tag 17: ExecID

Practical notes on ExecID

ExecID uniquely identifies one Execution Report from the sender.

• Use it to detect duplicate reports, for example after a resend: book a fill once per ExecID.
• Trade busts and corrections reference the original report's ExecID in ExecRefID (19).
• Every Execution Report has one, including acknowledgements and status reports that carry no fill.

Common mistakes

• De-duplicating fills by sequence number instead of ExecID. The same fill can arrive under two sequence numbers when PossResend is used.

See also:PossDupFlag vs PossResendHow to read an Execution Report

Tag 17 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

17=EXEC-000123

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

Message types that use tag 17

• Execution Report 35=8
• Allocation Instruction 35=J
• Dont Know Trade 35=Q
• Trade Capture Report Request 35=AD
• Trade Capture Report 35=AE
• Confirmation 35=AK
• Trade Capture Report Ack 35=AR
• Allocation Report 35=AS
• Collateral Request 35=AX
• Collateral Assignment 35=AY
• Collateral Response 35=AZ
• Collateral Report 35=BA
• Collateral Inquiry 35=BB
• Collateral Inquiry Ack 35=BG
• Allocation Instruction Alert 35=BM
• Execution Ack 35=BN
• Trade Aggregation Request 35=DW

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.