Imported from previous forum
[ original email was from matt simpson - MSIMPSON@cme.com ]
There are strong business reasons for supporting sub-allocations in FIX Allocation Model.
It’s often the case at the CME that a trade is executed on behalf of a firm who no longer has a presence in a given pit, or on the floor in general. This may also apply to electronic execution. In this case, the trade is executed by Firm A, on Firm B’s behalf. Firm A allocates the trade to Firm B who then accepts it and immediately sub-allocates it up to one or more customers belonging to Firm C.
Without a mechanism for sub-allocation, Firm B would be required to explicitly allocate the trade to Firm C after performing the initial acceptance. If a means of sub-allocation on the accept message is provided, Firm B can allocate the trade to one or more accounts at Firm C, thereby avoiding the necessity of submitting an additional Allocation message. The allure of the sub-allocation is that it brings us that much closer to true STP.
With regard to the Allocation message itself, it can provide support for the sub-allocation with an iterative SecondaryAllocBlock which allows the carry firm, Firm B in this case, to accept the allocation, and at the same time specify the firm, account, and accounttype to whom the order should be sub-allocated. The exchange/clearing org application handling the accept would be responsible for generating the Allocation message/s for the sub-allocation. The rules for unwinding an allocation, where the Firm C releases to Firm B and B in turn releases to A, would be enforced by the business system and would not require any special messaging requirements.
Finally, the sub-allocation is nearly identical to the process of performing an APS Accept and designating on that message who the sub-allocation carry firm will be. The current proposal provides support for this.
So for all these reasons, we feel that sub-allocation should be represented and supported by the FIX Allocation Model.