Hello,
We are implementing a minimum order size validation against orders so that orders below pre-defined minimum order size for the instrument are not posted in the book. As part of this requirement, I want to confirm how FIX ERs should be generated in following scenarios.
An aggressing order partially fills on entry with resting orders and the remainder is less than min order size for the instrument. Following 150=F ERs for trades, a single ER with 150 = C (Expired) and 39 = C (Expired) is sent for the aggressing order indicating its removal.
A resting order is partially filled such that the remainder is less than min order size for the instrument. Following a 150=F ER for the trade, a single ER with 150 = D (Restated), 39 = 4 (Cancelled) and ExecRestatementReason (378) = ‘Partial Decline of Order Quantity (5)’ is sent for the resting order indicating its removal from the book.
In both use cases, Text (58) field will be included with a text like “Expired/Cancelled (Remaining quantity is less than minimum quantity)”
Please share your thoughts on whether suggested FIX messages in above scenarios are correct or not as per the FIX 5.0 standard.
Nowadays, it should say “as per the FIX Latest standard” even if the semantic of your topic has not changed since FIX 5.0 was published many years ago.
Using “expiry” is not the right approach for this as that is about time. You can treat your first case similar to an IOC order where any remaining quantity is cancelled after (potential) execution (150=39=4 (Canceled)). However, there is not really a reason to make a difference between your two cases. There can be more reasons why an order is too small to be eligible for execution. The only difference is the trigger causing you to check whether an order has to be cancelled by the system. Hence, you could use the restatement approach for both cases, regardless of the fact that the order never makes it into the book in the first case.
The alternative for your first case is to send out a single ER that gives you the end result of the (atomic) matching engine transaction with ExecType(150)=F (Trade) and OrdStatus(39)=4 (Cancelled). Please see EP188 for such optimisations to reduce the number of messages sent in response to order submissions that trigger multiple events.
You may use the OrderEventGrp component to communicate information about the individual events rolled up into the single ER. For example, OrderEventReason(1798) supports user-defined values so that you could explicitly convey the cancellation with 100=“Order size below minimum” and OrderEventType(1796)=3 (Deleted).
Thanks @gtcpm for your response. Yes, it make sense to send it as a cancelled ER with 150=Restated. Like you said, there are other scenarios/use cases which trigger similar order cancellations by the system and it make sense to handle all of them in a uniform manner as restatements.