Anyone know what programming language(s) is algorithmic trading software mostly written in? Also known as automated trading, algo trading, black-box trading or robo trading.
If I wanted to write the above software where would I start? Any tips/trick/advice greatly appreciated.
Thank you in advance ;-)
Most of what I know is written in C++, less in Java, and some bits in C# and .NET ASP
Depends, these days a 4th gen language like Java or C# for normal e-commerce (other such languages will also function -- e.g., Erlang or Python); however, there is a real-time aspect to the --hard-core -- trading side.... such systems use expensive -- non-standard -- hardware to eliminate latency and naturally software is written in C++ or C. every ms counts when you want to out-do others competing with you.
JaneStreet uses OCaml. Here's a tech talk about why they chose a functional programming language to implement their trading software:
To be very honest: C, C++, OCaml, Perl, and FORTRAN. Those languages tend to dominate numeric things such as financials. I'm not saying they're better languages or that newer stuff hasn't come along but many companies are loath to pay for "upgrades."
I've come across autotrading software written in languages as diverse as VB6 and Java (hmm, maybe not that diverse). The stuff that actually talks to the exchanges to do the trades always seems to be written in C++ though.
I'm working on the same thing right now (FOREX), and I'm using Python.
C++ is needed only for really fast strategies (mili/microsecond level) or for huge amount of data (think arbitraging the S&P 500 index versus it's 500 component stocks, BTW, another microsecond level job)
You can use pretty much what you fancy if you won't trade less than a minute apart. It also depends on the API of the broker you use. Some offer FIX (socket programming), others Windows COM APIs, other Java APIs.
To answer your question, most use C++. Here's a job offer of the kind
It depends on what API your brokerage provides. The one I use for this sort of thing is Interactive Brokers, which provides APIs in DDE for Excel, Java, C++, and ActiveX. When I first started developing my ATS, there were some eccentricities to their C++ API, so I'm using the Java interface. It looks like the C++ API has improved since, but I've already got a large body of working code. The APIs may provide different features for individuals versus institutions. FIX interfaces are an industry standard, but it may be difficult to get direct access as an individual. Depending on which broker you select, YMMV.
You are not defining your terms well.
Automated trading (or black-box trading) can be written in anything, provided your trade horizon is long enough and your latency requirements are not stringent. That's where the stuff from the late-night commercials comes in and you get Windows applications with their own scripting languages etc. Some people do this in spreadsheets on daily closing prices or coarse-enough 'bars' of data, and daily trade frequency. However, at higher frequencies and/or model sophistication, the door opens for Python, Matlab, R, ... as well as compiled languages.
High-frequency trading is a different matter as trade horizons are much shorter and latency requirements can be critical. In this domain, the language of choice is C++ (as you can confirm by perusing job ads) with the odd sprinkling of Java or C#, as well as outliers as OCaml used by Jane Street.
Some systems, e.g. StreamBase, let you define your trading algorithms in a proprietary language (which may be a visual language or something declarative instead of a common programming language).
Engines of this type can be created using anything from Java (to run on any server) to machine language (to run on specialized hardware).
I work in a the field, so here is my knowledge about US companies:
Quite a few algorithmic hedge funds are C++ and Linux centric. Examples include Tower Research Capital, Hudson River, Knight, etc. They typically have their infrastructure done in-house, and benefit from C++ speed. C++ is generally more common in investment banks as well. Bloomberg is also C++ based though they don't do their own trading.
However, some serious players are actually in the Java world: D.E. Shaw is the most notable and probably largest. Two Sigma investments are also major players in Java, and then there are a lot of small players.
I'm less familiar with the Chicago and Austin markets (other algo powerhouses) but it still seems to be primarily C++ and Java.
I know that there is at least one firm in NYC that does only OCAML (Jane Street?), and they hire lots of Ph.Ds. who tend to come from a PL/functional background. I have heard stories of .NET shops but they're less common, likely because of licensing costs - Linux is more common in this domain because you can ramp up a lot of firepower quickly.
Finally, quite a few smaller houses buy access to APIs to do algorithms. The company I work for, for instance, provides a trading platform and a Java based API that one can use to implement specific algorithms. A lot of the complexities of programming are hidden so the quants can focus on the algo side.
I would seriously advise against writing your own trading platform. The market is saturated, and you usually have to hand optimize for years to get good performance. If you have an idea for a clever algorithm, you may be better off licensing a trading platform or joining an actual fund.
Just adding my two cents: the company I work at uses primarily .NET (C# and--believe it or not--VB.NET). As others have pointed out, you're probably not going to find a lot of managed languages like Java or anything in .NET for high-frequency trading (e.g., tens or hundreds of trades per second), but for algorithmic trading in general, a managed language can be a smart choice for the faster development speed. We are adding and changing functionality on a constant basis and would not be able to do so nearly as rapidly working in a language like C or C++.
The biggest issue with a managed language in this context is not garbage collection per se, but specifically garbage collection that occurs at a time-critical moment such as when a high volume of trades are being executed. Since the CLR handles this by itself, the developer has little control over such situations, which is fine (even desirable) in a typical business application but terrible in a real-time trading environment.
The standard strategy that I'm aware of (and that we use) to minimize this potentially catastrophic scenario (a quote lagged by 50ms could be bad; one lagged by 1s could be devastating) is to use resource pooling and recycle the same objects over and over in favor of creating new ones. The less garbage you create, the less there is to collect.
Besides that, constant performance profiling is obviously a must. A lot of the code in our codebase looks pretty ugly because of all the performance optimizations we've made (and continue to make). That's just the way it is, unfortunately, when you're competing with other traders to get to the market a few microseconds sooner.
We have run the Trading Shim project (link below) for several years, which is designed to provide the connector between a Java based, FIX translation and account management gateway, called the TWS, which connects to the upstream exchanges, account detail, and data farms of the broker: Interactive Brokers; and on the downstream toward the trader's strategy and management clients. It exposes a simple text command interface on its input, and results datastreams in several formats (syslog, logfile, standard out)
The shim is written in C++, and is released under a GPL3+ license. The testing harness (which simulates a client) is written variously in shell, Ruby, Python, and basically any language which can read from standard in, and write to standard out. So ... any language.
I collect a linkfarm to several such projects and products, note their implementation lamguage, and the licenses under which they are released here