What execution price would be used when limit sell price is lower than limit buy price?

, ,
1

Imported from previous forum

2

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

3

SwissBankAccount myAcct;
myAcct.open(mySecretPin);
myAcct.deposit(spread);
sendExecRpt(execReportToBuyer);
sendExecRpt(execReportToSeller);
MyGlobalFist.pump();

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

4

Hi Robert,

Making a spread sounds good, I am not 100 % sure of this but I think the Securities trading laws of most countries prohibit an exchange from buying-holding-selling stocks that are traded on it. As per my understanding a stock exchange only acts as a neutral open market place for the listed securities to match buyers and sellers.

Regards,
K. Mahesh

SwissBankAccount myAcct;
myAcct.open(mySecretPin);
myAcct.deposit(spread);
sendExecRpt(execReportToBuyer);
sendExecRpt(execReportToSeller);
MyGlobalFist.pump();

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

5

[ original email was from John Harris - john.harris@bondmart.com ]
Mahesh,

There is no “right” answer to this question (notwithstanding Mr. Mitchell’s clever guidance). You as market designer have to decide how to handle these conditions. The market will decide whether it likes your design choices. Almost certainly the market will not like using last trade as the basis for the match. You left out one other condition, which is indeterminate order of arrival in the book. That might happen, for example, if the book is busy cleaning up after its last match and buffers inbound orders during the process. You may have no way of knowing which arrived first.

Best,
John

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

6

John,

This puzzles me. The matching engine is not busy so no buffering. The order in which these orders arrived into the order book is known.

One of the alternatives I missed out above is opposite of the 2nd one - the order which is removing liquidity. Ryan Pierce stated “Some markets charge a lower fee or provide a rebate for orders that add liquidity.” at http://fixprotocol.org/discuss/read/dba8da31 . So as a market designer / matching engine developer I see some choices

  1. Since the order or execution (as per the above quoted thread of discussion regarding liquidity fields in exec reports) removing the liquidity is paying the fees, its limit price would be used as exec price.

  2. Be fair to both parties - use mid point price, let fees be charged as per liquidity remover pricing.

  3. Do NOT use the liquidity remover based pricing system, price the orders such that each of the orders pay half the fees each, thus the exchange gets the same amount of total fees for the buy-sell transaction but as two halves from the two orders.

Regards,
Mahesh

Mahesh,

There is no “right” answer to this question (notwithstanding Mr. Mitchell’s clever guidance). You as market designer have to decide how to handle these conditions. The market will decide whether it likes your design choices. Almost certainly the market will not like using last trade as the basis for the match. You left out one other condition, which is indeterminate order of arrival in the book. That might happen, for example, if the book is busy cleaning up after its last match and buffers inbound orders during the process. You may have no way of knowing which arrived first.

Best,
John

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

7

[ original email was from John Harris - john.harris@bondmart.com ]
Mahesh,

Imagine that two orders arrive while your matching engine is making a match that will leave the book empty prior to insertion of the new orders. This meets the test of your empty-book scenario.

Where will you store those orders prior to insertion? How will you know which arrived first?

As for Ryan’s points, some markets also pay for liquidity removal. Some markets prevent crosses or touches. There are all sorts of schemes. The design decisions you make with respect to all the scenarios that can arise cannot be known a priori to be correct; they can never be proven optimal. You just have to make your decisions and see if the market agrees.

Best,
John

John,

This puzzles me. The matching engine is not busy so no buffering. The order in which these orders arrived into the order book is known.

One of the alternatives I missed out above is opposite of the 2nd one - the order which is removing liquidity. Ryan Pierce stated “Some markets charge a lower fee or provide a rebate for orders that add liquidity.” at http://fixprotocol.org/discuss/read/dba8da31 . So as a market designer / matching engine developer I see some choices

  1. Since the order or execution (as per the above quoted thread of discussion regarding liquidity fields in exec reports) removing the liquidity is paying the fees, its limit price would be used as exec price.

  2. Be fair to both parties - use mid point price, let fees be charged as per liquidity remover pricing.

  3. Do NOT use the liquidity remover based pricing system, price the orders such that each of the orders pay half the fees each, thus the exchange gets the same amount of total fees for the buy-sell transaction but as two halves from the two orders.

Regards,
Mahesh

Mahesh,

There is no “right” answer to this question (notwithstanding Mr. Mitchell’s clever guidance). You as market designer have to decide how to handle these conditions. The market will decide whether it likes your design choices. Almost certainly the market will not like using last trade as the basis for the match. You left out one other condition, which is indeterminate order of arrival in the book. That might happen, for example, if the book is busy cleaning up after its last match and buffers inbound orders during the process. You may have no way of knowing which arrived first.

Best,
John

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

8

Hi John,

Putting aside the absurdity of limit prices, how do exchange matching engines determine order of order entry into matching engine / order book for purposes of liquidity adder / remover based fee pricing ? I am asking this because the method of calculating last price of this execution should not affect the way in which matching engines buffer inbound orders / cancels / cancel-replaces to implement sequential matching within a single ticker based on price then time matching of opposite sides to create executions.

I do NOT see a need for buffering in a way such that order of entry into that buffer cannot be determined. I am writing my matching engine in Java and for me Java would manage the order in which multiple Threads call synchronized methods Synchronized Methods (The Java™ Tutorials > Essential Java Classes > Concurrency) and I shall use a Threadsafe collection to queue the inbound orders / order actions, so even if these two orders arive thru two different FIX gateways at exactly the same milli-micro second, their order of entry into the matching engine’s buffer is always determinate.

Regards,
K. Mahesh

Mahesh,

Imagine that two orders arrive while your matching engine is making a match that will leave the book empty prior to insertion of the new orders. This meets the test of your empty-book scenario.

Where will you store those orders prior to insertion? How will you know which arrived first?

As for Ryan’s points, some markets also pay for liquidity removal. Some markets prevent crosses or touches. There are all sorts of schemes. The design decisions you make with respect to all the scenarios that can arise cannot be known a priori to be correct; they can never be proven optimal. You just have to make your decisions and see if the market agrees.

Best,
John

John,

This puzzles me. The matching engine is not busy so no buffering. The order in which these orders arrived into the order book is known.

One of the alternatives I missed out above is opposite of the 2nd one - the order which is removing liquidity. Ryan Pierce stated “Some markets charge a lower fee or provide a rebate for orders that add liquidity.” at http://fixprotocol.org/discuss/read/dba8da31 . So as a market designer / matching engine developer I see some choices

  1. Since the order or execution (as per the above quoted thread of discussion regarding liquidity fields in exec reports) removing the liquidity is paying the fees, its limit price would be used as exec price.

  2. Be fair to both parties - use mid point price, let fees be charged as per liquidity remover pricing.

  3. Do NOT use the liquidity remover based pricing system, price the orders such that each of the orders pay half the fees each, thus the exchange gets the same amount of total fees for the buy-sell transaction but as two halves from the two orders.

Regards,
Mahesh

Mahesh,

There is no “right” answer to this question (notwithstanding Mr. Mitchell’s clever guidance). You as market designer have to decide how to handle these conditions. The market will decide whether it likes your design choices. Almost certainly the market will not like using last trade as the basis for the match. You left out one other condition, which is indeterminate order of arrival in the book. That might happen, for example, if the book is busy cleaning up after its last match and buffers inbound orders during the process. You may have no way of knowing which arrived first.

Best,
John

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

9

[ original email was from John Harris - john.harris@bondmart.com ]
Mahesh,

Exchanges must choose one of two approaches in determining liquidity role: inference or expression.

Under the inference approach, liquidity role is determined (“inferred”) from conditions and rules. For example, if one order is deemed to have arrived first, the later, matching order may be deemed the remover and the former the provider.

Under the expression approach, order makers may or must, depending on exchange rules, either use an order type that is expressly deemed provider or remover or else explicitly designate their orders as provider or remover.

With the express (or explicit) approach, there is no ambiguity as to whether an order provides or removes liquidity. There can still be a debate, however, as to whether an order was entitled to a fill (which is where your ability to determine order age become ripe).

I appreciate the link. Having read the material, (1) it seems to me that all you have accomplished with that sync scheme is change the boundary of the determinacy problem and (2) I wonder if the issues identified in the tutorial are worth the risk. I am wandering beyond my expertise in speculating on that score, however. I will just say that match attempts will either be event-driven, determined by the passage of time, or scheduled, and each these scenarios creates edge cases that you have to handle as market designer.

Best,
John

Hi John,

Putting aside the absurdity of limit prices, how do exchange matching engines determine order of order entry into matching engine / order book for purposes of liquidity adder / remover based fee pricing ? I am asking this because the method of calculating last price of this execution should not affect the way in which matching engines buffer inbound orders / cancels / cancel-replaces to implement sequential matching within a single ticker based on price then time matching of opposite sides to create executions.

I do NOT see a need for buffering in a way such that order of entry into that buffer cannot be determined. I am writing my matching engine in Java and for me Java would manage the order in which multiple Threads call synchronized methods Synchronized Methods (The Java™ Tutorials > Essential Java Classes > Concurrency) and I shall use a Threadsafe collection to queue the inbound orders / order actions, so even if these two orders arive thru two different FIX gateways at exactly the same milli-micro second, their order of entry into the matching engine’s buffer is always determinate.

Regards,
K. Mahesh

Mahesh,

Imagine that two orders arrive while your matching engine is making a match that will leave the book empty prior to insertion of the new orders. This meets the test of your empty-book scenario.

Where will you store those orders prior to insertion? How will you know which arrived first?

As for Ryan’s points, some markets also pay for liquidity removal. Some markets prevent crosses or touches. There are all sorts of schemes. The design decisions you make with respect to all the scenarios that can arise cannot be known a priori to be correct; they can never be proven optimal. You just have to make your decisions and see if the market agrees.

Best,
John

John,

This puzzles me. The matching engine is not busy so no buffering. The order in which these orders arrived into the order book is known.

One of the alternatives I missed out above is opposite of the 2nd one - the order which is removing liquidity. Ryan Pierce stated “Some markets charge a lower fee or provide a rebate for orders that add liquidity.” at http://fixprotocol.org/discuss/read/dba8da31 . So as a market designer / matching engine developer I see some choices

  1. Since the order or execution (as per the above quoted thread of discussion regarding liquidity fields in exec reports) removing the liquidity is paying the fees, its limit price would be used as exec price.

  2. Be fair to both parties - use mid point price, let fees be charged as per liquidity remover pricing.

  3. Do NOT use the liquidity remover based pricing system, price the orders such that each of the orders pay half the fees each, thus the exchange gets the same amount of total fees for the buy-sell transaction but as two halves from the two orders.

Regards,
Mahesh

Mahesh,

There is no “right” answer to this question (notwithstanding Mr. Mitchell’s clever guidance). You as market designer have to decide how to handle these conditions. The market will decide whether it likes your design choices. Almost certainly the market will not like using last trade as the basis for the match. You left out one other condition, which is indeterminate order of arrival in the book. That might happen, for example, if the book is busy cleaning up after its last match and buffers inbound orders during the process. You may have no way of knowing which arrived first.

Best,
John

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

10

Mahesh,

The way I see it, the first order to the book “sets the price” so in your first example the price will be 100.03 and in the second (sell comes first) the price will be 99.99.

Think of it this way, let’s say that the delta between the two order is an hour. In that case, it is clear the price would be 100.03 (it is extremely likely that the sell order had that price in mind and the 4 ticks are just for safety). Make the delta a min, we would all probably agree that the price should still be 100.03. we can continue going to a second and millisecond delta and probably reach the same conclusion. At what point (= how small of a delta) should the behavior change?

I would say never. Any other answer will lead to inconsistencies as to why a delta of x nanoseconds has one behavior and n+1 a different behavior.

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

11

Hi Sagy Mintz,

Your idea of “first order sets the price” sounds acceptable and is consistent with “early bird gets the moth” :wink:

Regards,
K. Mahesh

Mahesh,

The way I see it, the first order to the book “sets the price” so in your first example the price will be 100.03 and in the second (sell comes first) the price will be 99.99.

Think of it this way, let’s say that the delta between the two order is an hour. In that case, it is clear the price would be 100.03 (it is extremely likely that the sell order had that price in mind and the 4 ticks are just for safety). Make the delta a min, we would all probably agree that the price should still be 100.03. we can continue going to a second and millisecond delta and probably reach the same conclusion. At what point (= how small of a delta) should the behavior change?

I would say never. Any other answer will lead to inconsistencies as to why a delta of x nanoseconds has one behavior and n+1 a different behavior.

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

12

Mahesh,

John is right, it’s up to you to decide the strategy that’s best for you. But I think you’ll find for all practical purposes, using the price of order that arrived first (the ‘standing’ or ‘resting’ order) is the way to go.

  1. As Sagy points out, it is common for traders to place an order above or below the market, in order to make sure your order matches, but expecting to still get the current best market price.

  2. If your time and sales record has the best bid as 100.03, and the next event is a trade at 99.99, that is going to look odd and inconsistent.

  3. The standing order is generally going to be from a market maker. The liquidity taker is generally going to be an “end customer”. In most markets “end customers” are the really valuable customers, you want to give them the best fills.

Note that the “first order sets the price” as you describe it, actually favors the second order (the buyer loses 4 cents he could have realized). Which, as I say, it probably how it should be.

Hi Sagy Mintz,

Your idea of “first order sets the price” sounds acceptable and is consistent with “early bird gets the moth” :wink:

Regards,
K. Mahesh

Mahesh,

The way I see it, the first order to the book “sets the price” so in your first example the price will be 100.03 and in the second (sell comes first) the price will be 99.99.

Think of it this way, let’s say that the delta between the two order is an hour. In that case, it is clear the price would be 100.03 (it is extremely likely that the sell order had that price in mind and the 4 ticks are just for safety). Make the delta a min, we would all probably agree that the price should still be 100.03. we can continue going to a second and millisecond delta and probably reach the same conclusion. At what point (= how small of a delta) should the behavior change?

I would say never. Any other answer will lead to inconsistencies as to why a delta of x nanoseconds has one behavior and n+1 a different behavior.

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

13

What if both orders are ALO (Add Liquidity Only)? Would the market be crossed?

Mahesh,

John is right, it’s up to you to decide the strategy that’s best for you. But I think you’ll find for all practical purposes, using the price of order that arrived first (the ‘standing’ or ‘resting’ order) is the way to go.

  1. As Sagy points out, it is common for traders to place an order above or below the market, in order to make sure your order matches, but expecting to still get the current best market price.

  2. If your time and sales record has the best bid as 100.03, and the next event is a trade at 99.99, that is going to look odd and inconsistent.

  3. The standing order is generally going to be from a market maker. The liquidity taker is generally going to be an “end customer”. In most markets “end customers” are the really valuable customers, you want to give them the best fills.

Note that the “first order sets the price” as you describe it, actually favors the second order (the buyer loses 4 cents he could have realized). Which, as I say, it probably how it should be.

Hi Sagy Mintz,

Your idea of “first order sets the price” sounds acceptable and is consistent with “early bird gets the moth” :wink:

Regards,
K. Mahesh

Mahesh,

The way I see it, the first order to the book “sets the price” so in your first example the price will be 100.03 and in the second (sell comes first) the price will be 99.99.

Think of it this way, let’s say that the delta between the two order is an hour. In that case, it is clear the price would be 100.03 (it is extremely likely that the sell order had that price in mind and the 4 ticks are just for safety). Make the delta a min, we would all probably agree that the price should still be 100.03. we can continue going to a second and millisecond delta and probably reach the same conclusion. At what point (= how small of a delta) should the behavior change?

I would say never. Any other answer will lead to inconsistencies as to why a delta of x nanoseconds has one behavior and n+1 a different behavior.

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

14

Most markets will either reject incoming orders which cause a crossed book situation, or move into auction mode. In your ALO order case, you could reject the incoming ALO order.

Regarding matching models, I agree that using the first order onto the book is the most common model in continuous matching.

There are however several other possibilities:

In a book which has a mixture of orders and quotes, you could use the quote price as the defining one, regardless of whether it was first onto the book. This would tend to protect the private investors who are less likely to have access to pricing models.

In an auction driven model, the time priority is not relevant in determining the price - matching is usually carried out at a price that creates the maximum matched volume.

Some exchanges publish their matching rules. If you are interested in alternatives you could look there.

What if both orders are ALO (Add Liquidity Only)? Would the market be crossed?

Mahesh,

John is right, it’s up to you to decide the strategy that’s best for you. But I think you’ll find for all practical purposes, using the price of order that arrived first (the ‘standing’ or ‘resting’ order) is the way to go.

  1. As Sagy points out, it is common for traders to place an order above or below the market, in order to make sure your order matches, but expecting to still get the current best market price.

  2. If your time and sales record has the best bid as 100.03, and the next event is a trade at 99.99, that is going to look odd and inconsistent.

  3. The standing order is generally going to be from a market maker. The liquidity taker is generally going to be an “end customer”. In most markets “end customers” are the really valuable customers, you want to give them the best fills.

Note that the “first order sets the price” as you describe it, actually favors the second order (the buyer loses 4 cents he could have realized). Which, as I say, it probably how it should be.

Hi Sagy Mintz,

Your idea of “first order sets the price” sounds acceptable and is consistent with “early bird gets the moth” :wink:

Regards,
K. Mahesh

Mahesh,

The way I see it, the first order to the book “sets the price” so in your first example the price will be 100.03 and in the second (sell comes first) the price will be 99.99.

Think of it this way, let’s say that the delta between the two order is an hour. In that case, it is clear the price would be 100.03 (it is extremely likely that the sell order had that price in mind and the 4 ticks are just for safety). Make the delta a min, we would all probably agree that the price should still be 100.03. we can continue going to a second and millisecond delta and probably reach the same conclusion. At what point (= how small of a delta) should the behavior change?

I would say never. Any other answer will lead to inconsistencies as to why a delta of x nanoseconds has one behavior and n+1 a different behavior.

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile:

15

[ original email was from John Harris - john.harris@bondmart.com ]
I would just clarify that in your remarks on auction models, George, you refer only to discrete auctions - auctions at a definite time. Most exchanges operate on the principle of the continuous, two-sided auction. Under that model, time priority (age of order) does matter. And there are discrete auction models where time priority is used, though you are correct that maximizing cleared volume is generally the object of the exercise.

Most markets will either reject incoming orders which cause a crossed book situation, or move into auction mode. In your ALO order case, you could reject the incoming ALO order.

Regarding matching models, I agree that using the first order onto the book is the most common model in continuous matching.

There are however several other possibilities:

In a book which has a mixture of orders and quotes, you could use the quote price as the defining one, regardless of whether it was first onto the book. This would tend to protect the private investors who are less likely to have access to pricing models.

In an auction driven model, the time priority is not relevant in determining the price - matching is usually carried out at a price that creates the maximum matched volume.

Some exchanges publish their matching rules. If you are interested in alternatives you could look there.

What if both orders are ALO (Add Liquidity Only)? Would the market be crossed?

Mahesh,

John is right, it’s up to you to decide the strategy that’s best for you. But I think you’ll find for all practical purposes, using the price of order that arrived first (the ‘standing’ or ‘resting’ order) is the way to go.

  1. As Sagy points out, it is common for traders to place an order above or below the market, in order to make sure your order matches, but expecting to still get the current best market price.

  2. If your time and sales record has the best bid as 100.03, and the next event is a trade at 99.99, that is going to look odd and inconsistent.

  3. The standing order is generally going to be from a market maker. The liquidity taker is generally going to be an “end customer”. In most markets “end customers” are the really valuable customers, you want to give them the best fills.

Note that the “first order sets the price” as you describe it, actually favors the second order (the buyer loses 4 cents he could have realized). Which, as I say, it probably how it should be.

Hi Sagy Mintz,

Your idea of “first order sets the price” sounds acceptable and is consistent with “early bird gets the moth” :wink:

Regards,
K. Mahesh

Mahesh,

The way I see it, the first order to the book “sets the price” so in your first example the price will be 100.03 and in the second (sell comes first) the price will be 99.99.

Think of it this way, let’s say that the delta between the two order is an hour. In that case, it is clear the price would be 100.03 (it is extremely likely that the sell order had that price in mind and the 4 ticks are just for safety). Make the delta a min, we would all probably agree that the price should still be 100.03. we can continue going to a second and millisecond delta and probably reach the same conclusion. At what point (= how small of a delta) should the behavior change?

I would say never. Any other answer will lead to inconsistencies as to why a delta of x nanoseconds has one behavior and n+1 a different behavior.

Let the last price of the last execution for a security be 100.00, matching engine has no open orders in its order book for this security, then a limit buy order is received with limit price 100.03 and a limit sell order is received with limit price 99.99, at what execution price would the matching engine match these orders ? Also the case of limit prices are same but sell order comes in first ?

? Limit price based on side - Buy or Sell

? Limit price of the first order which came into the matching engine, i.e. added liquidity

? Price of last trade i.e. 100.00

? Midway between these prices = (100.03 + 99.99) / 2 = 100.01

Note :- The above question sounds silly / investors with an ounce of brain would not place orders with limit prices like these, but in a matching engine code I am trying out, I have to code an

…
else
{
// Core Java code to set last price of this execution
// when this situation occurs
}
…

:frowning: all other ifs to determine execution prices have been handled :slight_smile: