Imported from previous forum
Hi all,
for a trailing stop (loss) order (ExecInst = a) one can set the stop price offset in tag 211 (FIX 4.3 PegDifference/ FIX 4.4 PegOffsetValue).
For a trailing stop limit order one has to set a limit price or limit price offset as well. Is there a standard way to set the limit price or the offset for the limit price?
If there’s no standard way to set the limit price what would be the best way to do it?
I’m thinking about to send the limit price offset in tag 44 (Price).
Regards
Oliver
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> for a trailing stop (loss) order (ExecInst = a) one can set the stop
price offset in tag 211 (FIX 4.3 PegDifference/ FIX 4.4 PegOffsetValue).
For a trailing stop limit order one has to set a limit price or limit
price offset as well. Is there a standard way to set the limit price or
the offset for the limit price?If there’s no standard way to set the limit price what would be the best
way to do it?I’m thinking about to send the limit price offset in tag 44 (Price).
That’s a very good question.
You mention two scenarios; one with an offset limit price, and one with a fixed limit price. I think it calls into question the definition of trailing stop limit; is a trailing stop limit order:
One that, when triggered, results in a limit order that is priced relative to something?
One that, when triggered, results in a limit order placed at a previously specified price?
One whose range of motion of the trailing trigger price is limited?
The OMS that my firm develops has trailing stop limit emulation. We consider limit price an offset, and it is relative to the tick that triggers the stop. (It could also be relative to the trail price; the two aren’t the same if the instrument gaps over the trigger price without touching it.)
In FIX, we would represent, say, a trailing sell stop with a 10 cent trail amount as Side=2 OrdType=P ExecInst=a PegDifference=-0.10 however we reached an impasse with representing the limit offset in FIX. So while we can accept trailing stops via FIX, trailing stop limits are only available via our GUI. I’m very interested that you are asking about this; if multiple firms have identified this gap in the protocol, then it means there’s a business need to consider adding this functionality to the spec.
Using the Price field for a limit offset on a trailing stop is, in my view, inappropriate. Its type is Price, which represents an absolute price, while we need another field in the message that, like PegDifference, would be of type PriceOffset. To support this, I think the protocol would need, say, two fields:
TrailingStopLimitInst (enum, 1 = Relative to triggering tick, 2 = Relative to trailing stop price)
TrailingStopLimitOffset (of type PriceOffset)
Then, say, Side=2 OrdType=P ExecInst=a PegDifference=-0.10 TrailingStopLimitInst=1 TrailingStopLimitOffset=-0.05 would be a trailing stop to sell an instrument if its price drops 10 pennies, and would do so by sending a limit order to sell priced 5 more pennies below the tick that triggered it.
Now you also mentioned a case of an absolute limit price. I’m not familiar with this. I believe that with most pegged orders, the Price field has the meaning of specifying a limit beyond which the pegged price can no longer move. I’m wondering if this would be of use with your fixed price example?
for a trailing stop (loss) order (ExecInst = a) one can set the stop
price offset in tag 211 (FIX 4.3 PegDifference/ FIX 4.4
PegOffsetValue).For a trailing stop limit order one has to set a limit price or limit
price offset as well. Is there a standard way to set the limit price
or the offset for the limit price?If there’s no standard way to set the limit price what would be the
best way to do it?I’m thinking about to send the limit price offset in tag 44 (Price).
That’s a very good question.
You mention two scenarios; one with an offset limit price, and one with
a fixed limit price. I think it calls into question the definition of
trailing stop limit; is a trailing stop limit order:One that, when triggered, results in a limit order that is priced
relative to something?One that, when triggered, results in a limit order placed at a
previously specified price?One whose range of motion of the trailing trigger price is limited?
We emulate a trailing stop limit order in our OMS with a limit price relative to the stop price. One has to set an absolute stop price, limit price and a reference price. The emulator calculates the stop and limit price offsets with the reference price. When the market is changing the emulator adjusts the stop and limit prices. That’s why I considered to send an absolute limit price.
The OMS that my firm develops has trailing stop limit emulation. We
consider limit price an offset, and it is relative to the tick that
triggers the stop. (It could also be relative to the trail price; the
two aren’t the same if the instrument gaps over the trigger price
without touching it.)In FIX, we would represent, say, a trailing sell stop with a 10 cent
trail amount as Side=2 OrdType=P ExecInst=a PegDifference=-0.10 however
we reached an impasse with representing the limit offset in FIX. So
while we can accept trailing stops via FIX, trailing stop limits are
only available via our GUI. I’m very interested that you are asking
about this; if multiple firms have identified this gap in the protocol,
then it means there’s a business need to consider adding this
functionality to the spec.
Using the Price field for a limit offset on a trailing stop is, in my
view, inappropriate. Its type is Price, which represents an absolute
price, while we need another field in the message that, like
PegDifference, would be of type PriceOffset. To support this, I think
the protocol would need, say, two fields:TrailingStopLimitInst (enum, 1 = Relative to triggering tick, 2 =
Relative to trailing stop price)TrailingStopLimitOffset (of type PriceOffset)
Then, say, Side=2 OrdType=P ExecInst=a PegDifference=-0.10
TrailingStopLimitInst=1 TrailingStopLimitOffset=-0.05 would be a
trailing stop to sell an instrument if its price drops 10 pennies, and
would do so by sending a limit order to sell priced 5 more pennies below
the tick that triggered it.
I agree to use the Price tag for the limit price offset is not a good idea, so I think the introduction of TrailingStopLimitInst and TrailingStopLimitOffset would be the best solution.
Now you also mentioned a case of an absolute limit price. I’m not
familiar with this. I believe that with most pegged orders, the Price
field has the meaning of specifying a limit beyond which the pegged
price can no longer move. I’m wondering if this would be of use with
your fixed price example?