PossResend(97) is specified in the StandardHeader. It is also covered in the FIX session layer specification. But, it is really not a session level field. PossResend(97)=Y is used to indicate when an application is resending a business message (let’s say an order) because the originator has not received an application level acknowledgement. True, the PossResend(97) is passed through the FIX session, but it is not a session level field or part of the session layer protocol. The field is a mechanism applications can use to communicate via the session layer that they are resending the same business content in a different FIX session message as identified by MsgSeqNum(34).
With all that said, and hopefully it will spark a conversation, does your application (buy-side OMS, EMS, trading platform use PossResend(97) as part of your application?
Any modern FIX application that doesn’t check the PossResend(97)=Y, risks processing duplicate transactions. Application should check the unique business level id in the FIX message (which varies by message type) for already processed transactions. Your application must store the appropriate unqiue business level id for the transaction in question. Then your application must make the appropriate check to see if a transaction for a message with that unique business level id has already been processed.
1 Like
In HFT execution system we ignore it. For backoffice dropcopies etc, we ignore it and always check in database if transaction is a duplicate.
@briandriscoll I think @rigtorp made the key comment, i.e. it should NOT depend on PossResend(97)=Y whether the receiving application checks for duplicates. You already say “Application should check the unique business level id” and that should happen regardless. The application should not rely on the counterparty, i.e. the sending application that it is not a duplicate if PossResend(97)=N or is absent.
I am not sure what the application should do differently when PossResend(97)=Y. The rules of engagement should define the business level ID and the receiver should always check it for uniqueness in my view.
Yeah, I agree with that. But it wasn’t clear in my post …
Duplicate transaction/business id with PossResend=Y, is okay maybe log a warning or info message.
Duplicate transaction/business id without PossResend=Y, is an error and might indicate a bigger problem.
@briandriscoll makes sense. Additionally, we want to cover the case more or less described by @rigtorp, i.e. to allow the counterparties to agree in their rules of engagement that PossResend it not used at all.
Whether used or not, it should be the responsibility of the receiving application to detect duplicates. That avoids a situation where PossResend is used in principle and the receiver rejects responsibility for an overfill because the sender did not set PossResend to “Y”. You do not want a court case over such an ambiguity.