The trading desk infrastructure of the future

As a recent Adox survey¹ confirmed, buy-side firms know they need to increase their OMS-EMS (Order Management System - Execution Management System) investments. The pressure from new regulations, new asset classes, tightening margins, and data challenges drives this need for them to stay competitive. However, they are struggling to find out what exactly these investments should be and how the resulting infrastructure should, optimally, look. An industry panel discussion recently hosted by SimCorp helped shed more light on the state of the industry and how to move forward.

In the late nineties, you had OMSs living next to EMSs in many firms, while others were trying to embed an EMS within their OMS, to varying degrees of success. Since most have preferred having external EMSs for specific purposes, many buy-side firms now have more than one EMS. A recent poll corroborated this trend when it was conducted during a buy-side industry panel session hosted by SimCorp and TradingScreen (TS) at the annual SimCorp North American User Summit (NAUS) in May 2018 (see Figure 1). The preference for external EMSs originates from a need for it to be fit for purpose; volume, connectivity, and data-wise, while the quest for instrument coverage specialization has caused the application of multiple EMSs within a single operation, resulting in none of these being used to full capacity. 

Figure 1: EMS model – preference and current setup

EMS model preference

Number of EMSs used in current setup

Results are based on a poll conducted at buy-side industry panel hosted by SimCorp and TradingScreen (TS) at the annual SimCorp North American User Summit (NAUS) in May 2018.

Most panel attendees also agreed that it lowers your operational risk to have your trading activity consolidated onto a single platform (See Figure 2). Otherwise, you’re dealing with lost information and workflow limitations to what can be communicated over FIX. As a consequence, a siloed effect is created between the OMS and EMS where you really need information on both systems to execute appropriately. So why, then, has this less than streamlined approach with an OMS and multiple EMSs continued for so long?

Figure 2: Would OMS-EMS consolidation reduce a firm's operational risk?

Results are based on a poll conducted at buy-side industry panel hosted by SimCorp and TradingScreen (TS) at the annual SimCorp North American User Summit (NAUS) in May 2018.

The OMS-EMS state of the industry

For many years, asset managers and/or the vendors that support them with technology solutions have been left to build connectivity to multiple venues, typically via FIX integration. This has come in the shape of FIX hubs, dark pools, fixed income platforms like Tradeweb, FX platforms, Bloomberg, and so on. Among the consequences of having a standard FIX connection built between the OMS and EMS, you have counterparty exposure not shared on the EMS, liquidity not visible in the EMS, and data not going back-and-forth because the focus is on order routing and executions - all of which ultimately translate into missed opportunities. 

Trying to combine an OMS and an EMS, however, does not come without disadvantages as they are designed for different purposes and have different capabilities. EMSs, in general, are highly scalable and focus on execution tools. An EMS is fit for purpose, which enables higher volumes, faster prices, and more transactions. Historically, each EMS is specialized in terms of asset class coverage and can handle more of the complex aspects of algorithmic trading or multi-legged trading for options, for example. In addition to utilizing investment-specific analytics, EMSs can typically also handle both pre- and post-trade cost analysis (TCA).

On the contrary, as Brent Rossum, CFA, Product Portfolio Manager for Front Office at SimCorp, stated during the panel discussion: “An OMS is built to handle things like pre- and post-trade compliance and counterparty exposures. This makes it more valuable when handling collateral-driven instruments like OTC within the order management suite since, in addition to counterparty exposures, you can do all the required counterparty checks and utilize the robust valuation and scrubbing tools that generally come standard due to the operational orientation of the product.”

Future trading desk infrastructure requirements

For a moment, let’s put aside the historic differences between OMSs and EMSs, and think about the set of requirements that need to be solved for in a solution that would help buy-side firms stay competitive. The high-level criteria list would look something like the following:

• Advanced execution capabilities
• Exposures, pre- and post-trade compliance and analysis, and TCA
• Global best-in-class multi-asset coverage and connectivity
• Broker independence for proper/uninfluenced price discovery
• Technologically advanced, stable/secure software, and single API for ease of use
• Fast and easy deployment (i.e. cloud-based) with an open architecture
• A central trade data repository for both regulatory and standard periodic reporting

So, now with an understanding of the historic differences and an idea of what the desired solution looks like, the question becomes how to best accomplish this?

Improved OMS-EMS communication is key
If there are advantages to still keeping OMSs and EMSs separate, how can the industry meet the above requirements which have so far not been possible to meet due to the inefficient communication that exists among the systems due to the standard FIX integration? If more focus were to be placed on improving the way these integrations work, it would certainly solve a lot of the challenges. However, there’s so much competition over share of wallet between the two types of platforms that software providers are losing site of their clients’ needs as a result.

There’s no good reason why an enhanced API that brings the two systems together can’t be built, no good reason why the trading data can’t be centralized, and no good reason why the transfer of data can’t be real-time and/or two-way. An API would allow the interface to represent a set of agreed-upon standards that enables the applications to continuously make requests and get data and/or functionality in return. If these improvements were made, better reporting of things like live counterparty exposure or compliance information, such as trade limits or positions held for collateral, would be achieved which would enable more advanced execution capabilities on behalf of clients. That’s not to say the process is simple, since different asset classes will still require different flows.

Providers must enable access to key data
The point is that providers need to make it easier for their clients to get certain pieces of key data regularly, such as:

• Beginning of day positions (for borrow names)
• Market analysis (liquidity aggregation tools),  
• Pre-trade market impact and risk analysis
• Cost analysis on a pre-trade basis
• Request for Quotes (RFQs)  

Some of the data can be two-way while other data would stay one-way, depending on what’s needed for each software product (OMS/EMS) to do what it does best. The shift in the buy side toward multi-asset coverage would make it ideal to find a multi-asset, centralized approach within the OMS world and a multi-asset, centralized approach within the EMS world, and bring the two together. This would allow clients to have the best of both worlds. Unnecessary duplications could, eventually, be eliminated. 

Required action from current providers

“To ensure success in sharing of key data, current providers need to change their approach, TradingScreen’s Quentin Limouzi, Chief Revenue Officer, commented on the panel and continued: “There needs to be a will to work together, above anything else. Removing the burden of enhancements and future integration headaches from the client is paramount, ensuring the most robust central trading desk available to the market. It’s a commitment to building and growing together. Having a deep, combined understanding of central activity workflows ultimately leads to tighter controls. The market needs to go beyond some firms being good at one thing and other firms good at others, taking the time to map it out and take the best of everything and bring it together. Keeping the communication open between the developed, mature, multi-asset OMSs and EMSs, all day long, is what’s needed.“ 

Limouzi added: “Broker restrictions are a perfect simple example of where if you don’t have that open communication and are relying on a once-a-day FIX connection, you will lose out on functionality on both sides. Pre-trade allocations, the shaping of the order, and live counterparty exposure simply can’t be achieved without a tight relationship in place that considers information like these restrictions.”

The unfortunate alternative, and what is still the reality in most cases, is that trades are being executed based on missing (thus bad) information. You can’t achieve best execution without having sufficient communication in place, not only because of operational risk but also because of regulatory risk. The buy side has a fiduciary responsibility to their investors and, given they have limited resources to spend on multiple partnerships and integrations, they seek efficiency. 

A situation where both OMS and EMS providers can offer best-in-class support for most asset classes, remain focused on what their solution was originally designed to do, and tightly align their efforts with one another in support of their client rather than competing, is the most innovative approach the market can take without compromising the nature and strengths of the two individual products.  “Where data transfer is involved, errors will eventually occur. The real test is how often this happens and how long it takes to rectify matters when they do,” said Rossum during the panel session. He went on to describe the example of a FIX message that goes out and has a problem – and asks how many points it would typically need to be pulled back from to remedy the situation. If OMS and EMS providers are committed to working with one another, both parties’ reputations should contractually be on the line when it comes to answering this question. 

Regarding such a combined support model, Limouzi stressed that: “Having a single point of contact representing the common solution will be a key success factor. Whenever breaks due to new functionality occur (i.e. new broker algorithms, liquidity venues, tools required by traders, etc.), the fixes and Quality Assurance (QA) on the client-specific workflows should be tested between the OMS and EMS before the client even sees it.” In other words, there should be a familiarity with the shared workflows that goes much deeper than standard FIX certification. The communication layer across both products needs to be there to institute the right processes for clients. The instrument types need to be considered as well. Futures can be different than options, and so on, in terms of how this communication layer will work, and should be coordinated accordingly when new instruments and strategies are considered.  

The OMS and EMS providers should look at the roadmap together and decide jointly, with clients as well, what the collective priorities should be. Joint roadmap efforts will be important to ensure the right product is enlisted at the right time.

What’s in store for the future?

It remains to be seen who will be able to effectively embrace this new way of thinking and of doing business together. Those are the ones that will stand out as the innovators that are finally solving the issues with which the buy side has struggled for over a decade. 

As future development progress is made and buy-side adoption of this form of advanced communication continues expanding to keep pace with firms’ growing business challenges, the current pricing models may need to be revisited. EMSs are typically sponsored by the street whereas OMSs are paid for by the buy side, but perhaps some form of combined pricing is something to consider to truly ensure joint commitment down the road.

It’s clear that progress will need to be iterative and, like any roadmap exercise, carefully prioritized. The industry panel at the SimCorp North American User Group Meeting was one of the first panels to discuss an alliance and communication model of this nature. A model that creates a combined infrastructure without merging or combining organizations (thus avoiding improper influence), and the path to success that was outlined seemed like a logical approach, entailing the following steps:

• Focusing on trading workflows and data first
• Expanding the API between OMSs and EMSs
• Enriching the existing real-time interface (more interoperability, more data consistency, and a centralized support model)

Overlaps in functionality will of course still exist and it would be unrealistic to think otherwise. What each firm is going to do/focus on should remain different (i.e., in its simplest terms, the OMS will hold the fill order and tell the trader what to do, the EMS will go out and look for the best/fastest way to fill it). The EMS can certainly crossover with the OMS and vice versa, but to summarize the point, they should stop trying to duplicate what the other already does better because that’s where the inefficiencies begin to come in. Many providers have yet to learn this lesson and are still unwilling to facilitate this level of connectivity and communication because they believe it limits their revenue potential. It’s the client, and subsequently their investors, that are suffering in the end and change is therefore inevitable.

1. Adox Research: ‘Follow the Money’ (2017).