rejecting a new order..

, ,
1

Imported from previous forum

2

[ original email was from Asim Kaleem - asimletters@yahoo.com ]
Hi,
If a new order hits Sell side with missing tag 60 (using 4.2), what’s the regular way to reject the new order? by sending 35=8,39=8 OR 35=3 ??

3

[ original email was from Himanshu Sharma - hsharma@knighttrading.com ]
IMHO
You would send 35=3 (session level reject) siting SessionRejectReason=“Require Tag Missing” and in Text field “58=Required field 60 missing”.
Rejecting unparsable messages at session level also avoids extra burden on your application side.
HTH

Hi, If a new order hits Sell side with missing tag 60 (using 4.2),
what’s the regular way to reject the new order? by sending 35=8,39=8
OR 35=3 ??

4

[ original email was from John Prewett - jprewett@lavatrading.com ]
> IMHO You would send 35=3 (session level reject) siting

SessionRejectReason=“Require Tag Missing” and in Text field “58=Required
field 60 missing”. Rejecting unparsable messages at session level also
avoids extra burden on your application side. HTH

Hi, If a new order hits Sell side with missing tag 60 (using 4.2),
what’s the regular way to reject the new order? by sending 35=8,39=8
OR 35=3 ??

IMHO, I would the message that is the most helpful to the recipient.

Many, many recipients of FIX Reject messages (35=3) use a manual procedure (if any) to process them.

On the other hand, most recipients of a FIX Execution Report (OrdStatus=Rejected) should be able to process that automatically.
I would therefore choose where possible an Execution Report (35=8) with OrdStatus(39) and ExecType(150) = Rejected(8).

Lastly, no mention has been made of the other option (Business Message Reject, MsgType=j). This should be used when a generic reject message is generated by an application. I would still use an ExecReport though, for the reasons I specified above - I want to attempt to guarantee that the recipient is able to process my response.

I cannot remember where in the FIX specifications, but I’m fairly sure I have read at some time that the order of preference for rejecting orders is:

  1. Use Exec Report if possible.
  2. If not possible to use Exec Report, then use Business Message Reject.
  3. If all else isn’t possible, use a Session-level Reject.

I hope this helps.

JohnP

5

[ original email was from Asim Kaleem - asimletters@yahoo.com ]
Exactly, my engine also takes care of new order rejects better, in execution report.

On the other hand, most recipients of a FIX Execution Report
(OrdStatus=Rejected) should be able to process that automatically. I
would therefore choose where possible an Execution Report (35=8) with
OrdStatus(39) and ExecType(150) = Rejected(8).

6

IMHO You would send 35=3 (session level reject) siting
SessionRejectReason=“Require Tag Missing” and in Text field
“58=Required field 60 missing”. Rejecting unparsable messages at
session level also avoids extra burden on your application side. HTH

Hi, If a new order hits Sell side with missing tag 60 (using 4.2),
what’s the regular way to reject the new order? by sending 35=8,39=8
OR 35=3 ??

IMHO, I would the message that is the most helpful to the recipient.

Many, many recipients of FIX Reject messages (35=3) use a manual
procedure (if any) to process them.

The reason for that is probably that lacking a required message could indicate a serious programming error.

On the other hand, most recipients of a FIX Execution Report
(OrdStatus=Rejected) should be able to process that automatically. I
would therefore choose where possible an Execution Report (35=8) with
OrdStatus(39) and ExecType(150) = Rejected(8).

IMHO, this blurs the difference between the required and the optional parts of the protocol. I would rather choose to treat the Reject messages automatically.

Lastly, no mention has been made of the other option (Business Message
Reject, MsgType=j). This should be used when a generic reject message is
generated by an application. I would still use an ExecReport though, for
the reasons I specified above - I want to attempt to guarantee that the
recipient is able to process my response.

I cannot remember where in the FIX specifications, but I’m fairly sure
I have read at some time that the order of preference for rejecting
orders is:

  1. Use Exec Report if possible.
  2. If not possible to use Exec Report, then use Business Message
    Reject.
  3. If all else isn’t possible, use a Session-level Reject.

True. This is a very useful guideline.

Cheers, Jörg

7

[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
IMGO this is a session (FIX implementation) level error and should not be responded to with ExecutionRpt or BusinessReject. I would reserve those messages for business contextual errors (such as unknown instrument, no limits to trade, invalid price step etc.).

8

IMGO this is a session (FIX implementation) level error and should not
be responded to with ExecutionRpt or BusinessReject. I would reserve
those messages for business contextual errors (such as unknown
instrument, no limits to trade, invalid price step etc.).

Agreed. The receiving side should be able to handle Reject messages appropriately. John suggested to use ExecutionReport(Rejected) since some application report back only this kind of error to the trader, but IMHO the client should also report Reject messages as order failures at the technical level.

Basically the question is how far you want to go to workaround deficiencies of the other side by breaking the FIX protocol.

Cheers, Jörg