Imported from previous forum
changeStrategyOnCxlRpl is defined as an optional attribute, however, the default value is not provided neither in XSD nor in FIXatdl-1.1 specification.pdf
Q. If the changeStrategyOnCxlRpl attribute is omitted in ATDL can a new strategy be chosen on modify?
changeStrategyOnCxlRpl is defined as an optional attribute, however, the default value is not provided neither in XSD nor in FIXatdl-1.1 specification.pdf
Q. If the changeStrategyOnCxlRpl attribute is omitted in ATDL can a new strategy be chosen on modify?
Thanks for the question. I can totally understand that its not entirely clear as of the moment.
In the original design of FIXatdl we ran up against fringe use cases and some “language” issues around the general FIX (not FIXatdl specific) cancel/replace technology. The term cancel/replace itself is problematic when it really means, sort of “update” what’s in place. Unfortunately FIXatdl further exacerbates the confusion.
Backing up a bit. The terms “Cancel and Replace” seem typically to imply, at least on the surface:
-
halt execution of the first order, wherever it is (immediate cancel)
-
replace that order with a new order that is 100% specified i.e. not short hand with just the changed parameters (immediate replace)
THEN, PERHAPS, on the EXECUTION END
- adjust the new order quantity for what has already executed on the first order. (and that’s where this all gets tricky…)
The most common “esoteric” cancel/replace use case we @ FIXatdl dealt with was a situation where some type of limit order was in a cue at an exchange where “first come, first served” priorities were granted. Some exchanges allowed very limited parameter changes to that standing limit order without loosing that time preferenced place in the cue.
To make matters worse FIXatdl crosses the bridge between the HCI and the FIX message wire. So does the OMS.
To a trader an OMS can easily make it “look” like he is updating a prior order, yet “under the OMS hood” its actually spitting out a full cancel message on the first order and a issuing a full replace message right behind it. To the trader it looks like one instruction, however to the FIX wire and exchange its actually received as two separate, 100% complete messages. Most of the time that’s exactly how they want to receive instructions - zero ambiguity and two time stamps.
The FIXatdl Stoddard “doesn’t know” what historical info the OMS keeps and if it can look up a prior order that is sill live and in process. Typically an OMS does a lookup, repopulates the original trader’s order screen, allows the trader to modify it, and then IT figures out how to send out the proper “cancel/replace” type message (as either one message or two).
In the above use case (where a place in a cue must be retained) the OMS looks up the original order, and IF the trader only tweaks the allowable parameters (so as not to loose his place in the cue, i.e. those parameters marked mutableOnCxlRpl) the FIX message that exits is a single “update”.
If the trader changes parameters that are not so marked (e.g. changes ticker, etc.) then TWO messages end up exiting the OMS - one to cancel the original order and the second to replace that with a ground up, entirely new order.
Frankly I don’t recommend traders change algo strategies “mid stream”. If they get nervous would rather they “tweak up” say an aggression parameter (marked mutableOnCxlRpl) to force things to move it along faster, etc. If they change strategies, at least in my mind, its better to shut down the old strategy and fully specify the replacement strategy.
Some of this may be related to the now dated:
847 TargetStrategy int (enums: 1 VWAP, 2 Participate (i.e. aim to be x percent of the market volume), 3 Minimize market impact etc.)
Not really sure of the what Greg is driving at with Strategies/@changeStrategyOnCxlRpl up at the strategies level but it may be related to the prior use of tag 847. He has it documented
“Indicates whether a new strategy can be chosen during a Cancel/Replace”
so its clear someone, some place, wants to somehow alter the strategy in place while holding some of the prior parameters fixed.
Unless there is the possibility of loosing a place in a cue would prefer they just take down the entire first order and build up from scratch (perhaps with the help of the OMS prepopulating the new order with the old order parameters) and sending out a 100% complete, fresh instruction.
On the other hand, if the algo MAKER designs A SINGLE algo that is able to “morph” while in execution mode, suggest that custom parameters be used that control exactly how the allowable morphing works. That way you have all the UI control (validation and flow) you need to help the trader make good morphing choices on his end. Mark the parameters that may be changed as mutableOnCxlRpl.
Greg however frequently has detailed knowledge of the more “off the trail” use cases and how FIXatdl can accommodate them. If you can post a reasonably detailed actual use case we may be able to give you a really good solution or at least a work around.
Rick
Thanks for following this.
I am an EMS developer. Our product historically had a set broker specific dialogs to enter strategy orders. A strategy dialog has “Strategy ID” drop-down list allowing user to select a strategy. A dialog can be opened in a “New” mode to enter a new strategy order. The same dialog can be opened when user wants to modify the algo order in a “Modify” mode. In the “Modify” mode of a strategy dialog some parameters can be disabled to prevent their modification. Some brokers specify in their FIX rules of engagements that changing strategy id itself is supported on Cancel/Replace. For such brokers the “Strategy ID” drop-down list is enabled in our “Modify” strategy dialog.
Behavior of every broker specific dialog is confirmed with broker during UAT test. The brokers who do not support the changing strategy ID on Cancel/Replace reject the Cancel/Replace request when the value in strategy ID tag is different from the original one.
For the past year more and more brokers started to provide the ATDL file together with a new version of their FIX strategy specifications. A generic ATDL dialog has been implemented in our GUI to replace the old set of the broker specific dialogs. The ATDL dialog can be opened for a strategy order modification. The ATDL dialog has the “Strategy ID” drop-down list. When the ATDL dialog is opened in “Modify” mode we use the value of “changeStrategyOnCxlRpl” attribute to enable/disable the “Strategy ID” drop-down list, allowing or preventing trader from changing strategy ID on modification. Therefore, whether the changeStrategyOnCxlRpl attribute is provided or not we have to decide to enable or disable the “Strategy ID” drop-down list. That is why we need a default value in the ATDL spec. For our implementation we assume this value is “false” just because is a safer assumption.
To avoid any misunderstanding we are trying to influence the brokers to explicitly specify changeStrategyOnCxlRpl attribute in their ATDL files, explaining the situation. So far it works.
However, at some point we can have two contradicting requirements from broker’s who are not willing to change their ATDL for us. One assuming that default value is “true”, second is “false”, both omitting this attribute on the basis that it is optional.
I think it is not good for ATDL as for a generic specification to have this kind of places for different understanding.
Sergey,
Thanks very much for the solid description, can really get a good feel for your exact situation.
Couple of in-line comments:
Behavior of every broker specific dialog is confirmed with broker during UAT test.
That is a very wise move! FIXatdl in its current incarnation does not eliminate all testing. While the FIXatdl spec is much tighter than free text, human language, written down on plain paper, its not a panacea in terms of “universal” protection. Plenty of room left for error.
Within FIXatdl we are constrained by XML itself and our very “rudimentary” rules system we enacted in the FLOW and VALIDATION areas.
Our VALIDATION concept was a “one time” batch style check that was to run after all fields were filled out and the “SEND ORDER” button was about to be pressed.
The FLOW area was to handle intermediate validation and branching during the order BUILD process - ahead of when the order was 100% complete. Much more comprehensive rules systems can be found but unfortunately they bring so much complexity with them we deemed them too “academic” for this industry at their current stage of limited, real-world deployment. Admittedly, that was a total judgment call. In the meantime by all means, TEST BEFORE DEPLOYING.
However, once you have a strategy all tested and you well know how it operates on both ends very well simple changes and updates to parameters are extremely easy. If you know the base strategy inside and out (and had done through testing on that) then small, incremental change from there, as expressed in a UPDATED FIXatdl file should require much less testing. Only the changed area from where you were needs to be examined in depth.
whether the changeStrategyOnCxlRpl attribute is PROVIDED or not we have to decide to enable or disable the “Strategy ID” drop-down list. That is why we need a default value in the ATDL spec. For our implementation we assume this value is “false” just because is a safer assumption.
I’m in total agreement with your assumption.
Suggest that the Algo WG officially consider closing the loop here in two three steps.
-
right now “unofficially” assume IF changeStrategyOnCxlRpl is omitted, THEN it’s FALSE.
-
Update the FIXatdl OFFICIAL DOCUMENTATION to reflect this.
-
At the next SCHEMA update consider having changeStrategyOnCxlRpl made REQUIRED with a DEFAULT of FALSE
If there were other viewpoints from readers of this forum I’d hope they would speak up ASAP. Given release schedules Step 2 might be accomplished in “months”, Step 3 might take up to a year or more, depending on where we are on other “errata” type items on v1.1.
The WG is not active on any MAJOR revision / update to the v1.1 schema. We of course are following all the Dodd-Frank and related change coming down the regulatory pike, but all that is likely at least a year away. Undoubtedly it will be a tsunami but we can’t really predict when that will finally swell up and hit the shoreline.
Rick
Thank you for the answer, Rick.
We will try to use this post as an extra argument to ask brokers to explicitly specify changeStrategyOnCxlRpl attribute in ATDL file or to assume it “false” if omitted.
Thanks for the comment on the validations and flows. So far, we do not have any problems with the strategy validations. The concept is clear enough. It seems the brokers can express in ATDL all rules they want in order to prevent a wrong order from being sent.
The flow control is very good tool as well. However, I would like to take this opportunity to describe one conceptual problem we have with the flow control. I call this problem “Restoring state of the unbound controls on Cancel/Replace”. The problem can be demonstrated on very common example of representing the “StartTime/EndTime” parameter on UI as two controls: CheckBox(or RadioButton) + Clock. InitValue of the checkbox usually set to “true” (checked). When CheckBox(or RadioButton) is checked (sometimes it means “Now” for StartTime) the clock is disabled and cleared using the flow. When unchecked, trader can enter the start time. Obviously, only the clock control is bound to StartTime parameter. It works find on “New strategy order” dialog. The problem is to restore the correct state of the unbound controls(such as the checkbox) when “Modify” dialog should be displayed to send Cancel/Replace request. The values of the bound controls (like “StartTime” clock) is restored fine from the FIX message using the fixTag. But what about the unbound controls? They do not have any direct data source to restore their values from. For the example above, the “Now” checkbox should be unchecked on “Modify” if the StartTime parameter has a value, and checked otherwise. It seems like some kind of invert flow logic should applied in this case to restore the values of the unbound control using the values of the bound controls. I am not sure if this problem can be solved generically.
Sergey.