Page History
...
| Table of Contents |
|---|
Overview
Sessions
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 will be restricted to dedicated API connections only.
For a given Client and given Whisperer Feed Handler deployment within MarketFactory, each session type will be assigned unique Venue connection credentials (typically TargetCompID and SenderCompID).
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,
| Note | ||
|---|---|---|
| ||
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 for the lifetime of the Whisperer SBE4 session.
- sendingTime - nanosecond-precision timestamp indicating when the message left the sender.
Users
Whisperer SBE4 requires the configuration of at least one 'User' to be used for a given Session. In general a single User should be associated with a single
Pricing
Venue as CLOB/Maker
The MFSBE4 client may organise subscriptions across Users as it deems fit.
| Note |
|---|
| Venues may reject multiple identical requests, so care should be taken to ensure that there is a clear demarcation of responsibility across Users. |
Venue as Taker
A single User must be defined, to avoid the need for configuration and logic to be maintained within MarketFactory to route each Venue QuoteRequest to specific individual Users.
Orders
Venue as CLOB/Maker
The MFSBE4 client may distribute Orders across Users as it deems fit.
Venue as Taker
A single User must be defined, to avoid the need for configuration and logic to be maintained within MarketFactory to route each Venue NewOrderMultileg to specific individual Users.
RFS
Venue as Maker
The MFSBE4 client may distribute RFQ and/or RFS across Users as it deems fit.
Venue as Taker
A single User must be defined, to avoid the need for configuration and logic to be maintained within MarketFactory to route each Venue RFS/RFQ to specific individual Users.
DropCopy
This is a single feed per Venue, delivering trade notifications from the Venue to to the Customer. A single User is defined, avoiding the need for configuration and logic to be maintained within MarketFactory to route trade notifications from the Venue to specific individual users.
Logon
Session Synchronisation
...