Fixed Income Trading: Buy-side desk of the near future?

There is a lot of talk about the current state of fixed income trading and this is something I have looked at on a number of previous occasions:Fixed Income Trading: New venues,
Back in 2008 I wrote:
"Buy-side EMS connects via pure FIX 4.4 to a limited number of brokers.  An RFS process starts to request two way quotes in size for a list of instruments that the firm is interested in.  These quotes are combined into a synthetic order book – such that the buy-side can see ‘market-depth’ for instruments of interest. The strength of this solution is that there is no longer a need to look at proprietary systems, the streamed quotes can be used for monitoring, it’s pure FIX, brokers can be plugged in or dropped without much fanfare.  The weakness is that the first buy-side to implement this may have to build the system.  Potentially it’s a very resource intensive system, depending on the number of quotes, brokers and instruments."
In 2008 I also wondered why Liquidnet were not in the Fixed Income space - I had seen the merits of their blotter scrape model for equities.  It took Liquidnet until March 2014 to actually make that change...
Anyway, I have been reading and hearing that some buy-sides are starting to look at making markets in Fixed Income instruments.  This is very interesting to me, since it's taking sell-side technology into the buy-side, which readers and/or clients will note is something I have been advocating for a number of years.  So, let's look at that idea....
In order to actually offer up a quote, a firm needs to be able to value the instrument in question.  Let's look at a nice simple market so we can strip this down to a simple set of requirements.  In Australia the convention is to use the 3 and 10 year bond futures to construct two risk free points.  These contracts are very liquid and are the benchmarks in the Australian market.  These points are then joined up to create a risk free curve (yes, I am keeping this very simple, so no need to tell me that no-one actually does it in this way).  So, if that's a risk free curve then if you want to value a 5 year bond there is some interpolation between 3 and 10 to get a hypothetical 5 year risk free rate. Imagine the firm has no axe in this name, no holding of the bond.
Now, apply a set of risk factors to the bond to work out what yield premium you need to achieve to account for the extra risk.  Add in the cost of carrying that bond (which is a non-trivial exercise), the cost of trading and so on and then you have a potential bid price.  Bear in mind that the bid price has to be at a particular size, so then issues around the liquidity available to the buy-side have to be covered - you don't want to make a market in a bond, get hit and then realise you are short of cash to actually buy the bonds.
On the other side, if you are creating an offer price then you need to look at what you can actually deliver to the market if someone lifts your offer.  Again, this requires understanding of the liquidity in the name, the holders of the bond, information from your securities finance (stock borrow/loan or repo) desk and so on.
So this requires, among many other things:
  1. Low latency real-time data from futures markets. So proper connections to the market rather than via a desktop API from a data aggregator.
  2. Fancy network technology to ensure that the data reaches the right servers quickly - so 40GigE, Solarflare, Mellanox, Napatech etc. network card.
  3. Packet capture technology to allow for non-invasive monitoring.
  4. High end servers to run compute.
  5. A tick database (such as kdb - others are available) to capture the real-time pricing data such that it can be analysed by quantitative analysts.
  6. A real-time position keeping system to understand the actual live positions - not a best guess while you wait for the custodian to come back to you.
  7. Access to futures markets to hedge.
  8. Access to ETF markets to hedge.
  9. Access to stock borrow/loan desks to deliver if a bond is sold that is not held.
  10. Quantitative analysts to construct the pricing models, validate and back-test them.
  11. Ability to deliver code changes into production in a hurry to resolve any issues
  12. Reactive, agile development capability
Now, I've worked with a number of investment banks, hedge funds  and real-money asset managers. In terms of this sort of capability, I have only ever seen this within investment banks and hedge funds. 
This is not due to some magical construct.  It's simple economics.  A bank that can make markets in bonds should be able to make money for the bank if they get this technology and business operation running sweetly.  A real-money asset manager would have to invest their own money to actually build this capability, then explain to their clients how they would somehow integrate a trading model with a traditional investment model.
I'm sure this could be done, but I would question the validity of the assumption that many firms can do this.  I think the only firms that could really do this sort of thing would be the 800lb gorillas.  So firms with more than $500 billion AUM, a sophisticated investment process and the ability to deliver complex, multi-dimensional IT projects to their business teams on-time, on-budget and on-scope.
What I could imagine is that some real-money asset managers will devote some of their portfolios to a more opportunistic model of buying bonds in the case of distressed sellers.  More like an old fashioned "Special Situations" fund on steroids.  Again, this will require some fancy technology but nothing like as much as above, rather more like my 2008 proposal.
Any real-money institutional asset management folks thinking of doing this? I'd love to chat...