Featured post

Fixed Income Trading: New venues

A simple question came up recently in a conversation – how many new Fixed Income trading venues are there?  I could not think of anywhere th...

Wednesday, 5 March 2014

What's the difference between an EMS and an OMS?

Suggestion: it’s directional, asset-class and/or execution style related…
If you got here from google - try also OMS and EMS

An OMS looks inwards – it links to investment book of record, benchmark systems, mandate tracking systems and other internal applications within the buy-side.  It also handles multiple asset classes and multiple execution styles. An OMS is typically a “big” system with a long search and selection, procurement and implementation cycle.  It common for an OMS to take 6-24 months to implement and to never reach a steady state as requirements will change during implementation which means that the implementation extends to a permanent change model.

See also The buy-side OMS, an appreciation part one...
and The buy-side OMS, an appreciation part two...

An EMS looks outwards – to allow a buy-side to trade in the markets.  Typically buy-side EMS systems will have two logical interfaces – one for market data and one for orders/executions.  It typically handles one or two asset classes.  So traditional exchange traded productions such as equities, options, futures are generally covered by one category of EMS and traditionally non-exchange traded products such as foreign exchange and fixed income are covered by further categories of EMS.  An EMS can typically be implemented on-top of an OMS in a short period of time – between two and eight weeks.

However, this model of deployment can be flawed, since restrictions on execution counterparties are not typically transmitted from OMS to EMS.  So, an order may be restricted by mandate to only execute with a sub-set of brokers that are configured in the OMS.  The EMS will typically come from another vendor and may not have access to the same restrictions database.  There have been various solutions proposed to this – such as custom FIX messages to pass restrictions at run-time to the EMS from the OMS, re-keying of restrictions into the EMS or event driven data distribution platforms to pass restriction data in real-time to the EMS.  All of these models have flaws.  This lack of integration will be covered in a future blog post [updated - Buy-side trading: OMS and EMS integration]

The recent legislative changes of Dodd-Frank and suchlike do mean that some traditionally non-exchange traded products are now moving to trade on Swaps Execution Facilities (SEFs).  Since a SEF looks rather like an exchange there is an interesting cross-fertilisation of traditional exchange traded technology solutions into the traditionally non-exchange traded technology arena. 

In a typical large multi-asset class buy-side there will usually be one OMS connected to many EMS platforms.  So an instance of an OMS such as Thinkfolio, Charles River or LatentZero will connect to
What this means for a large buy-side is that there is not just connectivity from an OMS out via FIX to brokers since there is also a range of connectivity out to diverse EMS platforms.  This diversity means that any firm that claims to manage outsourced buy-side connectivity will face the problem that the range of workflows becomes hard to manage – not just order/execution as with equities but also streams of f/x rates and RFQ based workflow. 
Once you add into that the mess of setup required to actually use a multi-bank-platform for FX trading you start to see that the possibilities for true connectivity outsourcing in a large, diverse footprint buy-side is horribly limited.

There are initiatives in the FIX world that would assist such as TESI but, at time of writing, TESI is not live anywhere. 

So how do you get this all working in a robust, reliable, low-cost manner?

No comments:

Post a Comment