Cantab Capital is one of Europe’s leading managed futures firms. Dr. Tom Howat is a Senior Scientist and one of seven partners at the Cambridge-based money manager. Here he talks to Hedge Fund Insight’s Publisher Simon Kerr about his experience of working there.
Q. (Simon Kerr) Tom, Can you tell me about when you joined Cantab?
A. (Tom Howat) I joined Sept 1st in 2006, and we started trading March 1st 2007. We spent 6 months on development and testing of the systems. I ended up writing the infrastructure for Cantab Capital, and this is one of our points of difference. Our architecture is different from our peer group in that we have distributed processes.
I had always been interested in software development, even as a kid. I had studied computer science at school, and had done some programming in Summer intern jobs. I went on to do the Maths Tripos at a college (Trinity College) in Cambridge. I picked up some of the disciplines of programming on the way. Even a small company needs to have a very disciplined institutional software development environment. This is a “source control” environment – we know who has used what and where and when.
Q. That sounds very controlled.
A. The discipline is important.
For example our code is tested on 32-bit and 64-bit systems, on both Linux and Microsoft operating systems. So the routines have to work independently of the platform they are run on. We have a similar mindset when it comes to (investment) strategies – a regression test in which strategy A produced result B yesterday has to produce exactly the same result today. When strategies tested on 20 years of data yesterday produced a specific result, adding another day’s data should not change that result.
Q. What other development disciplines do you have?
A. A lot of software design is about encapsulation, that is ensuring that it gives a solution to a specific problem. It should not do anything other than it is designed to do. It can be combined with other routines in a modular way to carry out a bigger, more complicated task.
One of our tenets is that if there is a parameter in our model we like to take it out. The more parameters you throw at a model the more it will contort itself to fit the data.
We plot the choice of parameter versus the quality of output. We are estimating the choice of parameter – so you need to know the error bars around the estimate. But there is no golden parameter given to us by the gods.
Q. To go up a level, how would you describe your culture of development?
A. We try to eliminate ownership in (investment) strategy development. Models are not owned by the people that create them. Rather the creators, like everyone else in development, tries to destroy the models. The environment we try to foster here is like a PhD research group, but even more collaborative.
Problems get recognised and we allocate them. We have design reviews – as interested members turn up they become an ad hoc project group on the problem. Someone could say “this has parallels to a problem we had in particle physics” and that person could join the group to work on the problem.
We don’t really distinguish between programmers and those on the quant-side when it comes to joining in a project. The distinction is somewhat artificial as we get examples where someone says “that is like a problem I had on my PhD , and I know how we might tackle that.” That person may be labelled a programmer but is coming with a mathematical solution. That happens because some of the problems the programmers face are complex mathematical problems.
Q. How do new staff members take this culture on board?
A. We don’t send people off on courses because that may distract them from our culture. We assign projects to new joiners once they have got up to speed on financial markets. We ask them “which of these tasks interest you?” As they become assimilated into the culture of the firm, it becomes more clear to them how they can contribute and add value to our systems.
They go from being led to being self-motivated. That attribute, being self motivated, is essentially what we look for in our candidates, and doing a PhD points towards that. Not that it is a requirement to have a Ph.D, but that experience of guiding your own research over 3 or 4 years to get to the end-point makes a person well prepared to thrive in this environment.
In general we encourage people to find out for themselves what would be useful for them to do, rather than allocate work. Anyone can contribute to idea generation for the models or the implementation side – it can be a database design, or an algorithm for allocation. We will all get together and talk about it.
We do have some people who are pure programmers, maybe with a computer science background, they may not be as involved in the strategy development as some of the others.
Q. What do you like about working at Cantab Capital?
A. I can think of three things why I like working here – the firm’s culture, I like the rigour we have here, and the technology. We don’t take decisions on a whim or gut feel. I like that we use a scientific method. And having done post-graduate mathematics it is great to be applying mathematics in your work. The third thing I like is the access to great computing resources –that allows us to reach our full potential when attacking problems.
We like to say we are a software technology firm that applies itself to finance. We see the firm as “the cathedral of software”. We build components, we test those components and we build a huge infrastructure from those components. That infrastructure controls almost everything about the company. And almost all of that infrastructure is software. The model of how a market works still has to be tested and implemented, and a lot of the added-value is in the implementation. That is why concerns over the intellectual capital in the models can be overstated – the added-value is more in how the models are put to work in practice.
Q. How much of the software are you using now was written more than, say, 2 or 3 years ago?
A. The non-changing elements are the systems structure or architecture, which goes back to 2007, and most of the components are the same. The component that manages a particular fund is the same in the way it behaves as when it was introduced. There are two components that can and do change – the ways to allocate risk among strategies (weighting algorithms), and the strategies themselves. Those both go through very rigorous development processes, taking 3-4 months.
It is difficult to get new signal generation capability into the production model. You have to look not just at the model in isolation, but the impact on the whole portfolio with and without the model.
We look carefully at the new and the old way: we look carefully at each of the old strategies. We have the thought-experiment of taking out the existing strategies and looking at them as if they were new. We ask ourselves “Would they get into the production model as they are?”
When we come up with a new strategy we want to run live we can slot it in easily to the existing systems: the risk allocation system will assign it some risk; the new strategy will consume real-time data to generate signals, and from that positions will be proposed and combined with positions from other strategies and the list of trades will go for execution. The researchers at Cantab Capital need only focus on the strategy – all those other elements are taken care of – so researchers’ time is really freed to carry out research.
Q. Leda Braga of Systematica has been quoted as saying that the sizing and weighting of positions can add more value than signal generation. Would you agree with that?
A. A weighting algorithm is like a meta-strategy, and so a distinction between trading strategies and weighting algorithms is a somewhat artificial distinction. The key to it (medium term investment success) is the extent of diversification you build into the portfolios.
Pure trend-followers have had some tough years since the Credit Crunch – which is why we prefer our more diversified approach. The underlying concept of a CTA is a commonplace.
Q. How do you separate programming and the mathematics parts of what you do at Cantab?
A. Everyone has to program here, because that is the only way that you can talk to our systems. We are not the kind of shop where if you are a quant you give your work to a specialist (a programmer) to program. If you want to interact with systems here you have to be able to program. So whilst it is not a condition to have a Ph.D to work here, it is a pre-condition that if you want to work here you have to be able to program. I use more of the programming skills I learned than the maths.
I spend most of my time either programming or designing. In the designing work it may be working on a problem and deciding how we are going to address it – getting the right group of people together to be the project team, and deciding how we are going to divide up the parts.
Although I get involved in implementing investment strategies, the implementation of weighting algorithms, and in execution algorithms, I get more involved in the enabling part – the infrastructure that facilitates that. So, for example, we may be implementing a strategy that requires us to calculate a risk measure in real time, and if we do not currently do that I may have to find a way to make those calculations.
The principal we use is that implementations should be as simple as possible whilst being effective. Over-engineering is a trap that people commonly fall into. You want to neither paint yourself into a corner through being very specific, nor solve all the future problems at the beginning. A lack of vision at the beginning can cause problems two years down the line in the kind of work I am talking about.
Q. Can you give an example of the kind of projects you get involved in?
A. We have been very interested in improving our execution capability. For example, one of the things we were tackling a few years ago was the means of implementation of large trades. Say in interest rate futures where there is large touch size, the question we have been asking is “is it better to join in the bid or offer in our (full order) size and let the market work its way through one large order, or break it down at the outset and feed a series of smaller orders into the market?” And what we always do in circumstances like this is to go to our historical data (which includes full order book quotes on exchanges, not just the best bid/offer price) and run an experiment. The concept is back-tested and then run in the actual trading systems on a small slice of the real order flows we generate.
The generalised capability we have is to switch on Parameter A in our execution systems and record the outcomes. The we can look back at how we did with A switched on and not switched on. In general it is very difficult to always gather sufficient data. So say we look at algorithms to help with tail-risk – even with all the data we have there will not be enough observations of extreme market events to be as rigorous as we would like. Our guiding principal is that we don’t want to jump to conclusions, we want our statistics to tell us what to do.
Q. That seems like a good point on which to stop – thank you Tom.
Related articles: