Stock Trading Application
Black box trading algorithms are interesting environments. They process massive amounts of data (sometimes tens of thousands, or even millions, of messages per second) and must provide millisecond response times in order to beat competing algorithms to the market. However, they must also interact at a much slower pace with humans, providing them with information, accepting their commands, and providing compliance controls for safety.
There are three common types of algorithms. White boxes monitor the market for opportunities and notify traders, but do no other work. Black boxes are fully automated and require little external control. Grey boxes mix the two, providing notifications to traders, but also responding to traders' commands to execute trading strategies, rather than making decisions entirely on their own.
The larger a company's trading operations, the more sophisticated its interaction cycle between algorithms, traders, and the compliance department needs to be. It takes a great deal of work for algorithms to decide where to route notifications or parse command messages and check for errors. Many companies also require compliance monitoring to be a separate application, making it harder to tamper with or bypass, and also preventing compliance monitoring from slowing down the primary application.
An ESB is an ideal method of solving this problem. Consider the diagram below:
In this application:
- Trading algorithms look for opportunities in the market. When they find them, they post messages to topics in an ActiveMQ server and go back to process market data. They don't need to wait for recipients to process them, or worry about resending dropped messages, buffering, etc. - the MQ server will handle those tasks. Messages are sent in a compact, comma-delimited format to save processing time, to an appropriate topic, such as /topic/Trading/Alerts/Nasdaq/CSCO.
Algorithms also subscribe to a similar command channel, such as /topic/Trading/Commands/Nasdasq/CSCO. They expect to receive command requests to tell them to Execute an opportunity found, and a share count to trade.
- Two modules are developed that run in Blackbird:
- Module A (on the left, above) has configuration rules that tell it how to route messages. It:
- Subscribes to /topic/Trading/Alerts/*. ActiveMQ supports wildcards, so it will receive any alert for any market/stock.
- Connects to a Jabber server and authenticates itself/marks itself online.
- Implements a message handler callback. In the callback, it converts the comma-delimited message bodies from the algorithms into XML/text Jabber messages, and routes them to Jabber recipients (could be individuals or groups) per its routing rules.
- Listens to incoming messages from Jabber senders, and verifies that they are formatted properly. If so, it converts the commands to the appropriate format for the trading algorithms and transmits them to /topic/Trading/Commands/Nasdaq/CSCO.
- Module B (on the right, above) subscribes to /topic/Trading/*, so it will receive both alerts and commands. It stores them in a database to provide an audit trail for later review.
- Module A (on the left, above) has configuration rules that tell it how to route messages. It:
- A basic Web application provides an interface for the audit department to review the alert/command entries in the database.
The real power of an ESB is in the speed with which the above may be developed (each module is just a few lines of code), and the number of ways this simple example may be easily extended, such as:
- A third module may be developed that exposes a SOAP API to send commands. Command interfaces other than Jabber may be easily created, such as simplified interfaces for handhelds. Writing SOAP interfaces in PHP takes just a few lines of code.
- The compliance department's application can use the SOAP API to issue halt/resume commands during review periods after alerts are triggered.
- A text-to-speech application could be developed that converts an alert into an audio summary, then transmits it over a streaming connection, so traders don't have alerts popping up constantly.
- Non-algorithm monitors (such as those that watch news feeds or analyst/earnings reports) can provide their own alerts by simply posting correctly-formatted messages to the correct /topic/Trading/Alerts// topic. This infrastructure could then become a standardized clearing-house that ties dozens or even hundreds of data sources together and feeds them to the appropriate recipients. PHP is particularly well suited to monitoring Web/RSS news feeds for this data.
The actual integration work required to perform the above tasks is minimal, allowing developers to focus on the important code, such as parsing a news feed.