Post-Trade Allocation Messages
| 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. |
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. 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.
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.
| 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 |
| 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]
Error Messages [s]
ClientClose Messages [s]
ClientCloseAck Messages [s]
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 |
L1_SwapLeg |
[optional] The allocation swap leg (this field is not defined for spot or forward trades). Valid values: "NEAR", "FAR". |
NEAR |
See also: