Previous posts, here, here and here have covered the OMS and EMS world but never the integrated OEMS, a deficit I will cover today. Firstly, the name. OEMS stands for “Order and Execution Management System”. As mentioned, an OMS is inwards looking and an EMS outwards looking. So why merge them into one application and how is that done?
In the mid to late 2000s there were two main pushes into the then nascent OEMS market:
(1) OMS vendors incrementally adding EMS functionality and/or acquiring an EMS vendor and integrating the product
(2) EMS vendors incrementally adding OMS functionality and/or acquiring an OMS vendor and integrating the product
In the first category most of the buy-side OMS vendors tried this strategy. They pretty much all did not hit the heights to which they aspired. Why? They had a number of severe problems:
(a) Technical platform
(b) No real market data distribution backbone integration
(c) Lack of the budget to compete with the true EMS vendors.
(d) Most importantly, of those firms that travelled this path they approached this with an equity workflow mindset of orders and executions.
Let’s look at these issues in turn, starting with the technical platform. In order to maintain “state” the majority of buy-side OMS platforms had a single threaded main process that processed every request to update a position. This single thread would rapidly become the rate-determining-step in performance of the system. Once connected to brokers and receiving regular order executions this thread would take on more load. Change the game to include FIX connected algorithmic trading with a vast step up in execution volume and it’s clear that a single thread would become overloaded. Without extensive, very expensive redesign this kills the system. Since buy-side OMS vendors are not noted for a desire to engage in expensive, extensive redesign there were workarounds and limitations built into the systems.
An EMS is powered by market data – it’s a substantial part of the value proposition. But proper market data distribution typically involves a combined hardware and software solution. At a very high level, different network segments to transport market data as opposed to email, regular files sharing and other applications. This requires a degree of network engineering that is not generally within the scope of buy-side asset management firms. As such, horribly compromised market data distribution has been used such as desktop integrations with Bloomberg and Reuters. Why is this horribly compromised? Once you have real-time data only distributed to the desktop you have to conduct any dependent calculations (such as real-time position value calculation or real-time profit-and-loss) on the desktop. As such, the desktop is being used a surrogate for the server and users will soon see performance problems – the canonical example being when loading up a large portfolio for real-time position keeping results in the underlying hardware groaning under the load and performing terribly. The average user of a buy-side OMS will simply try this and give up.
Lack of budget was a large source of problems. Building any decent software package generally costs more than people think. The EMS vendors in many cases were used to getting sell-sides to pay for the technology in order to gain distribution. That business model is beautifully simple – a buy-side requests to have twenty banks connected to an EMS and the EMS vendor then charges each bank an access fee per month. Once the EMS vendor has built up the initial set of connections the marginal revenue vastly exceeds the marginal cost, so there’s a natural tendency to go for scale quickly. Breaking into a market like that against incumbents is always tough. Why? The EMS vendor can effectively give the software away to the buy-side for free and make the money from the sell-side. The buy-side vendor, without that sort of revenue base is hamstrung from the start.
The equity mindset condemned buy-side OMS vendors to remaining trapped in the single asset class silo of equities. The reality was that buy-side OMS vendors approached the banks and offered to integrate the banks equity trading algorithms into the buy-side OMS. That sounds like a match made in heaven – banks wanted algorithmic trading distribution to drive market share and so paid OMS vendors to get onto the OMS. But the reality was that both sides of the trade – bank and OMS provider – was sadly missing the point. The sell-sides expected quick results but the buy-sides that managed the insourced OMS had no real incentive to conduct the fairly substantial work needed to upgrade their systems to gain access to the algorithms. Banks paid good money and received little incremental revenue. This model only really worked when the buy-side OMS vendor could push upgrades to the buy-side users quickly. But the revenue model of the buy-side OMS vendors was fatally flawed – upgrades rapidly became a necessary source of revenue in order to keep expensive professional services staff generating revenue rather than becoming a liability. As such, buy-side users of OMS platforms rapidly become almost fatally averse to upgrades since they became big, expensive and painstaking projects with very little gain to the buy-side.
An example of an OMS vendor acquiring an EMS was the spin-out from Convergex of Eze and Real Tick alongside the acquisition of Tradar. The covers a stack of
- Portfolio Management - Tradar
- Order Management - Eze
- Execution Management - Real Tick
The problems of OMS vendor business models will be covered in a later post…
Let’s now look at the other side – EMS vendors making a play for OMS functionality.
I suggest the best example of this was the acquisition of Macgregor by ITG. This was mentioned in a previous post here. Macgregor itself was a firm with two systems – the Predator OODBMS based, US-equity centric system and the legacy Merrin platform. ITG acquired Macgregor and started to work on a plan. My understanding of this may be flawed but I believe the plan was to upgrade the ITG Triton EMS platform and rename to ITG TritonX. During this re-write the Macgregor functionality within Predator and Merrin would be unified into Macgregor XIP and that would be merged into ITG Triton, a single “one-system-to-rule-them-all” would emerge. That process started in 2006 but the 2008 financial crisis caused a chill wind to hit ITG. The TritonX project was drastically scaled back and I am not sure if it ever restarted. ITG has released new products in this space and appears to be in rude health so perhaps TritonX will make a comeback at some point?
A sad sidenote to that transaction can be seen in a detail in the press release linked above: "Bear, Stearns & Co. Inc. served as exclusive strategic advisors to Macgregor during this transaction."
An interesting announcement was made on this topic last year here with further details here – that Citadel Technologies (the technology arm of the hedge fund) and Redi Technologies (the old Redi business arm of Goldman Sachs, acquired from Spear, Leeds and Kellogg) would work together on an OEMS. The announcement in September 2013 is the last I can find on the internet. I expect that they are busy working on this.
Other EMS vendors not mentioned in this post have tried to build OMS platforms – I am aware of one that was quite interesting in technical design in user-interface terms and back-end technology but it suffered from a US-centric design that meant it was not able to work very well outside of the US market except with some bolt-on workflow modifications. Clearly that sort of flawed design is what an RFI/RFP/ITT cycle is supposed to catch and judging by the sales figures for this system I think it’s fair to say that the vendor was caught out in most cases.
So why would an OEMS as described above be ahead of it’s time?
Simply put – the drivers for buy-side IT in the period since 2008 can be categorised into some nice simple buckets:
(a) Cost Reduction
(b) Compliance
(c) Mandatory upgrades, security patching, operational risk driven work
So how does the post-2008 mood music fit an OEMS world?
Well, a genuinely integrated order management system with cross-asset execution management capability allows for a cost reduction in operational terms. How? No need to support a whole range of bolted-on asset class specific EMS platforms. Reduction in operational costs for management and configuration of all of the myriad of platforms. True STP – FIX based allocation workflow over every asset class rather than a mix of capabilities and gaps.
Compliance - well, an integrated compliance model with OMS and EMS having access to the same rules in real-time with no-second class data citizens and no polling or other ugliness would clearly improve conformance to compliance restrictions.
Finally - outsourcing this entire system (which I believe to be essential for successful delivery) means that all of this IT operational risk can be handled by experts rather than a generalist buy-side IT operation.
The challenges that could not be overcome in the past were, in large part, related to trying to solve the problem from the wrong starting point. The legacy technology, business models and equity-only mindset can be overcome from the right starting place. Citadel and Redi are clearly in the space – it would be good to see further entrants to bring competition to the market.
Comments
Post a Comment