Session-level rejects (35=3)
SendingTime accuracy problem (373=10)
SendingTime (52) is too far from the receiver's clock, or OrigSendingTime on a replayed message is later than SendingTime. The receiver rejects the message with 373=10 and, under the FIX session rules, then logs out.
What it means
Receivers compare SendingTime with their own clock to catch stale or replayed traffic. QuickFIX allows 120 seconds by default; the tolerance is set with MaxLatency and the check can be turned off with CheckLatency.
The session rules treat this as serious: Reject, then Logout with a reason, then disconnect.
On replayed messages, OrigSendingTime (122) must not be later than SendingTime (52). A replay that swaps the two gets the same reject.
Common causes
- SendingTime written in local time instead of UTC, which puts it hours off.
- A server clock that drifted because NTP is not running.
- Messages queued for minutes before being sent, keeping the time they were built rather than the time they were sent.
- A replay that keeps the original time in SendingTime (52) instead of moving it to OrigSendingTime (122).
How to fix it
On the side that sent the message
- Set SendingTime (52) in UTC, at the moment the message is written to the socket.
- Run NTP (or PTP) on every FIX server and alert on clock offset.
- On replays, move the original SendingTime to OrigSendingTime (122) and put the current time in SendingTime (52).
On the side that raised the error
- Keep the check on in production. If a counterparty is known to be slow, raise the tolerance for that session rather than disabling it.
Example
A sender four hours behind UTC writes local time into SendingTime. The receiver rejects the message and logs out.
1. Buy side: SendingTime in local time
8=FIX.4.4|9=143|35=D|49=BUYSIDE|56=SELLSIDE|34=102|52=20261020-05:30:00.000|11=ORD-1001|21=1|55=MSFT|54=1|60=20261020-09:30:00.000|38=1000|40=2|44=187.50|59=0|10=120|
2. Sell side: Reject, RefTagID 52
8=FIX.4.4|9=120|35=3|49=SELLSIDE|56=BUYSIDE|34=1004|52=20261020-09:30:00.002|45=102|371=52|372=D|373=10|58=SendingTime accuracy problem|10=061|
3. Sell side: Logout
8=FIX.4.4|9=93|35=5|49=SELLSIDE|56=BUYSIDE|34=1005|52=20261020-09:30:00.003|58=SendingTime accuracy problem|10=070|
SOH (0x01) is shown as |. BodyLength (9) and CheckSum (10) are calculated as if every | were SOH.
Open this example in the parserQuestions
- How far off can SendingTime be?
- The FIX standard leaves it to the receiver. QuickFIX allows 120 seconds by default. Ask the counterparty for their tolerance.
- Should TransactTime (60) also be UTC?
- Yes. Every UTCTIMESTAMP field in FIX is UTC. TransactTime is not checked by the session layer, but a venue may reject an order whose TransactTime is far from its clock.