It’s always tempting to do everything yourself. After all, it’s easy to think I know best. I once tried to make macarons. Once my uneven mess of macarons emerged from the oven, I had a much better understanding of what motivated people to buy macarons from Pierre Hermes. Subsequent attempts at baking them proved more successful. However, even after quite a few attempts, I had to admit to myself that my core expertise was eating macarons, rather than making them.
At the start of any big quant project, the immediate question that any quant gets from management is, should we build this project in house or could we buy it externally? I’m not talking about stuff like operating systems or attempting to create a new computer language, which are outside the domain expertise of a quant. If any quant suggests writing a computer language to solve a particular project, please run a mile.. writing a good compiler is not something you can do without a lot of work and is very much a specific skill. Instead, it’s more about stuff related to quant models.
I think most quants (including myself) would often think of first building a quant tool internally. However, in practice, the decision to build or buy isn’t always easy. There are numerous pros and cons, when it comes to building quant tools internally, which we list below.
Pros of build
- get all the source code, so can modify and customise exactly as you want
- leverage internal development expertise you already have
Cons of build
- many projects end up being data engineering heavy, rather than data science/quant focused
- hence development time and cost end up being much more than expected
- the real killer cost is maintenance, which grows year after year, in particular when the original developers have left
- you will keep the trading desk waiting years for the development of the quant tool
So if building a quant tool isn’t always the perfect approach, what about the idea of buying from an external vendor? What about the pros and cons of buying existing quant based tools. What do you have to weigh up in this case?
Pros of buy
- ready made solution, so can use quickly, rather than making a trading desk wait for years before deploying
- relatively easy to setup, doesn’t require as much development expertise
Cons of buy
- don’t get access to source code, so can’t leverage internal expertise to customise, and vendors will not modify the solution easily (without a large cost!)
- you have to adapt to the product, not the other way round
- external services often require you to send out your data, and maybe you’d prefer to keep that private (especially trade data, which is very valuable)
As we’ve seen there are pros and cons to both build and buy, when it comes to quant tools. So what about an another approach which can combine the best of both, a hybrid approach? In this hybrid case, financial firms can use an external vendor. However the deliverable is not an external service, but instead actual source code, which can be run locally.
Pros of hybrid
- get access to all the source code
- leverage internal quants to modify or customise the code, focusing on adding value on the important business logic, which is the precise expertise of a quant
- can commission the vendor to make modifications if required to later, especially in the parts of the code not related to business logic
- run internally and keep your valuable data private (sending out sensitive data requires a lot of extra compliance safeguards)
- get external technical support to help with maintenance burden
- much, much cheaper than developing in house
- spend time adding domain specific enhancements, rather than rebuilding the wheel on data engineering problems
- and most important of all, you can deploy quickly, so your trading desk will be happy!
Cons of hybrid
- not always available for every quant tool, because not all vendors will offer their products on this basis
I’ve created a transaction cost analysis library in Python, tcapy, and I’m offering clients the full source code and allowing them to run it locally, essentially adopting this hybrid approach, giving the clients the best of build and buy approaches. Also knowing that my source code is being scrutinised by clients (already have my first client for tcapy), means that it enforces additional discipline to make sure the software is designed well, and properly commented. If no one is going to look at your code, it can be tempting to make to make it that bit more cryptic. Clients get maximum transparency in the process.
Of course for a vendor it is more difficult to give out source code, so there do need to be various NDAs in place. However, ultimately, it will result in a better client experience, and that is what a vendor should be striving for. If you’re interested in chatting about my tcapy solution, or indeed about build/buy dilemmas you may be facing in your quant business, feel free to drop me an e-mail at saeed@cuemacro.com