MathGroup Archive 2010

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

Search the Archive

Re: trading

  • To: mathgroup at smc.vnet.net
  • Subject: [mg111427] Re: trading
  • From: "Jimmy S. Lim" <onward.pm at gmail.com>
  • Date: Sun, 1 Aug 2010 04:55:53 -0400 (EDT)

Hello Andreas thanks so much for your insights. and i totally agree with you
and hope Wolfram is listening regarding your suggestions. It is exactly what
i'm looking for. although i'm a relative newbie to this, i'd like to be able
to link to the Singapore exchange, that's why a universal market data link
is what i'm looking for.

Chris, thanks too for the links.
Jim

On Mon, Jul 26, 2010 at 1:39 PM, Andreas <aagas at ix.netcom.com> wrote:

> Jimmy,
>
> 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
> infrastructures.
>
> 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.
>
> Best,
> A
>
>
>
>
>
>


-- 
cheers!
Jim


  • Prev by Date: Re: AxesLabel parallel to 3D axes?
  • Next by Date: Re: Mathematica- Use a previous equation into the function Function
  • Previous by thread: Re: Problem with Min Max between two functions
  • Next by thread: Surprising FullSimplify result