"Liquidity Routed Out"

[fplpo_x]

Imported from previous forum

[fplpo_x]

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

What is the meaning of enumerated value #3 “Liquidity Routed Out” in Tag 851?

Thank you for your help.

Best,
John

[fplpo_x]

[ original email was from Chris Snell - Chris.snell@patsystems.com ]
Hi John

Not 100% on this but I think this tag is used in Execution Reports in response to partfills/fills used in smart order routing/ECN scenarios where no liquidity is available and the liquidity gets routed out to another exchange.

Regards

Chris

Hi,

What is the meaning of enumerated value #3 “Liquidity Routed Out” in Tag 851?

Thank you for your help.

Best,
John

[fplpo_x]

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you for your kind reply, Chris.

In FIX 5.0 SP2 the LastLiquidityInd <851> field is described as follows:

“Indicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity. Applicable only for OrdStatus of Partial or Filled.”

By definition, the value supplied by the sender for this field informs the recipient about a fill. And further, the value purports to tell the recipient something about the cause of the fill: whether it resulted from “a liquidity provider providing or liquidity taker taking the liquidity.”

Multiple questions arise, then:

1. Should we infer from the definition that by protocol, every fill is deemed to result from a liquidity provider providing and a liquidity taker taking liquidity? Or, should the word “whether” in the definition be construed as meaning that fills may have causes other than liquidity providers providing and liquidity takers taking liquidity?

2. Assuming the former case in paragraph “1)” above, when the sender informs the recipient as to cause, whose perspective is assumed? If the sender populates the field with “1” for “Added Liquidity,” does that mean the order’s owner added liquidity or the order owner’s contraparty added liquidity? The same ambiguity arises in the converse case, when the sender populates the field with “2” for “Removed Liquidity.” Who, in other words, shall be assumed to have done what to whom?

3. Assuming the latter case in paragraph “1)” above, does the range of enumerated values specified by the protocol allow for all the possibilities? In addition to “1 = Added Liquidity” and “2 = Removed Liquidity,” we are given “3 = Liquidity Routed Out” and “4 = Auction.” What about concepts such as “liquidity routed in” (whatever that would mean) or “negotiated cross” as explanations for fills?

I don’t mean to task you with all these questions, Chris, and suspect you are correct about what the designers of this field had in mind. But, at least as far as I can tell, the meaning and usage of this field requires further clarification.

Hi John

Not 100% on this but I think this tag is used in Execution Reports in response to partfills/fills used in smart order routing/ECN scenarios where no liquidity is available and the liquidity gets routed out to another exchange.

Regards

Chris

Hi,

What is the meaning of enumerated value #3 “Liquidity Routed Out” in Tag 851?

Thank you for your help.

Best,
John

[ryanpierce_x]

The initial use for this field was for markets that operated continuous limit order books.

I agree that the language of the field definition is awkward. Obviously, there are more than two enums, so orders can’t be classified as only adding or taking liquidity.

Although I can see how it might not be explicit, my understanding is that LastLiquidityInd is determined from the perspective of the person placing the order. If I enter an order that stays on the book and adds liquidity, I’ll get a 1 back when it trades. The person who entered an order that hit my order on the book will have removed liquidity and will get a 2.

This can be of importance if the market’s pricing structure differentiates between adding or removing liquidity. Some markets charge a lower fee or provide a rebate for orders that add liquidity.

Within the US equities markets, Reg NMS generally prohibits one market from trading through another market’s published quote. So let’s say I send an order to Market A to buy at the national best offer. Market A doesn’t have any orders at that price. And my order is not an intermarket sweep. Market A may then send a buy order to Market B, who is displaying that price. Market A will have removed liquidity from Market B. But I will get a 3 back because my order was routed out of Market A to that other market. This is useful to know because Market A may charge me a routing fee or a higher rate.

In theory, for continuous limit books, orders should fall into one of these three categories. “Routing in” doesn’t have useful meaning to me. If I add an order to Market A’s book, it doesn’t matter to me if a member of Market A, or of Market B routing into Market A, traded against me. I’m still adding liquidity either way.

Now there can occasionally be “gotcha” scenarios. E.g. one person pegs to buy at the bid, and another pegs to sell at the offer minus 1 cent. Both orders are entered when the spread was 2 cents, hence both stay on the book. The spread tightens to 1 cent, and the orders trade against each other. So who added and who removed liquidity?

Stepping outside continuous markets, more enumerations may be needed. Auction is one of these. A market might have an opening auction prior to continuous trading, where the market accumulates buy and sell orders, and at a given time the auction happens, determining a price and matching the buyers and sellers. In this case, it might not be appropriate to designate who added vs. who removed liquidity, as both parties were contributing orders to the auction, so a value of 4 would be appropriate.

If you have a business need for more values, such as “negotiated cross”, these could be handled by submitting a Gap Analysis requesting them to FPL.

[fplpo_x]

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

Assuming your description of the business case for this field is correct, I would propose that the GTC act as follows:

1. Replace the description of the field LastLiquidityInd <851> with this text: “For orders sent to execution venues that (a) deem some orders to have provided liquidity or others to have removed liquidity and (b) report their decisions in that regard to order sources when and as such orders are filled, this field may be used to report said decisions to order sources.”

2. Amend the definition of enumeration “1” to “The execution venue deems this fill to have provided liquidity.”

3. Amend the definition of enumeration “2” to “The execution venue deems this fill to have removed liquidity.”

4. Amend the definition of enumeration “3” to “The execution venue makes no report of liquidity role for this fill.”

5. Strike enumeration “4”.

I would be happy to propose this formally if necessary and someone will be kind enough to tell me how to do so

Best,
John

The initial use for this field was for markets that operated continuous limit order books.

I agree that the language of the field definition is awkward. Obviously, there are more than two enums, so orders can’t be classified as only adding or taking liquidity.

Although I can see how it might not be explicit, my understanding is that LastLiquidityInd is determined from the perspective of the person placing the order. If I enter an order that stays on the book and adds liquidity, I’ll get a 1 back when it trades. The person who entered an order that hit my order on the book will have removed liquidity and will get a 2.

This can be of importance if the market’s pricing structure differentiates between adding or removing liquidity. Some markets charge a lower fee or provide a rebate for orders that add liquidity.

Within the US equities markets, Reg NMS generally prohibits one market from trading through another market’s published quote. So let’s say I send an order to Market A to buy at the national best offer. Market A doesn’t have any orders at that price. And my order is not an intermarket sweep. Market A may then send a buy order to Market B, who is displaying that price. Market A will have removed liquidity from Market B. But I will get a 3 back because my order was routed out of Market A to that other market. This is useful to know because Market A may charge me a routing fee or a higher rate.

In theory, for continuous limit books, orders should fall into one of these three categories. “Routing in” doesn’t have useful meaning to me. If I add an order to Market A’s book, it doesn’t matter to me if a member of Market A, or of Market B routing into Market A, traded against me. I’m still adding liquidity either way.

Now there can occasionally be “gotcha” scenarios. E.g. one person pegs to buy at the bid, and another pegs to sell at the offer minus 1 cent. Both orders are entered when the spread was 2 cents, hence both stay on the book. The spread tightens to 1 cent, and the orders trade against each other. So who added and who removed liquidity?

Stepping outside continuous markets, more enumerations may be needed. Auction is one of these. A market might have an opening auction prior to continuous trading, where the market accumulates buy and sell orders, and at a given time the auction happens, determining a price and matching the buyers and sellers. In this case, it might not be appropriate to designate who added vs. who removed liquidity, as both parties were contributing orders to the auction, so a value of 4 would be appropriate.

If you have a business need for more values, such as “negotiated cross”, these could be handled by submitting a Gap Analysis requesting them to FPL.

[timothystark73_x]

I did want to add a couple of comments to this discussion.

1. These values always refer to specific a specific execution, and not to an order.

2. Every order at the moment it enters the marketplace is either marketable or non-marketable. Orders that are marketable will be removing liquidity (at least until the executions on the order take all market liquidity at that point in time) and non-marketable orders will be adding liquidity. This principle still applies where the order entering the market is acting with a visible quote or with a non-visible quote such as a hidden mid market peg order.

3. In the US, when Reg NMS protected venue A routes to Reg NMS protected venue B, venue A may not actually know whether liquidity was taken or provided. Inter-venue routing does occur for reasons other than one venue routing to the another exchange to hit a NMS protected quote.

4. I imagine consumers of this info are primarily intending to do statistical analysis of the flag combined with Tag 30 to make inferences about a broker’s routing practices/effectiveness. If this is the case I think using ‘routed out’ as a proxy for ‘I don’t know’ is in itself an effective solution. I would expect the percentage of fills with a 3 value to be small.

5. The Auction value should definitely be kept since in an auction the provide/take distinction doesn’t make sense.

Hopefully this helps? I’m sure there may be other aspects I’m missing or other can provide more value on.

Regards,

Tim Stark

Thank you, Ryan.

Assuming your description of the business case for this field is correct, I would propose that the GTC act as follows:

1. Replace the description of the field LastLiquidityInd <851> with this text: “For orders sent to execution venues that (a) deem some orders to have provided liquidity or others to have removed liquidity and (b) report their decisions in that regard to order sources when and as such orders are filled, this field may be used to report said decisions to order sources.”

2. Amend the definition of enumeration “1” to “The execution venue deems this fill to have provided liquidity.”

3. Amend the definition of enumeration “2” to “The execution venue deems this fill to have removed liquidity.”

4. Amend the definition of enumeration “3” to “The execution venue makes no report of liquidity role for this fill.”

5. Strike enumeration “4”.

I would be happy to propose this formally if necessary and someone will be kind enough to tell me how to do so

Best,
John

The initial use for this field was for markets that operated continuous limit order books.

I agree that the language of the field definition is awkward. Obviously, there are more than two enums, so orders can’t be classified as only adding or taking liquidity.

Although I can see how it might not be explicit, my understanding is that LastLiquidityInd is determined from the perspective of the person placing the order. If I enter an order that stays on the book and adds liquidity, I’ll get a 1 back when it trades. The person who entered an order that hit my order on the book will have removed liquidity and will get a 2.

This can be of importance if the market’s pricing structure differentiates between adding or removing liquidity. Some markets charge a lower fee or provide a rebate for orders that add liquidity.

Within the US equities markets, Reg NMS generally prohibits one market from trading through another market’s published quote. So let’s say I send an order to Market A to buy at the national best offer. Market A doesn’t have any orders at that price. And my order is not an intermarket sweep. Market A may then send a buy order to Market B, who is displaying that price. Market A will have removed liquidity from Market B. But I will get a 3 back because my order was routed out of Market A to that other market. This is useful to know because Market A may charge me a routing fee or a higher rate.

In theory, for continuous limit books, orders should fall into one of these three categories. “Routing in” doesn’t have useful meaning to me. If I add an order to Market A’s book, it doesn’t matter to me if a member of Market A, or of Market B routing into Market A, traded against me. I’m still adding liquidity either way.

Now there can occasionally be “gotcha” scenarios. E.g. one person pegs to buy at the bid, and another pegs to sell at the offer minus 1 cent. Both orders are entered when the spread was 2 cents, hence both stay on the book. The spread tightens to 1 cent, and the orders trade against each other. So who added and who removed liquidity?

Stepping outside continuous markets, more enumerations may be needed. Auction is one of these. A market might have an opening auction prior to continuous trading, where the market accumulates buy and sell orders, and at a given time the auction happens, determining a price and matching the buyers and sellers. In this case, it might not be appropriate to designate who added vs. who removed liquidity, as both parties were contributing orders to the auction, so a value of 4 would be appropriate.

If you have a business need for more values, such as “negotiated cross”, these could be handled by submitting a Gap Analysis requesting them to FPL.

[fplpo_x]

[ original email was from John Harris - john.harris@bondmart.com ]
This is an important subject, Tim, and I hope it engenders a vigorous debate. Please see my comments below:

1. These values always refer to specific a specific execution, and not to an order.

I beg to differ, but by raising this point you have taught me that the definitions I proposed for the enumerated values are incorrect in a material way (instead of “this fill,” I should have said “the order resulting in this fill.”). Please consider my proposal amended accordingly.

Executions result from orders. It is non-sensical to speak of executions providing or removing liquidity. It is the orders that are deemed to have provided or taken liquidity. In the obvious case, an exchange matches what it deems to be a liquidity-providing order with a liquidity-taking order, the result of said match being an execution.

2. Every order at the moment it enters the marketplace is either marketable or non-marketable. Orders that are marketable will be removing liquidity (at least until the executions on the order take all market liquidity at that point in time) and non-marketable orders will be adding liquidity. This principle still applies where the order entering the market is acting with a visible quote or with a non-visible quote such as a hidden mid market peg order.

I trust that by “marketable” you mean: able to be matched immediately with one or more other orders. And while your statement is literally true, no source of any order has absolute, a priori knowledge of whether his order will in fact be executed. So at the time any order enters the market, its marketability can be estimated or projected, but not known with certainty. And that means that absent an explicit declaration to that effect incorporated into the terms of an order, no one can know in advance whether his order provides or removes liquidity. And further, absent such an explicit declaration, whether an order in fact adds or takes liquidity is at best a judgment or determination based on facts and circumstances, not an existential fact. Orders specifically declared to be liquidity-providing or liquidity-removing will (or at least should) result only in executions consistent with those stated terms. The only mystery, then, attaches to executions of orders that did not contain such explicit instructions. In that case, whether they provided or removed liquidity is because the market operator deemed it so.

3. In the US, when Reg NMS protected venue A routes to Reg NMS protected venue B, venue A may not actually know whether liquidity was taken or provided. Inter-venue routing does occur for reasons other than one venue routing to the another exchange to hit a NMS protected quote.

My response above addresses this point. Absent an explicit direction constraining an order as provider or remover, no one “knows” whether an order added or removed liquidity - that is a judgment or determination based on facts and circumstances (and which may vary from one market center to another). Reg NMS is stupid and why market participants have not already marched on Washington in protest of it, I know not, but to the extent “venue B” in the example above reports its determination as to whether an order it received provided or removed liquidity, there is no reason why the owner of the order should not be made aware of the fact.

4. I imagine consumers of this info are primarily intending to do statistical analysis of the flag combined with Tag 30 to make inferences about a broker’s routing practices/effectiveness. If this is the case I think using ‘routed out’ as a proxy for ‘I don’t know’ is in itself an effective solution. I would expect the percentage of fills with a 3 value to be small.

Well, okay, but given that human beings have to code to this spec, why not make the language as clear as possible? This field appears in the Execution Report message and is to be used only when such a message reports a fill. Further, this field purports to tell the recipient something about the liquidity role his order was deemed to have played in the execution. “Routed out” is fine (if indeterminate) information, I suppose, in a status report, but not in a fill report. In fact, it is pointless in a fill report if LastMkt <30> is used. If the value reported in LastMkt is other than the firm to which the order’s owner originally sent the order, then by definition, the order was “routed out.” Further, if the order was sent to a broker who in turn sent it to an exchange for execution, then by definition the order was routed out and the execution resulted from an auction (continuous, limit-order matching being a continuous, two-sided auction).

5. The Auction value should definitely be kept since in an auction the provide/take distinction doesn’t make sense.

Again, I beg to differ. There are two types of auctions: periodic and continuous. In a continuous auction (such as most exchanges implement), one of three conditions will hold: (1) the liquidity role is made an explicit condition of execution; (2) the executing venue determines and reports the liquidity role; or, (3) the executing venue makes no such determination (the case covered by my proposed enumeration “3”. In the case of a periodic auction, agreed, the liquidity flag is non-sensical, but then the owner of the order will already know, or at least should know, whether his order was subjected to a periodic auction.

What caused me to look again at LastLiquidityInd <851> was the announcement FPL Buy-Side Representatives Create Best Practices Around Execution Venue Reporting. I cannot help but wonder whether the promulgation of these best practices was motivated by concern on the part of some firms that their brokers are handling their orders in other than a satisfactory or candid way. But even if that is the case, I believe that the definitions and enumerations associated with LastLiquidityInd are in need of repair along the lines I have proposed.

Allow me a respectful word of advice. In every execution, alpha will fall to someone’s balance sheet. The only question is: whose? In my experience, many managers of separate accounts and mutual funds pay too little heed to execution alpha and rely too much on their brokers. Were I managing client money I would be embarrassed to cede control of my orders to a broker’s discretion or algorithms. To do so is to allow him or someone else receive alpha that my clients are paying me to capture. There are many terrific exchanges and dealers capable of providing immediate, direct execution for a wide range of orders. I respect what brokers do - they absolutely are needed in the marketplace - but in this day and age, the extent to which they are used by large money managers is almost malpractice.

Best,
John

Hopefully this helps? I’m sure there may be other aspects I’m missing or other can provide more value on.

Regards,

Tim Stark

Thank you, Ryan.

Assuming your description of the business case for this field is correct, I would propose that the GTC act as follows:

1. Replace the description of the field LastLiquidityInd <851> with this text: “For orders sent to execution venues that (a) deem some orders to have provided liquidity or others to have removed liquidity and (b) report their decisions in that regard to order sources when and as such orders are filled, this field may be used to report said decisions to order sources.”

2. Amend the definition of enumeration “1” to “The execution venue deems this fill to have provided liquidity.”

3. Amend the definition of enumeration “2” to “The execution venue deems this fill to have removed liquidity.”

4. Amend the definition of enumeration “3” to “The execution venue makes no report of liquidity role for this fill.”

5. Strike enumeration “4”.

I would be happy to propose this formally if necessary and someone will be kind enough to tell me how to do so

Best,
John

The initial use for this field was for markets that operated continuous limit order books.

I agree that the language of the field definition is awkward. Obviously, there are more than two enums, so orders can’t be classified as only adding or taking liquidity.

Although I can see how it might not be explicit, my understanding is that LastLiquidityInd is determined from the perspective of the person placing the order. If I enter an order that stays on the book and adds liquidity, I’ll get a 1 back when it trades. The person who entered an order that hit my order on the book will have removed liquidity and will get a 2.

This can be of importance if the market’s pricing structure differentiates between adding or removing liquidity. Some markets charge a lower fee or provide a rebate for orders that add liquidity.

Within the US equities markets, Reg NMS generally prohibits one market from trading through another market’s published quote. So let’s say I send an order to Market A to buy at the national best offer. Market A doesn’t have any orders at that price. And my order is not an intermarket sweep. Market A may then send a buy order to Market B, who is displaying that price. Market A will have removed liquidity from Market B. But I will get a 3 back because my order was routed out of Market A to that other market. This is useful to know because Market A may charge me a routing fee or a higher rate.

In theory, for continuous limit books, orders should fall into one of these three categories. “Routing in” doesn’t have useful meaning to me. If I add an order to Market A’s book, it doesn’t matter to me if a member of Market A, or of Market B routing into Market A, traded against me. I’m still adding liquidity either way.

Now there can occasionally be “gotcha” scenarios. E.g. one person pegs to buy at the bid, and another pegs to sell at the offer minus 1 cent. Both orders are entered when the spread was 2 cents, hence both stay on the book. The spread tightens to 1 cent, and the orders trade against each other. So who added and who removed liquidity?

Stepping outside continuous markets, more enumerations may be needed. Auction is one of these. A market might have an opening auction prior to continuous trading, where the market accumulates buy and sell orders, and at a given time the auction happens, determining a price and matching the buyers and sellers. In this case, it might not be appropriate to designate who added vs. who removed liquidity, as both parties were contributing orders to the auction, so a value of 4 would be appropriate.

If you have a business need for more values, such as “negotiated cross”, these could be handled by submitting a Gap Analysis requesting them to FPL.

[ryanpierce_x]

Regarding #1:

Adding or removing liquidity is a property of the execution, not the order.

Example: A market has a best bid of 100 shares at $10.00. The best published bid on any other Reg NMS market is $9.99. I enter a limit day order to sell 500 at $10.00.

What happens: 100 shares will immediately trade against what is on the book. My order will have removed liquidity on that execution. And the market will post to the book a sell of 400 at $10.00, which becomes the national best offer. Someone comes along and trades against it. In that case my order added liquidity.

So the same order gets two executions, one removing and one adding liquidity.

[fplpo_x]

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

Adding or removing liquidity is an event, not a property.

If the matching engine could speak, it would not say “I added liquidity” or “I removed liquidity.”

A human specialist running a limit order book on an exchange floor would not, upon matching two limit orders he has received, say “I added liquidity” or “I removed liquidity.”

In your own explanation below, you stated in one case “My order will have removed liquidity on that execution” and in the other “my order added liquidity.”

When exchanges pay rebates for adding or removing liquidity, they do not pay themselves: they pay those who submitted the orders that provided or removed the liquidity.

Exchanges mediate liquidity. When they effect transactions, they execute simultaneously two (or more) orders. That is, in a typical transaction involving one buyer and one seller, two order executions occur (though only one trade is effected thereby). Not all exchanges deem one or the other to have provided or removed liquidity, but no exchange deems itself to have provided or removed liquidity.

The exchange acts economically as agent (legally it may interpose itself or a clearinghouse between the parties when it consummates an agreement, but that is another matter). The order owners have each appointed the exchange to act as their agent and granted to the exchange, as agent, the power to execute their orders without further consent from them. Execution is the act of the exchange, as mutual agent of the order owners, consummating an agreement between them, each having expressed by virtue of their orders a willingness to enter into said agreement.

Yes, I agree, an order may provide liquidity in one moment and remove it in another (I did not mean to suggest otherwise and hope I didn’t).

Best,
John

Regarding #1:

Adding or removing liquidity is a property of the execution, not the order.

Example: A market has a best bid of 100 shares at $10.00. The best published bid on any other Reg NMS market is $9.99. I enter a limit day order to sell 500 at $10.00.

What happens: 100 shares will immediately trade against what is on the book. My order will have removed liquidity on that execution. And the market will post to the book a sell of 400 at $10.00, which becomes the national best offer. Someone comes along and trades against it. In that case my order added liquidity.

So the same order gets two executions, one removing and one adding liquidity.

[drewseward_x]

Hi John,

I think the best terminology is that adding or removing liquidity is a property of the last executed portion of the order (much like the analogous LastPrice or LastQuantity, which are not properties of the entire order). I agree that “this fill” is a bit misleading because it implies a property of the execution. How would you feel about “this filled quantity?”

If you propose a change on this field, don’t forget about tags 1443 (FillLiquidityInd) and 1444 (SideLiquidityInd).

Regards,
Drew

Ryan,

Adding or removing liquidity is an event, not a property.

If the matching engine could speak, it would not say “I added liquidity” or “I removed liquidity.”

A human specialist running a limit order book on an exchange floor would not, upon matching two limit orders he has received, say “I added liquidity” or “I removed liquidity.”

In your own explanation below, you stated in one case “My order will have removed liquidity on that execution” and in the other “my order added liquidity.”

When exchanges pay rebates for adding or removing liquidity, they do not pay themselves: they pay those who submitted the orders that provided or removed the liquidity.

Exchanges mediate liquidity. When they effect transactions, they execute simultaneously two (or more) orders. That is, in a typical transaction involving one buyer and one seller, two order executions occur (though only one trade is effected thereby). Not all exchanges deem one or the other to have provided or removed liquidity, but no exchange deems itself to have provided or removed liquidity.

The exchange acts economically as agent (legally it may interpose itself or a clearinghouse between the parties when it consummates an agreement, but that is another matter). The order owners have each appointed the exchange to act as their agent and granted to the exchange, as agent, the power to execute their orders without further consent from them. Execution is the act of the exchange, as mutual agent of the order owners, consummating an agreement between them, each having expressed by virtue of their orders a willingness to enter into said agreement.

Yes, I agree, an order may provide liquidity in one moment and remove it in another (I did not mean to suggest otherwise and hope I didn’t).

Best,
John

[fplpo_x]

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Drew - valid points and good suggestion. Good catch on tags 1443 and 1444. Accordingly, let me re-cast the proposal as follows:

1. For each of the fields LastLiquidityInd <851>, FillLiquidityInd ,<1443>, and SideLiquidityInd <1444>, replace its description with the following text:

“For orders sent to execution venues that (a) deem some orders to have provided liquidity or others to have removed liquidity and (b) report their decisions in that regard to order sources when and as such orders are filled, this field may be used to report said decisions to order sources. When using this field, the value of the field OrdStatus <39> in the same message must be either “1” (for “Partially filled”) or “2” (for “Filled”).” The execution venue to which this field refers is that reported in the field LastMkt <30>."

2. Amend the definition of enumeration “1” to “The execution venue deems this filled quantity to have provided liquidity.”

3. Amend the definition of enumeration “2” to “The execution venue deems this filled quantity to have removed liquidity.”

4. Amend the definition of enumeration “3” to “The execution venue makes no report of liquidity role for this filled quantity.”

5. Strike enumeration “4”.

Best,
John

Hi John,

I think the best terminology is that adding or removing liquidity is a property of the last executed portion of the order (much like the analogous LastPrice or LastQuantity, which are not properties of the entire order). I agree that “this fill” is a bit misleading because it implies a property of the execution. How would you feel about “this filled quantity?”

If you propose a change on this field, don’t forget about tags 1443 (FillLiquidityInd) and 1444 (SideLiquidityInd).

Regards,
Drew

Ryan,

Adding or removing liquidity is an event, not a property.

If the matching engine could speak, it would not say “I added liquidity” or “I removed liquidity.”

A human specialist running a limit order book on an exchange floor would not, upon matching two limit orders he has received, say “I added liquidity” or “I removed liquidity.”

In your own explanation below, you stated in one case “My order will have removed liquidity on that execution” and in the other “my order added liquidity.”

When exchanges pay rebates for adding or removing liquidity, they do not pay themselves: they pay those who submitted the orders that provided or removed the liquidity.

Exchanges mediate liquidity. When they effect transactions, they execute simultaneously two (or more) orders. That is, in a typical transaction involving one buyer and one seller, two order executions occur (though only one trade is effected thereby). Not all exchanges deem one or the other to have provided or removed liquidity, but no exchange deems itself to have provided or removed liquidity.

The exchange acts economically as agent (legally it may interpose itself or a clearinghouse between the parties when it consummates an agreement, but that is another matter). The order owners have each appointed the exchange to act as their agent and granted to the exchange, as agent, the power to execute their orders without further consent from them. Execution is the act of the exchange, as mutual agent of the order owners, consummating an agreement between them, each having expressed by virtue of their orders a willingness to enter into said agreement.

Yes, I agree, an order may provide liquidity in one moment and remove it in another (I did not mean to suggest otherwise and hope I didn’t).

Best,
John