Quant groups are coalescing in many modern industries – insurance, retail banking, advertising, media, medicine, and more – in addition to being well-entrenched in the financial industry.

One challenge I had as a manager of quant teams was how to scale them up without losing the innovation and pace of delivery found in small groups. Quants are strong mathematicians and creative problem solvers but sometimes only average developers who are unfamiliar with institutional best practices for large-scale software efforts. In addition, management is often unsure how to integrate their quant teams with the rest of the organization.

IQPs (Institutional Quant Platforms) are the solution for this problem in many businesses. IQPs are environments designed to make it easy for quants to write, share, and release code; access the data they need; and build and run the tools that feed the business.

 

How to Get Frustrated when Scaling a Quant Team

Quants love solving problems quickly: noodling a real-world scenario into a model and wrapping up that model in a tool that advances the business is a real rush.

And like all developers, quants love writing code from scratch: a green field always stokes the imagination with plans for the beautiful structures you can build in your favorite language.

Quant groups start out like this: a few smart people solving problems for their business by each one building their own bespoke suite of tools and analytics. They deliver a lot of results without a lot of investment, and businesses are eager to grow the team.

This is when things can start to go wrong.

Unless quants have tools and management that push them to collaborate and re-use code they will typically build a heterogeneous environment of components that do not easily work together. This state is frustrating for quants because it takes them longer to get things done as the various piles expand and interact with each other. It is also discouraging for management as costs grow quickly and the pace of delivery and innovation drops dramatically.

As quant teams grow they also butt up against the rest of the organization – particularly the technology group. To scale efficiently, quants and technologists need the right tools to work together or bureaucracy and internal politics will accrue at the interface.

A common, but inefficient, structure that arises out of such an environment is one where quants only write research papers and pseudo-code which they hand off to the technology organization to implement and support. This results in business users and executives complaining that the quants are “too academic” and do not understand the commercial nature of the business. This is often true when quants have been shunted into a role where they rarely interact with the people using their work to make money.

Another variation is one where quants build only low-level libraries containing their models which they deliver to technology to integrate with the production tools. This setup sometimes works but often leads to significant bureaucracy around who supports what, as well as finger-pointing when things go wrong or problems take too long to solve. And it still keeps the quants away from their end users.

The Right Tools for the Job

The right platform for quants is one that makes it easy for average developers to deliver useful results at an institutional scale with a minimum of bureaucracy. The details depend on the specific business, but any IQP will need most of the following:

  • Version control. Using a single, shared version control system (VCS) is one of the key tenets of good institutional development. Choose one and force everyone to use it.

  • One (or two, or maybe three) common language(s). A common language means everyone can use the same tools and build on the same shared code base. There may be more than one common language: for example, Python for high-level development and C++ for computationally-intensive analytics; or R for statistical analyses and Python to glue the analytics together. Choosing a common language is often the most contentious decision when choosing an IQP, but also the most important to being able to scale a quant team.

  • Data interfaces. Quants should not need to remember which SQL database contains which subset of data they need – the IQP should provide interfaces that make it easy for them to get all the data they need.

  • Reference models. There should be one right way of accessing a particular kind of analytics – for example, a particular financial instrument. Those reference models should be available for all the quants in the team to use and extend.

  • A job scheduler. Building a job scheduler into your IQP lets your quants easily automate common tasks and focus on building the next great thing. Without a job scheduler your quants will waste time managing workflows manually.

  • A grid scheduler. “Grid computing” means running calculations in parallel on many different computers, and most institutional quant problems can benefit from large-scale parallel computing. A grid scheduler is a service that manages the grid compute infrastructure and figures out which tasks to run when and on which unit of compute.

  • An application framework. The best models in the world are worth nothing if the business people who need the results cannot get at them. If an IQP lacks a way to build applications it will end up demoted to an analytics service – with the concomitant organizational problems around managing interactions between the service and the end-user applications that use it.

In this model quants own the entire stack: the low-level analytics all the way through the tools used by business people. They talk to their end users every day, quickly iterating their product as they get feedback, and they have to support the code they write. It keeps quants commercial because they work at the commercial edge of the business with no other group between them and their users.

Giving quants the whole stack only works if the platform is robust and recognizes that quants are usually average developers, not superstars. A good IQP is designed with that constraint in mind: the platform developers solve the hard technology problems on behalf of the quants.

Controls and Security

Most institutions have constraints on technology implementation, whether imposed by outside regulators or by internal control functions. The details depend on the industry, the type of company, and where the business operates, but the big picture is the same: access to production data needs to be controlled and monitored, and changing code in production needs appropriate approvals before the changes are made plus the ability to audit changes after the fact.

As both a development platform and a production environment, any IQP needs to adhere to its institution’s control requirements.

Satisfying these control requirements can be done two ways: through manual workflows, where humans mediate the process of code release and approvals; or by having the IQP itself enforce the workflows through automated tools. The latter results in cost savings, less bureaucracy, and faster and more efficient releases.

Security goes hand in hand with controls as a mitigant to technology risk. An IQP must deliver an entitlements system that defines appropriate roles in the organization and controls on data access that respect those roles. The IQP must also protect data from access outside the platform itself, whether that data is raw input data or generated as the result of analytics reporting or tools.

Building a secure IQP is a significant challenge and security concerns should be front and center at the inception of the platform. Bolting security onto an existing platform is very hard and often fails in the worst way: you do not find out that a problem exists until it is too late.

IQPs: a History at Investment Banks

IQPs have been developed in several different industries, but the one I know best is the sell side of the financial markets: market-making desks at investment banks.

The earliest example of a full-featured IQP is SecDB at Goldman Sachs. SecDB started as a trading system for foreign exchange in 1991. When the designers built it, they built it as an IQP first, rather than a stand-alone application specific to foreign exchange. That choice meant that extending SecDB to other trading desks at the firm was relatively easy: a shared set of development and production tools already existed to build on, as well as a core set of financial data and objects. Over a decade and a half SecDB was rolled out to all the trading desks at the firm, as well as Goldman’s asset management and traditional investment banking businesses. It is still used across Goldman today and is remarkable for its longevity as a Wall Street trading system. SecDB uses an in-house interpreted language called Slang, as well as C++ for low-level analytics.

SecDB also contains a dependency graph that is core to its financial object models, and an integrated object-oriented database that persists its financial objects. Both of these are powerful tools for quants building financial models.

Bear Stearns’s FAST group started in 1985 and developed a quant platform focused on structured products that rolled out to many of Bear’s derivatives businesses. It continued on as an important system at JPMorgan after it integrated Bear in the wake of the 2008 credit crisis. Quants could write models in the FAST IQP and expose them in spreadsheets on trader desktops for pricing and structuring new deals, and those same models would be used in batch jobs for nightly risk and PNL runs.

Kirat Singh and I took the IQP model to JPMorgan in early 2006 and built Athena: a platform using Python and C++ as common languages and modernizing many of the architectural models first imagined in SecDB. In addition to being the first example of a SecDB-like IQP outside Goldman Sachs, it was the first large-scale Python project at a major investment bank. Athena continues to expand through JPMorgan’s businesses today.

Kirat Singh took the same model to Bank of America Merrill Lynch in 2010 and launched and delivered Quartz, a Python/C++-based IQP used by many thousands of developers across the bank. Quartz is the largest Python project on Wall Street in terms of number of developers and lines of code.

Beacon: a Cloud-Hosted IQP

Kirat Singh and I co-founded Washington Square Technologies in May 2014 with the goal of building a licensable platform, and our Beacon IQP product was launched in January 2015.

In addition to implementing all the key components of an IQP, including a powerful dependency graph and an integrated object-oriented database, Beacon takes advantage of the modern generation of IaaS (infrastructure as a service) provided by cloud platforms such as Amazon’s AWS and Microsoft’s Azure, or by a local cloud in a client’s data center.

Beacon’s infrastructure services makes it very easy for our clients to manage their cloud-hosted hardware, adding or removing components through simple configuration changes that take effect in minutes. And Beacon’s grid scheduler is based on elastic compute: our services dynamically spin up and down compute resources to let our clients rent compute only when they need it.

Beacon’s Python development environment integrates modern IDE tools with an automated workflow tool for code release, ensuring that institutions can properly incorporate their internal control frameworks into the platform.

Beacon comes stocked with a full suite of reference financial models for most markets and financial products. Quants can start building their tools on top of that foundation very quickly without having to worry about building basic financial operations or market conventions, or integrating market data and reference data. Washington Square works with data vendors to host data – both real-time and historical – inside the platform, so that our clients can sign a license agreement with the vendor and immediately get access to the data, either directly or via Beacon’s financial objects.

Writing hosted web applications is easy with Beacon’s application development framework. This framework lets quants script user interfaces in Python and integrate with all Beacon’s compute services, then easily deploy those applications to their internal or external users. Clients can also write their own web applications natively in JavaScript and HTML5, then use Beacon to host the web applications as well as run the analytics behind the screen.

IQPs: Worth Doing Right

As you build your quant group you should think hard about how you set up your organization to make that effort successful: there are many traps scattered about the landscape that can reduce the effectiveness of your quants, as well as lead you into bureaucratic chaos and internal politics.

The environment in which your quants build and run their analytics and tools – your IQP – is part of the arsenal that, if constructed carefully, can help you avoid those traps.

Some large institutions choose to build an in-house IQP, which has benefits in terms of integrating with other internal systems. Vendor IQPs are another option that outsources the process of building the fundamental tools and financial models so that you do not need to reinvent the wheel.

Integrating an IQP with modern cloud-based IaaS and elastic compute is a very powerful cost-saving concept: you rent machines and compute as needed, without large fixed capital costs or long turnaround times associated with the traditional model of owning hardware in data centers.

Ultimately, the main focus for an IQP is to enable your quants to deliver great analytics and tools to the business users who turn them into money without having to be superstar developers and as well as superstar mathematicians. It is challenging, but this is one problem that has already been solved.

#iqp

Quant