Thursday, February 6, 2014

Other Trading System Functionality

At server start up, core services will be started:
  • Servlet Container (Tomcat)
  • Confirm JMS provider is active (ActiveMQ)
  • User Service
  • Account Service
  • Strategy Service (scan database for strategies to load)
  • Securities Service
  • Position Service
  • Order Service
  • Transaction Service
  • Metrics Service
  • Risk Service
  • Communications Service
  • Authentication Service (authentication and authorization)
  • Audit Service
    • Run every XX minutes.  Compare order quantity with transaction quantity and alert if different.
    • Will need to be run on start up to determine if there are issues.
    • At regular intervals, account quantity should be reconciled with transaction quantities.


Starting of strategies will follow this general flow:
  1. Scan the strategy_run table for strategies with their load set to true.
  2. Does a position exist in the position table?  
    1. Iterate through the the position table corresponding to this run id, and sum the quantities for each security/option in the position_details table.  Do all quantities = 0 -->
      1. yes - then will activate in the create-new-trade state
      2. no - then will activate in the managing-trade state.  Is trade complete -->
        1. yes - manage complete trade
        2. no - determine what components need to be built and continue building trade - send alert - trade incomplete


The StrategyService sends orders to the OrderService, and the OrderService receives fills and order status from broker.  These orders are associated with a strategy_run_id and a position_id, which can be resolved to an account, userid, and strategy.

When a fill occurs, an entry is created in the transaction table by the TransactionService.  A fill alert is sent via JMS to the StrategyService.  The StrategyService will call the PositionService to update the position_details table.  The StrategyService will also update it's positions map from the db by requesting an updated list of positions from the PositionService.  In backtest mode, an order is converted to a transaction automatically.

Order status alerts are sent by the OrderService to the StrategyService.  A strategy may act on an order status update by cancelling or replacing orders.

The trade_summary table is update at trade closure.  The trade_details_by_day table is updated daily.  These updates are handled by the MetricsService.


Many of the tables will have CRUD functionality provided by a browser based UI:
  • users
  • user_details
  • user_email
  • user_phone
  • user_address
  • account
  • strategy
  • strategy_settings
  • strategy_run
  • account_strategy_run


Additionally, the browser based UI will provide the following functionality:
  • Account Overview
    •     Can view orders associated with the account
    •     Can view fills associated with the account
    •     Can view transactions associated with the account
    •     Can view all securities in the account
    •     Can view the current cash balance in the account
  • System Overview
    •     Positions and/or transactions by strategy type or name
    •     Positions and/or transactions by security
    •     Positions and or transactions by account, then strategy, etc


Next steps:


Future blog post will be on the topics above as well as Tomcat, ActiveMQ, MySQLMaven, and Eclipse.  I may include some trading posts as well.

No comments:

Post a Comment