Imported from previous forum
[ original email was from John Prewett - jprewett@lavatrading.com ]
It is often the case that the application is a very separate layer from the FIX engine. The interface between these two is achieved by either an intra or inter process mechanism of some type which can be subject to delays when under stress.
An application knows when it receives a message (all it has to do is to look at the clock). What the application doesn’t know is when its FIX engine received the message. When the SendingTime indicates there was a delay in the application receiving a message, the presence of a timestamp added to the message by the receiving FIX engine could at least indicate whether the delay was “internal” between the FIX engine and the application or “external”.
It is currently unclear in the FIX specification as to whether SendingTime(52) in the FIX header is for use by the application or the sending FIX engine. Many application message bodies (but not all?) support TransactTime(60), which would suggest that SendingTime(52) is for use by the sending FIX engine. It would be a good thing if usage of SendingTime(52) were explicitly declared by the protocol specification.
The HopCompID(628)/HopSendingTime(629) fields added in FIX.4.3 could potentially solve both the above issues, although I think their intended usage was for FIX<->FIX hops and not App<->FIX "hops".
Personally, I would like to see some clarification as to usage of sending/receiving timestamps in the specification, especially focusing upon delays between application and FIX engine.
Thanks for listening.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> It is currently unclear in the FIX specification as to whether SendingTime(52) in the FIX header is for use by the application or the sending FIX engine. Many application message bodies (but not all?) support TransactTime(60), which would suggest that SendingTime(52) is for use by the sending FIX engine. It would be a good thing if usage of SendingTime(52) were explicitly declared by the protocol specification.
My understanding of is that you are entirely correct. SendingTime is a session level concept set by the sending engine, and TransactTime is an application level concept. A difference between them indicates latency between the app and the FIX engine prior to the message being transmitted over the wire. (Or, alternately, the engine and app are running on two different machines whose clocks are not in sync. 
> The HopCompID(628)/HopSendingTime(629) fields added in FIX.4.3 could potentially solve both the above issues, although I think their intended usage was for FIX<->FIX hops and not App<->FIX "hops".
I’d suggest against considering a simple system with a trading app/OMS and a FIX engine as having multiple hops. I believe these fields were designed for FIX routing networks.