
 We are moving into the quantitative finance industry - radmuzom
https://www.fpcomplete.com/business/blog/moving-quantitative-finance-industry/
======
zmanian
The advantage Haskell has in finance is there are a number of long term
success stories to point to.

Standard Chartered traders use an excel to Haskell interface for risk
management and trade execution.

S&P Capital IQ uses a Haskell DSL called Ermine for their reporting engine.

Tsuru capital is the largest hedge fund to use Haskell for trading but there
many smaller shops like Alpha Heavy Industries.

[http://www.haskell.org/haskellwiki/Haskell_in_industry](http://www.haskell.org/haskellwiki/Haskell_in_industry)

FP Complete repeatedly mentioned Standard Chartered's Excel to Haskell system
as something that they would want to see more widely adopted.

------
tdees40
Matlab, C++, C# and Java rule the roost in the finance world. Anything else is
treated with intense suspicion by finance companies. (I was once at a very
large financial company that wouldn't approve Python for use internally at all
because it was open-source. Let that sink in. We used it anyway of course.)

And yes, R and Python are making real inroads in quant finance, but they still
have a small market share. Most of the guys writing code either want MS Office
integration (sadly all traders love Excel), raw speed (C/C++/Java), or easy
prototyping (Matlab). People don't know Haskell, audit departments don't know
Haskell, and Haskell isn't as fast as C++, so this is an uphill climb, but I
wish them the best.

If you want to know the state of the art in quant finance, go stare at the
horrible over-engineered debacle that is QuantLib and see what kind of
programmers we have working in this area.

~~~
sheetjs
> sadly all traders love Excel

Why do you say 'sadly'? Excel is an incredible tool that other traders can
work with, it is sufficiently expressive to run trades and backtests, and the
connectors (e.g. Bloomberg) are better than the python equivalent

~~~
dredmorbius
There's a long history of spreadsheet errors and literature on same going back
a few decades now.

In a business sim class in college a couple of decades back, I discovered that
the Lotus spreadsheets (as I said: a couple of decades back) had a totalling
error which double-counted individual row totals in the bottom line
(everything was twice as profitable as the spreadsheet indicated).

At an early gig, one of the senior developers instituted a practice of code
walkthroughs on projects (only a subset of them). One of these involved, you
guessed it, a spreadsheet (we used a number of other development tools for
much of our work), in this case Excel. Again, numerous errors which
substantively changed the outcome of the analysis. One of the walkthrough
leader's observations was that you could replace all of the in-cell coding
with a VBA macro making debugging far easier (all the code and data are
separated and in one place each).

The particular analyst whose project this was: he insisted to the very end
that this "wasn't a program" and he "wasn't a programmer" and that the
walkthrough didn't apply to his situation. Despite the errors found and
corrections made.

At the time (mid 1990s) the walkthrough lead turned up a paper from a
researcher in Hawaii on the topic. I'm not certain it was Raymond Panko, but
his 2008 paper (a revise of a 1998 work) discusses the matter in depth:

[http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm](http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm)

------
kasey_junk
Having built systems that try to do this in the past, I encourage you to
question a few assumptions that many people have about the inefficiencies of
this silo'd model.

(1) That quants want to program (or that the business should want them to) in
something other than R, Matlap, NumPy, Julia, etc. (2) That the hard part of
moving a model into production is translating the model. (3) That the model is
the part of the system that will be the main driver of success.

Good Luck!

~~~
Estragon
This is very interesting. What actually is the hard part and what drives
success, in your experience?

~~~
kasey_junk
I've found that quants do not follow software best practices. They do not
produce production ready code and it isn't because they aren't using the right
language. It's because they aren't production software developers (and I don't
want them to be, I want them out there doing analysis). Further, I've never
encountered a model that didn't over simplify operations/execution
requirements. They do this so that they don't get bogged down in details when
they haven't figured out the big picture yet, and that's a good thing.

What drives success is having a good set of quants who can communicate with
production capable software engineers. At the end of the day, the hard part of
a quants job is usually finding concepts. Once they are found translating them
into something actionable is usually reasonably easy.

------
KingMob
While I want to cheer on esoteric languages and functional programming, this
seems like just more smart people wasting their brains on zero-sum detrimental
finance games. At least for them, they'll probably make a lot of money.

~~~
confusedread
"zero-sum detrimental finance games"

That depends on the market, doesn't it? They didn't say they were explicitly
building systems for Forex, right?

And who are you to tell people what they should "waste their brains on"? A lot
of programmers I know in research labs/academia speak condescendingly towards
really intelligent SV programmers who "waste their brains" on moving pixels
around a screen in order to make people click more ads.

~~~
_delirium
Fwiw, that line actually came from someone in the tech industry, though no
doubt some academics also like it. The oft-paraphrased quote is from Jeff
Hammberbache, an early Facebook employee, who at the time of the comment was
at Cloudera: "The best minds of my generation are thinking about how to make
people click ads. That sucks."

~~~
gjm11
So far, no one seems to have come up with an economic system that's more
effective in harnessing the collective skills of the human race to improve the
world (on balance) for everyone than the one we have at the moment.

It has the regrettable feature that it strongly incentivizes some very smart
people to spend their careers encouraging people to click on advertisements,
and some other very smart people to spend their careers arranging for the
profits from exploiting subtle equity mispricings to flow to one random set of
rich people rather than another. But the net effect is pretty good, or more
precisely less depressingly wretched than that of any other system found to
date.

(And some of those very smart people get rich by encouraging ad-clicking or
exploiting equity mispricings, and then use their money and/or freedom to do
neat things from which everyone benefits. Is that such a bad way for things to
work?)

~~~
_delirium
I guess I have some doubt that the American economic system in particular is a
local optimum. Something radically different carries risks, yes. But the
American system is a bit of an extreme in its encouragement to do _anything_
that makes a profit, even within the local space of variation of vaguely
market-based mixed economies. In Denmark, we have a bit more "managed"
economy, perhaps even "socialist" in a certain weak sense (there used to be
more of a socialist ethos, alas). The country is a bit less focused on VC
returns, big paydays, and "exits", and frowns a bit more on people doing
mercenary nonsense for profit. You get paid to go to university, there is
extensive arts funding, an industrial/scientific policy, etc., among other
things that try to redirect energies elsewhere. And that historical
"approximate equality for all, big profits for none, put your energy into
something worthwhile" approach to an economy has really not been disastrous,
quite the opposite.

~~~
gjm11
I didn't actually mean the American system specifically. (I'm in the UK, for
what it's worth.) My own preferences are quite leftish and I would prefer the
UK to be more like Denmark than it is. But, still, the US seems to be quite
effective in producing new technological things, and maybe that's partly the
entrepreneurial mercenary culture as well as the mere fact of being a rich
country.

Anyway, the "system" I had in mind was the (not necessarily well defined)
global one of which the US, the UK and Denmark are all parts.

~~~
eli_gottlieb
>But, still, the US seems to be quite effective in producing new technological
things, and maybe that's partly the entrepreneurial mercenary culture as well
as the mere fact of being a rich country.

Speaking as a born USAian, I honestly believe it's more that the USA can and
does brain-drain the entire rest of the world. When you actually _raise_
people in an environment of mercenary capitalism, what you mostly get is poor
people. When you let social-democratic states across the world raise and
educate people, let them fund their research or their early attempts at
businesses, and then steal those people when they get successful enough to be
an easy bet and put them in a ruthless entrepreneurial environment, _then_ you
get a seemingly high concentration of high-talent, high-productivity
businesses.

It's kind of like how people outside Israel say we've become a high-tech
powerhouse through the discipline of our military training, but actually the
Israeli army is one of the world's worst bloated, effort-wasting bureaucracies
for every soldier outside a tiny elite.

------
dia80
IPython + Pandas[0] + (sklearn/cvxopt/etc.) are an amazing combination and as
far as I can see gaining share. I would love to work in Haskell but I'm always
scared the library support / interactivity won't be there. Pandas has 8600
commits at the time of writing, unassailable?

[0] [http://pandas.pydata.org/](http://pandas.pydata.org/)

~~~
radikalus
This stack gets a LOT of use in HFT. (Including us)

Honestly, the three things I'd most love to have are: \- more wrappers,
support, documentation on PyMC -- a LOT could be done here and this could
replace HUGE amounts of code in all sorts of place \- libraries/models on top
of cvxopt \- more polished ipython notebook -> pdf or d3.js html -- I do this
a fair amount for auto eod reports etc

And maybe a fourth...a good open source alternative to kx...preferably one
that can accept .h5 files.

~~~
hogu
what group are you with? we're working on some relevant stuff

[http://continuum.io/](http://continuum.io/)

I can be reached at hugo@continuum.io if you want to chat about it

------
tom_b
I would like to read details about the model -> production code that the IAP
product uses.

I've been developing an interest in statistical modeling and moving those
models to production code (and of course, quantitative finance is an "obvious"
place where this happens). But I find, even in the statistical genomics world,
that the default process still seems to be:

    
    
      (1) specialized tools for data cleaning and initial crunching (maybe hadoop, maybe HPC clusters
      (2) consumption of data from (1) in R or Stata/SAS for model generation
      (3) only vague, research-y things where the model from (2) goes to production.
    

The vague part of (3) is probably just due to my simply not knowing what
people are doing with the generated models in (2).

Specifically regarding quantitative finance, it would seem that trumpeting
your implementation programming language would mainly be met with blank
stares, Jane Street excepted . . .

------
kopter
Growing up and moving into the finance industry? Excellent! Please fix the
typo in the 'FP Haskell Center (TM) Overview' section: "... The personal
edition aslo includes Emacs support ..."

~~~
G228
Thank you for pointing that out.

------
tunesmith
I think quantitative finance is interesting, but for personal purposes I'd
really only want to trade once a month or so, as opposed to multiple times a
day. I'm not sure what kind of software libraries/languages are suited for
that kind of approach, when everything seems tuned for HFT.

~~~
BSousa
For that kind, you don't really need any specific software. You can do it in
Ruby/Python/Haskell/Whatever. As long as you can communicate with an API
(Yahoo Finance to download the data for example and one broker that allows you
API access to issue orders) any language will do. You can run your software
once a month or week, analyse the data and issue the orders. If you are keen,
you can even use Google News/NLP/Sentiment Analysis in your model, again, in
any languages you want.

Take a look at: quantstart.com He has some tutorials with Python to do so, and
he is releasing a book (hopefully soon) that should give you a good overview
of it all. Also, I recommend you read Options, Futures and Other Derivatives
to understand how most of this financial instruments work. There is a lot of
good information there.

~~~
tunesmith
Thank you - that is very good information. I have done some perl scripting
using "Finance::Quote" and "Finance::QuoteHist" but I guess I have been
looking for the next step up. Particularly historical financial statement
information, like EPS and Sales data quarterly history. Historical
fundamentals as a data feed. I don't know where to find that. I'll check
quantstart and see what they offer.

------
habosa
Is there a difference between quantitative finance and HFT? I imagine it's a
square-rectangle relationship.

I'm a big fan of new tools to make mathematical models for traditional
investing, but I am fairly against the idea and practice of HFT.

~~~
gjm11
If you hope to make money from trading (beyond the quite respectable gains you
can get just from buying index funds or whatever), you basically have two ways
to do it. (1) Make better predictions (or better adjustments for risk, or
better hedging of one asset against another, etc.; these are all closely
related) than others. (2) Buy and sell without any attempt at predicting the
future; be willing to take the other side of any trade anyone wants to make,
in return for which you get to buy a little low and sell a little high.

For #1 you need quantitative finance. #2 is the activity known as "market
making" and HFT is what you get when you automate it and then let the people
doing it compete. The algorithms in HFT are pretty simple-minded; the goal is
to offer as thin a spread between buying and selling prices as you can while
still making a profit, and to offer it faster (when someone comes looking to
trade) than anyone else. The latter is genuinely useful when it's the
difference between (say) 5 minutes and 5 seconds. Unfortunately the same
incentives that make it worth while for high-frequency traders to offer sub-
second response times then make it worth while for them to keep chasing faster
and faster times, until the most important asset a HFT shop has is a bunch of
computers positioned slightly closer to a big exchange than anyone else's.

There's not much of what people mostly mean by "quantitative finance" in a
typical HFT system, I think.

------
rajacombinator
this is not a good industry to move into

------
notastartup
Can someone help me understand how hedge funds, trading desks use this type of
software?

~~~
ixmatus
Haskell has been used to model financial contracts by a few firms with an eye
towards type-level correctness guaranteed by the compiler (that you cannot get
with "mundane" type systems found in C++ / C / Java / etc...) That, coupled
with Haskell's speed, concurrency features, and other amazing features makes
it an attractive platform.

Alpha Heavy Industries is a small(er) SV based firm using Haskell a lot.

~~~
noname123
Hi ixmatus,

Can you give a more specific example? Are you saying that instead of in
Java/C++ where you have:

GenericSecurity > GenericOption > EuropeanOption, BarrierOption,
AmericanOption

You can have more mutable types/classes at run-time and more injections
instead of the concrete ones defined at compiled time?

Also, can you give any concurrency examples in terms of concurrency features?
Is it similar to Actor model in Scala? Or based more on concurrent data
structures as in java.util.concurrent.*?

~~~
tel
Take a look at [1] for details on the contract language they built. Instead of
modeling things in a taxonomy, they build the logic of contracts up from
primitives using a combinator library.

Concurrency in Haskell is a big thing. At the lowest level, purity means
there's a lot of opportunity for parallelization. Atop that Haskell has a
really great green threads system and new GHC has a very, very performant IO
manager for running them. It's GC'd so you do have thread-local pauses and
they're not as nice as Erlang's actor-local GC. Atop that you've got a nice
channel system, the best implementation of Software Transactional Memory
around, and neat new libraries like LVish for doing eventual consistency in a
very reasonable fashion.

[1] [http://research.microsoft.com/en-
us/um/people/simonpj/Papers...](http://research.microsoft.com/en-
us/um/people/simonpj/Papers/financial-contracts/contracts-icfp.htm)

~~~
noname123
Thanks tel for the helpful example, I scanned through [1] briefly and will be
attempting to grok the details later. But very interesting paper on using
Haskell combinators as opposed to the ugly Java single-inheritance model to
make up more and more complicated securities piecewise. Tbh, I'm quite envious
of using functional languages and will use the examples to try to learn it
(since I'm familiar with the domain area of financial contracts only in
imperative lang though).

I also like to learn concurrency in Haskell and don't know a thing about it
(currently, I'm trying to go over Clojure concurrency features). So what you
have mentioned regarding the LVish framework and Erlang's actor-local GC,
green threading will give me a good starting point to poke around. Thanks
again for your note!

~~~
tel
Simon Marlow wrote a book recently on Concurrency and Parallelism in Haskell
[1]. It's a good read for learning more about this kind of stuff as well.

[1][http://chimera.labs.oreilly.com/books/1230000000929](http://chimera.labs.oreilly.com/books/1230000000929)

