Imported from previous forum
In the documentation you mention an ExecInst=‘e’= “work to target strategy”. Does this flag still make sense in 5.0SP1?
Is the sell side supposed to ignore field TargetStrategy(847) if this field isn’t there or reject the order?
What is the point of having a flag that tells you to use an optional field?
In the documentation you mention an ExecInst=‘e’= “work to target
strategy”. Does this flag still make sense in 5.0SP1?Is the sell side supposed to ignore field TargetStrategy(847) if this
field isn’t there or reject the order?What is the point of having a flag that tells you to use an
optional field?
Tag 847 was a early attempt to enumerate every algo strategy offered as a straight enumeration.
1 VWAP
2 Participate (i.e. aim to be x percent of the market volume)
3 Mininize market impact
From a FIXatdl prospective that tag is obsolete. That approach (enumerate all strategies at FIX) proved impossible in the real world. It’s impossible for FIX to be the central reposiory of every algo strategy (in every version and flavor) in a strict, neat enumeration.
In FIXatdl, the only thing you are guaranteed (by intention, don’t rely on XML to actually enforce this via “well formed and validating”) is, once you have selected a specific Target (the entity who will recieve the algo order), you are guaranteed that the algo strategy name PLUS the version number, is unique (like a KEY field). Across Targets there is no consistency, no guarantees.
Perhaps in time we can FIX standardize some generic algo strategies. For the moment however there is zero attempt.
In the documentation you mention an ExecInst=‘e’= “work to target
strategy”. Does this flag still make sense in 5.0SP1?Is the sell side supposed to ignore field TargetStrategy(847) if this
field isn’t there or reject the order?What is the point of having a flag that tells you to use an
optional field?Tag 847 was a early attempt to enumerate every algo strategy offered as
a straight enumeration.1 VWAP 2 Participate (i.e. aim to be x percent of the market volume) 3
Mininize market impactFrom a FIXatdl prospective that tag is obsolete. That approach
(enumerate all strategies at FIX) proved impossible in the real world.
It’s impossible for FIX to be the central reposiory of every algo
strategy (in every version and flavor) in a strict, neat enumeration.In FIXatdl, the only thing you are guaranteed (by intention, don’t rely
on XML to actually enforce this via “well formed and validating”) is,
once you have selected a specific Target (the entity who will recieve
the algo order), you are guaranteed that the algo strategy name PLUS the
version number, is unique (like a KEY field). Across Targets there is no
consistency, no guarantees.Perhaps in time we can FIX standardize some generic algo strategies. For
the moment however there is zero attempt.
Thanks for your response!
Currently we were going to use Strategy(6258) to specify strategies since our strategies have a string id anyway. Does this seem like a good idea or is there some better field?
The original question was: should we require a field ExecInst(18) with ‘e’ in it? It looks like you’re saying no.
We aren’t using FIXatdl (yet). Are there fields we should know about for strategy name/version.
Thanks for your response!
Currently we were going to use Strategy(6258) to specify strategies
since our strategies have a string id anyway. Does this seem like a good
idea or is there some better field?The original question was: should we require a field ExecInst(18) with
‘e’ in it? It looks like you’re saying no.We aren’t using FIXatdl (yet). Are there fields we should know about for
strategy name/version.
Are there fields we should know about for strategy name/version.
Yes there are FIXatdl fields, but no there are not yet any FIX permanently assigned integer tags to them. There are three that YOU DECIDE the FIX integer tag you want to use:
strategies.strategIdentifierTag – fix tax number that will carry the strategyName
strategies.versionIdenfiferTag - – fix tax number that will carry the version number
strateges.draftIdentifierTag - fix tag number that optionally carries a TRUE. When TRUE the target does not execute that order, its only a draft, and expires NEVER executed. Its “dead” and never comes alive again. Its a one way transmission of an order idea. It also has an OMS generated orderID number. The Target can then possibly go to the BD over SSL and see some pretrade analytics on that order Idea. From there a fresh order would have to be created with a fresh orderID with out any TRUE in this tag for an order to be processed.
Further,
Each strategy has a has a string name that must be unique
strategy.name
[A-Za-z][A-Za-z0-9_]{1,255}
Version is optional but highly recommended
strategy.version
any string
The OMS must transmit the strategy name on the strategies.versionIdenfiferTag and optional (but highly recommend) the version on the strategies.versionIdenfiferTag
FIXatdl right now is agnostic on which FIX tags you select to send these values. However in the future we will probably ask the GTC to assign three tags dedicated to those purposes. One of those MAY be Tag 847 repurposed from integer to string for the Strategy Name UNIQUE [A-Za-z][A-Za-z0-9_]{1,255}
ExecInst(18) with ‘e’ in it? It looks like you’re saying no.
Correct. In FIXatdl we assume you are always “shooting real bullets” and want everything executed unless you take a specific action otherwise. Only when you include the OPTIONAL “TRUE” on the tag designated strateges.draftIdentifierTag does FIXatdl assume to hold off execution forever. It’s just away to transmit an IDEA to a BD and then “discuss the particulars” over the phone / via Internet, etc. Likewise we have away to import a trade IDEA back to the OMS, it then gets presented to the trader, he hits “send order” and all the validation/authorization built into the OMS can then run locally. The OMS may also apply whatever it deems appropriate at the time the trader tries to import an order IDEA into the system. The OMS and typically human trader are therefore, never, ever bypassed.
Rick