Imported from previous forum
Help me settle a question.
If I receive a NewOrderSingle from a client and they are not authorized in my system to trade the specified security I believe that I should issue a Business Level Reject message. Some (who shall remain anonymous) believe that we should issue an Execution Report <8> with OrdStatus set to Rejected (8). I believe that an Execution Report with an OrdStatus set to Rejected is intended to be used in a reply to an OrderStatusRequest message when the client inquires after an order which we previously rejected.
So, am I right?
Thanks,
Robert
Hi Robert,
You should issue a ExecutionReport with 39=8 in response to an order you cannot process.
You can see this in the Order State Change Matrices section in the appendices of the FIX spec (appendix D in the FIX 4.2 spec). D1, for example, shows at time 2 the possibility of a exec report reject (ord status 8).
Regards, Greg.
If I receive a NewOrderSingle from a client and they are not authorized in my system to trade the specified security I believe that I should issue a Business Level Reject message. Some (who shall remain anonymous) believe that we should issue an Execution Report <8> with OrdStatus set to Rejected (8). I believe that an Execution Report with an OrdStatus set to Rejected is intended to be used in a reply to an OrderStatusRequest message when the client inquires after an order which we previously rejected.
So, am I right?
Thanks,
Robert
[ original email was from Tommy Hannon - th2006@cox.net ]
I believe you should use ExecutionReport. Check out the following link…
http://btobits.com/fixopaedia/fixdic44/message_Business_Message_Reject_j.html
I believe you should use ExecutionReport. Check out the following link…
Business Message Reject (MsgType = j) - FIX 4.4 Dictionary
Thanks guys for the quick response. I’ll have to be wrong on this one (although the silver lining is that I won’t have to change a big chunk of code).
The problem is you are likely create havoc for your counterparties. With orders when in doubt err toward the ExecutionReport and study the order handling examples in the appendices of each version of the specification.
So you might not be changing code but multiple counterparties may end up doing so instead.
I believe you should use ExecutionReport. Check out the following link…
Business Message Reject (MsgType = j) - FIX 4.4 Dictionary
Thanks guys for the quick response. I’ll have to be wrong on this one (although the silver lining is that I won’t have to change a big chunk of code).
I agree with Jim and suggest to use OrdRejReason to explain the rejection, either 0 (Broker option) or 99 (Other) together with 58 Text, e.g. “Not authorized”.
The issue of a single generic reject message for all requests vs. a bespoke reject message for every request is worth a discussion but this is currently only foreseen on the session level with the SessionReject message which does not go beyond the syntax of a message.
The problem is you are likely create havoc for your counterparties. With orders when in doubt err toward the ExecutionReport and study the order handling examples in the appendices of each version of the specification.
So you might not be changing code but multiple counterparties may end up doing so instead.
I believe you should use ExecutionReport. Check out the following link…
Business Message Reject (MsgType = j) - FIX 4.4 Dictionary
Thanks guys for the quick response. I’ll have to be wrong on this one (although the silver lining is that I won’t have to change a big chunk of code).
Sorry Jim, I was trying to be funny and failed. The code currently issues an Execution Report. I was arguing that it should be changed. I was wrong to want to change it, but at least I won’t have to change it!
The problem is you are likely create havoc for your counterparties. With orders when in doubt err toward the ExecutionReport and study the order handling examples in the appendices of each version of the specification.
So you might not be changing code but multiple counterparties may end up doing so instead.
I believe you should use ExecutionReport. Check out the following link…
Business Message Reject (MsgType = j) - FIX 4.4 Dictionary
Thanks guys for the quick response. I’ll have to be wrong on this one (although the silver lining is that I won’t have to change a big chunk of code).