Archive

Monthly Archives: January 2013

In the previous post I finished support for the two fundamental order types: market and limit. In this post I am going to add support for a bit more exotic one – pegged order. Supporting pegged order type is a bit more involved compared to order types we handled before. Therefore I’m going to tackle them in two posts. In this post I’m going to handle pegged order position in the order book. And in the following post I’m going to cross them with other orders. The complete source code for this and other posts in the series is available from my GitHub repo: https://github.com/prystupa/scala-cucumber-matching-engine.

Maintaining pegged orders in the order book

A pegged order is a limit order to buy or sell a stated amount of a security at a displayed price set to track the current bid or ask of the central order book. The description of pegged order by Euronext is given next, and I am going to use it as acceptance criteria to test-drive the implementation: “Peg orders are accepted in continuous trading phase if there is in the order book a best bid or offer on its side. This means that in case of empty order book the peg order is automatically rejected. On a non empty book, the peg order is displayed at the best limit price in the market sheet. In case of an executable incoming order, the Peg order can be updated only if the new best limit is displayed in the order book (after the transaction). In case of a priced Peg order (set with a limit price), the order continues pegging until the display price meets the limit price specified. If the best limit of the order book disappears (following a cancellation or an execution), and the order book is suddenly empty, peg orders are automatically eliminated.”

Lets add a model to represent this new order type – for now, we will consider a simple Peg order that is not priced :

Read More

Advertisements

In the previous post I implemented the “best limit” crossing rule, matching incoming limit orders against outstanding market orders. In this post I am going to complete the logic related to market orders matching by implementing the last use case – matching market orders to opposite side market orders. To do this we will introduce and explain a notion of reference price. The complete source code for this and other posts in the series is available from my GitHub repo: https://github.com/prystupa/scala-cucumber-matching-engine

Crossing Market Order with Opposite Side Outstanding Market Orders

Consider when a market order matches with another market order in the opposite order book. At what price should the resulting trade occur? There are two possibilites here:

  • the opposite order book with the resting market order also contains one or more outstanding limit orders – in this case the opposite book has a “best limit” price we discussed in the previous post and this price becomes the price for the trade
  • the opposte order book does not have outstanding limit orders, so the “best limit” price is not defined. In this case the trade occurs at the “reference price”. Most often reference price is the last traded price for a security. An exchange sets the reference price at the opening, perphaps to the closing price from the last session, or the result of the opening auction session.

Lets capture the first rule (best limit price is available) using Cucumber:

Read More