Page History
...
Pricing
Subscription Management
A Venue pricing Session is established with the standard UserRequest (LogOnUser) / UserNotification (LoggedOn) message exchange.
On successful connection, if available, SecurityStatus messages will be delivered to the client, providing details of the supported instruments. These messages may also be sent intra-session, to notify the Client User of events such as tradeability changes, date roll events, etc.
Aside from this, CLOB Pricing sessions are managed via MarketDataRequest messages issued by the Client User to the Venue, with streaming MarketDataIncrementalRefresh messages being delivered until such time as the request is terminated.
The basic market data sequence is outlined below:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
ContractMultiplier- This is aka Lot SIze. whilst there are a few FX venues to allow the client to trade standardised contracts (e.g. LMAX), this is primarily present for trading Futures on venues such as the CME. For most venues, the contract multiplier returned will be 1.0.MinQty- This is the minimum allowed Order size for the Venue. given that the venue may be trading in terms of contracts, the client may safely assume that this quantity is expressed in ‘nominal’ units (e.g. contracts) and not in total units.
EndMarker Messages
For CLOB Priucing sessions, EndMarkers are sent to the Client in two contexts:
- SecurityStatus
- MarketDataIncrementalRefresh
SecurityStatus EndMarkers
An EndMarker message is sent by Whisperer to mark the end of the initial set of SecurityStatus messages sent after the venue session is established. It serves as an indication to the Client that the status of all available instruments has been published.
| Note | ||
|---|---|---|
| ||
The The |
MarketDataIncrementalRefresh EndMarkers
Venues typically publish market data in a conflated fashion (as opposed to a real-time stream of individual events), and it is important for Client systems to be able to recognise the end of each conflation interval. Where these notifications are available, they will be published in the form of EndMarker messages to the Client User, whenever any MarketDataRequest subscriptions have been established.
Under normal trading circumstances, EndMarkers may also be published for incremental refresh conflation intervals when nothing has changed. As such they have the appearance of a Venue heartbeat, but it must be remembered that they serve an entirely different purpose.
NOTE: For UDP/Multicast feeds, different EndMarkers may be published for each data channel, Incremental vs Trades Feeds for example. This is Indicated via MDBookType.
MarketData Messages
Snapshot vs Incremental Updates
...
| Info | ||
|---|---|---|
| ||
The MDEntryID is guaranteed to be unique through the MDUpdateAction lifecycle for the parent subscription only:
|
...
- Whisperer ensures that books will never exceed any specific requested depth - when implicit deletes are detected, the explicit Delete MDEntry is placed before the New that triggers it.
- Two MDEntries in a PriceDepth book may momentarily have the same price - this typically occurs when multiple MDEntries on one side of the book change their prices up or down, such that the first MDEntry moves to a price level occupied by a different MDEntry that has yet to have it's price modified.
UDP/Multicast MarketData Feeds
As well as the EndMarker behaviour outlined above, the client needs to be aware of the following unique attributes of UDP Market Data feeds:
- Line Arbitrage - the MDSubFeedType specifies the UDP market data source for venues which utilise A/B circuits.
- Gap Detection - in the event that a UDP message gap occurs, this is reported to the Client User immediately it is detected for each affected subscription, via the publication of a EmptyBook
MarketDatIncrementalRefreshmessage withMDFlags.IsSnapshotandMDFlags.GapDetectedboth set to TRUE. - Gap Recovery - the gap will be resolved by the Gateway utilising the venue's standard Late-joiner logic, and the next message will be a fresh Snapshot representing the full book.
Orders
The Orders workflow is always normalised and consistently implements the state transition model as outlined in the diagram below. Where Venue events are absent, synthetic equivalents are generated by Whisperer in their place. These messages are easily discernible by reference to the TradingFlags.IsSynthetic field.
...