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