shogunmike

Thanks for the Github link. I hadn't realised they had become open source!

Although (I had a 404), I think it's actually: https://github.com/InteractiveBrokers/tws-api-public

Indeed the PDT requirement is a pain...

I've had experience with IB in a quant fund setting. I was impressed with it. Significantly further ahead of the curve in regards to their API offering compared to other brokerages.

At my last check it was mostly geared towards C++/Java with less than ideal documentation. However there are some good open source wrappers available (Python): https://github.com/blampe/IbPy

As stated in the parent comment, the minimum account balance is $10k.

It's definitely an interesting area. However, I would start with paper trading (as other comments have suggested), as it is extremely easy to lose a lot of money in quant trading if you're not careful.

There's plenty of "academic interest" to be had without risking any real cash.

If you're interested in learning more (shameless plug), I run a quantitative finance information site.

I've linked directly to the articles on quant trading: http://www.quantstart.com/articles#algorithmic-trading

You're correct, co-location at the exchange data centre is indeed a requirement for most HFT firms.

I think (but I'm not 100% sure) that the length of network cabling is also tightly regulated at many exchanges so that nobody gains an advantage in that manner. If anybody has more insight into this, I'd love to hear about it.

Feel free to send me an email (mike@quantstart.com) if you want any other help!

I second the recommendation of 'Trading and Exchanges'. It's a great book to get insight into how the underlying exchanges work and how to exploit certain architecture to produce profitable strategies.

For HFT the learning requirements are extensive.

It is /almost/ essential to have a PhD in CompSci/EE from a top school to do HFT. Alternatively one should demonstrate extensive hardware/networking and optimisation skills obtained from other low-latency industries.

All of the top work is being done on FPGAs and latency is now on the order of microseconds (probably lower).

As for lower frequency algorithmic trading, that is a game that one can play at the 'retail' level if you're willing to spend (quite a lot of) time learning.

I run a website about algo trading. If you want to get a taste for what is involved have a look at some of the articles here: http://quantstart.com/articles/#algorithmic-trading

Machine learning techniques are becoming more common. Hence a shifting trend towards CompSci away from Physicists. The latter were often hired due to their modelling/probability capabilities in PDEs for derivatives pricing.

Also CompSci comes with a (perceived) "built in" ability to carry out good software development practices.

Nice trick with the Oyster card discount :-)

I think I may have suffered somewhat from selection bias when writing that, in that a lot of my friends/colleagues work at smaller shops, where they initially started as technology infrastructure developers and worked very hard to move over to the research side.

For instance, these were the guys -running- the data infrastructure so they were looking at it all day, every day. After a while it was probably straightforward to test out intuition on patterns they may have seen.

Thanks for pointing out that the difficulties in doing so at a larger firm.

Indeed, I am considering actually writing an entire article on that whole topic.

I haven't done an MFE personally, so I don't feel I can comment too much on what they're like, although I have a few friends who have. A lot of them simply went into research afterwards.

I completely agree with this.

While you may not be solving partial differential equations in your average tech startup, there are plenty of instances where a maths degree can be directly applicable. Statistics is one instance, for A/B testing. Another example is the use of vector calculus in machine learning and "data science".

How did you find the OU degree?

Yeah, this is pretty much the case.

The quant derivatives pricing teams at banks are where the stochastic calculus folk tend to head to. Their teams are generally highly respected in this area. Also, banks are doing a different job to funds. Banks are generally interested in assessing the risk or trading risk of these products, either on prop (i.e. with their own funds) or to clients.

Funds tend to concentrate more on statistical/machine learning/econometrics research approaches. The culture is generally more like a research institute thank a bank. They tend to hire more PhDs from Comp Sci, whereas banks will hire directly after MFE or straight out of undergrad.

I was a quantitative developer working alongside a quantitative trader in a small 'proprietary trading fund'. This is roughly how all quant funds are separated. There is the "technology" side, which builds the data/trading infrastructure and then there is the "research" side that generates the trading strategies to run on the infrastructure.

My job involved anything from hooking up to brokerage APIs to optimising MySQL replication topologies. Quite varied!

In a way, it wasn't too different from your average startup, with the possible exception that you deal with a non-trivial amount of data from day #1 (hundreds of millions of rows are not uncommon).

Open source has gained significant ground in funds these days. Python/R are now the "default" go to languages for quant trading research, with some MatLab too. Libraries such as NumPy, SciPy and pandas have really brought 'algo trading' to the 'retail' (algo) sector as well.

.NET is still generally used quite a lot in investment banking, particularly C# for front-office GUI code, and C++ for any legacy number crunching libraries.

I would say it's easier to get a job in risk management (likely in investment banking) than quant trading coming out of an MFE degree. This is primarily a consequence of how the MFE programs are set up, what they teach and the network of the professors etc.

Agreed - there is plenty of work for non-PhDs in both the buy and sell side. Quant developers are often possess undergraduate degrees, particularly in CompSci. Not much need for a PhD in the vast majority of systems development.

It is much harder in practice than in theory to be disciplined enough to do this! I always remember this great quote (paraphrased):

"A quantitative hedge fund only needs two members in order to be successful. A quant trader and a dog. The quant trader is there to feed the dog. The dog is there to make sure the quant trader doesn't touch anything."

The trick is to treat quant trading AS a business. You are essentially running a capitalised startup when you begin quant trading. There is a period of R&D, building the product (execution system), and then iterating - just like creating a mobile/web app.

The main difference is that if you're not interested in raising external capital, then you don't need to do any marketing - all of your focus can be on the product.

I have made it clear in the article that it is NOT easy, nor a get-rich-quick scheme which many seem to think it is. It takes a significant amount of work to generate consistently profitable strategies.

This also has a similar profile to the classic momentum - "trend following" - strategies. Higher quantity of loss-making trades (albeit small losses), but the winners win big.

Having experienced all three, by working as a grad student, as well as in a quant fund and starting an internet/tech startup, I can say that I gained enjoyment from all of these roles.

Each experience presented interesting challenges. Quant trading was very mathematical, academically interesting and presented "big data" issues right at the start. Tech startups taught me a lot about management, getting things done (TM) and why you need to have a market BEFORE building a product! Academia taught me how to really analyse a problem to an extreme degree and how to quickly find solutions.

Right now I'm enjoying building quant trading systems. To a certain extent they can be fully automated (although you have to be aware of "alpha decay" - i.e. strategies losing their profitability over time) and thus it is possible to have other interests.

(Disclaimer: I am the author of the article.)

Consider the case of finding a set of strategies governed by a particular set of parameters in a book. For instance, the Moving Average lookback period. You will see authors posting certain strategies, albeit without revealing the market/time series with which they're carrying them out on or which exact parameters they use. This is the critical information, but it is also relatively straightforward to trial/test, assuming you have the available data.

Also - the same strategy, implemented identically, can be both successful AND a failure for two different traders with identical starting capital. Why? Because one may not have the stomach for a 50% drawdown in the equity curve, despite the fact that had they waited, a "big swing" would have been around the corner. It is as much about preferences/tolerances as it is about the actual rule set.

If by 'quantitative finance' you mean option pricing then check out the books by Mark Joshi:

- 'The Concepts and Practice of Mathematical Finance' - 'C++ Design Patterns and Derivatives Pricing'

Also of note is Baxter & Rennie:

- 'Financial Calculus: An Introduction to Derivative Pricing'

Once you've studied those and have a good grasp of Measure Theory, you'll want to tackle Shreve, Vol II.

And a brief plug of my (slightly out of date!) quant finance website, Quantstart.com.

I really like the idea of QuickCheck. Presumably it is -best- used in conjunction with unit testing. It seems to me though that it would be suitable mainly for numeric type code, given the random nature of the inputs?

This is a great tool. I can see this being extremely useful.

Have you considered including a set of metrics which measure the maturity and status of each project? How about listing noteworthy uses in production? Also, recency and quantity of commits, bug fixes etc.

If things go wrong (and they invariably do), I can sleep safer at night knowing that there is a thriving community behind the project, which can provide guidance on any issues.

Admittedly what I have suggested presents some UI difficulties, at least on the home page. It would also need to be updated quite frequently. That could be partially automated by pinging public version control servers, for instance.

Still, a great job. Looking forward to seeing how it progresses.

Yes, I have heard of Eve Online, but didn't realise all of these dynamics had been put in place.

I'm sure I can dig answers out to these questions elsewhere, but I thought I'd ask how the economy is balanced. For instance, mining new materials obviously increases supply. To what extent is this activity capped by the game mechanics in order to keep demand at a reasonable level?

I've heard of space stations being bought and sold, but I think this was a separate MMO. Not far off restoring houses and flipping for profit in the real world!

Although there were basic market dynamics in Frontier and First Encounters, I always felt it was too straightforward to fly between Sol and Barnard's Star selling robots without any risk.

Market forces in an Elite-themed MMO environment would make it such an enjoyable experience. One can imagination hunting around star systems affected by war, supplying them medicine (or even black market weapons!), having to compete with other players to get the best deal.

Do I upgrade my trade capacity to make more of a profit or do I install a laser bank to reduce the risk of making any? What will the other guy(s) do? Can I hire somebody to protect me who will take a share of the profit?

Infinitely more fun than the 'grind...grind...grind...' dynamic that plagues MMOs these days.

Phil Plait has a great write-up of the image over at Bad Astronomy: http://blogs.discovermagazine.com/badastronomy/2011/01/14/th...

Unfortunately the original Quest for Glory games ran on Sierra's SGI and not the AGI which is used for the games here. This link has a good write-up about game interpreters: http://oss.sgi.com/LDP/HOWTO/Linux-Gamers-HOWTO/interpreters...

Luca,

On your About page (http://www.adormo.com/project/en/aboutus.htm) you have a spelling mistake. "Wordlwide" should read "Worldwide".