So what is Volatility Arbitrage anyway?

Vol arb, as described here, is a type of quantitative trading in which bets are placed on the difference between an option's current market (implied) volatility, and a trader's best guess of how much actual volatility of the option's underlier realizes over the duration of the option. It's somewhat complicated, but it essentially boils down to buying and selling insurance on stocks, or whatever the option's underlier happens to be.

Vol arb is what I do. Well, at least it's what the tools and systems I build are designed to do. Without going into specifics, vol arb requires a lot of system support. Option prices move quickly, risks are many and not always easy to understand, and the market is very, very sophisticated. A nice fat juicy berry can turn into a lemon in a split second. And if you spend too long on your homework to make sure it really is a berry, odds are someone will come along and scoop it out from under you. Tools to support vol arb trading have to be fast, accurate and reliable. They need to display lots of data quickly, with minimal latency. When systems crash, or fail to provide accurate calculations, risks can grow exponentially.

In my previous post, I made the claim that .NET and C# are the best overall development environment for meeting this challenge. Particularly when development resources are tight. I believe this is true because of the design philosophy behind C#. Consistent, highly quality, high security, object-oriented features built upon decades of best practices in designing computer languages. Across every dimension I care about, I consistently find well thought-out, well implemented functionality. Code compiles cleanly to near bare metal speed, threading interfaces are easy to understand and work as expected, distributed computing and remote objects are almost second nature, and, of course, tight integration with high-quality, 3rd party screen components that run natively on the Windows operating system (still the best bang for the buck for high-performance processing anywhere). Some have called C# buggy. I beg to differ. In the entire time I have spent building out my framework, not once have I encountered a bug that I could trace back to C# or the CLR (there were a couple of minor annoyances with Visual Studio 2005 when it first came out, but rapid and intelligent support from Microsoft cracked these quickly).

Taken together, no other development language can match of these features. As I mentioned in my earlier post, some processes may require pure bare metal - like you can get with C, such as for pricing models. Some parts of market data feed handlers are also well-suited to C, particularly when you are trying to capture up to 200k+ updates per second, as you can see on the OPRA feed. However, these areas tend to be isolated, and because of their nature, should have employ a bare minimum of code. Once outside of these high-demand areas, i.e. the vast majority of the code in an enterprise system such as you need to support vol arb trading, C# enters it's forte.