FIXT 1.1 : Logon<A> message

Structure | Sample Message | Related Messages


Establishing a FIX connection involves three distinct operations: creation of a telecommunications level link, authentication/acceptance of the initiator by the acceptor and message synchronization (initialization). The sequence of connection follows:

  • The session initiator establishes a telecommunication link with the session acceptor.
  • The initiator sends a Logon<A> message. The acceptor will authenticate the identity of the initiator by examining the Logon<A> message. The Logon<A> message will contain the data necessary to support the previously agreed upon authentication method. If the initiator is successfully authenticated, the acceptor responds with a Logon<A> message. If authentication fails, the session acceptor should shut down the connection after optionally sending a Logout<5> message to indicate the reason of failure. Sending a Logout<5> in this case is not required because doing so would consume a sequence number for that session, which in some cases may be problematic. The session initiator may begin to send messages immediately following the Logon<A> message, however, the acceptor may not be ready to receive them. The initiator must wait for the confirming Logon<A> message from the acceptor before declaring the session fully established.

    After the initiator has been authenticated, the acceptor will respond immediately with a confirming Logon<A> message. Depending on the encryption method being used for that session, this Logon<A> message may or may not contain the same session encryption key. The initiator side will use the Logon<A> message being returned from the acceptor as confirmation that a FIX session has been established.

    successful-logonSuccessful Logon

    If the session acceptor has chosen to change the session encryption key, the session initiator must send a third Logon<A> back to the other side in order to acknowledge the key change request. This also allows the session acceptor to know when the session initiator has started to encrypt using the new session key. Both parties are responsible for infinite loop detection and prevention during this phase of the session.

  • After authentication, the initiator and acceptor must synchronize their messages through interrogation of the MsgSeqNum(34) field before sending any queued or new messages. A comparison of the MsgSeqNum(34) in the Logon<A> message to the internally monitored next expected sequence number will indicate any message gaps. Likewise, the initiator can detect gaps by comparing the acknowledgment Logon<A> message’s MsgSeqNum(34) to the next expected value. The section on message recovery later in this document deals with message gap handling.
  • It is recommended to wait a short period of time following the Logon<A> or to send a TestRequest<1> and wait for a response to it before sending queued or new messages in order to allow both sides to handle resend request processing. Failure to do this could result in a ResendRequest<2> message being issued by one’s counterparty for each queued or new message sent. (see "Logon Message NextExpectedMsgSeqNum Processing" for an alternative approach)
  • It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, ... which can result in many resent PossDupFlag(43)=Y messages.
  • When using the ResetSeqNumFlag(141) to maintain 24-hour connectivity and establish a new set of sequence numbers, the process should be as follows. Both sides should agree on a reset time and the party that will be the initiator of the process. Note that the initiator of the ResetSeqNum<4> process may be different than the initiator of the Logon <A> process. One side will initiate the process by sending a TestRequest<1> and wait for a Heartbeat<0> in response to ensure of no sequence number gaps. Once the Heartbeat<0> has been received, the initiator should send a Logon with ResetSeqNumFlag(141) set to Y and with MsgSeqNum of 1. The acceptor should respond with a Logon <A> with ResetSeqNumFlag(141) set to Y and with MsgSeqNum(34) of 1. At this point new messages from either side should continue with MsgSeqNum(34) of 2. It should be noted that once the initiator sends the Logon <A> with the ResetSeqNumFlag(141) set, the acceptor must obey this request and the message with the last sequence number transmitted “yesterday” may no longer be available. The connection should be shutdown and manual intervention taken if this process is initiated but not followed properly.

The Logon<A> message authenticates a user establishing a connection to a remote system. The Logon<A> 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 (same value used by both sides).

Upon receipt of a Logon<A> message the session acceptor will authenticate the party requesting connection and issue a Logon<A> message as acknowledgment that the connection request has been accepted. The acknowledgment Logon<A> 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<A>. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation Logon<A>, however it is recommended that normal message delivery wait until after the return Logon<A> is received to accommodate encryption key negotiation.

The confirmation Logon<A> 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<A> 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<A> message can be used to specify the MaxMessageSize(383) supported (i.e. can be used to control fragmentation rules for very large messages which support fragmentation). It can also be used to specify the MsgTypes supported for both sending and receiving.


Tag Field Name Req'd Comments
<MessageHeader> Y MsgType(35) = A
98 EncryptMethod Y

(Always unencrypted)

108 HeartBtInt Y
95 RawDataLength N

Required for some authentication methods

96 RawData N

Required for some authentication methods

141 ResetSeqNumFlag N

Indicates both sides of a FIX session should reset sequence numbers

789 NextExpectedMsgSeqNum N

Optional, alternative via counterparty bi-lateral agreement message gap detection and recovery approach (see "Logon Message NextExpectedMsgSeqNum Processing" section)

383 MaxMessageSize N

Can be used to specify the maximum number of bytes supported for messages received.

<MsgTypeGrp> N


464 TestMessageIndicator N

Can be used to specify that this FIX session will be sending and receiving "test" vs. "production" messages.

553 Username N


554 Password N

Note: minimal security exists without transport-level encryption.

925 NewPassword N

Specifies a new password for the FIX Logon. The new password is used for subsequent logons.

1400 EncryptedPasswordMethod N


1401 EncryptedPasswordLen N


1402 EncryptedPassword N


1403 EncryptedNewPasswordLen N


1404 EncryptedNewPassword N

Encrypted new password- encrypted via the method specified in the field EncryptedPasswordMethod(1400)

1409 SessionStatus N

Session status at time of Logon<A>. Field is intended to be used when the Logon <A> is sent as an acknowledgement from acceptor of the FIX session.

1137 DefaultApplVerID Y

The default version of FIX messages used in this session.

1407 DefaultApplExtID N

The default extension pack for FIX messages used in this session.

1408 DefaultCstmApplVerID N

The default custom application version (dictionary) for FIX messages used in this session.

58 Text N

Available to provide a response to Logon<A> when used as a Logon<A> acknowledgement from acceptor back to the Logon<A> initiator.

354 EncodedTextLen N

Must be set if EncodedText(355) field is specified and must immediately precede it.

355 EncodedText N

Encoded (non-ASCII characters) representation of the Text(58) field in the encoded format specified via the MessageEncoding(347) field.

<MessageTrailer> Y


Sample Message

The '^' character is used to represent SOH character.


Related Messages

Copyright FIX Protocol Limited

Onix Solutions