Post-Trade Allocation Messages

The following trade model and set of messages describe the fields and values required to successfully execute a post-trade allocation using the FX Professional Motif 2.

For each of the messages below, [c] denotes that the message is sent by the client, [s] denotes that the message is sent by the server.

Client

For the front-end client, the trademodel library handles the processing of these messages. Streamlink is 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.

Server

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.

Trade Model State Diagram

 

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).

Submit Message

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.

Trade Fields

Field Name Description Example
RequestID

The client generated ID that is unique for this user and post allocation. The client-side trading library generates this.

12654444444
MsgType

The transition that the client wants to make in the state model

Submit
TradeID

The ID of the original trade. Field obtained from blotter message

12312312
BuySell

The side of the original deal. Valid values: "BUY", "SELL".

This is required by the back end so that it can determine if each allocation is positive or negative when compared to the original deal.

BUY

Trade Leg Fields

Field Name Description Example
LX_Amount

The amount that this allocation represents

20000
LX_Account

The account that this allocation should be made to

Acct
LX_BuySell

The side of the allocation

BUY or SELL

Optional
LX_SwapLeg

The allocation swap leg (this field is not defined for spot or forward trades)

NEAR or FAR

**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).

SubmitAck Message [s]

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

Field Name Value Example
RequestID The request ID of the original ChangeState message 112314243333
MsgType The transition that the server wants to make in the state model PickUp

PickUp Message [s]

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.

Field Name Value Example
RequestID The request ID of the original ChangeState message 112314243333
MsgType The transition that the server wants to make in the state model CancelWait

AllocationConfirmation Message [s]

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.

Field Name Value Example
RequestID The request ID of the original ChangeState message 112314243333
MsgType The transition that the server wants to make in the state model AllocationConfirmation

Reject Messages [s]

See Common Messages Specifications

Error Messages [s]

See Common Messages Specifications

ClientClose Messages [s]

See Common Messages Specifications

ClientCloseAck Messages [s]

See Common Messages Specifications

Viewing Allocations

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:

/PRIVATE/<username>/FX/ALLOCATIONS/<trade id>

Response:

Field Name Description Example
L1_Amount

The amount that this allocation represents

20000
L1_Account

The account that this allocation should be made to

Acct
L1_BuySell

The trade direction of the base currency, from the perspective of the user. Valid values: "BUY", "SELL".

BUY
Optional
L1_SwapLeg The allocation swap leg (this field is not defined for spot or forward trades). Valid values: "NEAR", "FAR". NEAR

See also: