Good day everybody,
we are communicating as a buy side retail OMS client to a broker hub routing to international brokers/venues via FIX 4.4.
Due to some current lack of processing abilities our side uses the prime broker to let them compute the sum of all relevant fees and return this amount in a (partial) filled message type 35=8 represented in one NoMiscFeeGrp with a bilaterally agreed new FeeType (tag 139) = 1000.
So far so weired…
Second our buy side wants to instruct the broker on how to compute the sum in the Orderrequests (New, Modify) . There are only a handful of algorithms represented by a set of integer keys 1…x.
For this purpose one could easily turn on tag 13 and look for an approriate usage of the standard vaues or create biltarally agreed new key values far out eyond the standard range.
Unfortunately this is not possible.
Looking on the User Defines fields I came across reserved tag 6500 “Commission Handling Instructions” but it appears as “TBD”. What consequences are implied by the “TBD” attribute ?
Folks on both sides are now discussing about occupying and violating tag 494 (“Designation”). It has a free text field format. But 494 has has a sompletely different business background and sense iof usage. I think this is a typical example on how easily unaware people corrupt standards.
Does anyone have a reasonable solution to the specific demand and peculiar situation here ?
Would it be the least but most sensable solution to create a completely new user defined field for the very purpose requred ?
the usage of user-defined values are not permitted for MiscFeeType(139). Hence the solution bilaterally agreed with your prime broker is non-compliant. Based on the latest extension of this field (EP231, see https://www.fixtrading.org/packages/ep231/), there are now 36 different types. Maybe you can find a standard values that comes close enough to what your fee is about. It is standard FIX policy to be able to use messages, fields and valid values from higher versions if you cannot natively switch to this higher version.
Tag CommType(13) also does not permit bilaterally agreed values and has a different semantic compared to your business requirements of sending an instruction of how to calculate a fee. It “Specifies the basis or unit used to calculate the total commission based on the rate.” It is not about an algorithm.
Using a fee text field as a placeholder is a bad idea in general, especially if your usage semantics do not match at all. Almost every FIX message has a generic free text field Text(58) which could serve your purpose. I can understand if you want to avoid usage because it is probably already used for something else. FIX intentionally does not provide more than one generic text field.
You can always use a user-defined field and 6500 appears to have a name that represents your semantic. It was never fully defined by the submitter, hence the “TBD” for the applicable message types and “Future use” for the description. The submitter should have updated the information but more likely the “future use” never happened and the field was not given back to the community
There are no more user-defined fields available in the 5000-9999 range, only in the 20000 to 39999 range. However, the latter are not published by FIX and there is no guarantee of uniqueness, so you are better off with 6500.
The best solution is to get involved in one of the FIX working groups and submit a FIX Gap Analysis to cover a perceived gap. I did a quick search and could not find an existing standard solution but maybe others can also comment on this aspect. A FIX Gap Analysis results in a FIX Extension Pack (just like EP231 mentioned above).
and submit a FIX Gap Analysis to cover a perceived gap. I did a quick search and could not find an existing standard solution but maybe others can also comment on this aspect. A FIX Gap Analysis results in a FIX Extension Pack (just like EP231 mentioned above).