Imported from previous forum
[ original email was from Aaron Pryce - aaron.pryce@citigroup.com ]
As we are moving towards a mass of industry implementation in the FIX allocations space, initially in 4.0/4.1 (FIX replaces FAX model)it would make sense to define a commonly accepted max. size for messages. An allocation message could become quite large if there were many repeating fields with large account numbers (especially if the max number of repeating fields negotiation fetaure in 4.2 is used). An overly large FIX message could slow down a FIX engines processing or worst case scenario cause a systems error.
Are there any thoughts on defining a maximum message size in relation to allocations?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Are there any thoughts on defining a maximum message size in relation to allocations?
In general, the FIX Protocol has evolved away from setting limits on things such as message size and number of messages in a session. Leaving these kinds of things up to counterparties means that FIX remains flexible enough to adapt to many business needs, although this comes at the cost of more details that counterparties must agree upon.
In practical terms, allocations don’t have to get too big, provided that both parties agree not to list each and every partial fill. This is especially important when trading with ECNs/Exchanges where one typically receives numerous partial fills. If you send just one allocation mesage per security per side, and don’t include the individual executions, the size of the message really only depends upon the number of accounts that will receive shares.
That does bring up a good point, though. In some circumstances, an order could have thousands of allocations on it(trust accounts; wrap accounts). The allocation message doesn’t have any way to support fragmentation, does it? Maybe it should.
> > Are there any thoughts on defining a maximum message size in relation to allocations?
>
> In general, the FIX Protocol has evolved away from setting limits on things such as message size and number of messages in a session. Leaving these kinds of things up to counterparties means that FIX remains flexible enough to adapt to many business needs, although this comes at the cost of more details that counterparties must agree upon.
>
> In practical terms, allocations don’t have to get too big, provided that both parties agree not to list each and every partial fill. This is especially important when trading with ECNs/Exchanges where one typically receives numerous partial fills. If you send just one allocation mesage per security per side, and don’t include the individual executions, the size of the message really only depends upon the number of accounts that will receive shares.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> That does bring up a good point, though. In some circumstances, an order could have thousands of allocations on it(trust accounts; wrap accounts).
The Allocation message can be "fragmented" by just simply sending multiple allocations for each symbol and side. This works if both parties are expecting it, and if no execution information is given.
For instance, if I traded 1,000,000 shares of a stock, and I want to allocate 1,000 shares into each of 1,000 accounts, I could send 10 allocation messages, each listing a breakdown for 100 accounts.
Now the broker probably shouldn’t send the allocation ack until after receiving all 10 allocations, summing them, and verifying that my share and price totals match what the broker believes is accurate.
[ original email was from Ross Hutcheon - ross.hutcheon@ubsw.com ]
Aaron does raise a valid concern. There is definitely appetite from Institutions to send numerous splits on large block orders: 500 sub-account allocations on a single order are not uncommon today and desire has been expressed to be able to send up to 10,000. Although the allocation message does have repeating groups, 10,000 is likely an unmanageable number.
As far as setting a maximum size to a message; a precedent was set in the 4.0 List Status message, which states:
"Each list status message will report on only a maximum of 50 orders; if the list contains more than 50 orders multiple status messages will be required."
Given that one of the aims of FIX is to promote interoperability, I believe there is some merit in considering a maximum number of repeating groups in a single allocation message (e.g. 1000).
> > Are there any thoughts on defining a maximum message size in relation to allocations?
>
> In general, the FIX Protocol has evolved away from setting limits on things such as message size and number of messages in a session. Leaving these kinds of things up to counterparties means that FIX remains flexible enough to adapt to many business needs, although this comes at the cost of more details that counterparties must agree upon.
>
> In practical terms, allocations don’t have to get too big, provided that both parties agree not to list each and every partial fill. This is especially important when trading with ECNs/Exchanges where one typically receives numerous partial fills. If you send just one allocation mesage per security per side, and don’t include the individual executions, the size of the message really only depends upon the number of accounts that will receive shares.
>
>
[ original email was from Aaron Pryce - aaron.pryce@citigroup.com ]
Additionally the FIX 4.3 spec allows for the max message size to be negotiated on logon using "Tag 383 (MaxMessageSize) which can be used to specify the maximum number of bytes supported for messages received".
> Aaron does raise a valid concern. There is definitely appetite from Institutions to send numerous splits on large block orders: 500 sub-account allocations on a single order are not uncommon today and desire has been expressed to be able to send up to 10,000. Although the allocation message does have repeating groups, 10,000 is likely an unmanageable number.
>
> As far as setting a maximum size to a message; a precedent was set in the 4.0 List Status message, which states:
> “Each list status message will report on only a maximum of 50 orders; if the list contains more than 50 orders multiple status messages will be required.”
>
> Given that one of the aims of FIX is to promote interoperability, I believe there is some merit in considering a maximum number of repeating groups in a single allocation message (e.g. 1000).
>
>
> > > Are there any thoughts on defining a maximum message size in relation to allocations?
> >
> > In general, the FIX Protocol has evolved away from setting limits on things such as message size and number of messages in a session. Leaving these kinds of things up to counterparties means that FIX remains flexible enough to adapt to many business needs, although this comes at the cost of more details that counterparties must agree upon.
> >
> > In practical terms, allocations don’t have to get too big, provided that both parties agree not to list each and every partial fill. This is especially important when trading with ECNs/Exchanges where one typically receives numerous partial fills. If you send just one allocation mesage per security per side, and don’t include the individual executions, the size of the message really only depends upon the number of accounts that will receive shares.
> >
> >
>
>
> Additionally the FIX 4.3 spec allows for the max message size to be negotiated on logon using "Tag 383 (MaxMessageSize) which can be used to specify the maximum number of bytes supported for messages received".
>
That is correct. Note that this was added to FIX 4.3 to work in conjunction with messages which support "Fragmentation". "Fragmentation", the ability to split a single logical repeating group into "sets" of repeating groups sent in multiple FIX messages, was added to FIX 4.3 for Mass Quote (Vol 3) and New Order - List (Vol 4). Both of these messages have examples of how Fragmentation works. The MaxMessageSize optional field could be used to determine the optimal level of fragmentation for the sender.
It sounds like we should consider enhancing the Allocation message to support "Fragmentation" in the next release of the protocol.