Order Submission Messages

The following trade model and set of messages describe the fields and values required to successfully submit a Limit Order trade using the FX Professional Motif 2. Note that this trade model only deals with submission. All other events regarding the order after submission, such as its execution, cancellation and progression are sent as updates to the order blotter. For each of the messages below, [c] denotes that the message is sent by the client, and [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 Limit Order, the Client must send a message that submits the order, known as the submit message. The server will then send a set of responses informing the client of the progress of the order submission which either ends successfully and activates the order, or ends with an error.

Server

For the back-end adapters, the FXIntegrationAPI consumes the client messages. The requests for Order Submissions are handled by an Adapter that instantiates the FXOrdersAdapter object and registers an OrderSubmissionListener (see the FX Integration API documentation for more information on Adapters). The order submission is handled by the FX Integration API using implementations of the OrderStrategy. There is an implementation for each of the StrategyTypes (see below). These implementations contain the Responders and Events required to send messages from the server side, in order to transition the trade model to the final state.

Strategy Types and Setups

The following describes the order strategies available in the FX Professional Motif 2, and how they must be set up.

  • SINGLE - Trade, Leg (id1)

  • OCO - Trade, TP or SL Leg (id1), TP or SL Leg (id2). The orders must consist of a TP and an SL (you cannot have two TPs, for example).

  • IF-DONE - Trade, Parent Order Leg (id1), TP or SL Leg (id2)

  • IF-DONE-OCO - Trade, Parent Order Leg (id1), TP or SL Leg (id2), TP or SL Leg (id3). The OCO orders must consist of a TP and an SL (you cannot have two TPs, for example).​

Trade Model State Diagram

Blue arrows denote a message sent by the client, or a system timeout, green arrows denote messages sent by the server.

States that allow the server to send messages, can aslo send the Error and Reject message. These two transitions are therefore not shown on the diagram above.

Submit Message [s]

This is the message that the client sends to submit a limit order.

Field Name  Value Example
RequestID The client generated ID that is unique for this user and trade. The client-side trading library generates this. 112314243333
MsgType The transition that the server wants to make in the state model Submit
CurrencyPair

The currencyPair for all orders in this strategy

GBPUSD
Account

The account to trade on

Acct1
ActivationDate

What date the Order should be activated

"GFA" or an ISO date "20130606"

(GFA is Good From Activation)

ActivationTime

What time the Order should be activated if the ActivationDate was in the format of yyyymmdd

12:12:12

ActivationLocation When location should be used to evaluate the time to activate if the ActivationDate was in 
the format of yyyymmdd
'new york'
ActivationUTCOffset

The activation date UTC offset for the client's location as defined by the browser

Send a value of 00:00 if the location is anything other than "LOCAL"
Send the offset e.g. +05:00 when the location is "LOCAL"
ExpirationDate What date the Order should be expired GTC, GFD, 20130606 
GTC=Good Till Cancelled 
GFD=Good For Day (valid for the current trading day only).
ExpirationTime

What time the Order should be activated if the ExpirationDate was in the format of yyyymmdd

12:12:12
ExpirationLocation When location should be used to evaluate the time to expire if the ExpirationDate was in 
the format of yyyymmdd
'new york'

ExpirationUTCOffset

The expiration date UTC offset for the client's location as defined by the browser Send a value of 00:00 if the location is anything other than "LOCAL"
Send the offset e.g. +05:00 when the location is "LOCAL"
StrategyType The Strategy that this trade object represents SINGLE, OCO, IF-DONE, IF-DONE-OCO
AlertType

The types of alerts that should be sent for this order

SMS, EMAIL (comma separated list, zero or more values)

Account

The settlement account to use

SetAcc1

Trade Leg Fields

Note: all leg fields should be prepended with L* where * represents the leg id. _

For a multi-leg order the second order would have L2 instead of L1, and the third order L3. The L1 fields are considered the parent order.

Field Name Values Example
L1_ExecutionType

How this order should be executed.

CALL-ORDER, TAKE-PROFIT, STOP-LOSS, MARKET, or BENCHMARK.

CALL-ORDER and BENCHMARK are only valid for single-legged strategies.

MARKET is only valid for a parent order in a multi-legged strategy.

TAKE-PROFIT

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

The type of benchmark to fix to.

A string defined by the back-end trading system. eg. WMR, ECB
L1_Amount Amount 100000.00
L1_FillRate

The rate at which this order should be filled

1.1232
L1_DealtCurrency

The currency that the amount is specified in

GBP
L1_Remarks

Comment/remarks by the client

Call John when filled

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 client generated ID that is unique for this user and trade. The client-side trading library generates this. 112314243333
MsgType The transition that the server wants to make in the state model SubmitAck

Accepting Message [s]

This is the message the server sends to tell the client that the order has been received by the back-end trading system and is being processed.

Field Name Value Example
RequestID The client generated id that is unique for this user and trade. The client-side trading library generates this. 112314243333
MsgType The transition that the server wants to make in the state model Accepting

Accept Message [s]

This is the message the server sends to tell the client that the order is now accepted by the back-end trading system.

Field Name Value Example
RequestID The client generated id that is unique for this user and trade. The client-side trading library generates this. 112314243333
MsgType The transition that the server wants to make in the state model Accepted
OrderID The ID assigned to the accepted order by the trading system. 5.1.30086

Reject Message [s]

See Common Messages Specifications.

Error Message [s]

See Common Messages Specifications.


See also: