Would you like your software to be more reliable, harder to hack and cheaper to run? Then, if you aren’t already in on the act, it may be time to embrace functional programming – a maths-based approach that is challenging the status quo at financial firms.

Proponents of functional languages say they are better at handling certain financial operations than the dominant, so-called imperative languages. They will become even more relevant, these fans argue, with greater adoption of the distributed ledger technology (DLT) in finance, spurred in part by the International Swaps and Derivatives Association’s common domain model (CDM).

“Functional programming has been gaining popularity in banking for the past decade, but the pace is accelerating,” says Neil Mitchell, who has worked with functional languages at Credit Suisse, Standard Chartered and Barclays. He is now a senior product architect at Digital Asset, which builds DLT products for financial firms and counts ASX, the Australian securities exchange, and the Depository Trust & Clearing Corporation (DTCC) among its clients.

“It’s likely a combination of success stories, greater compatibility with existing systems and more experienced senior engineers with functional programming skills,” he explains.

For banks and trading firms using functional programming, its appeal lies in a number of ‘magical properties’ that are absent or less common among imperative languages.

For instance, the so-called strong typing feature prevents mundane coding errors such as the programmer accidentally typing in a letter where there should be a number, while easier testing catches other mistakes before a program is run.

Code written in the functional style also tends to be more concise because functional programming works by telling the computer what the desired result is, rather than by spelling out the steps it should take to achieve the result – as imperative languages do. Simpler and shorter code is easier to check for bugs.

Fewer flaws in the code mean fewer weaknesses for hackers to exploit.

“The ability of the [strong] type system to catch [mundane] errors allows us to spend more time thinking about other, deeper issues in our code and drives down our error rate, making it possible to move faster while still maintaining safe and reliable systems,” says Yaron Minsky, co-head of the technology group at liquidity provider Jane Street.

The firm, as it puts it, writes “everything that we can in OCaml”, a functional language, and employs 300 OCaml developers.

OCaml has another advantage: it is better-suited for concurrent computing than imperative languages, such as C, Java and Ruby. The same goes for the other languages on the functional spectrum used in the financial industry, such as Clojure, F#, Haskell and Scala.

Concurrent programs excel at complex tasks, involving many simultaneous actions. They are faster than sequential ones if run on a parallel computer – a computer with more than one processing unit or core – and most computers today are multi-core. Concurrent programs also make better use of available hardware, whether it has only one or many cores, and reduce the need to buy or rent additional servers.

Bulletproof code

Functional programming is not new – the first functional language was developed in the late 1950s. But historically, imperative languages had substantial memory and speed advantages when applied on hardware that existed at the time. And so, in a nutshell, imperative programming came to dominate.

But as technology advanced, hardware became much less of a constraint, prompting a closer look at functional programming. Fast forward to today, and the previously niche approach has made its mark at a number of banks and trading firms, including Goldman Sachs, Trafigura and AQR.

“When I started functional programming commercially, at a bank in 2008, I knew everyone in the Haskell community. It was hundreds, maybe a thousand people – I at least knew their institution. Now I don’t know most of the people,” says Mitchell at Digital Asset.

As other devotees of functional programming, he singles out the strong typing present in main functional languages – F#, Haskell and Scala – although it also exists in some conventional languages.

The feature alerts the programmer when an inappropriate data type has been entered into a memory field – say, a decimal number where a whole number should be. Importantly, the mistake is reported before the program is run, allowing it to be fixed before it does any damage.

“It is similar to ‘spell check’, which flags spelling and grammatical errors,” says Mitchell. “If you are running finance applications, you’d much rather have the developer get a compile error before they push their code, rather than have your system operator get a runtime error at 4am because the entire reconciliation batch just failed.”

Digital Asset is using a proprietary functional language inspired by Haskell in its work to replace ASX’s clearing and settlement system for the Australian equity market. The exchange, which expects the new system to go live in March or April 2021, has described the project as “a once-in-a-generation opportunity to deliver material benefits for the securities industry and the broader economy”.

Like Mitchell, Mas Nakichi of financial technology firm Axoni stresses the reliability of functional programs – essential for mission-critical applications, “such as aerospace engineers launching rockets, which is where a lot of functional programming is home to right now”.

A project Axoni is participating in, which will process “trillions of dollars” of contracts, calls for the same kind of bulletproof quality, according to Axoni’s head of strategy and business development.

Together with IBM and blockchain outfit R3, Axoni has built a DLT platform for post-trade processing of credit derivatives at the DTCC, which is currently being tested. The DTCC’s existing platform hosts almost $10 trillion in outstanding transactions, both cleared and bilateral.

Axoni has also been selected to provide smart contract applications for the new platform and these will be written in AxLang, its own language based on the functional-imperative hybrid language Scala.

No data left behind

Advocates of functional programming say its particular reliability also comes from a characteristic that makes testing easier: languages on the functional end of the spectrum support only or primarily what is known as immutability, whereas languages that are more imperative favour mutability.

To give a simple example, immutability means that once a variable, such as x, is given a value – for example, 5 – the 5 is recorded in memory and cannot be changed. If the programmer then wants to give x another value – say, 6 – the new value does not overwrite the previous value but a new address in memory is created, in which a variation of x, such as x1, equals 6. In other words, immutability means the program keeps all versions of the data used.

Mutability, on the other hand, allows a value to be changed at the same address in memory.

One benefit of immutability is that some parts of the program can reference the original value of x, stored at one address, while others can draw on the new value of x, stored elsewhere. A program can also be tested easily by inputting a fake value and without disrupting the parts of the program that depend on that variable. If the program works with the fake value, the coder can be sure it will work with real values too.

The immutability of data and strong typing are what convinced Credit Suisse to turn to F# for its quantitative analytics, says Ganesh Sittampalam, lead quant developer at the bank.

“In large-scale programs, built up with lots of different libraries and lots of pieces of code written by hundreds of different developers, knowing that shared data can’t change unexpectedly really helps with our architecture.”

Sittampalam adds that Credit Suisse also uses an F# application to price securities, building on the lessons the bank learnt when it deployed a Haskell-based language, Paradise, a decade ago.  

OCaml powers almost everything we do, from low-latency trading and market risk systems to tools for managing and monitoring infrastructure, workflow tools and data analytics

Yaron Minsky, Jane Street

Strong typing was cited by Barclays in a 2008 research paper as a big reason it had chosen Haskell, considered the purest functional language, to represent and process exotic derivatives – not only because it prevented “many ‘typo’-style bugs” but also because it forced developers “to plan their algorithms more carefully, reducing the maintenance load later”.

Barclays still runs the Haskell application, called the Financial Payout Framework, says Lee Braine from the chief technology office of the bank’s investment banking arm.

The same feature, which provides “a safety advantage”, is a key attraction of OCaml for Jane Street, according to Minsky. “OCaml powers almost everything we do, from low-latency trading and market risk systems to tools for managing and monitoring infrastructure, workflow tools and data analytics,” he notes.

Standard Chartered, for its part, has developed Mu, a dialect of Haskell, won over both by strong typing and the ease of writing concurrent programs.

Concurrent programs are those that can be broken up into smaller tasks and each can then be run on a separate core of a multi-core computer, so that they are executed in parallel rather than one by one. Not only does this lead to faster execution, but it means a program involving multiple tasks is less likely to crash: it can either work on one process at a time, constantly switching between the processes, which results in better user experience; or it can distribute the tasks among more cores; or it can do both at the same time.

Andy Adams-Moran, head of strats at Standard Chartered, says concurrent programs work well for complying with the Fundamental Review of the Trading Book, which requires the bank to apply up to 300 mathematical functions, such as fair value or risk sensitivity calculations and market shocks, to millions of live trades daily.

Standard Chartered also uses Mu for pre-deal analysis to check the cost of doing business – including credit valuation adjustments, funding valuation adjustments and risk-weighted assets – as well as increasingly for regulatory reporting. In addition, traders script Mu apps that create trades and portfolios and provide speculative pricing and risk on them.

New horizons

Proponents of functional programming believe it will continue to spread in finance, not just as more people become aware of its advantages, but as other, complementary technologies advance.

DLT is one. As it represents a computing network run across many machines, it is similar to running a program across many cores on a single machine. Therefore, the features that make functional programming well-suited to concurrency also make it a good fit for DLT.

The emerging technology has become a buzzword in the derivatives industry since the development of Isda’s CDM – a set of standardised machine-readable identifiers for the events that occur during the life of a derivatives trade, such as partial termination, novation and compression.

In an October 2017 document, Isda said that, although the model could be adopted via any technology, the implementation was targeted at distributed ledgers. “Processing of financial contracts lends itself to concurrent/parallel/distributed processing,” it noted.

Software engineers from firms around the world have already completed initial work on DLT use cases for the CDM, as part of a competition hosted by Barclays in London and New York last year.    

Isda has said the CDM could also provide a foundation for smart derivatives contracts, which could be held on a blockchain or another type of DLT. The association defines a smart derivative contract as a derivatives deal with some terms that can be automatically performed by a computer and the other terms expressed in natural language. For example, such a contract could automate the calculation of a floating rate interest amount.

Functional programming is the best choice for smart contracts, according to Digital Asset, which won the overall prize at the London leg of the Barclays hackathon. The firm’s own, Haskell-inspired language Daml has been developed specifically for coding smart contracts between financial institutions. Among Daml’s benefits, Digital Asset cites its suitability for formal verification – a way to prove mathematically, rather than through repeated testing, that a program will execute as intended.

Axoni’s Nakichi agrees, saying that formal verification is much harder to achieve in imperative languages.

The infancy of DLT, meaning it is not locked into legacy code, also bodes well for functional programming, suggests Braine at Barclays. The advent of distributed ledgers gives programmers “a nice opportunity to implement their workflows from scratch, to green-field, rethink and go back to fundamentals for what is the best programming language”, he says. He adds that the CDM “maps elegantly” to functional programming.

Another recent trend that could help the functional style go mainstream is the growing popularity of cloud computing, which provides cost-efficient, on-demand access to a shared pool of computing resources, such as servers and applications.

Banks may start using cloud providers for FRTB calculations, says the head of capital management at a bank.

“Cloud may have a real impact here, depending on the extent to which re-engineering takes place as calculations migrate to the cloud,” he says, noting that Google’s Cloud Dataflow service, designed for analysing large datasets, supports applications in Go – a language with some functional features – among other languages.

A functional future?

So, wide acceptance may now be within grasp. But there are still barriers to overcome.

One is a relative shortage of coders with functional programming skills compared with hordes of imperative programmers.

“Most of the popular languages are imperative,” says Conor Svensson, founder and chief executive of Web3 Labs, a blockchain fintech firm. “This is the biggest challenge with focusing exclusively on functional – you cut out the majority of programmers who don’t know functional programming.”

The tricky mathematical concepts of functional programming, such as category theory, lambda calculus and type theory, mean the style may never be as popular with budding coders as its imperative cousin.

This could pose a problem further down the line. “If the code is going to live for a long time, those that maintain it may not have the same skills as the original developers,” says Felix Distel, quantitative developer at risk software provider Fincad.

Other downsides of functional programming include greater demands on computer memory and the generally lower speed of execution compared with imperative programs.

Compiler optimisation can deal with both problems to some extent. As compilers get better at this process of adjusting human code for machine execution, the memory and speed gaps will narrow. It should also become possible to implement some particularly advanced functional features – mostly in Haskell – that can’t be expressed efficiently in machine-readable binary code at the moment.

Some believe, however, that the choice does not have to be between functional and imperative. Each approach has its place, depending on the task.

Mike Hearn, lead platform engineer at R3, thinks imperative programming is better-suited for most projects but admits that sometimes it makes more sense to go with a functional language. R3 is even experimenting with Eta, a dialect of Haskell, to show how it can be used on its blockchain platform Corda.

And in a more subtle way, functional programming has already ascended: by introducing functional features into conventional languages.

The future, then, may not belong entirely to either style.

Russell Goyder, director of quantitative research and development at Fincad, puts it this way: “In the mixed martial art of programming, Haskell is tai chi – beautiful and elegant. But the most successful combatants are those who are able to draw from various schools.”

Editing and additional reporting by Olesya Dmitracova