By Thomas Rodgers Matlock Capital, LLC

 Privately held trading firm specializing in Stock and Stock Options market making  Focus on sophisticated analytics and highly automated trading  Member of the Chicago Board of Trade, Chicago Board Options Exchange, New York Stock Exchange, International Securities Exchange

 Usually targeted at trading logic specification  Vendor proprietary grammars  Leverage tools like Matlab and Mathematica  Other examples include  Specifying “over the counter” (non-exchange traded) options contracts  Risk scenario specification  Report generation

 Too specific  Little opportunity for customization  Useful only for the most simplistic of trading strategies  Poorly designed grammars  Lack of debugging and testing tools  Poor performance  Particularly with DSLs based on mathematics packages  High cost  You’ll pay (a lot) to not have a debugger

 Issue ~500,000 orders per day ▪ We expect to increase this to ~2M orders per day over the next year  Issue ~4M option quotes per day ▪ We expect to increase this to ~10M quotes per day over the next year  Majority of trading decisions are expected to complete within 5-10ms of a price tick  System should require no more than one or two traders to monitor

 Sophisticated analysis and filtering of price feeds  Minimize risk of catastrophic loss in adverse market conditions  Real time risk exposure monitoring is used to modify quotes to make trades more or less likely to happen  Automated hedge trading ensures our position stays within acceptable risk limits  Trade sentinels monitor order flow and preempt routing to exchanges  We do not want trading machines trading with themselves  Ensure no more than some number of a given type of trade are working simultaneously  Poor price quality from an exchange means we shouldn’t be sending orders to it  Ensure that order flow rate does not exceed a configured threshold

 Distributed asynchronous message driven architecture  Timing sensitive  Exhibits non-linear behavior  Trading strategy growth  Tends to be fairly organic  Attempts to codify trader intuition in many cases  Reaction to short lived market conditions  Often easier to specify what the system clearly should not do  Not get run over in a fast market  Violate exchange or SEC rules  Fail to manage market exposure due to market volume

 Smaller surface area to cover than a trading logic DSL  Match on system events  Generate Prices, Quotes, Orders, Market Execution Reports, Volatilities and Interest Rates  Basic assertions and comparison operators  We would like to make test scenarios business readable  Minimize friction by hijacking the language of open out-cry trading  Apply Behavior Driven Design to trading strategy development

 Individual tick data feed testFeed 10 { MSFT Jul put MSFT AAPL 500:83.50 }  Generated tick data feed testFeed2 10 { MSFT Jul call { step 500 from [5,50] to to } }

 Most trading systems are message driven  Typically use JMS, TibcoRV, or FIX internally  FIX protocol is the financial industry standard for message interchange between institutions  Engine executing test scenarios should  Interface with the system under test using these messaging protocols  Handle asynchronous nature of a MDA  Match and respond to particular events using expressions that are easily understood by traders/financial analysts

 Trading system  Listens to a simulated price feed  Executes a buy/write transaction  Verification  The call must be covered, stock options are contracts for 100 shares of stock, so option contract size should be number of stocks/100  Recovering from an error  Fail the stock order and fill the option  Expect the system to trade out of the option position within a specified time frame

 CBOE Learning Center  Financial Information eXchange (“FIX”) Protocol –  Matlock Capital –  QuickFIX Engine

Thomas Rodgers