Duplicate Order Submission Protection
Release Details
Release Date: October 19, 2026
Release Type
New feature
Summary
To prevent accidental order duplications, we are extending Client Order ID (FIX tag 11) idempotency checks across all order states. Previously, ClOrdID uniqueness was validated against open/active orders only. With this update, ClOrdID uniqueness is enforced globally, including historical orders that reached a terminal state (such as FILLED, CANCELED, EXPIRED, or REJECTED).
What's Changing
- Previous Behavior: Reusing a ClOrdID was blocked only while an order remained open/active. Once an order reached a terminal state, the same ClOrdID could be reused.
- New Behavior: Any incoming order that reuses a ClOrdID previously assigned to an order in any state will be immediately rejected.
Scope and Validation Criteria
An incoming order is compared against previous orders using the combination of the following fields:
Account(FIX tag 1)Participant(FIX tag 50)Symbol(FIX tag 48)ClOrdID(FIX tag 11)
Rejection Behavior
When a duplicate ClOrdID is detected under matching scope criteria, the order will be rejected with the following reason:
Rejection Reason: "matching engine order insertion ClOrdID idempotency check"
Note on Retention Window
Following a maintenance window, the matching engine is restarted and historical execution reports (cancelled, rejected, or filled) are archived. As a result, the idempotency check only retains ClOrdIDs from the past week. ClOrdIDs older than one week may be reused.