Hi,
Simple question (I hope) : if NoLegAllocs > 1 on a ExecutionReport (35=8), would you expect to receive a value in the Account (tag1) field? Should the Account tag (and a corresponding value) be omitted from the message, assuming that LegAllocAcct (671) is populated correctly?
Thanks.
That depends on the account structure / data model of the firm. The message NewOrderMultileg allows you to populate the nested LegPreAllocGrp as well as the root level Account(1) field. If this is the case then I would expect the ExecutionReport to look the same. However, these two are semantically different and should not be compared to each other. LegPreAllocGrp is about pre-allocation across multiple allocation accounts and needs to be seen together with PerAllocMlegGrp and AllocAccount(79). Account(1) on the other hand needs to be seen together with LegAccount(2680) and is used when you do not need to split up an execution across multiple allocation accounts.
Question is what the semantic of NewOrderMultileg is when both (for each pair mentioned above) are filled. I would be interested to hear from others if they have use cases for this. Currently, FIX does not exclude that both exist, i.e. there is no conditional requirement that one or the other needs to be empty.
In my experience trading venues use the Account(1) field in order messages as a single-instance pre-allocation account - either final or temporary if allocations will come post-trade. In that scenario you would omit Account(1) given that your multi-leg trade is being allocated on fill.
Finally, if you are connecting to an existing platform it’s best to ask about their policy. If you are writing a new ROE then you should document your policy.
Thanks for your replies.
Sorry, I should have stated that I’m using FIX4.4.
I believe some of fields you mention are part of 5.0 onwards? In any case, I am sending orders to the exchange as pre-allocated (i.e. a single MultiLeg order having multiple Leg Allocations). I specify the individual accounts and expect to receive the same ‘structure’ back on the single execution report. I assume I’ve understood the concept of pre-allocation correctly.
Yes, FIX 5.0 starts with tag 957 but the pre-allocation fields relevant to you should all be within FIX 4.4. What to expect back in case of multileg orders depends on the existence/setting of MultilegReportingType(442) on the ExecutionReport. It should always be provided in case of multi-leg orders as the default is 1=“Single security” when it is not present, i.e. it is not a multi-leg order in the first place.
Value 2=“Individual leg of a multi-leg security” would mean that you get one ExecutionReport message per leg. The allocations for this leg would be contained in the repeating group .
Value 3=“Multi-leg security” would mean that you only get a single ExecutionReport message. The allocations for this leg would be contained in the repeating group which is part of the repeating group .