Trade model: Order Submission

This page describes the FX Integration API’s OrderSubmission trade model, as defined in the file config/OrdersAdapter/Blade/DataSource/etc/trademodels.xml in the FX Integration API Kit.

This documentation is for the FX Integration API 8.12.0.

Trade models are XML-defined state machines used by the Java Trading API, the C Trading API, and Caplin Trader’s Trading API to manage trading workflows. For more information on trade model XML definitions, see the Trade model XML schema reference.

State diagram

The state diagram for the OrderSubmission trade model is shown below. To simplify the diagram, the Timeout and Error states have been omitted.

InitialSubmittedQueuedPendingAcceptAcceptedSubmitSubmitAckAcceptingAcceptAcceptLegendTransitions initiated by the client are inyellow.Transitions initiated by the server are inblue.

Messages: client → server

Trade-channel messages sent by StreamLink clients to the FX API DataSource.

For high-level information on message fields, see Message and record fields. For information about fields in specific messages, see the message specifications below.

Submit
OrderDetails
LegDetails Ln
Ln_OrderID
string
The id of the order.
Ln_Amount
decimal
The amount of a trade or order in the DealtCurrency.
Ln_MonitorSide
string
The side that should be monitored for an order to be triggered.
Ln_DealtCurrency
string
Example: GBP
The currency of the Amount of a trade or order.
Ln_BuySell
string
The direction of the trade or trade leg, from the client's perspective. This always refers to the BaseCurrency, NOT the DealtCurrency.
Ln_ExecutionType
string
The order type. Caplin supported types are [BENCHMARK, CALL-ORDER, MARKET, PEGGED, STOP-LOSS, TAKE-PROFIT]
Ln_BenchmarkType
string
The benchmark order name. For example, ECB.
Ln_LimitPrice
decimal
The price at which a leg should fill.
Ln_Margin
decimal
The amount of margin
Ln_Remarks
string
The text content of a comment left on a leg of a trade or order, visible to Client and sales and possibly the trader, set/edited by Client or sales
Ln_TraderRemarks
string
The sale's comments on an order leg - visible to only the Trader and sales, set/edited only by the sales
Ln_ChildLegId
integer
Ln_ChildRelationship
string
Ln_PartnerLegId
integer
Ln_PartnerRelationship
string
Ln_LoopLegId
integer
Ln_AllowPartialFill
Denotes if this leg may be partially filled
Ln_FillMode
The permitted fill types for this leg, e.g. ANY, MANUAL or AUTO
Ln_FillRate
string
Ln_Discretion
decimal
Number of points the trader has discretion to fill the order
Ln_OrderTenor
string
The tenor the order will settle on for Forward and NDF orders. Either OrderTenor or OrderSettlementDate should be provided but not both.
Ln_OrderSettlementDate
date
The settlement date the order will settle on for Forward and NDF orders. Either OrderTenor or OrderSettlementDate should be provided but not both.
Ln_OrderFixingDate
date
The date an NDF order will fix on if filled.
CurrencyPair
string
The currency pair for the trade. For example, EURUSD
Account
string
Example: Garfields|GARF
The account a trade or order has been submitted against. The format is <description>|<name> or <name>|<name>
ActivationType
string
How the order should be activated. Caplin supported statuses are [GFA, EXPLICIT]
ActivationDateTime
datetime
Example: 2013-07-24T17:13:59.985
The time and date the order will become active. This is in ISO-8601 format.
ActivationDisplayTimeZone
timezone
Example: Europe/London
The timezone that the activation time and date should be formatted to for display. This is in the TZ database format.
ExpirationType
string
How the order should be deactivated. Caplin supported statuses are [IOC, GTC, GFD, FOK, EXPLICIT]
ExpirationDateTime
datetime
Example: 2013-07-24T17:13:59.985
The time and date the order will be deactivated. This is in ISO-8601 format.
ExpirationDisplayTimeZone
timezone
Example: Europe/London
The timezone that the expiration time and date should be formatted to for display. This is in the TZ database format.
AlertType
string
The type of alert that an order will send. Caplin supported statuses are [EMAIL, SMS].
EntityId
string
Example: CUSTONE
The entity the trade is on behalf of. For example, if the logged in user user1@customer.co.za wishes to make a trade on behalf of entity CUSTONE, then the value of this field will be CUSTONE. If this field is absent on a leg then the default entity should be presumed.
TOBOUser
string
Example: client@customer.co.za
The user the trade is on behalf of. For example, if the logged in user dealer1@novobank.co.za wishes to make a trade on behalf of user client@customer.co.za, then the value of this field will be client@customer.co.za.
StrategyType
string
The strategy the order was submitted with. This field should not be used by the front end for structuring orders. Comma separated list of Caplin supported values are [SINGLE, IF-DONE-OCO, OCO, IF-DONE, IF-TIMEOUT, IF-DONE-LOOP, LOOP]. OTHER denotes a strategy type that is unsupported.
AppID
A unique identifier for the client application
AlertPhoneNumber1
string
Phone number that should be called when an order event occurs
AlertPhoneNumber2
string
Phone number that should be called when an order event occurs
AlertPhoneNumber3
string
Phone number that should be called when an order event occurs
AlertPhoneNumber4
string
Phone number that should be called when an order event occurs
AlertPhoneNumber5
string
Phone number that should be called when an order event occurs
AlertPhoneNumber6
string
Phone number that should be called when an order event occurs
AlertPhoneNumber7
string
Phone number that should be called when an order event occurs
AlertPhoneNumber8
string
Phone number that should be called when an order event occurs
AlertPhoneNumber9
string
Phone number that should be called when an order event occurs
AlertPhoneNumber10
string
Phone number that should be called when an order event occurs
AlertEmailAddress1
string
Email address that should be mailed when an order event occurs
AlertEmailAddress2
string
Email address that should be mailed when an order event occurs
AlertEmailAddress3
string
Email address that should be mailed when an order event occurs
AlertEmailAddress4
string
Email address that should be mailed when an order event occurs
AlertEmailAddress5
string
Email address that should be mailed when an order event occurs
AlertEmailAddress6
string
Email address that should be mailed when an order event occurs
AlertEmailAddress7
string
Email address that should be mailed when an order event occurs
AlertEmailAddress8
string
Email address that should be mailed when an order event occurs
AlertEmailAddress9
string
Email address that should be mailed when an order event occurs
AlertEmailAddress10
string
Email address that should be mailed when an order event occurs
FixingSource
string
Example: WMR 8am London Time
SettlementCurrency
string
Example: GBP
A currency for of settlement instruction
ActivationDate
string
What date the strategy should be activated.
ActivationTime
string
What time the strategy should be activated if the ActivationDate was in the format of yyyymmdd.
ActivationLocation
string
Example: Europe/London
When location should be used to evaluate the time to activate if the ActivationDate was in the format of yyyymmdd.
ActivationUTCOffset
string
ExpirationDate
string
What date the strategy should expire.
ExpirationTime
string
What time the strategy should be activated if the ExpirationDate was in the format of yyyymmdd.
ExpirationLocation
string
When location should be used to evaluate the time to expire if the ExpirationDate was in the format of yyyymmdd.
ExpirationUTCOffset
string
MsgType
String
Example: Submit
Name of the transition
RequestID
String
The RequestID. A Unique identifier, must remain the same for each event in the trade model
TradingSubProtocol
string
Example: SALES_RFS
This field is used to indicate to the back end that the user is requesting a trade with Sales functionality.

Submit message

The Submit message includes strategy fields and one or more leg fields. Each leg field is prefixed with the leg number, in the format 'Ln_', where 'n' is the leg number.

The number of legs in a Submit message depends on the value of the StrategyType field:

StrategyType L1_* L2_* L3_* Notes

SINGLE

Leg 1 can be a take-profit, stop-loss, or call order.

OCO

One leg must be a take-profit order and the other leg must be a stop-loss order.

IF-DONE

Leg 1 is the parent order and leg 2 is the child order. Leg 1 can be a take-profit order or a stop-loss order. Leg 2 can be a take-profit order or a stop-loss order.

IF-DONE-OCO

The OCO component (leg 1 and leg 2) must comprise a take-profit order and a stop-loss order. Leg 1 and leg 2 cannot be of the same type.

Messages: server → client

Trade-channel messages sent by the FX API DataSource to StreamLink clients.

For high-level information on message fields, see Message and record fields. For information about fields in specific messages, see the message specifications below.

Accepting
MsgType
String
Example: Accepting
Name of the transition
RequestID
String
The RequestID. A Unique identifier, must remain the same for each event in the trade model
SubmitAck
MsgType
String
Example: SubmitAck
Name of the transition
RequestID
String
The RequestID. A Unique identifier, must remain the same for each event in the trade model