[This message was posted by Jim Kaye of Bank of America Merrill Lynch 
<[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/1098e8b8 - PLEASE DO NOT REPLY BY MAIL.]

Based on the requirement that the allocations for the individual legs of a 
multi-leg order may be different for each leg, then I would proceed on the 
basis that we'll add the same allocation leg functionality available on the new 
order message to the allocation instruction message.

I think there's a separate question as to why you'd need to regular allocation 
block on the new order multi-leg message (it seems somewhat duplicative to have 
both), so if you can think of a reason for that, then let me know. I wouldn't 
actually recommend removing it, instead adding clarififying comments to the 
specification to indicate that only one or the other should be used.

Jim.

> 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.

Reply via email to