Page History
...
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.
| Venue Type | SessionType | Venue is CLOB | Maker | Client is Taker | PricingClient is Maker | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Pricing | A single User must be defined and used for all MarketData subscriptions. This ensures consistent latency and throughput characteristics. | A single User must be defined and used for all ESP subscriptions. This ensures consistent latency and throughput characteristics. | The Client may organise subscriptions across Users as it deems fit.
The Client may organise 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 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 is 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. | ||||||||||
...