Page History
...
If you are a prospective customer, please contact [email protected] for more information.
Normalization
MarketFactory (MF) defines API Normalisation as a direct transformation between Venue and MF API representations, with no modification of Customer/Venue intent.
Any feature that results in the creation, modification or deletion of Customer or Venue-provided data (eg messages sent/received, message content - prices, qtys, value dates etc) is Business Logic.
The default Whisperer behaviour should be to act as a normalised API only.
Please note that Customer enhancement requests will be rejected if they should require business logic within Whisperer. This is because of the implicit log-term costs that would otherwise exist:
- MF Customers and Venues cannot reliably review issues without MF involvement.
- MF Customers cannot be in full control of their pricing/trading strategies.
- MF needs to involve every otheraffected existing Customer in every business logic change to ensure that there are no adverse/unintended consequences.
To this end, MF is working towards a medium-long term goal where all Whisperer business logic will:
- Be deployed in self-contained MF components, separated from the core Whisperer product
- Require an explicit, active, safe opt-in from the client, rather than the current opt-out - requiring prior knowledge, discussion etc.
API Normalisation
Current
- Unified approach to different book structures
- Provide MF metafields for client configuration and flow mgt - User, Model iD
- Standardise client quote/order IDs across all venues
3.15
- Maker/Taker-perspective agnostic
- Standardised Quote/Order/Deal representations
- Unify Order matching, ESP and RFS flows
- Standardised Regulatory Reqts support - DoddFrank/SEF, EMIR, MiFID II
Business Logic
- API Server - Order handling (Cum/LeavesQty tallying done internally (TBC I don't regard this as business logic by above definition), OrderCancelRejects handled internally, not passed to venues, also limits monitoring etc)
- Price Improvement - Trade on in-flight quotes not yet received by taker, superficially nice idea, but can of worms. See Analysis for PRODMGT-42 [Improve the handling and management of quote ID's in MD/Order submission].
Exceptions
There are obviously many aspects of the trading work flow that cannot be normalised. These are typically venue-specific behaviours or features, such as:
- Timing of date rolls.
- Time-slicing of book market data.
Benefits
Whisperer has a number of aims, the primary aim is normalisation, accomplished by reducing the barriers to integration, arising from the differences between messaging transports and their application across markets. Whisperer achieves this by the adoption of consistency, with concepts and terminology used across Trading Venues being normalised and given consistent and specific definitions. These definitions are used as uniformly as possible throughout the API. This shields customer applications from having to maintain code specific to a Trading Venue.
...