Whisperer Enterprise 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 Venue/Session, although there is some flexibility as set out below.
| SessionType | Venue is CLOB | Client is Taker | Client is Maker |
|---|---|---|---|
| Pricing | To ensure consistent latency and throughput characteristics, a single User is recommended to be used for all MarketData subscriptions. If client requirements dictate, multiple users may be configured, as per MarketData, below. Please contact MarketFactory Support to coordinate required configuration settings. | To ensure consistent latency and throughput characteristics, a single User is recommended to be used for all ESP subscriptions. If client requirements dictate, multiple users may be configured, as per TakerESP, below. Please contact MarketFactory Support to coordinate required configuration settings. | A single User must be defined. This avoids the need for configuration and logic to be maintained within MarketFactory to route each Venue ESP QuoteRequest to specific individual Users. |
| Orders | The Whisperer Client may distribute Orders across Users as it deems fit. | The Whisperer Client may distribute Orders across Users as it deems fit. | A single User must be defined. This avoids the need for configuration and logic to be maintained within MarketFactory to route each Venue ESP Order to specific individual Users. |
| RFS | - | The Whisperer Client may distribute RFQ and/or RFS subscriptions across Users as it deems fit. | A single User must be defined. This avoids the need for configuration and logic to be maintained within MarketFactory to route each Venue RFS/RFQ QuoteRequest 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 must be defined. This avoids the need for configuration and logic to be maintained within MarketFactory to route trade notifications from the Venue to specific individual users. | ||
Each individual client User maintains an individual session with the Gateway, and each one must establish a connection to the Venue via a UserRequest as described in Venue Connection Management.
The first user to do this will trigger Whisperer to establish the venue-side session and resolve any session synchronisation issues that arise.
In the event of a Venue FIX Session failure, session synchronisation will be triggered when the first Client User reconnects. Specific implications relating to this are discussed below.
In this case any resent messages will only be forwarded to the Client when the correct Client User finally reconnects. This implies that state should be persisted across Venue Connections.
The first Client User to reconnect will trigger FIX message resends from the Gateway to the Venue for all affected Client User Sessions. Any messages sent by the Venue in response will only be forwarded to the Client when the correct Client User finally reconnects.
Any Client User messages delivered during Client Session synchronisation will only be forwarded when that User finally reconnects to the Venue. This may be some considerable period after the FIX session has been established, from the Venues perspective. This scenario is thus subject to the same caveats as outlined above.
Similarly, when Client Users request a disconnection from the Venue via UserRequest (UserRequestType=LogOffUser), it is only the request of the last User that will actually trigger Whisperer to logout from the venue-side session. Any messages received from other client users will be persisted by Whisperer until their next venue session is established.
Whilst Whisperer Enterprise trading sessions have always been shareable across multiple users, pricing sessions have to date been constrained such that only a single client user was allowed to connect. This was because the support of multiple users sharing a single subscription incurs latency and other costs:
The existing architecture avoids these problems by delegating responsibility for client-side distribution of the market data to the client, using the client's specific technology choices (message bus, hardware/network architecture, etc.).
This approach works well for those clients that have a homogeneous connectivity architecture, internally.
For those clients that don't, Whisperer now offers Price Subscription Multiplexing ("Price MUX") for MarketData and TakerESP subscriptions.
For both scenarios, subscriptions are shared by the use of a common MDReqID, or QuoteReqID as outlined below. Other than this, each user maintains their own independent session with a given venue gateway, no knowledge of other users' session status is required.
MarketData sessions rely on MUX users using a common MDReqID to subscribe to shared subscriptions.
Once a user has connected to the gateway and established a session with the venue via the standard UserRequest(LogOnUser) message, SecurityStatus messages will be published defining the status of available instruments.
These messages are identical to those received in a non-MUX context, with the addition of a new BodyPassthruKey/Value pair, "MFSecurityID". MUX users must use this ID as the MDReqID in any subsequent MarketDataRequest messages. It should be noted that these IDs are not shared across venues and will change as venues make adjustments to their supported instruments.
In addition, all other instrument details in the MarketDataRequest must match those published in the SecurityStatus message:
Symbol, SecurityType, SecurityGroup, RegulatoryBodies, LegSettlType, etc.
From the perspective of the user, subscription behaviour is always consistent: subscribe and receive an initial snapshot, followed by updates. Observed latencies will differ, depending on the subscription-sharing model chosen:
The first user will observe minimal delay vs option 1, but others will observe additional latency due to the sequenced delivery of the update to each subscribed user (the classic TCP round-robin saw-tooth distribution).
After the subscription is established, subsequent late-joining users will receive an initial snapshot to synchronise book state (MarketDataIncrementalRefresh.MDFlags.IsSnapshot = TRUE).
Thereafter, each incremental message will be sent to all subscribers, in turn. Whilst the message header will reflect the specific user session (SendingTime, MsgSeqNum, etc), every user receives the identical message body content.
Remaining possible subscription details ( In the event of any validation errors, Whisperer will respond to the user with a |
Each subscribed book depth is a different view on the full venue book.
If necessary, users may subscribe to a shared Instrument with different MarketDepths, although it should be noted that this means that Whisperer must additionally maintain separate views on the book for each unique depth. Since late-joiners may subscribe to deeper book depths than the initial subscription, it also means that Whisperer must always make full-book subscriptions to the venue.
If the first user's subscription is full-book, then it will observe minimal delay vs option 1, but other user/MarketDepth subscriptions will observe additional latency vs option 2, due to the two-tier iteration of view management and per-view user distribution.
Each incremental received from the venue will be processed against every unique subscribed MarketDepth view, with a different message body being generated for each, containing additional explicit synthetic new and delete MDEntries as needed. A given venue MDEntry may result in any of the following:
MDUpdateAction | Within View | Below View |
|---|---|---|
New | Delivered. If an entry below is pushed outside the view as a result, then a synthetic | Excluded from the client message |
Change | Delivered. | Excluded from the client message |
Delete | Delivered. If an entry currently below moves into the view as a result, then it will be delivered as a synthetic | Excluded from the client message |
It follows that a given venue MarketData message may not result in any message being sent to the subscribed user(s) at all.
Each view will be distributed in turn, with the message for the view also being sent to each subscribed user in turn.
Remaining possible subscription details ( In the event of any validation errors, Whisperer will respond to the user with a |
A venue-side subscription will be terminated when the last subscribed user either unsubscribes or suffers a disconnection.
TakerESP instrument permissions are managed bilaterally between Venue and Client and may vary significantly through time.
In this context Whisperer is unable to provide an equivalent to the MFSecurityID provided for MUX MarketData, so in order to share subscriptions, users must be aligned on the following subscription qualities:
QuoteReqIDSymbol (currency pair), SecurityType (Spot/Fwd/NDF), LegSettlType/Date (Tenor)Side (probably 2-Way)QuoteRequest.NoUnderlyings)The first users' QuoteRequest subscription for a given instrument will set these parameters, and any subsequent users' subscription for the same instrument must match.
In the event of any validation errors for subsequent users, Whisperer will respond with a BusinessMessageReject.
Whisperer ensures that ExecutionReport messages for a given ClOrdID are always routed to the User that submitted the originating NewOrderMultileg.
Orders may be automatically cancelled in the event of session outages.
A session disconnect may occur in the following contexts:
UserNotification (UserStatus=LoggedOff) as per VenueLogoff details. The Venue will apply any Cancel-on-Disconnect rules applicable for their venue, and cancellations will be delivered along with any other In-flight ExecutionReports, as part of the synchronisation of the re-established session.OrderCancelRequest message for all in-scope active orders, as per the table below. NOTE: If the last Client User is disconnected unexpectedly, currently Whisperer will drop the socket connection to the Venue so as to trigger Venue Cancel-on-Disconnect.| TimeInForce | Description | Cancel On Disconnect |
|---|---|---|
| DAY | Short-lived Orders (single trading day) | YES |
| GTC | Long-lived Orders (multiple trading days) | NO |
| IOC | Immediate Orders | NO |
| FOK | Immediate Orders | NO |
| GTD | Short-lived Orders (typically single trading day) | YES |
| GFT | Short-lived Orders (typically single trading day) | YES |
| GFA | Auction-period Orders (Fixing) | NO |
| AMO | Auction-period Orders (Market Open) | NO |
| AMC | Auction-period Orders (Market Close) | NO |