Imported from previous forum
A need has been identified to be more granular when communicating Allocation status to include the role of the counterparty.
AllocStatus is used to report the status of allocations.
AllocStatus values as of FIX.5.0SP2
0 = accepted (successfully processed)
1 = block level reject
2 = account level reject
3 = received (received, not yet processed)
4 = incomplete
5 = rejected by intermediary
6 = allocation pending
7 = reversed
Allocations when done with a central counter party would benefit from having a way to add the party role from which the allocation status was reported.
N Accepted by the Clearing Broker
R Rejected by the Clearing Broker
A Accepted by the clearing member
L Rejected by the clearing member
C Cancelled by the Executing Broker
S Cancelled by the system
X Rejected Request
Instead of extending the list of status to provide different values by party instead we are considering proposal adding an optional AllocStatusPartyRole - that will be used to identify the role associated with the AlloCStatus.
This approach minimize changes to existing implementations but does introduce a second piece of state information.
The alternative is to expand the list of AllocStatus.
Thoughts?
[ original email was from John Harris - john.harris@bondmart.com ]
Jim,
If I am understanding your proposal correctly, won’t it have to be followed in a few months by even more state information to resolve ambiguities introduced by the new state information?
The proposed scheme seems to allow for an allocation to be accepted by one party in a chain, while rejected by another, yet not in a synchronous way. So the sender, upon receiving new state information, will be in an indeterminate state, knowing only part of the story if you will. Resolving the ambiguity will require (a) waiting for additional information or (b) more likely, out-of-band action.
In other words, I don’t think the additional state information helps much at all, but it could create more ambiguity.
The current scheme at least has the advantage of being simple, clean, and determinate. If a sender has to place an extra call or send an extra email message to determine exactly why an allocation was rejected, it’s not that big of deal.
Also, your proposed value “X Rejected Request” seems inconsistent with the others for lack of source information.
Best,
John
A need has been identified to be more granular when communicating
Allocation status to include the role of the counterparty.AllocStatus is used to report the status of allocations.
AllocStatus values as of FIX.5.0SP2 0 = accepted (successfully
processed) 1 = block level reject 2 = account level reject 3 = received
(received, not yet processed) 4 = incomplete 5 = rejected by
intermediary 6 = allocation pending 7 = reversedAllocations when done with a central counter party would benefit from
having a way to add the party role from which the allocation status
was reported.N Accepted by the Clearing Broker R Rejected by the Clearing Broker A
Accepted by the clearing member L Rejected by the clearing member C
Cancelled by the Executing Broker S Cancelled by the system X
Rejected RequestInstead of extending the list of status to provide different values by
party instead we are considering proposal adding an optional
AllocStatusPartyRole - that will be used to identify the role associated
with the AlloCStatus.This approach minimize changes to existing implementations but does
introduce a second piece of state information.The alternative is to expand the list of AllocStatus.
Thoughts?