Network & Connectivity Sequence Numbers Logon Failures Fill Reconciliation Order Rejects Latency & Timing Duplicate Orders Gap Fill & Resend
LAT 10 min read Troubleshooting

Latency & Timing

Diagnose slow order acknowledgments, delayed executions, timestamp mismatches, and clock synchronization problems across a FIX workflow.
Critical Warning
Do not treat every timestamp difference as exchange latency.

A delayed acknowledgment may be caused by:

  • application queuing
  • FIX-engine queuing
  • network delay
  • broker risk checks
  • exchange processing
  • clock drift
  • timestamp formatting or precision differences

Before escalating latency, confirm that all systems are using synchronized clocks and that the timestamps being compared represent the same event.

Tag 52 vs Tag 60
Tag Field What It Represents
52 SendingTime When the FIX message was sent by the FIX engine
60 TransactTime When the business event or transaction occurred

SendingTime (52) is part of the FIX message header and reflects when the message leaves the FIX engine. TransactTime (60) reflects the time of the underlying business action — when an order was created, changed, or executed. They may be close, but they are not interchangeable.

60=20260714-13:30:00.120
52=20260714-13:30:00.145
  • • The order event occurred at 13:30:00.120.
  • • The FIX message was sent at 13:30:00.145.
  • • The internal application-to-FIX delay was approximately 25 milliseconds.

Comparing Tag 52 on one message with Tag 60 on another can produce a misleading latency number.

Quick Triage
  • 1 Identify the exact latency being measured. Application-to-FIX, network transit, broker processing, and round-trip time are different intervals and must not be conflated.
  • 2 Confirm the relevant timestamps use synchronized clocks. Millisecond comparisons are meaningless when hosts differ by more than a few milliseconds.
  • 3 Compare TransactTime (60) with SendingTime (52) on the outbound message. This isolates the application-to-FIX handoff delay.
  • 4 Measure from outbound send time to inbound acknowledgment time. Use the 52 on the outbound message and the receipt timestamp on the inbound 35=8.
  • 5 Check application and FIX-engine queues. A full queue explains FIX-side delay without any network involvement.
  • 6 Compare against a known-good period before blaming the exchange. Establish a baseline before escalating.
Common Problems
Symptom Likely Cause First Check
Tag 60 is earlier than Tag 52 Normal application-to-FIX delay Difference between the two values
Tag 60 is later than Tag 52 Clock skew or incorrect timestamp population Host clock and application logic
Slow order acknowledgment Network, risk, broker, or exchange delay Outbound 52 vs inbound receipt time
Sporadic latency spikes Queuing, garbage collection, packet loss, or load Application and system metrics
Consistent timestamp offset Clock synchronization issue NTP/PTP status and time zone
Negative latency calculation Unsynchronized clocks or mismatched events Timestamp source and clock drift
Delayed fills only Market conditions or downstream reporting Execution timeline and venue timestamps
Define the Latency You Are Measuring
Order created
↓
Application queue
↓
FIX engine sends message
↓
Network
↓
Broker / exchange processing
↓
Execution Report received

Latency may refer to any of these intervals:

  • application-to-FIX delay
  • FIX send-to-wire delay
  • network transit time
  • broker or exchange processing time
  • round-trip order acknowledgment time
  • execution-report delivery time

Use a clear start timestamp and end timestamp. "The order was slow" is not a measurement.

Reading the Logs

Example 1 — Order round-trip with timestamps:

APP 13:30:00.120 Order created ClOrdID=ABC123 OUT 13:30:00.145 35=D|11=ABC123|52=20260714-13:30:00.145|60=20260714-13:30:00.120| IN 13:30:00.188 35=8|11=ABC123|150=0|39=0|
  • • Application-to-FIX delay: 25 ms (60 → 52).
  • • FIX send-to-acknowledgment delay: 43 ms (outbound 52 → inbound receipt).
  • • End-to-end order creation-to-acknowledgment: 68 ms.

Example 2 — Tag 60 later than Tag 52:

OUT 13:30:00.500 52=20260714-13:30:00.500|60=20260714-13:30:01.200|
  • • Tag 60 is 700 ms later than Tag 52 — this is not a normal ordering of events.
  • • Check host clock synchronization and how the application populates TransactTime (60).
Clock Synchronization

Millisecond-level analysis is meaningless when the participating clocks differ by seconds. Confirm:

  • • all hosts use UTC
  • • NTP or PTP is healthy and drift is monitored
  • • leap-second handling is understood and tested
  • • timestamp precision is consistent — milliseconds vs microseconds vs seconds
  • • application, FIX engine, and packet-capture hosts are all synchronized to the same source
Resends and OrigSendingTime

Resent messages may carry PossDupFlag (43) = Y and OrigSendingTime (122).

SendingTime (52) reflects when the resent message was transmitted. OrigSendingTime (122) reflects the original send time. Do not calculate original business latency from the resent SendingTime alone — the gap between 122 and 52 is session-recovery time, not application latency.

Recovery Checklist
Latency & Timing — Recovery
5-Minute Diagnosis
Latency & Timing — TL;DR
  • What interval is being measured — application-to-FIX, network, broker, or round-trip?
  • Are the clocks synchronized? Is the offset known?
  • Are Tag 52 and Tag 60 being compared correctly?
  • Is the delay occurring before the FIX engine or after it?
  • Is the issue constant or sporadic?
  • Does the same behavior appear across venues or sessions?