Clients will initiate FIX sessions with the EBS FIX engine. There will be separate sessions for Market Data and Order Management.

To support trading on EBS, both the Quote and Order sessions must be active:

• If the Market Data session becomes disconnected, then market data books will be cleared to prevent new trades. The transactional session will remain open to allow trades in-flight to complete.

• If the Order Management session becomes disconnected, then market data will not be forwarded to clients. However, as long as the Market Data session is still active, subscriptions on the Market Data session will not be terminated, and market data flow to clients will resume when the transactional session is re-established.

Session Management includes the following:

Session Recovery

Clients are expected to specify ResetSeqNumFlag = 'Y' on every Logon to force a session reset. Logons which do not specify ResetSeqNumFlag='Y' will be rejected with a Logout message, the Text field will indicate "Session Reset Required".

For firm workflow only, Application level recovery will support re-delivery of any firm NewOrderSingle (35=D) for which a trade confirmation (35=8, 150=F) has not been received. These firm orders, which indicate a confirmed trade on the EBS system, will be resent at session re-initiation and flagged with the PossResend in the header. To avoid booking duplicate trades the Maker should determine, based on the ClOrdId of the order, whether the trade has already been booked in the Maker system.

For non-firm workflow recovery is not necessary since indicative orders will never be booked in the absence of a fill (35=8, 150=F) from the LP.

Logon (35=A)

Message Overview

A single SenderCompID/TargetCompID may have only one active FIX connection at a time. If a duplicate Logon request for the same SenderCompID/TargetCompID is received while a FIX connection is active, there will be no response to the new Logon request.

Makers are cautioned not to repeatedly attempt to Logon following an unsuccessful Logon attempt. Client applications should wait a configurable time interval before re-attempting a successive logon.

Failed Logon Attempts

If a Client Logon request has passed network layer authentication and initial message validation, but the Logon Request cannot be completed for any reason, EBS will reply with a Logout message indicating the reason for the Logon failure in the Text field.  The Logon request must include a valid SenderCompID/valid TargetCompID combination. This Logout message is uni-directional and should not be replied to so we are safe to terminate the connection at this point, however if the client nevertheless sends a Logout in response we can simply ignore it and proceed to terminate the connection.  After sending the Logout message, EBS will immediately terminate the network connection.

Connection attempts which do not pass network layer authentication will not be responded to. Similarly, mal-formed Logon messages (missing required field, invalid data type, invalid header or trailer) will be ignored.

Clients are cautioned not to repeatedly attempt to Logon following an unsuccessful Logon attempt. Client applications should wait a configurable time interval before re-attempting a successive logon. Logon attempts more frequent than the EBS provided configured maximum logon frequency will not be responded to.

Heartbeat (35=0)

Test Request (35=1)

Sent to request a Heartbeat from the other side. FIX protocol recommends using the current timestamp as the TestReqID.

Resend Request (35=2)

EBS does not support retransmission of missed Sequence Numbers; upon receipt of a Resend Request EBS will respond with a Logout(35=5).

Sequence Reset (35=4)

EBS does not support Sequence Reset(35=4), sequence numbers should only be reset as part of the Logon (35=A) message by way of ResetSeqNumFlag(141) = Y. If a SequenceReset(35=4) message is received by BrokerEBSTec we will respond with a Logout (35=5)

Session Level Reject (35=3)

A generic message which can be used by either side to reject a FIX message which fails session-level validation. It contains fields to indicate the FIX MsgType and FIX tag of the invalid data.

If a message contains multiple session level rule violations which would cause rejection, only the first detected error will be indicated in the Reject message. To avoid rejection loops, errors in a Reject message should not themselves be rejected.

Logout (35=5)

The Logout message may be sent by either party to initiate proper, controlled shutdown, or to indicate that an unrecoverable connectivity error has occurred. A good practice is to issue a TestRequest and receive the corresponding heartbeat before Logout.

Logout may occur due to receipt of a malformed message, a heartbeat timeout, or a scheduled shutdown period. To assist with troubleshooting, a Logout reason should be provided on each Logout via the free-form Text field.  After sending the Logout Request, the logout initiator should not send any additional messages other than responding to an incoming ResendRequest.

When one side receives a Logout request from the other, it should flush any queued messages and then respond with the Logout message. This lets the other side know that it will not receive any more messages from the other and that it can close its connection. A configurable timeout will be implemented, so that if a Logout response is not received after that time, EBS will unilaterally close the connection.

On the order management sessions, if the Maker receives a Logout request from EBS, it should immediately suspend the matching of any non-firm open orders, publish Execution Reports for all active orders, and then reply with the Logout response. This will minimize the occurrence of DKTrade messages for Execution Reports that were received in an untimely fashion.

Similar action should be taken any time the Maker detects a loss of connectivity or stale heartbeat with the EBS system. Active non-firm orders should be pulled, unsent Execution Reports should be published, and a Logout Request should be sent to the EBS system.