I am very confused about the field SendingTime (Tag 52) if it’s the timestamp when the message is sent or the timestamp when started assembling the snapshot ( in case of 35=W) ?
I found a topic in the FIX trading community forum having answers saying it is the time the message was sent. Please check the answer saying: This field is typically added automatically by your FIX engine just before the message is sent (ie after any internal queuing) along with other transport related fields such as MsgSeqNum and CheckSum which cannot be predicted by application level code.
I’m asking the question because I found no way to change the implementation for the 52= at the application level as mentioned in the topic answer so wanted to double check with you.
It’s the time the message was sent, not the time it was generated. For W tags like LastUpdateTime might fulfill your application level need.
If a W message was re-sent due to sequence number mismatch, tag 52 would be updated on the resend to the time it was re-sent but tags like LastUpdateTime wouldn’t be modified.
On the technical session level, if the outgoing message has to be resent triggered by a ResendRequest of the counter party (e.g. due to network issues) then the SendingTime becomes OrigSendingTime and the SendingTime is filled with the current time. If another resend request is triggered the SendingTime is updated again to the current time, but the OrigSendingTime is not touched.
In this way, the counter party could detect stale messages by comparing the OrigSendingTime (the time when the message was first sent) and the SendingTime (the time the message was resent recently).
@cm4cdow timestamps for regulatory reporting purposes should not come from the StandardHeader. They should come from the TrdRegTimestamps component in the application message, or from TransactTime depending on what kind of timestamp.
@ltaikit I believe accurate timekeeping regulations applies to all auditable timestamps, not just those times submitted on a regulatory report. It can be difficult to explain to an auditor, for example, why a trade was executed after it was sent.
The regulator usually defines the timestamps that it wants to see in its specifications. @cm4cdow, do you have an example where a regulator wants to see technical sending times of messages in addition to or even instead of business level timestamps related to order submission and execution? There are examples of timestamps representing the time when a message was received, but referring to the clock of the recipient and not the sender. See TrdRegTimestampType(770) for details.
This field also supports sending times, e.g. 10=Order submission time, representing the time that the application “sent” the order to lower layers of the infrastructure. That is the time of the investment decision, in this example to submit an order. SendingTime(52) should only be used to troubleshoot connectivity issues between counterparties. It should not be provided to the application layer as it also does not come from that layer. Legacy FIX engines running FIX 4.2 may not have the TrdRegTimestamps component as it was added with FIX 4.4. However, GTC policy is that it can be used in previous versions as well.
An example would fall under SOX 302.2, if the FIX logs were retained as part of evidencing internal controls. Also, regulators like the Fed can and do request copies of logs when they are investigating activity (think Enron, Madoff). If you retain your FIX logs, it’s a good policy to keep all timestamps on those logs accurate.
2. Establish safeguards to establish timelines. (Section 302.3)
Implement an ERP system or GRC software that timestamps all data as it is received in real-time. This data should be stored at a remote location as soon as it is received, thereby preventing data alteration or loss. In addition, log information should be moved to a secure location and an encryped MD5 checksum created, thereby preventing any tampering.
That seems to be about the timestamping upon receipt of data, not sending data. All you can control yourself is the time you received information. People may send you inaccurate timestamps that you should not have to rely on when answering to an auditor. The sender may claim something that does not match up with your own records. Timestamps in the FIX Standard Header are relevant either way, but are not intended to convey business level information. I do not doubt that they are still used in that way by users of FIX legacy versions.
For an audit like SOX, the rules on timestamps are whatever policies your internal and external auditors on set SOX controls. Going back to my original example - a keen-eyed auditor will haul you over the coals for stamping an execution with a sending time before the execution time - if the FIX log is part of your control.
I think nobody is suggesting that this would be ok. You have to sync your own clock devices (e.g. matching engine server versus FIX engine gateway) to avoid anything like that from happening.
) .
2. Establish safeguards to establish timelines. (Section 302.3)