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...

Sunday, 8 May 2016

EMS: Staging is not an EMS

Within the world of Fixed Income trading there is some dispute around what constitutes an EMS.  My view is that the buy-side Fixed Income EMS is a product that sophisticated buy-sides would love, but which does not exist.

Let's look at the current model of a buy-side OMS connecting to an incumbent execution venue.  Take your pick, they all work in a similar manner...
 
 

So we see a buy-side OMS connecting to the Execution Venue deployed UX which then connects to the Execution Venue and hence to the banks with which you trade.
 
Realistically this will not be an accurate representation of the world of a sophisticated buy-side - instead it's more likely to look like this:

Again, this is a simplification - each venue has a list of banks - see If not banks, then who? for a list for a small subset of venues.  But as we know, the number of venues is increasing - Fixed Income Trading: New venues.   We've covered this topic before - Buy-side desktop real-estate in a new Fixed Income world??  covers the problem that the buy-side appears to be moving to a world where each buy-side trader is expected to have multiple execution-venue specific applications each of which has a learning curve, login/password, desktop installation, training, legal agreements and a mountain of overhead.
 
A further problem is that there is an invalid "funnel" of data.  The Execution Venue deployed UX will show streaming data for RFQ and RFS where available, but that data cannot be readily captured by the buy-side.
 
BUT - capturing that granular data is core to the buy-side mission of providing verifiable best execution - again, we've covered that on this blog here Buy-side analytics: FI BestEx and RFQ Broker selection
 
This can all be linked to what we proposed in 2008: Fixed Income Trading: Buy-side desk of the near future?.  All of which would be linked together using FIX and preferably FIX Orchestra
 
And that future state model looks something like this:
 

 
 

4 comments:

  1. In terms of Buy Side Analytics, we need the FIX protocol to enforce the addition of the screen price before the RFQ is returned... as to compute the slippage (how much the real price deteriorates from the screen price) and start making statistics about the Banks

    ReplyDelete
  2. In terms of Buy Side Analytics, we need the FIX protocol to enforce the addition of the screen price before the RFQ is returned... as to compute the slippage (how much the real price deteriorates from the screen price) and start making statistics about the Banks

    ReplyDelete
    Replies
    1. While I understand your point, I don't agree. Your proposal is one way to do this, but there are many ways to look at arrival price/implementation shortfall analytics for a decent size buy-side...

      Delete
  3. arrival price/implementation shortfall belongs to the listed world to me.

    ReplyDelete