Server response to accepted NewSingleOrder with 43=Y

1

I had connectivty issues from my Client to a Server. The server requested a resend twice in a short period with 35=2. The resend start SeqNum rquested contained the same NewSingleOrder (35=D) both times.

The server accepted the order of the first resend, but rejected the second. Therefore I received a Pending New (and eventual Fill) and a Reject for the same OrderID.

I feel that getting sent a reject for a dup (43=Y) order that the Server already accepted is incorrect.

Can someone please clarify whether this is the correct response or not

2

How was the second order rejected? Reject(35=2) message with SessionRejectReason(373) or ExecutionReport(35=8) message with OrdRejReason(103)? What was the reject reason provided?

3

It was rejected as below:

With 35=8, 39=8

20200916-17:28:50.302 : 8=FIX.4.4 9=0369 35=8 49=SERVER 56=CLIENT 34=10182 52=20200916-17:28:50.301 37=O20200916L3N2000037537 17=E20200916L3N2000040058 150=8 39=8 55=EGGS 54=2 11=BB-FSB-M50!514607-200916T002012000883 38=400000 44=104.962 151=400000 14=0 32=0 31=0 6=104.962 278=2s219102b79ba2b069b4a001102b79ba2b069b4a+ 40=D 15=USD 59=3 60=20200916-17:28:50.299 58=Technical incident 10=107

4

Sounds interesting…looks like OrdRejReason(103) is not being used. My guess is that the duplicate check did not identify the order as a duplicate. Due to PossDupFlag(43)=Y, the FIX engine should not have passed the message to the application layer a second time. I assume you (correctly) did not issue a new sequence number when retransmitting the requested messages.

See https://www.fixtrading.org/standards/fix-session-layer-online/ for the official specification and https://www.fixtrading.org/standards/fix-session-testcases-online/ for test cases.

5

Great - that’s a really useful link. I believe the Server should have ignored the message