For years, strategic discussions concerning financial trading technology have centred on one burning question: build or buy. Depending on the nature of a firm, its market position, its customer base, its culture and ethos and its core competencies, there inevitably would be a range of pros and cons on both sides of the divide. In theory, firms just needed to add them all up and see which side had the most pros, the fewest cons and ultimately delivered the best ROI.
Strategic decision-making is rarely that simple, of course. But what if the whole premise of buy-or-build could be called into question? What if the keyword wasn’t ‘buy’ or ‘build’ but was ‘or’ – and what if it could be replaced with ‘and’? Some firms are now learning that there is a way to think beyond the binary either/or framework and realise the advantage of both approaches.
The reason why this has become possible comes down to what some people describe as an app revolution. The fact is, technology at almost every level and in every industry is becoming more modular and driven by the proliferation of APIs.
What that means in the financial industry is that decisions on what to build or buy can be much more targeted. Firms can think about what technological tasks might offer a differentiator and can look to build only those, allocating their development resources towards solving specific problems that will give them a competitive edge. Then, for more commoditised aspects of a trading system, they can buy in the necessary components.
What might fall under one category versus another? One way to think about it is to consider the parts of a trading system that involves unique decision-making.
Where to send orders, where to find liquidity, what trading strategies to employ, what percentage to route to dark venues, how best to slice and dice – the parts of a trading system that make those decisions are the ones that stand the best chance of creating a differentiator by ensuring clients are successful. If you can offer your own distinct flavour of algorithms or trade routing software, you may be able to lay claim to an audience that others can’t.
Meanwhile, for more routine parts of a system, why not leverage the work that others have already done by taking a component-based approach rather than devoting scarce resources to building it yourself? Take feed handlers, for instance. There are certainly qualitative differences to be found in feed handlers, but for the vast majority of trading firms, the complexity and on-going maintenance of building one in-house would rarely make sense.
Firms thus don’t need to worry about time to market on those “buy” components, leading to shorter times to market for the “build” components too because developers will have fewer tasks to take on.
The attraction of a build-and-buy strategy for developing trading systems is even greater when you consider broader trends in financial technology. Think back 10 years and the main differentiator for trading systems was usually latency. Now, firms can buy lower latency, they don’t need to build for it.
The net result is that the unique differentiator nowadays tend to be factors of the execution strategy itself rather than just exclusively being about speed. A build-and-buy approach lends itself perfectly to this environment. And there is the added benefit that firms are less likely to be locked into 10+ year technology approaches because APIs can allow for easy integration, enabling components to be easily swapped out, to create interoperability and more open platforms.
It’s as if development teams are being presented with a large technology menu that they can pick and choose from, but at the same time, they still have the option to go into the kitchen and cook up something entirely different too. Whether firms like to cook or order à la carte, they no longer have to choose between the two. That makes everything a lot more strategically appetising.