As a provider of technology for the capital markets, STT partners with clients in various segments of the trading industry on both the buy side and sell side. We have seen the industry go through bull markets, bear markets, and multiple industry-wide trends such as high frequency trading, commission free trading, crypto, and everything in between.

Over the last several years we have noticed a gradual yet significant shift in how market participants are approaching their technology solutions for trading, order management, and risk and margin. Many established market participants have hired aggressively to build out their in-house technology teams, with the hope that this will help them optimize their strategies, control costs and bring new offerings to market more quickly.

With these resources at their disposal, it’s no surprise that a lot of these companies are reexamining how they answer the age-old “Do we buy, or do we build?” question.

It’s a valid question. Technology systems are complex, mission-critical and require hyper-specific expertise – so much so that a firm’s vision for an in-house build almost always ends up being delayed by months or even years. There are many factors that might tempt market participants to try to build proprietary solutions, but most are rooted in misconceptions and overly optimistic planning that can have a major negative impact on their business.

No one wants to be the first to use a complex system – but that’s exactly what firms building their own solutions are signing themselves up for. A firm building its own system is exceptionally exposed to key staff departure and therefore must over-hire to ensure business continuity. Finally, any new build carries with it a significant amount of project risk. Cost overruns and failed projects are common.

Today, we’d like to share what we’ve observed over the years about the ever-present buy vs. build question – and why, especially when it comes to areas as complex as order management and risk and margin systems, working with an established provider is a better choice.

Get Specific

Not all technology teams are created equal. Even veteran developers who have built their careers in financial services often lack the established footprint and granular expertise required to build, for example, an OMS or a risk and margin system.

In addition, technology and development are not typically the “core” business of a capital market participant. Staff turnover in these areas is high, which increases both project risk and operational risk for any in-house build.

For an OMS, capacity and throughput are essential. Standing up a system that routes orders for hundreds of trades a day is difficult enough, but building one that can scale and validate pre-trade margin to support millions of trades a day, with no drop-off in latency, is a far greater challenge – and too often, in-house developers confuse the two objectives. Many firms that choose to build a proprietary OMS or work with a third-party vendor that is not built to scale will find that their growth ultimately outpaces their technology, putting them right back where they started.

An OMS is largely a behind-the-scenes product, so end users will only notice it if it is not working well. Other than that, OMS functionality is opaque to end users – they tend to focus more on the parts of the system they can actually see.

Risk management adds additional challenges. The ability to handle complex pre-trade margin validations for each asset class in a timely way requires sophisticated programming skill and a mathematical understanding of complex risk concepts. Building an OMS and risk system in-house means traders are limited by the technology team’s knowledge and understanding of both risk and margin requirements. Building pre-trade margin checks requires substantial market knowledge, especially for complex options.

Designing a risk and margin system is daunting. It’s not only a technology challenge, but a mathematical one as well. The person leading the project needs to be a true subject matter expert, with risk management experience, finance and mathematical skills, and an expert understanding of technology. Risk systems perform huge volumes of risk calculations in real time, so advanced mathematical concepts and efficient code are needed to create viable offerings.

Of course, risk concepts evolve over time, requiring frequent modifications. We saw this dynamic play out during the meme stock period, when many firms’ risk management failed. Additionally, regulatory changes and changes in requirements from the exchanges can be technical and difficult to keep up with. It adds up to an environment in which frequent changes are needed, often in near real-time, a situation in which many firms will struggle to keep up.

The generalist developers that usually make up the technology teams at large financial institutions do many things well, but when it comes to order management, risk and margin, a higher level of expertise and intimate knowledge is required.

Don’t Underestimate

Of course, many companies know that these systems are highly complex and choose to continue with in-house builds anyway. But even with that awareness, firms are prone to underestimating how challenging these builds can be – and getting it wrong can create significant negative impacts on the whole of the business.

Even among very advanced firms, there is a history of projects that failed or went well over budget. There are many causes of this, including poor gathering or understanding of business requirements, inadequate design, poor system performance, staff turnover, incomplete systems and unrealistic expectations.

On the flipside, firms that buy a system can have the confidence that they are gaining access to a working solution, minimizing project risk. Even if additional development is needed -- such as the coding of a house risk policy, for example – this work is minor compared to building an entire system. It’s the equivalent of adding a closet to an existing house as opposed to building the entire house from the ground up.

The highly dynamic nature of today’s trading landscape adds to the risk. The markets evolve and systems need to as well – no system is ever really complete. A firm that started a project two years ago might be working toward something that is now completely out of step with today’s market realities, risk practices or compliance requirements. Firms that use in-house systems will always be chasing the next trend, as opposed to evolving alongside it.

Failure to account for these risks can cause knock-on effects, restricting a firm’s ability to grow due to late deliveries, or causing a crisis when a system goes down and the needed staff is not there.

Conclusion

So why do so many large firms still decide to build proprietary systems? Beyond underestimating the complexity, in-house technologists often find themselves conflicted by a sense of self-preservation. It can be difficult to recommend buying a 3rd party system when you have an in-house development team.

All companies face pressure to reduce costs, and many senior technologists view building in-house as a means of controlling costs and self-preservation. This logic falls down when you consider the economies of scale a technology firm realizes by building a single system that is used by multiple market participants. The cost of buying a vendor-supplied system is typically a fraction of building the system from scratch. As an analogy, think about the effort required to build a new car from scratch as opposed to just buying one from a dealer. Even if the two cars were similar, the car you built yourself would be much more expensive.

Internally built systems can suffer from performance issues and slower time to market. There are additional and ongoing costs as the system needs to continuously evolve to handle the many changes that take place throughout the year from both a regulatory and trading perspective. Many technologists have failed to grasp that a true outsourcing partner doesn’t replace you – it helps you do your job at an even higher level.

In reality, the buy-or-build question doesn’t need to have the same answer for every project at an enterprise. In-house developers can make significant contributions by focusing on areas that drive revenue and are unique to the firm, from client-facing applications to reporting systems to tools that empower marketing and sales. But order management, risk and margin are both more generic functionality as well as being on the extreme end of the complexity spectrum, making them among the worst candidates to handle internally. Even platforms can be considered somewhat generic, as they all have a trade entry screen and a position window, for example.

It all adds up to a strong case for partnering with a vendor that has been there and done that for infrastructure items such as OMS and risk.

We’ve already gone through connectivity and integration pain points, developed workarounds, honed our knowledge and been highly targeted in our hiring. We also are open to customization, enabling our clients to build things that make them unique atop a stable platform. We’ve built our company around the many factors that go into building systems for order management, and risk and margin, so that our clients don’t have to.

Interested in learning more? Drop us a line.