Introduction

MarketFactory provides low-latency API connectivity in LD4/NY4/TY3/DC3 to 80+ ECN/Bank/Non Bank venues, allowing Customers to access Normalised and/or Aggregated data from these venues, place orders, and make markets.

Client-side integration may be via the Whisperer API available in C++  (as static libraries for Linux), C# (.NET assemblies) and (Java JAR files). Alternatively Customers may integrate directly via our SBE interface.

In each case, the language-specific documentation available on this site is authoritative for that implementation. 

The Whisperer API distribution contains automatically-generated API reference documentation for both Java (JavaDoc) and C++ (Doxygen), in the top-level java/doc/ and cpp/doc/ directories.

Summary

• Our product normalises market data and orders between your internal platform and venues in a 3-20 microsecond range. 
• We provide smart order routing (SOR), aggregation, order management system (OMS), trading interfaces, data analytics, internal order books for 'resting off market', price improvement and much more.
• We can seamlessly turn on/off access to any of our connected venues.
• New venues and connections are added by request by emailing [email protected].
• Every client gets a dedicated deployment.
• We store all market data and maintain the infrastructure.

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, although for historic reasons Whisperer currently does provide additional features.

Future requests for enhancements that require business logic within Whisperer will, most likely, be rejected - 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 other affected 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.

Whisperer Classic API Normalisation

• 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

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.

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.

Whisperer as a byproduct of meeting the first two aims, also results in the reduction of physical feeds that the customer has to connect to from within the data centre (with the only connection going from the customer infrastructure to the MarketFactory instance (possibly with an additional secondary connection for redundancy).

A Customer Application also exercises full control as to when it reads from the communication socket(s) and dispatches events. The Customer and their Application has complete control to decide as to where and when processing occurs

The Whisperer application software may reside on a single server or a network of servers which can be separated geographically. The servers are installed, hosted, maintained, and monitored by MarketFactory who take responsibility for their maintenance.

Using this model results in a reduction in costs for a firm, that would otherwise have to engage a team to implement integration to each of the venues they connect to with the varying protocols and venue specific enumerations. 

• Full pre/post trade lifecycle
• Isolate user from venue API changes
• Identify per-PB risk

Additional Material

Further detail is provided in the following page(s):