A couple of firms have requested the ability to add N-level allocations to FpML 4.2. This basically means the ability to allocate a block trade to multiple allocation trades, and then allocate these in turn to other allocation trades (and so on if desired). The use case is a client that wishes to allocate a block trade to multiple prime brokers, and then within each prime broker to multiple accounts. In many cases only a part of the allocation process is visible to a given player (so the existing 4. 2 allocations are adequate); however in some cases it is necessary to aggregate all of the allocations across multiple prime brokers to completely reconcile the resulting trades. For these cases a multi-tier allocation model would be helpful. This requirement probably applies mostly to non-OTC instruments at the moment, however I understand from a major prime broker that this is a practice that is relatively new and is growing quickly, and so may also be used for OTC in the future. The reason for requesting N-level rather than 3-level is simply to accommodate any possible future allocation scheme, and on the theory that N is probably no harder than 3. I believe that this could be accommodated quite easily creating a new partyTradeIdentifier derived type (e.g. “BlockAndAllocationTradeIdentifier”) that includes the allocationTradeId element from BlockTradeIdentifier and the blockTradeId element from AllocationTradeIdentifier. All other semantics would be identical. Can we please discuss this request at the next MWG meeting? Brian Lynn, CTO Global Electronic Markets, <http://global-emarkets.com> http://global-emarkets.com High-speed FpML matching, reconciliation, and validation: <http://fpml-mediator.com> http://fpml-mediator.com
<<attachment: winmail.dat>>