Matching engine for corporate bonds?

Let's start with a brief description of a matching engine, what it does and one future direction.

 A very poor Wikipedia entry states:

"A matching engine is an algorithm that operates on an order book and matches and determines prices at which orders are matched."

 

In essence a matching engine is a piece of computer processing logic to which market participants send orders.  The matching engine receives the orders, processes them and attempts to match them.  A simple example:

• Broker A sends an order to Exchange L. The order is a limit order to buy Z number of equity K shares with a limit price of 154p.
• Broker B sends an order to Exchange L. The order is a limit order to sell X number of equity K shares with a limit price of 155p.

So, we have an order from broker A to buy shares in equity K with a maximum price to be paid of 154p.  At the same time we have an order from broker B to sell the same equity with a minimum price of 155p. 

 

At this time there is no trade possible, if the only seller wants 155 and the only buyer will only pay 154p there's no possible trade.

 

So, at the moment the market would be described on screen as something like:

 

 

Now, imagine that we have the following new orders:

• Broker D sends an order to Exchange L. The order is a limit order to buy F number of equity K shares with a limit price of 154p.
• Broker E sends an order to Exchange L. The order is a limit order to buy P number of equity K shares with a limit price of 153p.

So after these orders are received the market would be described on screen as something like:

 

 

We clearly still have no potential for any trades to happen.

 

So, now, let's throw something into the mix...

• Broker W sends an order to Exchange L. The order is a limit order to sell Q number of equity K shares with a limit price of 154p.

So after this order has been received the market would be described on screen as something like: 

 

 

Now, we have a seller who will sell for 154p and a buyer who will buy at 154.  So, let's trade...

 

Firstly, we have to establish the orders which should be matched off.  Here we have one order on the ask side for Q shares at 154 and two orders on the bid side for 154.  Since there's no reason for Z+F to be equal to Q a matching engine will have to establish which order is matched first.  The usual (but not only way) is to match on price and time priority.  Which is a fancier way of saying that the first order received by the exchange at any price level is the first one matched.  So Q will match again Z first and if Z is fully filled then any remaining order quantity will match again F.  If F is fully filled then the remaining quantity of Q-Z-F will sit on the order book until another matching order arrives on the buy-side.

 

Now, the whole narrative so far has been to look at matching.  So we are looking at the case where firms are buying and selling a particular instrument.  That could be an equity, an option, a future or anything else that is exchange traded on a central limit order book.  Essentially it's a specialised use case for a message based logic match routine. 

 

So far we have seen a price and time priority matching algorithm example.  There is also price and size priority matching which is used by ITG Posit.

 

In these cases the logic may vary but the inputs to the algorithm are orders for a specific instrument.  Typically the instrument will be identified by ISIN, Sedol, exchange specific mnemonic or ticker.  But in each case the algorithm looks at one instrument.

 

Why not widen this out?  This blog has looked at alternative models for exchanges before in a number of posts: 

• Google, robots.txt and the “Search for Liquidity”
• Bootstrapping, FIIDL and the mesh exchange
• Google, robots.txt and the “Search for Liquidity”: Fixed Income edition
• Project Neptune, MTFs, SEFs, the central limit order book for corporate bonds and the loch ness monster  

So, why not use matching engine that uses a non-binary logic at the order level?  Rather than matching on an ISIN, why not match on instrument attributes?  Let's take an example:

 

Look at the morningstar website for Vodafone:

 

 

 

If you look at the above data set you can see a degree of commonality between a number of the bonds - take for example the 1.25% of 26/09/2017 and the 1.625% of 20/03/2017.

 

If a portfolio manager wants exposure to the name, rather than explicitly requiring a bond, why not match on attributes such as issuer name (or LEI), duration, convexity, running yield, redemption yield, credit rating, outstanding issue amount, callable and so on...

 

Point is - stop matching being binary and make it more like the way google will match data based on a more complex algorithm.  This is not a revolutionary idea but it is one that could go some way towards providing relief to the liquidity issues affecting the corporate bond market.

 

Conclusion: More google, less binary...

And here's another engine...