Financial engineering is and remains a divisive term.

In my Finextra blog last month, I argued that leading institutions were weighed down by legacy. Financial engineering is perhaps an example of such a technology that has also been tarnished by the Global Financial Crisis (GFC) of 2009.

So, seven years later, financial engineering feels vintage when sat alongside exciting “new” big data and data science fields.

But I believe history matters in my field. When you consider the foundations of “quant”, financial and risk modelling, you roll back 64 years and arrive at the work of American economist Harry Markowitz in modern portfolio theory in 1952

This seminal work sprung from Markowitz spotting that the then existing methods to understand stock prices did not consider the impact of risk. From his work with the RAND Corporation, those theories of 1950s vintage were turned into the algorithms that are key elements of industry algorithms used today, particularly on the buy-side. It sounds good, doesn’t it? Simple.

Fast forward from the Atomic Age to the Big Data Age, and a post-GFC world where financial engineering, including Markowitz, has had to grow up but without losing any of its relevancy.

The financial crisis of 2009 highlighted how financial engineering was enmeshed with extremely complicated products and strategies.  Systemic risks were missed, one example being the non-detection of apparent negative feedbacks into the financial system from complicated subprime investments. Complexity had obfuscated simple common sense. The (financial) world lost its head.

As I said before financial engineering splits opinion, sometimes very sharply. In the red corner recently, Time Magazine’s Rana Faroohar argued that financial engineering is ‘destroying value’, noting airlines can make more money from hedging on oil prices than selling seats. In the blue corner, Quant legend and University of Toronto Joseph L Rotman School of Management professor John C. Hull remarked last week at the Global Derivatives Conference that “derivatives can help to cure cancer”.

Given its mixed reputation, some academics and vendors have sought to soften the terminology by naming courses or product lines synonymous with financial engineering such as  “computational finance”.  Nothing wrong with that, it’s a great term, but I would stand up for the status of financial engineering, at least when it simplifies and embraces complexity, not adds to it.

Three reasons.

First, the essence of engineering is the notion of control, between interdependent subsystems and at the system level. It is similar to how an aerospace engineer is concerned about controlling the forces critical to keeping an aircraft flying and performing exceptionally well in the most testing conditions. Returning to the finance field, economic theory, practiced by those fixing the GFC, has made good use of state-space methods, core to control engineering.

Second, models are not going away. Even in the new world of Big Data and data-driven models, curves, spreads, surfaces, scenarios and predictive modelling are model constructions. Parameterization too – the identification of the relevant parts of your data universe - is essentially a modelling procedure. In fact it is a very mature one, underpinned by optimization, another methodology utilized across many industries and to some extent under-played in a data science world dominated by machine learning.

Third, financial engineers are best equipped to determine controls in a chaotic yet exciting big data world, mitigating risks in small subsystems and identifying risk-managed opportunities, as well as offer holistic, system level insights. Practitioners such as Andrew Lo and Rama Cont have conducted great work in this area.

What does this all mean in practice?

When you drive your car, certainly one less than ten years old, do you question its reliability? Probably not. You trust engineers to make your car safe and fun to drive. 

In the same way, Risk Managers need to be in a position to trust their own engineers – or quants, strats, data scientists or whatever you want to call them – to make their worlds more secure. This can be achieved only if both parties embrace that complexity positively and openly, for themselves and for their customers. Markowitz did this when he recognized the simple notion of risk, but back in the early noughties financial engineers were oftentimes adding complexity with the tacit approval of their bosses – who incidentally understood how these products worked even less than their customers. Embrace engineering, financial engineering, as long as it works to simplify, not complicate.