Allocation Status - associating a party role with allocation status - would like some feedback

, ,
1

Imported from previous forum

2

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?

3

Hi Jim,

Maybe I’m stating the obvious here, but the introduction of another piece of state information might lead to complications when considering co-dependencies between the AllocStatusPartyRole and AlloCStatus.
Extending the existing list of AllocStatus-es may not be pretty, but might be simpler to process, use and (perhaps more importantly) adapt to. Of course, we may also run the risk of rendering some of the old statuses practically defunct.
I guess it’ll be a compromise either way.

Kind Regards,

Prateek

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?

4

Agree to keep it simple by extending the current field. Its values are already using secondary information (block, account, intermediary) and the number of party roles needed seems to be very limited.

Regards,
Hanno.

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?