Imported from previous forum
Our stock exchange trading engine generates stop activation messages when the stop price is reached. Does anyone know any cases of FIX 4.2 implementations where an exchange (or ECN)would generate a FIX message to reflect this scenario? Potentially, this could be useful for Stop Limit orders. However, I understand that generating a second confirmation (39=0) when this happens would not be FIX compliant…
Please advise
jek
[ original email was from Michael Katkin - michael.katkin@transacttools.net ]
> Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX 4.2
implementations where an exchange (or ECN)would generate a FIX message
to reflect this scenario? Potentially, this could be useful for Stop
Limit orders. However, I understand that generating a second
confirmation (39=0) when this happens would not be FIX compliant…
Please advise jek
One of our exchange customers does this. When the order is triggered they send an acknowledgement execution report with OrdType (tag 40) set to “1” for stop orders and “2” for stop limit orders. Although this FIX scenario is not explicitly covered, the message used is FIX compliant.
Michael Katkin
TransactTools
Professional Services
Phone: 1.212.584.2472
Michael Katkin
TransactTools
Professional Services
Phone: 1.212.584.2472
This sounds like a good idea and when set as an optional session parameter could provide additional functionality without raising any FIX compliance issues.
Thanks for your help.
Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX 4.2
implementations where an exchange (or ECN)would generate a FIX message
to reflect this scenario? Potentially, this could be useful for Stop
Limit orders. However, I understand that generating a second
confirmation (39=0) when this happens would not be FIX compliant…
Please advise jekOne of our exchange customers does this. When the order is triggered
they send an acknowledgement execution report with OrdType (tag 40) set
to “1” for stop orders and “2” for stop limit orders. Although this FIX
scenario is not explicitly covered, the message used is FIX compliant.Michael Katkin TransactTools Professional Services Phone: 1.212.584.2472
Michael Katkin TransactTools Professional Services Phone: 1.212.584.2472
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX 4.2
implementations where an exchange (or ECN)would generate a FIX message
to reflect this scenario? Potentially, this could be useful for Stop
Limit orders. However, I understand that generating a second
confirmation (39=0) when this happens would not be FIX compliant…
Please advise jek
I don’t believe that there are any standard FIX-defined methods for representing a triggered stop. Since some firms have implemented mutually incompatible representations, it makes sense that FPL should standardize something for the next protocol release.
While I can see a need for defining something in the spec, it can’t be mandatory. Some exchanges, ECNs, execution systems, other order routing protocols that might be translated to/from FIX, etc. don’t differentiate between non-triggered and triggered stops. So it must always be legal for a stop order to be acknowledged immediately as New, trigger without notice to the client, and then trade.
I would suggest that a new ExecType of “Triggered” be created for the next FIX version. Message flow would be as follows:
→ New Order Single
← Execution Report, OrdStatus = New, ExecType = New [Immediately]
[time passes]
← Execution Report, OrdStatus = New, ExecType = Triggered [Optional]
← Execution Report, OrdStatus = Filled, ExecType = Trade
OrdType in this case would still stay Stop or Stop Limit throughout the life of the order and would not switch to Market or Limit.
This also could be used for the Trailing Stop Peg type, which acts very much like a stop order.
While an argument could be made that “Triggered” represents not just an event but also a state, and that there should be a place for it in the OrdStatus enumerations as well, I’d caution against doing so because it would introduce more complexity without much added value.
[ original email was from Francesc Prats - fprats@meff.com ]
In FIX 4.4 can be used the tag 636 (WorkingIndicator) to say if a stop/stop limit order is NOT triggered (636 = N) or has been triggered (636 = Y).
Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX 4.2
implementations where an exchange (or ECN)would generate a FIX message
to reflect this scenario? Potentially, this could be useful for Stop
Limit orders. However, I understand that generating a second
confirmation (39=0) when this happens would not be FIX compliant…
Please advise jekI don’t believe that there are any standard FIX-defined methods for
representing a triggered stop. Since some firms have implemented
mutually incompatible representations, it makes sense that FPL should
standardize something for the next protocol release.While I can see a need for defining something in the spec, it can’t be
mandatory. Some exchanges, ECNs, execution systems, other order routing
protocols that might be translated to/from FIX, etc. don’t differentiate
between non-triggered and triggered stops. So it must always be legal
for a stop order to be acknowledged immediately as New, trigger without
notice to the client, and then trade.I would suggest that a new ExecType of “Triggered” be created for the
next FIX version. Message flow would be as follows:→ New Order Single ← Execution Report, OrdStatus = New, ExecType = New
[Immediately] [time passes] ← Execution Report, OrdStatus = New,
ExecType = Triggered [Optional] ← Execution Report, OrdStatus = Filled,
ExecType = TradeOrdType in this case would still stay Stop or Stop Limit throughout the
life of the order and would not switch to Market or Limit.This also could be used for the Trailing Stop Peg type, which acts very
much like a stop order.While an argument could be made that “Triggered” represents not just an
event but also a state, and that there should be a place for it in the
OrdStatus enumerations as well, I’d caution against doing so because it
would introduce more complexity without much added value.
For electronic markets description of the value ‘Y’ in this tag indicates that the order has transitioned from a contingent to a market order. This implies that in the case of stop limit orders the stock exchange application would always send two OrdStatus=0(New) execution reports i.e. first one when received and the second when triggered (unless the stop got activated straight away)? If this is the case would 636 be the only tag where the value changes from one execution report to the next?
Thanks
In FIX 4.4 can be used the tag 636 (WorkingIndicator) to say if a
stop/stop limit order is NOT triggered (636 = N) or has been triggered
(636 = Y).Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX
4.2 implementations where an exchange (or ECN)would generate a FIX
message to reflect this scenario? Potentially, this could be useful
for Stop Limit orders. However, I understand that generating a
second confirmation (39=0) when this happens would not be FIX
compliant… Please advise jekI don’t believe that there are any standard FIX-defined methods for
representing a triggered stop. Since some firms have implemented
mutually incompatible representations, it makes sense that FPL should
standardize something for the next protocol release.While I can see a need for defining something in the spec, it can’t be
mandatory. Some exchanges, ECNs, execution systems, other order
routing protocols that might be translated to/from FIX, etc. don’t
differentiate between non-triggered and triggered stops. So it must
always be legal for a stop order to be acknowledged immediately as
New, trigger without notice to the client, and then trade.I would suggest that a new ExecType of “Triggered” be created for the
next FIX version. Message flow would be as follows:→ New Order Single ← Execution Report, OrdStatus = New, ExecType =
New [Immediately] [time passes] ← Execution Report, OrdStatus = New,
ExecType = Triggered [Optional] ← Execution Report, OrdStatus =
Filled, ExecType = TradeOrdType in this case would still stay Stop or Stop Limit throughout
the life of the order and would not switch to Market or Limit.This also could be used for the Trailing Stop Peg type, which acts
very much like a stop order.While an argument could be made that “Triggered” represents not just
an event but also a state, and that there should be a place for it in
the OrdStatus enumerations as well, I’d caution against doing so
because it would introduce more complexity without much added value.
[ original email was from Francesc Prats - fprats@meff.com ]
Exactly, Jurek.
In other words is like considering the combination of “OrdStatus=New + Working Indicator=N” as a “Pending Triggered” Status.
For electronic markets description of the value ‘Y’ in this tag
indicates that the order has transitioned from a contingent to a market
order. This implies that in the case of stop limit orders the stock
exchange application would always send two OrdStatus=0(New) execution
reports i.e. first one when received and the second when triggered
(unless the stop got activated straight away)? If this is the case would
636 be the only tag where the value changes from one execution report to
the next? ThanksIn FIX 4.4 can be used the tag 636 (WorkingIndicator) to say if a
stop/stop limit order is NOT triggered (636 = N) or has been triggered
(636 = Y).Our stock exchange trading engine generates stop activation
messages when the stop price is reached. Does anyone know any
cases of FIX
4.2 implementations where an exchange (or ECN)would generate a FIX
message to reflect this scenario? Potentially, this could be
useful for Stop Limit orders. However, I understand that
generating a second confirmation (39=0) when this happens would
not be FIX compliant… Please advise jekI don’t believe that there are any standard FIX-defined methods for
representing a triggered stop. Since some firms have implemented
mutually incompatible representations, it makes sense that FPL
should standardize something for the next protocol release.While I can see a need for defining something in the spec, it can’t
be mandatory. Some exchanges, ECNs, execution systems, other order
routing protocols that might be translated to/from FIX, etc. don’t
differentiate between non-triggered and triggered stops. So it must
always be legal for a stop order to be acknowledged immediately as
New, trigger without notice to the client, and then trade.I would suggest that a new ExecType of “Triggered” be created for
the next FIX version. Message flow would be as follows:→ New Order Single ← Execution Report, OrdStatus = New, ExecType =
New [Immediately] [time passes] ← Execution Report, OrdStatus =
New, ExecType = Triggered [Optional] ← Execution Report, OrdStatus
= Filled, ExecType = TradeOrdType in this case would still stay Stop or Stop Limit throughout
the life of the order and would not switch to Market or Limit.This also could be used for the Trailing Stop Peg type, which acts
very much like a stop order.While an argument could be made that “Triggered” represents not just
an event but also a state, and that there should be a place for it
in the OrdStatus enumerations as well, I’d caution against doing so
because it would introduce more complexity without much added value.
Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX 4.2
implementations where an exchange (or ECN)would generate a FIX message
to reflect this scenario? Potentially, this could be useful for Stop
Limit orders. However, I understand that generating a second
confirmation (39=0) when this happens would not be FIX compliant…
Please advise jekI don’t believe that there are any standard FIX-defined methods for
representing a triggered stop. Since some firms have implemented
mutually incompatible representations, it makes sense that FPL should
standardize something for the next protocol release.While I can see a need for defining something in the spec, it can’t be
mandatory. Some exchanges, ECNs, execution systems, other order routing
protocols that might be translated to/from FIX, etc. don’t differentiate
between non-triggered and triggered stops. So it must always be legal
for a stop order to be acknowledged immediately as New, trigger without
notice to the client, and then trade.I would suggest that a new ExecType of “Triggered” be created for the
next FIX version. Message flow would be as follows:→ New Order Single ← Execution Report, OrdStatus = New, ExecType = New
[Immediately] [time passes] ← Execution Report, OrdStatus = New,
ExecType = Triggered [Optional] ← Execution Report, OrdStatus = Filled,
ExecType = Trade
With an ExecType Triggered you have no possibility to check with an order status request if an order is triggered or not. As the order status request is often used for recovery I think changing the order type from stop order to limit order is the better solution.
OrdType in this case would still stay Stop or Stop Limit throughout the
life of the order and would not switch to Market or Limit.This also could be used for the Trailing Stop Peg type, which acts very
much like a stop order.While an argument could be made that “Triggered” represents not just an
event but also a state, and that there should be a place for it in the
OrdStatus enumerations as well, I’d caution against doing so because it
would introduce more complexity without much added value.
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
I believe that since the introduction of FIX 4.3 a Stop Order is indicated using the WorkingIndicator (636). Since 4.4 (i’m no 4.3 expert) you preferably use:
- Execution Report for order waiting to be triggered:
- OrdStatus (39) = 0 (New)
- WorkingIndicator (636) = N (Order has been accepted but is not yet in a working state)
- Execution Report when the order is activated/triggered but not filled or otherwise changing status:
- OrdStatus (39) = 0 (New)
- WorkingIndicator (636) = Y (Order is currently being worked)
The FIX spec explicitly states that the WorkingIndicator is only applicable in OrdStatus = New. In all other statuses it is implicitly active or removed from the book as indicated by the OrdStatus tag.
I also support Ryan’s idea to introduce a “Triggered” ExecType in order to more clearly relay the event that the order is activated but not filled.
Our stock exchange trading engine generates stop activation messages
when the stop price is reached. Does anyone know any cases of FIX 4.2
implementations where an exchange (or ECN)would generate a FIX message
to reflect this scenario? Potentially, this could be useful for Stop
Limit orders. However, I understand that generating a second
confirmation (39=0) when this happens would not be FIX compliant…
Please advise jekI don’t believe that there are any standard FIX-defined methods for
representing a triggered stop. Since some firms have implemented
mutually incompatible representations, it makes sense that FPL should
standardize something for the next protocol release.While I can see a need for defining something in the spec, it can’t be
mandatory. Some exchanges, ECNs, execution systems, other order routing
protocols that might be translated to/from FIX, etc. don’t differentiate
between non-triggered and triggered stops. So it must always be legal
for a stop order to be acknowledged immediately as New, trigger without
notice to the client, and then trade.I would suggest that a new ExecType of “Triggered” be created for the
next FIX version. Message flow would be as follows:→ New Order Single ← Execution Report, OrdStatus = New, ExecType = New
[Immediately] [time passes] ← Execution Report, OrdStatus = New,
ExecType = Triggered [Optional] ← Execution Report, OrdStatus = Filled,
ExecType = TradeOrdType in this case would still stay Stop or Stop Limit throughout the
life of the order and would not switch to Market or Limit.This also could be used for the Trailing Stop Peg type, which acts very
much like a stop order.While an argument could be made that “Triggered” represents not just an
event but also a state, and that there should be a place for it in the
OrdStatus enumerations as well, I’d caution against doing so because it
would introduce more complexity without much added value.