MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: trading

  • To: mathgroup at
  • Subject: [mg111293] Re: trading
  • From: Andreas <aagas at>
  • Date: Mon, 26 Jul 2010 06:39:25 -0400 (EDT)
  • References: <i2eafg$q3s$>


It depends.  Our hedge fund uses Mathematica as our core analytics
engine in a fully automated trading environment, so yes one can lots
with it, but it also depends upon what you want to do.

>From our point of view one needs 3 basic things to trade:

1. market data
2. analytics
3. trade execution

Let's look at each of them briefly.

Market data, while Mathematica has the ability to scrape data from
free online sources, one has to evaluate their own analytics, time
sensitivity, and strategy to determine whether they can productively
use this kind of data.  It typically has significant drawbacks
including errors and delays.  These services typically get data
directly from exchanges or third party suppliers that don't have the
redundancy and error correction infrastructure of the 3 high end data
suppliers.  The same drawbacks come with data from online brokerages
(i.e. Interactive Brokers has some of the most robust technology, but
they don't have Bloomberg's or Reuter's error correction).  So, if you
need intraday day data you may need to pay for it and it means dealing
with one of the vendors' API's and probably MathLink or J/Link to
access the data and get it into Mathematica.  I'll leave aside a
discussion of whether you need a database or whether you employ some
RAM based persistence scheme (perhaps the fastest solution).

In our case we trade intraday, but we don't employ high-frequency
trading approaches.  This led us to the decision to use Reuters.  They
have a rather antiquated, but robust data feed.  I also recommend that
you evaluate the technical and operational redundancy of any data
supplier, all have frightening single points of failure in their

It only makes sense to use Bloomberg if you already pay for and use
their terminal service, very pricey otherwise.  You also need to make
decisions about continuous and/or consolidated data feeds, they both
have their strengths and weaknesses, you just need to balance them
relative to your approach.  We have a relatively simple Java process
which captures data from a Reuters API, all of the rest of our code
resides in Mathematica.

Analytics -- Here Mathematica soars above anything else I've seen.  We
use it for R&D, and rely heavily on its parallel processing
capabilities in our production trading environment.  Fast, elegant,
smart.  Nothing else comes close.

Trade execution -- Once you generate trading orders you need to get
them to an execution platform.  This typically involves another API.
This could look as simple as manual entry into an online trading
system if your approach can live with it.  Probably better to connect
through an online broker's API.  Interactive Brokers again has a
useful API for this.  Goldman does too with its Redi system, and if
you don't meet Goldman's assets under management requirements some
mini-prime brokers like Wall Street Access can provide access to
Goldman's platform through one of their programs.  e-Trade?  Maybe.
I'd approach all retail platforms suspiciously.

The best solution involves connecting directly with one or more
brokers/exchanges via the financial information exchange (FIX)
protocol.  You certify and run your own FIX server, generate your
orders in the FIX format directly out of Mathematica, basically
creating your own Mathematica to Fix API.  Setting up and maintaining
a FIX box takes some infrastructure knowledge.  One needs to establish
2 or more VPN tunnels to the broker's/exchange's corresponding box,
typically one for outgoing and one for incoming messages.  Nothing
particularly hard about this, it just takes time.

Clearly Wolfram has an interest in supplying tools to this market and
I believe that wide spread adoption of Mathematica in the industry
could help address some systemic risk due to frail platforms for
models (way to much of the industry still runs on Excel spreadsheets).

To my mind, rather than pack the application with more stock charting
options and financial engineering tools for pricing derivatives and
such (almost all of which proceed from terribly flawed assumptions) it
would serve them and the industry better to construct:

1.  marketData/Link - A universal professional market data connector -
something like DB/Link, but for market data streams rather than
database connectivity.  They could easily adapt it to the 3 major
suppliers, and directly to exchanges.  The interface could have
subscription credentials, where required for paid services.

2. FIX/Link API.

These two pieces would then allow users of Mathematica to focus on
their analytics and trading strategies.

 (Mike H. hope you're listening ;-)

Just my 2 cents.


  • Prev by Date: Re: Need to align data from sublists to Union of dates
  • Next by Date: Re: Kolmogorov-Smirnov 2-sample test
  • Previous by thread: Re: trading
  • Next by thread: mathematica gives strange result