# Post-Trade Allocation Messages **❗ IMPORTANT**\ This documentation is for FX Professional 2.18 and earlier. From version 2.19 (2 Jun 2019), FX Professional requires back end adapters to implement the FX Integration API 3. For documentation on FX Integration API 3 messages, see [FX Integration API,window="_blank"](../../fx-integration-api/index.md). 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. ## Architecture For the front-end client, the **trademodel library** handles the processing of these messages. [Streamlink,window="_blank"](../../caplin-platform/streamlink/index.md)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. 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](the-fx-integration-api.md) 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,window="_blank"](https://docs.caplin.com/developer/api/fxintegration/latest/) to encapsulate the request for the details of an allocation. ## Trade Model State Diagram ![PostAllocationTradeModel](../../images/PostAllocationTradeModel.jpg) 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 | | LX_SwapLeg | [optional] 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](common-messages.md#rejectmessage) ## Error Messages [s] See [Common Messages Specifications](common-messages.md#errormessage) ## ClientClose Messages [s] See [Common Messages Specifications](common-messages.md#clientclose) ## ClientCloseAck Messages [s] See [Common Messages Specifications](common-messages.md#clientcloseack) ## 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//FX/ALLOCATIONS/ ``` **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 | | L1_SwapLeg | [optional] The allocation swap leg (this field is not defined for spot or forward trades). Valid values: "NEAR", "FAR". | NEAR | --- **See also:** * [Post-Trade Allocations](post-trade-allocations.md) * [Common Messages Specifications](common-messages.md) * [ESP Trade Message Specification](esp-trade-messages.md) * [RFS Trade Message Specification](rfs-trade-messages.md) * [Block Trade Message Specification](block-trade-messages.md) * [Order Submission Message Specification](order-submission-messages.md) * [Order Change State Message Specification](order-change-state-messages.md) * [Order Detail Messages](order-detail-messages.md) * [Edit Strategy Messages](edit-strategy-messages.md) * [Order Cancel Message Specification](order-cancel-messages.md)