Post Trade Allocation Messages

For the front-end client, the trademodel library handles the processing of these messages. Streamlinkis used to send messages to the back end. For Post Trade Allocations, the client must send the Submit message. The server will then send a set of responses informing the client of progress for the post allocation; which either ends in a successfull allocation of the order, or in an error.

For the back-end adapters, the FXIntegrationAPI consumes the client messages. Requests for Post Allocations are handled by the Adapter that instantiates the FXPostAllocationAdapter object and registers a PostTradeAllocationListener to handle the execution of the post trade allocation. The Adapter also registers a PostTradeAllocationViewListener to handle requests that ask for the details of an already allocated order. See the FX Integration API documentation for more information on Adapters.

The PostTradeAllocationList object is used by the FXIntegrationAPI to handle post trade allocations; it contains the Responders and Events to send messages to the client and transition to the final state of the trade model. The AllocationViewEvent object is used by the FX Integration API to encapsulate the request for the details of an allocation.

Note that since an allocation may fail a Credit Check, it is possible for an allocation to go to Dealer Intervention (where it will stay in the queued state until a Dealer picks it up). In this case we may also need to deal with a crossing on the wire issue; if the client attempts to cancel the allocation, the server may at the same time attempt to transition into PendingAllocation (where the dealer has picked up the allocation and accepted it). If this happens, we need to allow the trade to transition into AllocationConfirmation on the front end, hence the transition from ClientCloseSent to PendingAllocation (See diagram above).

This is the message sent by the client to submit a post trade allocation. The message contains a set of legs representing an allocation, the sum total of each allocation equals the amount of the trade to be allocated.

Where 'X' represents the leg number.

Note that since we are using generic objects, we will not have to define all of the fields in the fields.xml (since there could be potentially up to 50 or 100 allocations).

This is the message the server sends in order to acknowledge that the Submit message has been received by the back-end adapters.

This is the message that is sent by the sever to notify the client that the allocation is now being processed by the back-end trading system.

This is the message that is sent by the sever to notify the client that the allocation has been successfully executed in the back-end trading system.

See Common Messages Specifications

See Common Messages Specifications

See Common Messages Specifications

See Common Messages Specifications

Once a trade has been allocated, the confirmation should allow for a read only view of the allocations. Note that this section should be configurable (to show or not show) as some implementations will show allocations in the blotter, rather than the ticket.

Record Request:

Response:

See also: