Should hedge fund technologists panic about off-the-shelf systems?
If you're a software developer who works for a hedge fund, you might think you're onto a good thing. After all, hedge funds usually employ lots of software developers, because they use lots of proprietary software. However, what if it were possible to buy-in that software from elsewhere? That’s what ex Goldman’s executive director Bogdan Donca has planned. He’s offering systematic hedge funds an off-the-shelf product that will, in theory, mean they can fire most of their developers.
How realistic is this?
The ‘buy versus build’ argument has been around for almost as long as the computer. The advantages of buying software are obvious, which is why I’m writing this in an off-the-shelf word processing package rather than my own bespoke product. Because the development costs are spread over many users, it should be cheaper. Off-the-shelfsoftware is also likely to be more robust. Exposing it to external users requires testing to be more thorough, and bugs should be found more quickly. In many cases, it will be faster to implement than a product that has to be built from scratch.
But building your own software also has benefits. Most importantly, it can be customized to meet your exact requirements. You don’t have to buy a piece of ‘bloatware’ that offers far more functionality than you need, or buy something that only fulfills some of your requirements and has to be extended.
It can also be a lot of work to write APIs for external code so it works with your own code and code for other vendors. This isn’t work that many programmers enjoy: it’s dismissively known as ‘plumbing’. It will hard to attract and motivate top developers if they spend all day with their hands stuck down the metaphorical U-bend of someone else’s product. Finally, if you do find bugs in your own software then you can fix them yourself, rather than waiting for the vendor.
For all these reasons it can work out cheaper for hedge funds to build their own systems, particularly once they’ve factored-in licensing and integration costs for buying-in, versus up front and maintenance costs for in house builds. Naturally, developers are heavily biased towards building their own, because - hey - it’s more interesting than doing third party integration: a manifestation of the ‘not invented here’ syndrome.
Fundamentally, the decision about buy or build comes down to how specific the required software is, and how much effect it will have on your bottom line. Fund making the choice will need to ask questions like “Does this component meaningfully contribute to my strategy, or is it something that just needs doing? Can I get an edge by writing it myself? Is there an off the shelf version that is better than my proprietary solution?“
Sometimes it makes sense to buy part of the technology stack off-the-shelf. Let’s consider the typical stack for a systematic trading shop. Firstly, we’re going to need some historic data for testing potential strategies, and some live data for trading. We have to translate data coming in from different vendors, and save it into a master database. Software may also do some automated checks to see if any data needs cleaning. A lot of alternative data will need pre-processing to identify features suitable for testing, or perform matching against relevant securities.
This sort of service seems fairly commoditized, and therefore suitable for off-the-shelf software. Particularly with the growth in alternative data, funds are struggling to integrate many disparate sources, so intermediaries have popped-up offering to deliver many types of pre-processed data through a single API. This isn’t an entirely new business; Bloomberg and other firms have offered consolidated data for many years.
Now we’re ready to develop some strategies, for which we need a back-testing environment. This will allow a researcher to create a hypothetical strategy, test its performance against historic data, and calibrate any parameters. I would say that the back testing environment is the hardest to build off-the-shelf, for a number of reasons.
Firstly, there is a lot of variation in the strategies that funds use, and in the design of those strategies. Could a single back-testing platform cope with equity long-short, stat-arb ETF pairs trading, and delta hedged options; to name but a few? Even for a given trading style, there are considerable variations. I can think of several funds in the managed futures space, where I used to work, that use completely different methods to construct their portfolios. It would be a struggle to write a single back-tester that they could all use.
Also, by definition, researchers are seeking innovative strategies. Unless they’re just variations on an existing theme, some changes will need to be made to the back tester. Because of the fluid nature of the research process, that is very hard to do unless the developer is working closely with the researcher (or they’re the same person).
Most researchers also dislike ‘plug and play’ software. They like to control the back-testing process through hand coding their own algos. Even when a back-testing platform is built in house, you find sporadic outbreaks of personal code libraries which implement functionality that is absent from the ‘official’ software, or where the researcher just doesn’t like the provided API or methodology.
Next we’re going to need a live trading platform. The platform will suck-in live data, make decisions, and execute trades. A robust trading platform will also include monitoring and checking processes to ensure nothing goes wrong. As a result, only a tiny percentage of the code on the platform will implement the strategy. Much of the rest is fairly vanilla, and could potentially be covered by third party software. In fact, for many funds outside of the high frequency space, it’s already common practice to farm out your execution to sell-side algos.
However, there is the issue of deployment security to consider. There is clearly considerable business risk if you are using someone else’s software as a cloud product or on their co-located servers, and this should be avoided unless the all important kernel of secret strategy code is properly secured. You will feel more relaxed if it’s running on servers that you control, but there is always the possibility that your secrets are being secretly leaked by third party software unless you have carefully isolated it.
I haven’t discussed many of the other packages that a hedge fund will typically use, including pricing libraries, risk management tools, and back office accounting software. Although in the past these were also bespoke, third party packages are becoming increasingly common. Much of this is because of standardization driven by regulatory requirements.
On balance, I think there are places when off-the-shelf software can make sense for quant hedge funds. This is especially true for smaller funds, without the headcount to develop their own bespoke stack. But I think larger funds will continue to develop much of their own core platform. Any hedge fund technologists reading this can probably stop panicking now.
Robert Carver is the author of 'Systematic Trading', 'Smart Portfolios' and ‘Leveraged Trading’. He is a former derivatives trader a, and former head of fixed income at quantitative hedge fund AHL, where he used mostly used proprietary in house software. Robert now manages his own money using systematic trading strategies, and still thinks (probably incorrectly!) that the trading software he has written himself is better than anything he could buy.