Introduction
This article is targeted at model developers and the technical support teams that support model developers. This is also useful information for senior management and architects exploring the cost effectiveness of the various options as this is an important consideration in a clear choice process.
Finally, in this article we apply the eighty-twenty rule. We are talking of the most common (eighty percent) use cases here. If your particular use case requires something more special (tensorflow quant finance on GPU’s, for example), please reach out and speak to us.
What is a model?
We will restrict the definition of a model to “a mathematical representation of the world view you are trying to encapsulate” for the purposes of this article. We will focus on financial models based on mathematical equations and statistical techniques used to explore the behaviour of that financial market. For example:
- A simple mean reverting model on interest rates that can be used to study the behaviour of the Bond or the Swap market.
- A stochastic path based approach (simulations) to study the behaviour of structured equities.
- A time series model that uses statistics to look at trends in the generation of electrical power and the effect it has on the Liquified Natural Gas markets.
The above examples focus on a degree of predictions in order to understand how future prices may “drift” and “diffuse”.
Other models might include calibration models that take in current market prices to reverse out the market parameters that underpin these prices. For example, working out the implied volatility from option prices.
Arbitrage models could be tuned to explore markets around the world to understand mispricing by institutions and exploit such opportunities for their brief period of existence.
In our experience, each of these models have their own unique characteristics and need to be treated in a different manner in order to exploit market opportunities and provide the ability for business to respond effectively to changing market conditions, especially volatile ones.
Data (and the consistency with which it is sourced, referenced and dispersed) is crucial to the model behaviour and its output. However, this is often easier said than done. We will not discuss the issue of data consistency in this article as it requires a space of its own due to the vastness of the subject.
Models For Platforms
Closed Form Models
Models that are based on either mathematical formulae or equations, including statistical ones, to which there are known solutions typically fall into this category. Closed form models could also be iterative such as finding the roots of a polynomial equation.
Embarrassingly parallel models (Fanout Models)
Models that cannot be evaluated by a (set of) equation(s) that require simulation of future market scenarios are typically fan out models.
Models with larger dimensions of parametrisation (typically four or more) may benefit from a simulation based model. Clearly, as the number of simulation paths increases, the better the convergence of the model. But this also involves more complex distribution and collation patterns as the computation scales out. The model is “embarrassingly parallel” since each path can be independently evaluated, i.e. the execution of the model can be scaled in a near linear fashion.
Fan-out models (Path dependency + state retention)
Fan out models can be much more complex than the embarrassingly parallel kind. Counterparty credit risk is one such example where the probability of default of the counterparty is being simulated. Additional complexity can arise from the fact that at any given point in time and across the simulation paths, two related counterparties’ risk can be netted off against each other (as dictated by the netting sets rules).
When pricing American options, using – for example – the Longstaff-Schwartz Algorithm, the state of the path that is “[early] exercise favourable” may have to be retained.
Though, in both examples, fan out occurs – the fact that state needs to be tracked leads to a whole set of complexities in terms of engineering that must cater for robustness as well as recovery.
Platform for Models
Batch based engines
Batch based engines (synonymous with task engines) originated from the need to run calculations at scale using a computational grid. At a more generic level, a computer program needs to be run repeatedly at scale on a large grid of computers. This worked quite well until the computational demands began to increase. Task based engines needed to discharge their results quickly in order to pick up the next task. However, as more tasks are run, it was necessary to introduce distributed caching to make this more efficient but that also introduced its own inherent scaling limitations.
The largest problem with batch based engines is that the processing of data was too simplistic and therefore very inefficient. All data that is processed must be serialised (sent) to the calculation engines. When data requirements become very large, batch based engines struggle to scale and create hot spots on the grid which cause errors. Recovery can require rerunning the entire batch if the processing order is not carefully engineered, which adds to the total cost of ownership.
A new type of engine evolved from batch based engines has emerged in public clouds. Streaming engines such as Google Dataflow based on Apache Beam and Databricks based on Apache Spark, to mention a few. These engines have demonstrated superior scaling characteristics and can dynamically rebalance to cope with hot spots. However, this does require the analytics to be tuned for such engines.
Please see our blog on using Google Dataflow as a Risk Engine, which provide an alternative to Task based engines for batch processing.
Streaming engines
To better understand the importance of streaming engines, we must introduce the concept of bounded vs unbounded data sets. Bounded data is finite and unchanging, while unbounded data is infinite, unpredictable, and not always sequential.
Examples of unbounded data include traffic data, weather data, internet traffic, etc. As one can imagine, data for unbounded data sets cannot fit in the memory space of a single compute node. Strategies to deal with unbounded data that can effectively utilise compute grids require very different concepts from batching.
One of the key challenges in financial service for unbounded data is data consistency and meaningfully grouping market data snapshots since the data becomes available at different cadences. For example, when building an interest rate curve. Feeds for short term rates can be more frequent (in multiple ticks per second), while long term rates could be one every few seconds or longer.
Assembling such a data set that is market consistent at that instant of time is not trivial and requires data processing semantics that have evolved into a discipline called “Data Engineering”. Streaming frameworks such as Apache Beam are designed with data engineering concepts that can describe data processing requirements. The streaming data is then fed to the models with very little code. Ie. Skills required to create the model differ greatly from the skills to define the data processing. True real time pricing requires adapting to such paradigms. The underlying pricing libraries also need to be tuned to work in such scenarios.
Models written for bounded and batch runs are often not suited to run in streaming mode. It may require considerable re-engineering of the model itself to adapt it for a streaming paradigm. The converse, however, may not be true. Developing a model for streaming is more complex and requires a larger investment. So if you are never going to use it in streaming mode, you need to decide if the increased cost justifies the flexibility.
Please see our blog on Streaming Risk with Apache Beam on Google Dataflow for more detailed explanation.
Micro batching
People often mistake running a batch based system to a higher frequency to be an alternative to streaming. Micro batching breaks up larger data sets into smaller batched chunks. Though it may give the appearance of a more frequent refresh from the model metrics, it is fundamentally different to continuous streaming that operates on unbounded data sets.
Micro batches still fundamentally operate on bounded data sets. The complexity is transferred from the model platform to the data system responsible for assembling the data and providing that data consistency that the model requires. Often, this may be a sufficient extension of the batch based system for satisfying certain business requirements.
Messaging is not streaming
Another misconception is that adding messaging to process data events or model data is synonymous with streaming. Streaming is built on a framework of concepts such as windowing, processing time, event time, etc. These will be discussed in subsequent articles.
Micro Service based engines
Risk Engines based on micro service patterns (and deployed on Kubernetes) offer a good alternative when working with closed form models. The pricing of a single Interest Rate Swap should complete in milliseconds (a bit longer, perhaps, if the interest rate curve needs to be bootstrapped first).
When pricing a portfolio of such swaps is also not difficult as well designed Kubernetes based engines should scale (though scaling is not always instantaneous and needs complex overheads like service meshes).
Kubernetes can also handle fanout models that are embarrassingly parallel. However, the result again needs to be dumped somewhere in order to perform the map reduction.
Kubernetes based engines become particularly weak when working with fanout models that retain state or have path based dependencies. Tracking these and reassembling data sets has to be done manually and can often lead to complex engineering challenges which become even more acute with scaling.
Finally, Kubernetes based engines can be made to operate in batch or streaming modes. For batch modes it may require external triggers to schedule and initiate the process inside Kubernetes. For streaming, it needs to be plugged into a streaming pipeline ecosystem with some complex engineering to accompany it.
Buy versus Build
There are many factors that drive this argument of buy versus build. Before the era of public clouds, this used to be largely driven by the time-to-market argument with a counter argument being market responsiveness (for example, response to changing regulatory controls).
But with the advent of public clouds, this choice has become more complex. The major cloud providers now provide for managed services that are enterprise grade systems for use on a per second basis. This opens a third dimension that allows you as a modeller to control the analytics but leverages cloud based systems for scale of operations without the overhead of carrying large technology teams. Public clouds clearly also are an alternative to captive data centres which are becoming a less attractive option for institutions that do not wish to be in the infrastructure management business.
The buy versus build choice has now become that much more complex when evaluating the total cost of ownership (TCO). To get a true picture of the TCO you will now need to take into consideration your utilisation metrics, any negotiated bulk discounts on offer, the effect of pre-emptive pricing. Certain other factors such as availability of skilled personnel at cost effective rates can be approached from a global perspective as access to public cloud is, generally, democratic (in most parts of the world).
The other factor adding colour to this debate would be the ability to use and exploit the latest hardware without worrying about depreciation costs and other complicated tax overlays. This becomes particularly relevant when the business seeks an accelerated response to certain problems that require intelligent use of Artificial intelligence.
The AI Fairy Dust
With an AI driven toothbrush and toothpaste to clean your teeth coming to a store near you soon, the world of financial modelling is unlikely to escape from this fascination with AI. Financial modellers are largely driven by patterns observed from the past. A mean reverting model for interest rates was developed because mean reversion was observed and deterministically applied. The model was adjusted to prevent negative rates because such a scenario was deemed impossible (though this myth was busted in the recent past).
Models rely on glimpses of the future only through the window of a calibrated past.
Artificial intelligence also relies largely on recognising patterns. It just happens to do this much more quickly and working through tonnes and tonnes of data that no human mind could. At the heart of a good AI driven system, lies an intelligent network of models that the AI system can leverage to make inferences on the data that it possesses.
AI systems are evolving rapidly and these are more readily available when operating in the Cloud. This is the final dimension that drives the buy versus build argument. But in the case of AI the argument tilts in favour of knowing which tool to direct the AI system to leverage for a particular problem set.
The engineering intelligence remains human even though the results may give the appearance of being artificial.