Overview

Session Types

Whisperer SBE4 Maintains the following session types:

Pricing - used for delivery of Market Data from a CLOB Venue, or ESP mass-quotes from a Maker.
Orders - used for submission and execution of CLOB Venue orders, or trading against ESP Maker liquidity (published on a separate Pricing session).
RFS - used for the full RFS/RFQ quotation negotiation life cycle between Maker and Taker.
DropCopy - used for the delivery of post-Trade Straight-Through Processing (STP) trade notifications. Typically this will be

Session Schedule

All session types are maintained directly with an individual Whisperer Feed Handler and operate a weekly schedule commencing on Sunday prior to Asia-open and ending on Friday, NY-close. This is irrespective of the schedule of the Venue itself,

This field should never be reset intra-week, for any session type.

Message Header

In addition to the default SBE message header fields (blockLength, templateId, schemaId and version), the MFSBE4 header additionally defines the mandatory population of the following fields:

messageLength - this is provided to allow verification that the full message has indeed been received (e.g. should it span multiple packets).
msgSeqNum - this is the standard integer message sequence number. At the start of a session it should be set to '1', and incremented with every subsequent message sent.
sendingTime - nanosecond-precision timestamp indicating when the message left the sender.

Logon

Session Synchronisation

The Whisperer SBE4 APi utilises the 'new' model of session synchronisation introduced in FIX 4.4. This ensures that each side can expect any sequence number gaps to be filled automatically, eliminating the need for ResendRequest messages - and the problems that historically accompany these.

The MFAPI client initiates a new session with a Logon message - this contains the next MsgSeqNum[34] value that the client expects to receive from the Whisperer Feed Handler.

The Whisperer Feed Handler validates the sequence number value as expected by the MFAPI client as follows:

If the Client is expecting a sequence number higher than the FH's next-to-be-assigned msgSeqNum, then this is an unrecoverable error and the FH will abort the session with a Logout message.

Otherwise the FH will issue a LogonResponse message containing the next MsgSeqNum[34] value that it expects to receive from the client.

If the Client is expecting a sequence number lower than the FH's next-to-be-assigned msgSeqNum[34], then the message gap is resolved by the FH with SequenceResetGapFill messages and the resending of persisted messages as necessary.

The Whisperer Feed Handler signals it's completion of session synchronisation with a TestRequest.

Any new (i.e. not SequenceResetGapFill or resent) messages sent by the MFAPI Client prior to the required Heartbeat response will result in ErrorReport messages.

After any inbound sequence number gaps have been resolved for the MFAPI Client, it then reciprocates in a similar manner, based on the the next MsgSeqNum[34] value that the Whisperer Feed Handler expects to receive from the client - as specified in it's LogonResponse.

The mutual exchange of TestRequest and Heartbeat (response) messages are required as verification that no sequence number gaps remain. The MFAPI client should only proceed after it has received the Heartbeat sent in response to it's own TestRequest.

Message Persistence

The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:

Message	Sent By	Received By	Persisted
Logon	Client (Both)	Feed Handler	No
LogonResponse	Feed Handler	Client (Both)	No
Logout	Client (Both)	Feed Handler	No
LogoutResponse	Feed Handler	Client (Both)	No
SequenceResetGapFill	Client (Both)	Feed Handler	No
SequenceResetGapFill	Feed Handler	Client (Both)	No
Heartbeat	Client (Both)	Feed Handler	No
Heartbeat	Feed Handler	Client (Both)	No
TestRequest	Client (Both)	Feed Handler	No
TestRequest	Feed Handler	Client (Both)	No
SecurityStatus	Feed Handler	Client (TAKER)	No
UserRequest	Client (Both)	Feed Handler	No
UserNotification	Feed Handler	Client (Both)	No
ErrorReport	Feed Handler	Client (Both)	Yes
MarketDataRequest	Client (Both)	Feed Handler	No
MarketDataRequestReject	Feed Handler	Client (Both)	No
MarketDataIncrementalRefresh	Feed Handler	Client (Both)	No
QuoteRequest	Client (TAKER)	Feed Handler	Optional
QuoteRequest	Feed Handler	Client (MAKER)	Yes
QuoteRequestReject	Client (MAKER)	Feed Handler	Optional
QuoteRequestReject	Feed Handler	Client (TAKER)	Yes
Quote	Client (MAKER)	Feed Handler	No
Quote	Feed Handler	Client (TAKER)	No
MassQuote	Client (MAKER)	Feed Handler	No
MassQuote	Feed Handler	Client (TAKER)	No
QuoteResponse	Client (MAKER)	Feed Handler	Optional
	Feed Handler	Client (TAKER)	Yes
	Client (TAKER)	Feed Handler	Optional
	Feed Handler	Client (MAKER)	Yes
NewOrderMultileg	Client (Both)	Feed Handler	Optional
NewOrderMultileg	Feed Handler	Client (MAKER)	Yes
OrderCancelReplaceRequest	Client (Both)	Feed Handler	Optional
OrderCancelRequest	Client (Both)	Feed Handler	Optional
OrderCancelReject	Feed Handler	Client (Both)	Yes
OrderTimeout	Feed Handler	Client (Both)	Yes
ExecutionReport	Client (MAKER)	Feed Handler	Yes
ExecutionReport	Feed Handler	Client (TAKER)	Yes
ExecutionAck	Client (TAKER)	Feed Handler	Optional
ExecutionAck	Feed Handler	Client (MAKER)	Yes

Logon to Existing Session

Any attempt by the MFAPI client to log on to an existing session will result in the session being aborted.

Session Monitoring

Active sessions are monitored at the application level by each party via Heartbeat and TestRequest messages. Indications of problems must result in the monitoring party aborting the session.

The maximum allowed message transmission time (MaxTx) between between the MFAPI Client and the Whisperer Feed Handler is fixed, currently set to one second.

Heartbeats

Once the MFAPI Client has successfully established a session with the Whisperer Feed Handler (i.e. on dispatch of the first Heartbeat message in response to the end of synchronisation TestRequest), subsequent Heartbeat messages are sent by each party at the interval specified by the MFAPI client in it's Logon message.

Unlike standard FIX sessions, Heartbeat messages must be published as a metronome - no allowance should be made based on whether or not other messages are sent within each interval.

A heartbeat is deemed to have been missed if it is not received within HeartBtInt + MaxTx seconds and must result in the monitoring party issuing a TestRequest.

Test Request

TestRequest messages may be issued by either party and under normal circumstances result in a Heartbeat being sent in response, echoing the specified TestRequestID.

TestRequest messages may be used to obtain an approximate indication of message round-trip times between the MFAPI Client and the Whisperer Feed Handler.

If no Heartbeat response is received within HeartBtInt + MaxTx seconds of the issuance of the TestRequest, then the party must abort the session with a Logout message.

ErrorReport

The ErrorReport is a custom, user-defined, message used by the Whisperer Feed Handler to notify the MFAPI Client when erroneous messages are received:

From Client

At an invalid lifecycle phase (e.g. QuoteRequest sent before the connection to the Maker Venue is established, or after the Whisperer Feed Handler has disconnected from the Venue).
Message is not supported by the Venue (e.g. sending a Quote to a Maker Venue).
Message contains invalid data.

From Venue

A FIX Reject or BusinessMessageReject message

Since there are scenarios where ErrorReport messages may not be delivered (e.g. during session abort sequences), these messages are persisted and will be delivered on reconnection.

Logout

All Logout messages must be echoed with a LogoutResponse.

If no LogoutResponse is received within HeartBtInt + MaxTx seconds of the issuance of the Logout, then the session and associated TCP socket connection must be dropped.

All messages received by the Whisperer Feed Handler between the exchange of Logout and LogoutResponse messages will result in ErrorReport messages.

Venue Login

Session startup behaviour is standardised across Taker, Maker and CLOB Venue types as follows:

MFAPI Client first establishes connection to Whisperer with Logon & LogonResponse, then connects to Venue with UserRequest (UserRequestType=LogOnUser) & UserNotification (UserStatus=LoggedOn)
All MFAPI Client pricing/trading requests sent before this will be rejected by Whisperer via ErrorReports.

Illustrate multiple logon attempts to venue - 5 attempts, one minute interval, then logout to client. Eg Consider Reuters MAPI.

Illustrate what happens when Venue or Client connection is dropped.

Illustrate EOD session/seq num resets.

Multiplexing - if we have multuiple users connecting to single venue, and first user triggers logon, last user triggers logout, how de we support first user logout cleanly - eg their order cancellations that they need to be notified of...

user sends initiates a transaction after after receiving a loggedout user notification