The Lab

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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
titlemsgSeqNum

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

...