[This message was posted by John James of Self Employed <[email protected]> to the "Allocations" discussion forum at http://fixprotocol.org/discuss/13. You can reply to it on-line at http://fixprotocol.org/discuss/read/e4707ec9 - PLEASE DO NOT REPLY BY MAIL.]
Interesting !! Thanks for looking into that for me. So the question that now begs is what my best approach is ? I'd like to try and make sure that whatever I do is as future proof as can be. Its going to either be that the leg-level allocation will be removed from the new-order-multileg, or that it will be added to the other messages. Unless I hear otherwise I'm going to see if I can work using a model based on the latter. J > Right - I've taken a look at the 4.4 and 5.0 specs for multileg. You're > right, there is a leg-level allocation block on the new order multileg > message (in addition to the usual allocation block - not sure why we have > both). I don't think anybody on the Allocations Working Group at the time of > writing 4.4 was aware of the multileg allocation requirements so nothing was > added to this effect to the post-trade allocation messages. This sounds like > something we need to clean up. > > Jim. > > > Let me have a look into that - I'm not familiar with the NewOrderMultiLeg > > functionality. > > Jim. > > > > > Hi > > > Thanks for responding - that does help somewhat but as you say what it > > > means is you can't allocate individual legs in different ways... however > > > if you use the NewOrderMultileg message you can allocate the individual > > > legs in different ways (as each LegOrdGrp does contain a LegPreAllocGrp). > > > > > > So it looks as though you can preallocate the legs in different ways but > > > not post allocate them. And going on from that you can't use > > > AllocationReports (or TradeCapture either - as that has the same > > > limitation). > > > > > > So what I guess I'm concluding is that even though the NewOrderMultileg > > > does have allow individual leg allocations, it doesn't seem to be > > > supported across the other messages in the same manner. > > > > > > Any comments appreciated. > > > > > > thanks. > > > > > > > > > > Hello, > > > > > > > > It's been a while since I looked at this, but if my memory serves me > > > > correctly, the InstrmtLegGrp part of the message is part of the general > > > > 'instrument component block' which the allocation message will use to > > > > describe the instrument, in exactly the same way as you would on, say, > > > > a new order single. The allocations themselves are stored in the > > > > allocation repeating group part of the message, just as they would be > > > > for a single-leg instrument. What this does mean of course is that you > > > > can't allocate the individual legs in different ways (unless somebody > > > > since has identified a way to do this). Note that the AllocLinkId > > > > structure is there simply to support fragmentation of a single logical > > > > message into a number of physical messages (for systems that can't > > > > handle very large messages). Every InstrmntLegGrp block would need to > > > > be the same across each of those fragments. > > > > > > > > Hope this helps > > > > > > > > Jim. > > > > > > > > > > > > > Hi > > > > > This question was posted about 6 years ago but there were no replies > > > > > - hopefully there is some more insight on this now. > > > > > I'd like to understand the best approach is to specifying post trade > > > > > allocations on multileg orders - initially FX Swaps but this should > > > > > also be valid for more complex multileg orders. > > > > > > > > > > I'm looking at the 5.0SP2 specification but any help on use with > > > > > previous version is appreciated. > > > > > Looking at the AllocationInstruction message there seems to be an > > > > > InstrmtLegGrp component. There is also the AllocLinkID to link more > > > > > than one allocation instruction together. Functionally I think it > > > > > would be easier to use 1 allocation instruction containing all the > > > > > legs within it but that would make the use of AllocLinkID redundant. > > > > > > > > > > Any experience/thoughts/help greatly appreciated. > > > > > > > > > > thanks > > > > > J [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
