Technically, user strategies are Java classes - written, compiled and deployed by the user.

Empirica has created proprietary API (Application Programming Interface) in Java for writing user strategies. The API handles all interactions with the system and third party trading infrastructure. Each strategy has to comply with API rules, providing proper initialization code and event handlers. By using the API, strategy can receive different market data and trade events, send new orders or cancel/modify it’s own orders. Details of the API and sample strategy code are explained further in this document.

The overall strategy development process is depicted below:

Strategy development process

Strategy development starts with programming in the Java IDE ( Integrated Development Environment). Empirica provides ready to use Eclipse IDE with pre-configured project.

Once written the strategy must be deployed in TradePad. Deployed strategies can be executed (tested) in TradePad.

Testing is possible in Simulated Exchange mode (using random data) or Back-Test mode (using historical market data and paper broker). System also gives possibility to optimize strategy parameters, it means to find parameter values for which the strategy gives the best result. Testing and optimization are explained in the “TradePad User Guide” documentation.

Architecture overview

Each user strategy (Strategy) is executed in the sand-box, called Execution Platform (Platform).

It is up to Platform to create Strategy instance and mange it till completion.

Strategy events

The life cycle of the Strategy starts with initialization state. During initialization user strategy must register event handlers (functions) for all event types it wants to handle.

After successful initialization Strategy is started and receives events from Platform.

Strategy life cycle


Strategies are event-driven. Strategy work flow does not rely on any continuous background process. Strategy’s logic is executed in response to events occurring outside strategy. Each event results in calling strategy’s function that is specific to the given event type. Events are queued and passed to a strategy sequentially, so only one strategy function is called at a time. This means that next event can only be processed after the function called by the previous event returns. In order for a strategy to be responsive, functions should be simple and must not perform any time consuming tasks.

Strategy events

All actions performed by the strategy are submitted to the Execution Platform. All results of such actions are received by the Execution Platform afterwards. Those results are then transformed into strategy’s events and delivered to the strategy, one at a time. Strategies can take various actions, thus resulting events can have various origins. Main types of events delivered to a strategy are described next.

Trade events

Trade events are a result of the interaction with the broker. Interaction consists of sending new orders and canceling or replacing existing ones. All strategies receive only those trade messages that are a result of their own activity. When starting a strategy, user determines which broker will be receiving its orders, containing specific market symbols.

Types of messages contained in trade events:

Execution Report Notifies about changes in order status.
OrderCancelReject Response to OrderCancel or OrderReplace that could not be accepted.
BusinessReject Response to sending valid order that could not be accepted due to business constraints.
SessionReject Response for order that contains invalid data.

Detailed description of message kinematics are available at individual stock exchange vendors. Trade events that contain trade messages of type SessionReject or BusinessReject may have negative impact on the overall system performance. It is advised to avoid situations that may generate such events. Some Execution Reports (types PendingNew, PendingReplace and PendingCancel) are originated by the Empirica system. They contain additional information regarding sent orders that may not be guaranteed in the messages originated by the broker.

Market data events

Market data events are a result of interactions with the feed. Strategy can subscribe for certain types of notifications, regarding specific market symbols. When starting a strategy, user determines feed to which send the subscription requests, containing specific market symbols.

Types of market data events:

TradeEvent Each time transaction on given symbol occurs new trade event is being published. It contains transaction specific data such as volume and price.
BestQuoteEvent Each time top of the book changes new best quote event is being published. It consists of two quote events - one bid and one ask.
OrderBookEvent Each time book changes on depth the client is interested in, new order book event is being published. It represents an order book snapshot for given market symbol and contains two separate lists for quote events - one for bids and one for asks. Single offer position in the proper list reflects its position in the book, starting from the top (e.g. first element is a top of the book).

Represents,a single buy or sell offer in the book of particular side and level. It is part of best quote event and order book event and contains following data:

  • side (bid/ask),
  • action - possible values:
    • ADD - new offer,
    • CHANGE - original offer was changed,
    • DELETE - offer was removed from book,
    • RETRANSMISSION - offer was retransmitted from previous session,
    • DELETE ALL FOR SIDE - all offers in book were deleted,
  • order type (e.g. market, limit, peg),
  • price,
  • volume.

Contains other data such as:

  • indicative matching price,
  • opening price,
  • closing price,
  • closing price from previous session (reference price),
  • lowest and highest prices reached for current session,
  • change - percentage difference between reference and last transaction price,
  • cumulative volume of all transactions of the session,
  • turnover - value of all transaction of the session,
  • open interest.

This event is published each time at least one of the above changes (e.g. with each transaction the cumulative volume and turnover change so whole event is resent).