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. 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, [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 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.

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, 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

Order Submission 1 7 0

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

<Location> where <Location> is a value defined by APAMA

This should ideally be in a single case (upper or lower) and not include spaces

Please specify format!

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:

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, BENCHMARK

CALL-ORDER and BENCHMARK ONLY VALID FOR Strategy=Single

MARKET ONLY VALID for parent order

L1_BuySell

BUY or SELL

BUY, SELL

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 Open 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

OpenAck

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]