0

We recently had a network connectivity blip that affected the server running our service that uses a FIX connection to get transaction details. QuickFIX/n recovered from the outage but ended up skipping the message that was in flight at the time of the outage because it was rejected with SENDINGTIME_ACCURACY_PROBLEM as the reason.

I monitor all FIX rejections, and there has never been a time when I would have actually wanted to treat messages flagged with SENDINGTIME_ACCURACY_PROBLEM any differently than other messages. Now that this has caused us to drop a fill, I'd like to disable this rejection reason (perhaps logging it, but not sending a REJECT message or skipping over it).

However, I can't find any way in QuickFIX/n to customize the rejection behavior (there's no method to implement or override I've been able to find). Is there any way to tailor the rejection reasons, either in code or in configuration?

We're using FIX 4.4, in case that matters.

Dov
  • 15,530
  • 13
  • 76
  • 177

1 Answers1

1

I don't think there is the possibility to customize only this special rejection (e.g. by suppressing it in toAdmin()), especially because a Logout message will be sent afterwards and you will be disconnected anyway. See https://github.com/connamara/quickfixn/blob/c4e8171e9a702be29078eab3b6dc26b713002de2/QuickFIXn/Session.cs#L1003-L1009

You could however kind of disable this rejections by either turning of the latency check (CheckLatency=N) or configuring a higher threshold (e.g. MaxLatency=3600).

See http://quickfixn.org/tutorial/configuration.html

NB: I don't know the specifics of your FIX connection or application but it might be sensible to send these rejections in some cases, e.g. to prevent stale orders to be sent to the market.

Christoph John
  • 3,003
  • 2
  • 13
  • 23