The Lab

Expand all   Collapse all

Versions Compared

Old Version 3

changes.mady.by.user Unknown User (jkasakya)

Saved on

compared with

New Version Current

changes.mady.by.user Matthew Whitaker

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The following components comprise the current Whisperer Classic system:

Table of Contents

Whisperer is the name given to the collection of software as a multi-process application which may reside on a single server or on a network of servers that may be separated geographically. The Whisperer server provides connectivity to foreign exchange and futures trading venues.

"Connectivity" is defined as the ability to receive market data from and manage orders on a Trading Venue.


Customer

 A MarketFactory client who has a business relationship with a number of Venues and wishes to connect to them all in a unified manner using Whisperer. 

MFAPI Client

The MarketFactory-provided software which MarketFactory customers link into their local application in order to connect to the MarketFactory Whisperer APIServer.

The MarketFactory API (MFAPI) Client consists of little more than a message encoding and decoding layer that presents the contents of messages to callback functions.

MarketFactory has specifically limited the work performed within the MFAPI in order to minimize Client-side latency and maximize stability.

Handler

The Customer-written software which performs different actions on reception of messages of various types from the APIServer. This inherits from the MFHandler class.

Message

A MFAPI message is an application-level protocol data unit which is received by an MFClient object, and is passed to the appropriate function in a user-supplied class derived from MFHandler,  based on its type. 

Market

The MarketFactory name for a given instrument, for example EUR/USD for spot FX, or 6EH6 for CME Eurodollar futures expiring in March 2016. 

Whisperer

The generic name for the MarketFactory server software. A Whisperer installation consists of an APIServer (which faces the customer), and one or more FeedServer components (which face the exchanges), as well as auxiliary data-logging components which are used internally and do not interact directly with the outside world.

The API Server 

The API Server

In order to promote a smooth, uneventful client onboarding process, it is essential that we provide new clients with the necessary material to ensure that the process is self-driven, as much as possible, with a minimal amount of needless Q&A.

The following documents/artefacts are intended to act as a draft/proposed replacement for the material currently found in the Lab:

Whisperer

The Whisperer platform is composed of a series of individual processes that combine together to form a unified platform, composed of the below constituent parts:

The API Server 

The MarketFactory API (MFAPI) Server is the heart of the Whisperer platform and acts as the interface to which the customer infrastructure connects. The API Server It creates the customer sessions to the Whisperer platform and permits the customer infrastructure (and the associated users) to gain access to the Trading Venue Feeds/ connections configured for the instance. As the only interface for the customer infrastructure (using the classic implementation), the API server API Server is also the site of the session handling elements processes associated with customer connections to Whisperer prior to feed/venue connection subscription.

DB Logger

The DBLogger DB Logger applies the user authentication requirements for Whisperer, through use of a Lightweight Directory Access Protocol (LDAP)database. Ensuring that only users established within the designated customer infrastructure, listed individuals, known devices etc.. are the only users granted access to the platform and associated connections. failure to authenticate with the DBLogger the DB Logger will result in the customer infrastructure or user(s) being rejected. These user entries can be made directly to the LDAP database or explicitly to a static configuration.

DC Server

The Drop Copy Server (or DC Server) generates a stream of MFAPI TradeCapture Messages. MarketFactory can then allow an MFAPI Client thenallowanMFAPIClient to subscribe to these messages, similar to a traditional FIX drop copy using the MarketFactory protocol instead. This is an additional feature that can be enabled for customers, the benefits of which are described in more details below (under additional services).

FeedServers

Feed Handlers

Every Trading Venue that MarketFactory's Whisperer is able to integrate with has a FeedServer (a term used synonymously with Feed Handler) which makes the integration possible. The Feed Servers connect directly with the API server under via the Classic MFAPI classic model of operation.

Customer infrastructure can connect directly to the Feed Server (for market data only) using the MarketFactory's new SBE implementation. The benefit of direct connection with the Feed Server being that messages do not have to pass through the single bottleneck of SBE3 implementation, avoiding the risk of bottlenecks in the API server (which traditionally has been the only interface available to the customer infrastructure). The more direct This approach is not only aimed at reducing latency at times of high message frequency but also improves high availability by reducing dependency on access to the API server in order to obtain market data from Trading venuesVenues.

The Feed Servers also exist as a source of normalisation, by integrating venue messages, tags and fields to align with the MarketFactory message protocol resulting in a Feedserver that aims to be as closely compatible to the venue as possible, whilst maintaining a normalised library of messages to smooth out the differences between differing trading venues and their protocols.

 

Additional Services

The Whisperer platform is also supplemented with additional features provided by MarketFactory, that enhance the benefits available to customers outside of connectivity alone. These optional modules are explained below:

Drop Copy 

Traditionally exchanges and other trading venues are “producers” of Drop Copies. With executing / clearing brokers and trading firms being “consumers” of Drop Copies. MarketFactory has made some changes to this traditional model by synthesising drop copy messages using the information obtained from the API server (in a standard format) following the execution of a trade. The purpose of this message is to act as a supplement to a customers risk management model by producing a comparable series of messages that can be compared to the venue drop copy feed to identify and deal quickly with any inconsistencies.

"Drop copy" can be viewed as an element or contributor to risk management that equips market participants with near real-time copies of trade reports and messages related to orders. Drop Copy as a report then summarises a participant’s execution activity on a trading venue, to provide an accurate picture of the firm's position in the market.

Drop Copy as a Risk Management Tool

Robust risk management policies and procedures are critically important aspects of any market participant’s trading operation. To aid in the implementation of and adherence to those policies and procedures, many trading venues have provided their participants with Drop Copy feeds. Consumers of Drop Copies have different methods of leveraging Drop Copy functionality to meet their individual risk management needs. The following examples illustrate possible uses of Drop Copies by Consumers:

  • Consumers may use Drop Copies for real-time trade reconciliation. At a minimum, they typically compare the information provided by a Drop Copy in real-time with the trade notifications received from production trading sessions. This comparison process allows firms to reconcile their electronic trading activity with an independent source of exchange-provided trade notifications. In the event a discrepancy is found, the responsible party or parties may take action immediately to address trading risk, determine the cause of the discrepancy, and resolve any issues.
  • Consumers may also use Drop Copies to supplement their risk management process. Trading firms, for example, may have multiple trading sessions on a single trading venue. Drop Copies provide market participants with the ability to consolidate multiple trading session reports into a single data feed. This consolidated data feed may then be used by operational staff to monitor a participant’s trading activity.

    • . Refer to Additional Services for further detail.


    Venue

    An organisation which provides trading facilities, such as a bank or ECN. A Venue may provide the same services via multiple Feeds (for example via different protocols).

    Feed

    The term for a connection to a Venue, which (normally) consists of two login sessions to the venue, one for market data, and one for order entry.

    A MarketFactory Customer may have more than one Feed to a given Venue, depending on the relationship the Customer has with the Venue.

    Feeds are referred to by numeric and string identifiers. These identifiers are globally consistent across all Whisperer installations. 


    Additional Material

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

    Children Display

    Brokers that provide their clients with sponsored access to trading venues may use Drop Copies to monitor the trading activity of those clients. Brokers use Drop Copy to monitor: 
    1. When trading activity approaches limits established by the sponsoring broker.
    2. Unusual changes in intraday trading activity that may indicate a potential problem at the client.
    3. Activity that may increase positions in accounts that are in a “liquidation only” state. 

     

    All events would lead to a discussion with the client to understand the situation and take appropriate action.

     

    For more information on the MarketFactory provided Drop Copy please click here

    PrimeBroker TradeReporting

    A prime brokerage account allows customers to utilise broker dealers or execute their orders themselves while designating a central or main firm to maintain custody of their assets. The firm that carries and receives the customer’s cash and securities is known as the “prime broker”. Prime brokerage accounts are usually established by institutional investors and larger retail investors. Acting as agents of security and trust for the market (trading venues and market participants) by ensuring participants have the capital to make good on their trades.

    The PrimeBrokerTradeReport developed by MarketFactory uses the MFAPI to collect data from DropCopy events received from the APIServer. The data is then arranged in the format required by a Prime Brokers such as JPMorgan, and periodically (every 30 seconds) the service sends any pending records to the PrimeBroker using SFTP, for processing by the Prime Brokers back office systems. 

    The PrimeBrokerTradeReport achieves this by connecting to Whisperer as a regular "DropCopy" user, this MFAPI user is established in the standard procedure within the Whisperer configuration, with access to the appropriate Feeds which are of interest to the Prime Broker concerned.  The Whisperer dropcopy (on which the PrimeBroker TradingReport draws a large part of it's information) will not be discussed further here.

    Hosted Servers

    Hosting of clients algo servers inside MarketFactorys cage. This is the lowest latency and the highest throughput option. Each hosted server will have a 10Gbit connection to MarketFactory Whisperer server with sub-microsecond latency. 1Gbit connection is also supported.

     

    Market Data Collection

    Due to MarketFactory's unique position within the market and with connectivity to 70+ trading venues, MarketFactory has a unique portfolio of historic Market Data from the FX market going back for years. 

    The FX market, contrary to most other asset classes is an almost entirely fragmented over-the-counter market, aside the very small number of FX futures that are trading at relatively low liquidity levels. Customers will very rarely encounter a single serious liquidity provider that will take a stab at estimating total traded volume in any of the currency pairs. Having said that, there are some brokers that may show traded volume that crosses their own books, only.

    To further confound the picture it is not appropriate to compare FX markets with any listed cash equity, futures, or options market. Why this is the case?

    In some pools the actual liquidity still comes from various firms. If considered closely a 200 million block in the end passed from one participant to the other, while each participant in the chain retains a small chunk until it is split up sufficiently for the remaining participant to hold. So the same 200 million or part of it may pass the same brokers and order books several times before it is swallowed up by those the risk eventually ended up with.

    What MarketFactory will in time be able to do is leverage it's unique market access and substantial Market Data portfolio to provide a vivid view of the historic movements of the FX market across venues at a resolution not previously seen before through use of a broker or trading venue. This product is presently only a concept but will remain in the sights of the MarketFactory's Product and R&D teams for future Development.

    Configuring Whisperer

     

    Whisperer Users

    Description

    Historically usernames such as "ProdUser1" have sometimes been used in Whisperer configurations.  These are limiting for several reasons, not least of which is the fact that they are not globally unique across different Whisperer instances.

    Usernames should follow the format mnemonic-environment-purpose-instance, where mnemonic is the three/four-letter identifier for the customer, the environment is one of duat, or prod, the purpose is one of trading, dropcopy, admin, api, and the instance is a three-digit identifier.  While this format is not the shortest, it aims to strike a balance between brevity and clarity.

    User types

    Whisperer system users have different roles, so a component of the username should indicate this.  Here are some examples:

     

    example username

    purpose name

    description

    bwp-prod-trading-001
    trading

    regular trading users, used for market data and order entry

    bwp-prod-data-001
    data

    used for market data only, does not have trading rights

    bwp-prod-dropcopy-001
    dropcopy

    dropcopy subscriptions, does not have trading rights

    bwp-prod-admin-001
    admin

    administrative users, for NOP setting

    bwp-prod-mm-001
    mm

    market-making trading

    bwp-prod-api-001
    api

    regular usage via the API

     

    Feeds Filters

    MarketFactory allows Customers to request the creation of Whisperer API users as described under the 'Whisperer Users' heading. Further, these users can be restricted or enabled in their abilities to access different connections for the trading venues through the use of feeds filters. In terms of definitions, the term trading venue connection is synonymous to Feed. The Feed filter exists as a statically defined enumeration within the Whisperer configuration and can allow for the following configuration examples:

    • Users can be grouped together within a filter and provided with access to a collection of shared connections.
    • A filter can be created to permit a user access to only feeds/connections with Banks, ECN's or a combination of these liquidity providers or any other distinguishing feature a customer wishes to divide or group feeds/connections with.
    • Feeds filters can also enable the monitoring of prescribed users, a feature that is explored further in the user heading within this section.