Imported from previous forum
[ original email was from jim whitehead - jwhitehead@latentzero.com ]
Has the following come up before and does anyone have views on the following?
Amending Algos - Currently I’m fine with a Cancel/Replace mesage being used to update the regular FIX tags and also being used to update the parameters of the current algo strategy.
But should a cancel/replace message allow the replacement of one algo strategy with another supplied by that broker? By default I’d like to say yes and stay as flexible as possible but i’m also away that some brokers have a ‘DMA’ algo strategy which may involve the amend message going down a separate pipe to the original algo which could be problematic.
Thanks in advance for your help
Jim
From a Programmers point of view, an Algo Cancel-Replace (CR) can be made to work.
Lets take an example :-
The original algo order is called Killer and has a set of algo Tags set-K. The new order to replace killer is a Mercenary algo has a set of algo Tags set-M. The algo CR message has all tags from Set-M for the creation of the Mercenary order. In contrast, if one Killer algo order were to be replaced with another Killer algo order, all tags from set-K would be needed in the CR message. To keep the solution generic from the FIX Engine’s point of view, tags from both sets K and M should be present (without duplicates except in repeating groups) because the FIX Engine would not know if the CR message changes the strategy itself or only changes values within the same strategy.
Regarding
[start quote] some brokers have a ‘DMA’ algo strategy which may involve the amend message going down a separate pipe to the original algo which could be problematic. [end quote]
From the order generation side this can be handled as
send a Cancel, wait preset time interval for response,
if response is cancel accepted, send new strategy order,
else if response is cancel rejected, take the executions,
else if respose is unknown and timeout happens,
either take risk and place new strategy
or re-evaluate strategy
The above logic assumes that Cancel for an algo would go down the same pipe as the original order.
Internally, a Sell side system (desination of algo orders) honouring a algo cancel-replace request would try to cancel the original algo and place the new new algo on the market applying logic as below
if original algo fully executed, send cancel-replace reject with Too Late to Cancel followed by execs
else cancel unexecuted quantity and accept new algo strategy
For an algo cancel-replace, is there a way to specify the quantity of the new algo order as carry forward the unexecuted quantity from the original order? For example :- I start the day with a plan to buy 100,000 shares of Ticker XYZ and place a “Dagger” strategy on the market, Midway thru its execution, I decide to “switch” to a different strategy “Stealth”. When my Stealth order goes to the market to replace the Dagger, I would like it to know how much quantity to carry forward, ie the leaves quantity of the exiting Dagger order would be the Order quantity of the new Stealth order. This way, I could switch algos while ensuring my total order quantity is maintained.
Regards,
K. Mahesh
Note :- Algo strategy names used in this Message are not real 
Has the following come up before and does anyone have views on the
following?Amending Algos - Currently I’m fine with a Cancel/Replace mesage being
used to update the regular FIX tags and also being used to update the
parameters of the current algo strategy.But should a cancel/replace message allow the replacement of one algo
strategy with another supplied by that broker? By default I’d like to
say yes and stay as flexible as possible but i’m also away that some
brokers have a ‘DMA’ algo strategy which may involve the amend message
going down a separate pipe to the original algo which could be
problematic.Thanks in advance for your help Jim
[ original email was from jim whitehead - jwhitehead@latentzero.com ]
Thanks for that , very interesting.
Good to see you’ve complied with the industry-standard of rambo-esque naming conventions 
From a Programmers point of view, an Algo Cancel-Replace (CR) can be
made to work.Lets take an example :-
The original algo order is called Killer and has a set of algo Tags set-
K. The new order to replace killer is a Mercenary algo has a set of algo
Tags set-M. The algo CR message has all tags from Set-M for the creation
of the Mercenary order. In contrast, if one Killer algo order were to be
replaced with another Killer algo order, all tags from set-K would be
needed in the CR message. To keep the solution generic from the FIX
Engine’s point of view, tags from both sets K and M should be present
(without duplicates except in repeating groups) because the FIX Engine
would not know if the CR message changes the strategy itself or only
changes values within the same strategy.Regarding
[start quote] some brokers have a ‘DMA’ algo strategy which may involve
the amend message going down a separate pipe to the original algo which
could be problematic. [end quote]From the order generation side this can be handled as
send a Cancel, wait preset time interval for response,
if response is cancel accepted, send new strategy order, else if
response is cancel rejected, take the executions, else if respose is
unknown and timeout happens, either take risk and place new strategy or
re-evaluate strategyThe above logic assumes that Cancel for an algo would go down the same
pipe as the original order.Internally, a Sell side system (desination of algo orders) honouring a
algo cancel-replace request would try to cancel the original algo and
place the new new algo on the market applying logic as belowif original algo fully executed, send cancel-replace reject with Too
Late to Cancel followed by execs else cancel unexecuted quantity and
accept new algo strategyFor an algo cancel-replace, is there a way to specify the quantity of
the new algo order as carry forward the unexecuted quantity from the
original order? For example :- I start the day with a plan to buy
100,000 shares of Ticker XYZ and place a “Dagger” strategy on the
market, Midway thru its execution, I decide to “switch” to a different
strategy “Stealth”. When my Stealth order goes to the market to replace
the Dagger, I would like it to know how much quantity to carry forward,
ie the leaves quantity of the exiting Dagger order would be the Order
quantity of the new Stealth order. This way, I could switch algos while
ensuring my total order quantity is maintained.Regards,
K. MaheshNote :- Algo strategy names used in this Message are not real
Has the following come up before and does anyone have views on the
following?Amending Algos - Currently I’m fine with a Cancel/Replace mesage being
used to update the regular FIX tags and also being used to update the
parameters of the current algo strategy.But should a cancel/replace message allow the replacement of one algo
strategy with another supplied by that broker? By default I’d like to
say yes and stay as flexible as possible but i’m also away that some
brokers have a ‘DMA’ algo strategy which may involve the amend message
going down a separate pipe to the original algo which could be
problematic.Thanks in advance for your help Jim
Most algo providers that I’ve seen who support Cancel/Replace that changes the strategy, simply end up treating it internally as a full cancel of the balance of the original strategy order and then treat the new strategy (leaves qty) as a different internal strategy order while still adhering to the Execution Report Order Qty, Cum Qty, etc. rules.
Has the following come up before and does anyone have views on the
following?Amending Algos - Currently I’m fine with a Cancel/Replace mesage being
used to update the regular FIX tags and also being used to update the
parameters of the current algo strategy.But should a cancel/replace message allow the replacement of one algo
strategy with another supplied by that broker? By default I’d like to
say yes and stay as flexible as possible but i’m also away that some
brokers have a ‘DMA’ algo strategy which may involve the amend message
going down a separate pipe to the original algo which could be
problematic.Thanks in advance for your help Jim
Has the following come up before and does anyone have views on the
following?Amending Algos - Currently I’m fine with a Cancel/Replace mesage being
used to update the regular FIX tags and also being used to update the
parameters of the current algo strategy.But should a cancel/replace message allow the replacement of one algo
strategy with another supplied by that broker? By default I’d like to
say yes and stay as flexible as possible but i’m also away that some
brokers have a ‘DMA’ algo strategy which may involve the amend message
going down a separate pipe to the original algo which could be
problematic.Thanks in advance for your help Jim
Interesting question. Actually, There are two ways to handle this functionality: the broker will assume a full cancel replace and replace all strategic parameters and if all parameters are not provided, the broker will insert the defualt (e.g. end time=end of market)
OR
the broker can simply change the parameter sent in the cxl/rpl and not change the other parameters from the original order.
It may sound complicated but it’s not. The certifcation can be pretty time consuming because one will have to cover many possible cases.
Has the following come up before and does anyone have views on the
following?Amending Algos - Currently I’m fine with a Cancel/Replace mesage being
used to update the regular FIX tags and also being used to update the
parameters of the current algo strategy.But should a cancel/replace message allow the replacement of one algo
strategy with another supplied by that broker? By default I’d like to
say yes and stay as flexible as possible but i’m also away that some
brokers have a ‘DMA’ algo strategy which may involve the amend message
going down a separate pipe to the original algo which could be
problematic.Thanks in advance for your help Jim
Jim,
In FIXatdl we never envisioned an “update” to be permissible across brokers or even within a single broker if the actual algo strategy was to be changed. These actions were always assumed to be a full cancel of the first order and a full new order as the replacement.
However, the cancel/replace functionality you describe might be presented to the trader via the OMS functionality as fully “integrated”. Under the hood however that functionality was expressed as a plain cancel message, followed by a brand new order message.
At FIXatdl we did however envision an “update” for a single broker, single algo strategy that was released and executing. For example: watching some simple variant of a TWAP algo strategy executing with a custom parameter set aggressiveness=“low”, the trader notes via standard FIX exception message stream coming back at him that his algo as initially specified, is not keeping up with his desire for actual “in the bag” executions. Trader wants to update that standing algo order to aggressiveness=“high” for the balance of the order quantity not yet already executed.
In FIXatdl there is a concept called mutable on cancel/replace that covers that. See the attribute at:
CORE.xsd parameter.parameter_t.mutableOnCxlRpl
type=“xs:boolean”
xs:documentation>Indication of whether the parameter’s value can be modified by a Cancel-Replace message.
Again, the idea is the “cancel/replace” message in this unique instance doesn’t interrupt the executing algo, however it does allow a parameter marked mutableOnCxlRpl=T to change in the middle of execution.
We also have the FIXatdl Pre Order Feedback Facility - that is used to send actual DRAFT algo parameters very rapidly to the target and get back pre trade analytic information based on exactly what parameters were entered into the algo order entry screens at the time the “feedback” button was pushed. That can be used repetitively by the trader “fiddling” with all the parameters of the algo and having the target give specific real-time feedback of how that set of parameters might go off in the market. The trader/broker can iterate very rapidly back and forth with that model. The idea being that after those iterations are done, the desired final algo parameters are then placed in the algo order, and that finalized order is released live to execution.
The Pre Order Feedback message is sent “out of band” meaning not down the FIX pipe, it goes over SSL Internet to the URL described in the FIXatdl file. We are currently writing it up as a “ridiculously simple” Web service - only one call “get feedback” and only read only information coming back from the target to be set to the traders GUI.
There is no way for the Pre Order Feedback facility to actually set the value of any parameter of what will later become a live algo order. The human trader must do that. (or the OMS be written to bypass that bit of human intervention) Perhaps more Web Service functionality in future versions (v2.0+ or later a few years out) but for now its very simple.
That being said there are some extremely interesting things that can be done with that Pre Order Feedback facility.
Rick