The Lab

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 1.5.80

...

For those clients that don't, Whisperer now offers Price Subscription Multiplexing ("Price MUX") for MarketData and TakerESP subscriptions.For both scenarios, where subscriptions are shared by the use of a common common MDReqID, or QuoteReqID for a given instrument. The first users' MarketDataRequest or QuoteRequest 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.

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.

...

Venue Session Establishment

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 standard UserRequest(LogOnUser) message, SecurityStatus messages will typically 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

MUX users must use this ID as the MDReqID in any subsequent MarketDataRequest messages.

Subscription Management

Subscription

MarketData sessions rely on MUX users using a common MDReqID to subscribe to shared subscriptions. Two ID-to-instrument mapping models are supported:

  • Client-managed: Clients define and use whatever ID/instrument mapping they prefer. The first subscription defines the instrument details that subsequent requests must match.
  • Whisperer-default: MUX users must use the provided MFSecurityID for their target instrument. In addition, all other instrument details in

...

  • the MarketDataRequest must match those published in the SecurityStatus message

...

  • .

Unsubscription

A venue-side subscription will be terminated when the last subscribed user either unsubscribes or suffers a disconnection.

Book

...

Management

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:

...

Info
titleOther Subscription Parameters

Remaining possible subscription details (MDBookType and NoUnderlyings) must be pre-agreed between users. The first users' 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, Whisperer will respond to the user with a BusinessMessageReject.

Unsubscription

...

.

TakerESP

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 a client-managed ID-to-instrument model must be adopted, with all users aligned on the following subscription qualities:

  • QuoteReqID
  • Instrument - Symbol (currency pair), SecurityType (Spot/Fwd/NDF), LegSettlType/Date (Tenor)
  • Side (probably 2-Way)
  • Sweepable vs FullAmount liquidity style
  • Rung count and size (usually implicit, sometimes explicit via 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.

...

Trading

Whisperer ensures that ExecutionReport messages for a given ClOrdID are always routed to the User that submitted the originating NewOrderMultileg.

...