|
General Q/A
< Previous Next >
Re: Allocation Status - associating a party role with allocation status - would like some feedback
Hanno Klein / Deutsche Börse Systems <>
11 Mar 2010 11:07AM ET 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?
Re: Allocation Status - associating a party role with allocation status - would like some feedback
Hanno Klein / Deutsche Börse Systems 11 Mar 2010 11:07AM ET
|
