Imported from previous forum
Some basic order behavior questions:
-do 18=6 (participate don’t initiate) orders behave as “post-only” (ie. will only be providers and never takers)?
-as i assume that they do, is it required/preferred that they be “non-display” orders so that they can lock or cross the market when another 18=6 order is resting on the book?
-what is the standard tag used to denote “non-display”?
-since default day order behavior is aggressive (ie. will take if liquidity is available), will it retain its aggressive behavior when no liquidity is available to hit and it posts to the book? (ie. if a post-only order on the other side comes in, will it aggress on that order?) Or does its behavior become passive when it posts? (ie. will it prevent interaction with a new incoming non-display post-only order on the other side?)
-if it retains its aggressive nature while being posted on the book, will a new incoming day order (aggressive by nature) be rejected for locking/crossing the market? or will the new incoming day order take and the posted order provide?
Chris,
18=6 behaves as you suggest, we also call them “book-or-cancel” to express that they can only get into the book upon entry if they are non-executable at that time. Once they are resting, however, they are considered to be liquidity providers and can match at any time. They must then be visible to the market. You ask “if a post-only order on the other side comes in, will it aggress on that order?” which I do not quite understand. The post-only order coming in is the aggressor, i.e. it will be rejected if it would execute against the resting post-only (or any other resting) order. I believe you describe a scenario where you do not reject an executable post-only order but store it with non-display in the book. What should be the trigger for activating such an order again?
A question arises whether the post-only condition should be tested again upon modification and, if so, should a modification be rejected if it would make the order executable or should the modification become a cancellation and lead to a removal of the order from the book? In any case I do not think it helps to store an executable post-only order as it must never be the trigger for a match event. It would require the matching engine to repeat the attempt to post it on the book every time the book changes due to an incoming order or a match event. I would simply reject it upon entry and have the user attempt it again. The semantic seems weird to say “Please take my order and do not match it even though it would do so currently. Please match it once the price has moved away and then come back to the price of my order.”
On a general note, hidden orders can be expressed with 1138 DisplayQty=0 which is the tag to identify a reserve order.
Regards,
Hanno.
Some basic order behavior questions:
-do 18=6 (participate don’t initiate) orders behave as “post-only” (ie. will only be providers and never takers)?
-as i assume that they do, is it required/preferred that they be “non-display” orders so that they can lock or cross the market when another 18=6 order is resting on the book?
-what is the standard tag used to denote “non-display”?
-since default day order behavior is aggressive (ie. will take if liquidity is available), will it retain its aggressive behavior when no liquidity is available to hit and it posts to the book? (ie. if a post-only order on the other side comes in, will it aggress on that order?) Or does its behavior become passive when it posts? (ie. will it prevent interaction with a new incoming non-display post-only order on the other side?)
-if it retains its aggressive nature while being posted on the book, will a new incoming day order (aggressive by nature) be rejected for locking/crossing the market? or will the new incoming day order take and the posted order provide?
Hanno,
Thanks for your reply.
You answered my 18=6 behavior question and my ‘non-display’ tag question.
The nature of the aggressor vs. provider question is with regards to respecting the difference in provide vs. take fees/rebates which would potentially cause clients to want to lock/cross the market. This creates a scenario in which it would be preferable to keep original order behavior intention, encouraging true matches, and not discouraging liquidity.
It seems that through the use of optional ‘non-display’ stipulation, liquidity would not be discouraged by allowing orders to rest even if locking/crossing the market.
The question then remains:
-How can you respect the notion of ‘taker’ and still respect the notion of ‘day TIF’? If you convert an order from a taker to post-only (ie. provider), then this discourages a true match if a new post-only order from a provider comes in since it will reject the order.
However, if you maintain the notion of ‘taker’ on a posted order, then a new order from another ‘taker’ will not be able to hit it and will be rejected. This is the dilemma. Perhaps a custom ‘auto-aggress’ tag is the best solution, albeit still imperfect.
Chris,
18=6 behaves as you suggest, we also call them “book-or-cancel” to express that they can only get into the book upon entry if they are non-executable at that time. Once they are resting, however, they are considered to be liquidity providers and can match at any time. They must then be visible to the market. You ask “if a post-only order on the other side comes in, will it aggress on that order?” which I do not quite understand. The post-only order coming in is the aggressor, i.e. it will be rejected if it would execute against the resting post-only (or any other resting) order. I believe you describe a scenario where you do not reject an executable post-only order but store it with non-display in the book. What should be the trigger for activating such an order again?
A question arises whether the post-only condition should be tested again upon modification and, if so, should a modification be rejected if it would make the order executable or should the modification become a cancellation and lead to a removal of the order from the book? In any case I do not think it helps to store an executable post-only order as it must never be the trigger for a match event. It would require the matching engine to repeat the attempt to post it on the book every time the book changes due to an incoming order or a match event. I would simply reject it upon entry and have the user attempt it again. The semantic seems weird to say “Please take my order and do not match it even though it would do so currently. Please match it once the price has moved away and then come back to the price of my order.”
On a general note, hidden orders can be expressed with 1138 DisplayQty=0 which is the tag to identify a reserve order.
Regards,
Hanno.Some basic order behavior questions:
-do 18=6 (participate don’t initiate) orders behave as “post-only” (ie. will only be providers and never takers)?
-as i assume that they do, is it required/preferred that they be “non-display” orders so that they can lock or cross the market when another 18=6 order is resting on the book?
-what is the standard tag used to denote “non-display”?
-since default day order behavior is aggressive (ie. will take if liquidity is available), will it retain its aggressive behavior when no liquidity is available to hit and it posts to the book? (ie. if a post-only order on the other side comes in, will it aggress on that order?) Or does its behavior become passive when it posts? (ie. will it prevent interaction with a new incoming non-display post-only order on the other side?)
-if it retains its aggressive nature while being posted on the book, will a new incoming day order (aggressive by nature) be rejected for locking/crossing the market? or will the new incoming day order take and the posted order provide?
Chris,
I am aware of the fee implications of taker vs provider. I am afraid I do not get the concept of a maintaining the notion of a taker on a posted order and the connection with a day TIF. This would result in an order book with some orders marked as takers and others marked as providers and implies that the notion statically applies.
The taker notion can only apply as part of a workflow, i.e. the entry, modification or triggering of an order. If the owner of an order wants to avoid being the taker, he can attach a “post-only” attribute which can be used by the matching engine to determine whether to accept or reject the requested transaction. If an order is not “post-only” then the submitter risks being executed. In the case of not being executed, why would you penalize him by putting his order on the book but mandating that his order must always be a taker? You become a provider by entering the book without execution. The next order from a submitter who is not willing to take the execution risk should be rejected and not executed against the resting order whose submitter originally was willing to take the execution risk. The willingness to take the execution risk is a dynamic element that is expressed at the time of order submission based on the current order book and is limited to that point in time. A resting order is subject to a moving market so that you should not assume that the owner is willing to still be a taker when his order eventually becomes executable (you called this “keep original order behavior intention”). There is no reason not to execute the resting order if another order comes in from someone who is also willing to take the execution risk. For me this is not a “taker to taker” match.
Maybe I am just not familiar with the flow you are describing. Is there an electronic marketplace that maintains the notion of taker for the lifetime of the order if so expressed upon entry?
The attribute driving the fee calculation cannot be statically assigned to an order prior to its execution. It has to be assigned when it is executed and it is specific to the execution, not to the order. An order can be partially filled upon entry as taker and subsequently filled multiple times as provider, hence the order is then both a taker and a provider. The post-only attribute is specific to the order and prevents it from being executed as a taker in general.
Regards,
Hanno.
Hanno,
Thanks for your reply.
You answered my 18=6 behavior question and my ‘non-display’ tag question.
The nature of the aggressor vs. provider question is with regards to respecting the difference in provide vs. take fees/rebates which would potentially cause clients to want to lock/cross the market. This creates a scenario in which it would be preferable to keep original order behavior intention, encouraging true matches, and not discouraging liquidity.
It seems that through the use of optional ‘non-display’ stipulation, liquidity would not be discouraged by allowing orders to rest even if locking/crossing the market.
The question then remains:
-How can you respect the notion of ‘taker’ and still respect the notion of ‘day TIF’? If you convert an order from a taker to post-only (ie. provider), then this discourages a true match if a new post-only order from a provider comes in since it will reject the order.
However, if you maintain the notion of ‘taker’ on a posted order, then a new order from another ‘taker’ will not be able to hit it and will be rejected. This is the dilemma. Perhaps a custom ‘auto-aggress’ tag is the best solution, albeit still imperfect.
Hanno,
This is a valid point and I appreciate your input.
Chris,
I am aware of the fee implications of taker vs provider. I am afraid I do not get the concept of a maintaining the notion of a taker on a posted order and the connection with a day TIF. This would result in an order book with some orders marked as takers and others marked as providers and implies that the notion statically applies.
The taker notion can only apply as part of a workflow, i.e. the entry, modification or triggering of an order. If the owner of an order wants to avoid being the taker, he can attach a “post-only” attribute which can be used by the matching engine to determine whether to accept or reject the requested transaction. If an order is not “post-only” then the submitter risks being executed. In the case of not being executed, why would you penalize him by putting his order on the book but mandating that his order must always be a taker? You become a provider by entering the book without execution. The next order from a submitter who is not willing to take the execution risk should be rejected and not executed against the resting order whose submitter originally was willing to take the execution risk. The willingness to take the execution risk is a dynamic element that is expressed at the time of order submission based on the current order book and is limited to that point in time. A resting order is subject to a moving market so that you should not assume that the owner is willing to still be a taker when his order eventually becomes executable (you called this “keep original order behavior intention”). There is no reason not to execute the resting order if another order comes in from someone who is also willing to take the execution risk. For me this is not a “taker to taker” match.
Maybe I am just not familiar with the flow you are describing. Is there an electronic marketplace that maintains the notion of taker for the lifetime of the order if so expressed upon entry?
The attribute driving the fee calculation cannot be statically assigned to an order prior to its execution. It has to be assigned when it is executed and it is specific to the execution, not to the order. An order can be partially filled upon entry as taker and subsequently filled multiple times as provider, hence the order is then both a taker and a provider. The post-only attribute is specific to the order and prevents it from being executed as a taker in general.
Regards,
Hanno.Hanno,
Thanks for your reply.
You answered my 18=6 behavior question and my ‘non-display’ tag question.
The nature of the aggressor vs. provider question is with regards to respecting the difference in provide vs. take fees/rebates which would potentially cause clients to want to lock/cross the market. This creates a scenario in which it would be preferable to keep original order behavior intention, encouraging true matches, and not discouraging liquidity.
It seems that through the use of optional ‘non-display’ stipulation, liquidity would not be discouraged by allowing orders to rest even if locking/crossing the market.
The question then remains:
-How can you respect the notion of ‘taker’ and still respect the notion of ‘day TIF’? If you convert an order from a taker to post-only (ie. provider), then this discourages a true match if a new post-only order from a provider comes in since it will reject the order.
However, if you maintain the notion of ‘taker’ on a posted order, then a new order from another ‘taker’ will not be able to hit it and will be rejected. This is the dilemma. Perhaps a custom ‘auto-aggress’ tag is the best solution, albeit still imperfect.