The rise of functional programming in Banks

By Abdul Muhit | Oxford Knight


Functional programming in 2006:

Back in 2006 I recall headhunting a candidate who was highly recommended to me, referred to as a genius with a double first from Oxford. As a junior recruiter at the time a referral of this nature is perhaps best described as gold dust! So you can understand my excitement when the candidate in question agreed to meet for a coffee to discuss an exciting role at a leading high freq hedge-fund I was working with.

I recall the candidate in question being perfect in every aspect (CompSci from top university, sound understanding of data structures, algorithms, complexity….coupled with actual practical programming experience, and oh yeah – decent knowledge of Exotic Risk and Pricing). However, to my disappointed he was exclusively using a language that I had never heard of before….Haskell. What further compounded my disappointment was that despite the candidate wanting to look for something new, he would only consider functional programming based roles….so I searched, …and…came back with nothing!

Today, just looking at job boards and speaking to various banking hiring managers, I am surprised at the sheer volume of functional programming and functional programming style roles available. So what has changed since 2006? What has promoted this continued rise of functional programming roles in the banking industry?

Why such an interest?

Today Functional programming in banking is no longer the hobby of a few. One major American bank is pushing a JVM based language that supports functional programming (Scala) as a firm-wide technology. Another two major banks are using Clojure for both real-time risk and pricing, and risk reporting. Speaking specifically to some of team members/the hiring manager of team that work on these Scala/Clojure roles, I am able to understand better why there is an increase in the interest in functional programming….below is my recruitment (non-technical) explanation…..

Easier to write concurrent programs

Banking Trading systems and concurrency tend to go hand in hand. Whilst Java does provide concurrency concepts, ….speaking to many Java developers across the several banks that have adopted (Scala/Clojure) there is an agreement that shared memory multi-threading approaches in Java cause more trouble than solving the problem. In other words, Concurrency certainly seems to be the major driving force, with ‘imperative’ languages like java struggling due to having sequential statements and mutation so fundamentally baked-in. JVM based languages that do offer functional programming approach makes it very easy to write concurrent programs.

An industry built upon maths:

Another reason for the rise in functional programming in banking is due to the fact Banking is a business that is built upon mathematical functions and data transformations. Functional programming is closely modelled on proven mathematics, and of course mathematics is all about abstraction and composition. As such it is these vastly superior abstraction and composition techniques that functional programming give, which allow functional programming teams to cope with the complexity of large codebases and difficult problems.

Low risk and not so steep learning curve:

I appreciate there is some oragnisation risk with adopting…….

This is my personal opinion, but generally speaking what I have found is that technologists in general (banking or not) tend to be a progressive bunch. There is a need to do better, and to improve on what is in place already. What stops progressiveness is risk vs. reward. I mean why use/do something new that may disappear tomorrow and mean that the time spent would have been wasted? ….I mean, look at Silverlight in 2009… .banking went mental for it, paying super high contract rates, …and now it’s not even supported by Microsoft.

However, I feel the rise of functional JVM based functional programming languages is due to their low risk. They are low risk simply because Scala/Clojure are built upon the JVM …meaning if tomorrow Scala/Clojure become obsolete, you get to retain the JVM.

Moreover, Clojure is based on LISP which has been around for a long time, and it’s safe to say it will still be around in the future. Finally, whilst I have never coded, because Clojure/Scala is on the JVM it’s very easy to pick up for a good Java developer.

Functional recruitment today:

I appreciate that I might have offended some people by not always making the distinction between functional and JVM based languages that support a functional programming style. I am aware that there is a clear distinction; however, for the purpose of describing the functional programming landscape today I am going to coin them together.

  • Scala: both being used in banking and some funds (high freq and systematic). I first started noticing adoption of Scala within these types of business in 2009, and if anything there has been a steady rise in its use; which doesn’t appear to be stopping. Usage in the UK is probably half of that in the US (Palo Alto in particular).
  • Clojure: used for risk and pricing applications for fixed income and for a brand new Greenfield risk reporting application. Unlike Scala this has seemingly come out of nowhere. Usage of Clojure remains slightly more popular here in UK and Europe more so than the US.
  • Haskell: heavily used by three separate banks for their quant modelling groups. These are sometime business reporting groups and compared with IT reporting roles pay a lot better. However, open headcount in these teams are few and far between, and the roles are almost more suited to PHD students who have used Haskell heavily during their PHD work. The community is much smaller than that of other functional programming groups and key attendees of Haskell meet-ups are very well known to each other.
  • OCaml: some use in the systematic hedge-funds. Adoption of this language is very low, but like Haskell it’s been around for a while making it a mature, stable language.
  • F#: currently used by 3-4 funds casually, and also by 1-2 modelling quant groups. There was a big hype around it in 2007/8….but noise around it has died down somewhat.


What does this mean for banking technologist today?

Unlike some extremist functional programmers I have spoken to, who make big, bold claims that Java is dead, I feel there is still a great deal of work to be done with OO Languages etc. For me as a technical recruiter trying to place strong candidates, nothing beats a strong grasp of an OO Language. With that said, those with time to spare after a hard day’s work should spend a little time exploring functional programming. From what I am told it’s interesting, addictive, and supposed to help improve OO skills. Moreover, What I find really interesting is that the mainstream industry seems now ready to take their languages in a Functional programming direction. This quote from Brain Goetz, the Oracle Java team lead, is particularly telling: so to sum up, for I don’t think there’s any avoiding a hint of functional programming in banking for too long!

By Abdul Muhit

Linked In:



Oxford Knight is a technical recruitment agency. None of our consultants have written a line of code… yet. We apologise if this article doesn’t keep some purist happy, but we’re trying to build a new generation of technical recruitment agencies…. We listen, participate, and deliver.

More information

Get in touch using the contact form below or give us a ring at +44 (0)20 3137 9570 or +1 646 7129 405. We'd love to speak with you about what we can offer.