Firms have long had to employ expensive and non-interchangeable resources in the form of quantitative developers to realise and support their alpha-generating activities. Off the shelf solutions, in the limited cases that they are available, come bundled with opaque and closed source vendor models. This is a necessary consequence of the unrelaxable constraint imposed when models are implemented by humans.
Fundamentally, libraries written by humans need to be expressed in a series of orthogonal abstractions to be maintainable and tractable. As the library becomes more powerful, the abstractions become more abstruse and coupled. As a result, they become harder to learn, harder to modify and harder to integrate with external systems. This increases the activation energy of adding new members to the team and transitioning to newer and better ways of modeling the domain. This leads to de-facto code lock, both with in-house libraries and nominally open source libraries (like Strata and NumPy).
SimianQuant exposes a quasi-symbolic statically typed domain specific language (written on top of Scala) that allows programmers to write models with the same fluency that they would have when writing them on paper. It has a minimal set concepts which can be learnt in less than half an hour by anyone with a grasp of high school algebra and basic programming. Its generators can be configured to integrate with any external library, eliminating the possibility of vendor lock.
In general, the advantages can be summarised under four headings:
The library can keep track of more information when generating the implementation, as well as mass customize a model for each use case. The result is an implementation that runs at the limit of the underlying hardware. Performance steps of upto 250x have been measured.
The symbolic nature of the library’s API means that programmers need to specify the least amount of information to build a model. This has two additional consequences:
- It accelerates the write-test-iterate loop, allowing programmers to stay focused on solving the problem
- Programmers can write sloppy and slow code, and let the library optimize it
The net result is that the time to market is drastically cut.
Broader Talent Pool
Since programming expertise is no longer a prerequisite, domain experts can directly contribute to the model. When the team is expanded, less effort needs to be spent to train the new members.
Consistency Across Applications
In practice, models need to be used by different teams with different goals. For example, the trading desk of a bank is concerned with evaluating the model to get a price, while risk management is concerned with studying the sensitivity of that price to market data. The library can be used to generate multiple implementations from the same description, customized to the requirements of each team. This significantly reduces operational risk.