Hi All,
Interested to get some views on the use of the Commission Amount Sub Type and specifically 2 = other.
Do people associate this with soft/add-on when mapping the various supported values?:
‘0’ Unspecified
’1’ Acceptance
’2’ Broker
’3’ Clearing broker
’4’ Retail
’5’ Sales commission
’6’ Local commission
‘7” Research Payment
Thanks in advance
The intention was to have sub amount types for research payments where the business requirement was to single out RPA and CSA only and have a third value to express “research payment other than RPA and CAS”. Obviously, the other amount types you show above may also have subtypes where such a value “other” may make sense. That is not the case today, so we can cross that bridge when we come to it.
Also, if a third explicit value XYZ for research payment (in addition to RPS and CSA) were to come up, the semantic of the 2=other value needs to change to “research payment other than RPA and CAS and XYZ”.
I do not think we would want to have multiple values saying “other than …” but I am interested to hear what other people think about this. Should we have a generic subtype “other” that applies to explicit subtype values for the given type?
Thanks very much for getting back to me. I will feed this back internally and perhaps we can discuss this on the next CUB working group or PTWG meeting?
are the tags defined for below now ? I cant find any latest document. whatever found it says ‘tbd’ -
CommissionAmountSubType
AllocCommissionAmountSubType
The extension will be published shortly as EP 233. Tag numbers for the new fields have been pre-assigned as follows, please check the final publication to see if anything has changed.
CommissionAmountSubType(2725)
AllocCommissionAmountSubType(2726)
Datatype is int and valid values are
0 = Research payment account (RPA)
1 = Commission sharing agreement (CSA)
2 = Other type of research payment [Elaboration: A type of research payment other than RPA or CSA.]
Many Thanks !! One more question there - this tag series 26xx and 27xx are from FIX 5.0 SP2 version. Can these MiFID specific tags be used on FIX 4.4 if my whole setup is based on this version ?
Yes, the official FIX version policy is to use tags from higher versions whenever you can. If you cannot “convince” your FIX engine to accept tags from higher versions, you should first turn to user-defined fields in the range 8000-8499 (https://www.fixtrading.org/standards/user-defined-fields) which are issued by FIX for regulatory purposes. Only if that also fails, you should turn to user-defined fields in general, either in the range 5000-9999 as published by FIX or in the range 20000-39999 as defined by you.
Hi Hanno. For CommissionType Is the expected value/common practice for the broker’s execution services charges Commisiontype=2 (broker) as opposed to “6:local”. Thanks for your help.
The two commission types address different scenarios. CommissionAmountType(2641) = 6 (local) is defined in FIXimate (http://fiximate.fixtrading.org/latestEP/index.html) as “Commission paid to local broker in a cross-border transaction.”. If your use case does not relate to a cross-border transaction, this value does not apply. A broker’s execution services may be cross border or not.
Please see https://www.fixtrading.org/packages/ep204/ for further details.
I see EP#233 document is published but with confusions.
what are the valid values for 2656/2642 ?
why is 2655 tag strik’ed out completely ?
Doc says new field for 2726/2725 will be introduced for type of research payment, when ?
Every vendor/broker would be looking to see final tag and valid values published soon so that they can develop supporting code and do testing in their lower environments before Nov end (before usual code freeze for the year) to be ready for Jan-3rd .
As soon as an EP is published, a number of related artefacts are published as well. Furthermore, FIXimate (http://fiximate.fixtrading.org/latestEP/index.html) is upated to reflect the changes from the new EP. You will find tags 2656/2642 and 2726/2725 and their valid values in FIXimate. Please let me know where you have been looking for this information. It is important to always check the FIX website as golden source of any extensions.
You see the strikethrough of 2655 due to its redundancy in the Data Dictionary in the Gap Analysis. CommissionAmountType(2641) was extended with a new valid value 7=Research payment. AllocCommissionAmountType(2655) uses enums from tag 2641 and hence automatically receives this new value (fields are technically linked in the FIX Repository). The Gap Analysis is the basis for the implementation of the Extension Packs. It is only supposed to contain gaps that require a change in the FIX repository. Note that the published EP doc means that the extensions described in it are final and can be implemented by the community.
Thanks for your response. I see all I need in fiximate.