[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/600f3129 - PLEASE DO NOT REPLY BY MAIL.]

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