Session Messages

Session-level messages manage the connection lifecycle between client and server, ensuring message sequence integrity and heartbeat maintenance.

Implementation Notes

Session Management

• Require Logon/Logout exchange and consistent sequence numbers.
• Start heartbeat monitoring right after logon; persist state to allow reconnect recovery.

Error Handling

• Send Reject on protocol violations.
• Use heartbeat checks to detect failures and close sessions cleanly to avoid data loss.

Security

• Protect credentials and use unique, unpredictable session IDs.
• Ensure message integrity with correct sequencing and enable FIX encryption if needed.

Administrative Messages

Session Flow Diagram

Session Establishment Flow:

• Initiator sends Logon message with proposed heartbeat interval and credentials
• Acceptor validates credentials and responds with Logon acknowledgment
• Both parties may begin message exchange after successful logon sequence
• Heartbeat monitoring begins immediately using the agreed interval

Standard Header

All FIX messages include a standard header containing essential routing and sequencing information. The header must appear at the beginning of every message and contains the following fields in the specified order:

Logon (MsgType=A)

The Logon message establishes and authenticates a FIX session connection. It must be the first message transmitted by the session initiator and requires acknowledgment from the acceptor before normal message flow can begin.

Heartbeat (MsgType=0)

Heartbeat messages maintain session connectivity during periods of inactivity and verify the communication link status. They are automatically generated when no other messages are transmitted within the heartbeat interval.

Additional Heartbeat requirement:

Client should send a Heartbeat (35=0) message to ACY Connect at least every 30 seconds, else the session may be disconnected.

Heartbeat Behavior

• Auto-generates if no other messages are sent within the interval.
• Resets the timer whenever any message is received.
• Must be sent at least every 30 seconds when idle to avoid disconnection.

Test Request (MsgType=1)

Test Request messages verify bidirectional communication and prompt an immediate Heartbeat response. They are used to detect communication failures and ensure session connectivity.

Usage Guidelines

• Send to verify connectivity.
• Expect a Heartbeat reply with the same TestReqID.
• Allow for normal network delay before timing out.
• Useful for spotting and clearing communication gaps.

Reject (MsgType=3)

Reject messages indicate that a received message could not be processed due to session-level errors such as invalid format, unsupported message types, or protocol violations.

Rejection Handling:

• Session-level rejects indicate protocol or format errors
• Distinguished from business-level rejects which use application-specific messages
• Rejected messages are not re-queued automatically
• Sender should investigate and correct the issue before retransmission

Logout (MsgType=5)

Logout messages gracefully terminate FIX sessions, allowing both parties to close connections in an orderly fashion and preserve session state information.

Logout Process

• Either side may start a logout.
• The peer replies with a Logout message.
• Close the connection once the exchange finishes.
• Preserve session state for future reconnection.
• Keep sequence numbers unless a later logon requests a reset.

Business Message Reject (35=j)

The Business Message Reject (j) message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject (3) message should be issued.

Scenarios which receives Business Message Reject:

• Message passes FIX session-layer validation but violates business rules
• Unsupported message type received by the application
• Conditionally required business fields are missing
• Business authorization failures occur
• No specific reject message exists for the particular business case

BusinessRejectReason (380)

• 0 = Other
• 1 = Unknown ID
• 2 = Unknown Security
• 3 = Unsupported Message Type (receive a valid, but unsupported MsgType (35))
• 4 = Application not available
• 5 = Conditionally Required Field Missing
• 6 = Not Authorized
• 7 = DeliverTo firm not available at this time
• 18 = Invalid price increment