Fix Specification Lookup – Session – Logon

Session – Logon Protocol

The logon message is utilized to authenticate a user attempting to establish a connection to a remote system. The logon message must be the first message sent by the application requesting to initiate a FIX session.

The HeartBtInt (108) field is used to declare the timeout interval for generating heartbeats.

Upon receipt of a Logon message the session acceptor will authenticate the party requesting connection and issue a Logon message as acknowledgment that the connection request has been accepted. The acknowledgment Logon can also be used by the initiator to validate that the connection was established with the correct party.

The session acceptor must be prepared to immediately begin processing messages after receipt of the Logon. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation Logon, however it is recommended that normal message delivery wait until after the return Logon is received to accommodate encryption key negotiation.

The confirmation Logon can be used for encryption key negotiation. If a session key is deemed to be weak, a stronger session key can be suggested by returning a Logon message with a new key. This is only valid for encryption protocols that allow for key negotiation. (See the FIX Home Page Application notes for more information on a method for encryption and key passing.)

The logon format is as follows:

TagField NameReq'dDescription
8BeginStringYFIX.4.0 (Always unencrypted, must be first field in message)
9BodyLengthY(Always unencrypted, must be second field in message)
35MsgTypeY(Always unencrypted, must be third field in message)
49SenderCompIDY(Always unencrypted)
56TargetCompIDY(Always unencrypted)
115OnBehalfOfCompIDNTrading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)
128DeliverToCompIDNTrading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)
90SecureDataLenNRequired to identify length of encrypted section of message. (Always unencrypted)
91SecureDataNRequired when message body is encrypted. Always immediately follows SecureDataLen field.
34MsgSeqNumY(Can be embedded within encrypted data section.)
50SenderSubIDN(Can be embedded within encrypted data section.)
57TargetSubIDN“ADMIN” reserved for administrative messages not intended for a specific user. (Can be embedded within encrypted data section.)
116OnBehalfOfSubIDNTrading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)
129DeliverToSubIDNTrading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)
43PossDupFlagNAlways required for retransmissions, whether prompted by the sending system or as the result of a Resend Request. (Can be embedded within encrypted data section.)
97PossResendNRequired when message may be duplicate of another message sent under a different sequence number. (Can be embedded within encrypted data section.)
52SendingTimeY(Can be embedded within encrypted data section.)
122OrigSendingTimeNRequired for message resends. If data is not available set to same value as SendingTime (Can be embedded within encrypted data section.)
112TestReqIDNRequired when the heartbeat is the result of a Test Request message.
93SignatureLengthNRequired when trailer contains signature. Note: Not to be included within SecureData field
89SignatureNNote: Not to be included within SecureData field
10CheckSumY(Always unencrypted, always last field in message)