The overall latency of the receive process includes all latencies of all operations inside this process. The following sequence of operations are performed when the FIX Engine receives a FIX message:

• Invocation of the system receive function of the TCP socket. In practice, the latency of the system receive function can be about 5-10 microseconds what depends on the size of receive data, network workload, network software/hardware, etc.
• Invocation of the BytesReceived event.
• Deserialization of the raw buffer to the inbound message. The latency of this action depends on the SessionMessageMode property. For the Message class it is an expensive operation and it can take a few microseconds what depends on the message size. For the FlatMessage class it is a cheap operation because an object of this class represents the serialized buffer.
• Validation of the incoming FIX message following validation settings (for Message objects only). Therefore, the number of validation aspects affects this latency.
• Invocation of the InboundSessionMsgEvent or InboundApplicationMsgEvent event.
• Writing necessary data (message content, timestamp, sequence numbers, etc.) to the session storage. For the File-Based Session Storage, it is a very expensive operation and it can take tens of microseconds. For the Asynchronous File-Based Session Storage, it is far cheaper, because the actual writing is performed in a separate thread. And lastly, for the Memory-based Session Storage, it is a very cheap operation, because data is stored in the memory, not in the file system. Please note, that for session-level messages, the logging is performed before calling the InboundSessionMsgEvent, but for application-level messages, the logging is performed after calling the InboundApplicationMsgEvent. The reason is to deliver application-level messages as soon as possible to the user's callback.

Based on the above, one can understand what the send latency includes.