RFS Trade Messages
The following trade model and set of messages describe the fields and values required to successfully execute an RFS Trade using the FX Professional Motif. 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, and [c/s] both client or server.
- Architecture
- Trade Model State Diagram
- Submit Message [c]
- SubmitAck [s]
- PickUp Message [s]
- PriceUpdate Message [s]
- Execute Message [c]
- ExecuteAck Message [s]
- TradeConfirmation Message [s]
- Expire Message [c]
- Withdraw Message [c]
- Reject Message [s]
- Error Message [s]
- Hold Message [s]
- ClientClose Message [s]
- ClientCloseAck Message [s]
Architecture
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 RFS trades, two messages must be sent by the client:
-
the first is to initiate the RFS, known as the submit message. In response to this message, if successful a trade channel is created and the back end begins to process the request.
-
the second is the execute message which occurs when the client wants to trade on a quote that has been received on the stream.
For the back-end adapters, the FXIntegrationAPI consumes the client messages. The requests for RFS are handled by an Adapter that instantiates the FXTradeAdapter object and registers an RFSTradeListener (see the FX Integration API documentation for more information on Adapters). The RFS is handled by the FX Integration API using the RFSTrade object. The object contains the Responders and Events required to send price updates, as well as transition to the next stage of the trade model.
Trade Model State Diagram
Blue arrows denote a message sent by the client, 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 [c]
This is the message that the client sends in order to open an RFS ticket and receive quotes.
Trade Fields
These fields should be identical to the ESP Open message apart from the following differences:
| Field Name | Value | Example |
|---|---|---|
QuoteID |
This should be not sent because we haven’t received a quote yet. We are asking for a stream of quotes, we are not trying to trade on a quote we already received. |
N/A |
SpotBidRate |
This should be not sent for the same reason as above |
N/A |
SpotAskRate |
This should be not sent for the same reason as above |
N/A |
TradingProtocol |
The value must be RFS, not ESP |
RFS |
TradingType |
The type of trade: SPOT, FWD, NDF, TIME_OPTION or SWAP. This contrasts with ESP trades, where TradingType can only be SPOT, FWD or NDF. |
SPOT |
Account |
The settlement account to use |
- |
BuySell |
The trade direction for one-way pricing, from the client’s perspective. To request a two-way price, set this field to an empty string or do not send it. |
BUY |
Trade Leg Fields
These near leg fields should be identical to the ESP Open message apart from the following differences:
| Field Name | Value | Example |
|---|---|---|
L1_Tenor |
Unlike ESP you can do RFS trades on broken dates, so this value can be "broken", in which case the settlement date should be used. |
12M |
L1_SettlementDate |
The settlement date of the trade. Use this if the tenor is "broken". |
20121212 |
L1_FixingDate |
This should be not sent unless the trade is for an NDF currency pair. The Fixing Date is usually two business days before the settlement date. |
20121210 |
L1_AllInBidRate |
This should be not sent because we haven’t received a quote yet. We are asking for a stream of quotes, we are not trying to trade on a quote we already received. |
N/A |
L1_AllInAskRate |
This should be not sent for the same reason as above |
N/A |
L1_FwdBidPips |
This should be not sent for the same reason as above |
N/A |
L1_FwdAskPips |
This should be not sent for the same reason as above |
N/A |
L1_FwdBidPoints |
This should be not sent for the same reason as above |
N/A |
L1_FwdAskPoints |
This should be not sent for the same reason as above |
N/A |
SubmitAck [s]
This is the message the server (a trading adapter) will send in order to acknowledge that the request to initiate an RFS has been received by the back-end adapters. These fields should be identical to the ESP OpenAck message apart from the following differences:
| Field Name | Value | Example |
|---|---|---|
SubmissionDate |
This should be not sent because the user hasn’t submitted a trade yet |
N/A |
SubmissionTime |
This should be not sent for the same reason as above |
N/A |
PickUp Message [s]
This is the message the server (a trading adapter) will send in order to notify the client that the RFS request is being processed 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 client wants to make in the state model |
PickUp |
PriceUpdate Message [s]
This is the message the server (a trading adapter) will send to the client when it receives a price update from the back-end trading system. The initial price update should contain the overall timeout, which is the duration for which prices will be streamed. Subsequent quotes in the stream should not set the overall timeout, otherwise they will reset the overall timeout for the stream to a new value.
Trade Fields:
These fields should be identical to the Streaming price update message apart from the following differences:
| 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 client wants to make in the state model |
PriceUpdate |
OverallTimeOut |
This is not present on standard price updates. It is the number of seconds remaining before this stream (not this individual quote) is timed out. |
60 |
BidAskQuoteID |
For RFS swaps, this is the unique OMS generated ID that the client should trade on if he wants to execute the bid price on the near leg and the ask price on the far leg, i.e the client is executing a SELL/BUY swap. For non swap quotes this field would be not sent. |
|
AskBidQuoteID |
For RFS swaps, this is the unique OMS generated ID that the client should trade on if he wants to execute the ask price on the near leg and the bid price on the far leg, i.e the client is executing a BUY/SELL swap. For non swap quotes this field would be not sent. |
|
BidPips |
For swap quotes this contains the swap points, specified in pips. It generally equals the value of L2_FwdBidPips - L1_FwdBidPips, although the rules are different for short swaps. This is what we would display on the buy and sell buttons. For non-swap quotes this field would be not sent. |
4.5 |
AskPips |
See BidPips |
4.5 |
BidPoints |
For swap quotes this contains the swap points, specified as a raw number. It generally equals the value of L2_FwdBidPoints - L1_FwdBidPoints, although the rules are different for short swaps. The client will typically never display this to the end user. For non-swap quotes this field would be not sent. |
0.00045 |
AskPoints |
See BidPoints |
0.000045 |
Trade Leg Fields:
These fields should be identical to the Streaming price update message with the following difference:
| Field Name | Value | Example |
|---|---|---|
L1_Amount |
Unlike streaming prices which are based on volume bands RFS quotes are based on the exact amount the user specified, so we could send this field if we want to. However the client already knows it, so it’s probably unnecessary. |
50000 |
Execute Message [c]
This is the message the client will send in order to execute a trade on a quote received on the stream. The fields on this message are similar to, but subtly different from the ESP Open message.
| 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 client wants to make in the state model |
Execute |
Account |
(Optional) The settlement account to use - if defined, it should be the same as on the Open message |
- |
BidPips |
For swap trades this field is included on the rate update that the client wants to trade on, and should be sent back unchanged on the Submit message. For non-swap trades this field should be not sent. |
4.5 |
AskPips |
For swap trades this field is included on the rate update that the client wants to trade on, and should be sent back unchanged on the Submit message. For non-swap trades this field should be not sent. |
4.5 |
QuoteID |
The unique ID of the quote the client wants to trade on. This is generated by the OMS. Unlike ESP where you have a quote ID for the forward points and a quote ID for the related SPOT quote there is only one quote ID for an RFS quote, even if it’s a forward or swap. |
EQ:1366899484.1:230 |
SpotBidRate |
This field is included on the rate update that the client wants to trade on, and should be sent back unchanged on the Submit message |
1.2345 |
SpotAskRate |
This field is included on the rate update that the client wants to trade on, and should be sent back unchanged on the Submit message |
1.2345 |
CurrencyPair |
We already sent this on the Open message but we have to include it again or the Permissioning system will block the message |
GBPUSD |
AssetClass |
We already sent this on the Open message but we have to include it again or the Permissioning system will block the message |
FX |
TradingAssetClass |
We already sent this on the Open message but we have to include it again or the Permissioning system will block the message |
FX |
TradingProtocol |
We already sent this on the Open message but we have to include it again or the Permissioning system will block the message |
RFS |
TradingType |
We already sent this on the Open message but we have to include it again or the Permissioning system will block the message |
SPOT, FWD or SWAP |
Trade Leg Fields:
| Field Name | Value | Example |
|---|---|---|
L1_BuySell |
Whether the client wants to buy or sell the base currency, NOT the dealt currency. For example if the currency pair is EURGBP and this value is EUR then this field always tells you if the client wants to buy or sell EUR, even if the dealt currency is GBP. The dealt currency just tells you which currency the client has specified the amount in. |
Either "BUY" or "SELL" |
L1_AllInBidRate |
This field is included on the rate update that the client wants to trade on, and should be sent back unchanged on the Submit message |
1.2345 |
L1_AllInAskRate |
This field is included on the rate update that the client wants to trade on, and should be sent back unchanged on the Submit message |
1.2345 |
L1_FwdBidPips |
This field is included on the rate update that the client wants to trade on if it is a streaming Forward rate, and should be sent back unchanged on the Submit message. If it is not present on the rate update (which will be the case for an RFS SPOT trade) then it should not be sent on the Submit message either. |
4.5 |
L1_FwdAskPips |
This field is included on the rate update that the client wants to trade on if it is a streaming Forward rate, and should be sent back unchanged on the Submit message. If it is not present on the rate update (which will be the case for an RFS SPOT trade) then it should not be sent on the Submit message either. |
4.5 |
If the trade is a swap, then we want L2_ fields for each of the L1_ fields above, representing the second leg of the swap.
ExecuteAck Message [s]
This is the message sent by the server (a trading adapter) to acknowledge that the client’s request to execute an RFS quote 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 client wants to make in the state model |
ExecuteAck |
SubmissionDate |
The date on the server that the trade was submitted to the OMS (ISO format) |
20130425 |
SubmissionTime |
The time on the server that the trade was submitted to the OMS (HH:MM:SS) |
20130425 |
TradeConfirmation Message [s]
This is the message sent by the server (a trading adapter) to confirm to the client that the RFS trade has been successfully executed in the back-end trading system. The message contains the details of the trade that the client wants to see in order to verify the correctness of the trade.
Not all fields are sent. Others may be added as needed. Could be used as the Execution/History message as well.
Trade Fields
| 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 client wants to make in the state model |
TradeConfirmation |
TradeID |
The ID for the trade as generated by the OMS |
EQ:1366900842.9:245 |
OrderId |
If trade was based on an Order, generated by the OMS |
4.1.12345678 |
FillID |
A unique identifier for the execution. This is generated by the OMS, and is different to the Trade ID. For example, in the OMS there might be a trade with ID 1 and an execution for that trade with ID 2. |
1366844776:228_1 |
CurrencyPair |
The currency pair being traded. |
EURUSD |
DealtCurrency |
The currency the L1_Amount is in. |
EUR |
SpotRate |
The SPOT rate that the client traded on. This should be either the L1_AllInBidRate or L1_AllInAskRate, depending on whether the client wanted to do a buy or a sell. |
1.2345 |
ExecutionDateTime |
The timestamp in UTC that the trade was executed. The front end should convert this to the users’s local time. |
20121212150000 |
TradeDate |
The date the trade was booked on. May be rolled to the next work day. |
20121212 |
Account |
The Client Account that the deal was booked into. |
Account 1 |
SubmittedBy |
Username of person booking the deal. |
|
SubmittedFor |
Username the deal was booked on behalf of by Sales Traders. The same as SubmittedBy for regular users. |
|
SwapPips |
If a Swap the pips on the whole deal. In scaled format, i.e. sent as 4.50 but would be used as say 0.000450. |
4.50 |
TradingType |
Trade Type |
SPOT |
AssetType |
The type of the Asset |
FX |
SwapType |
The Type of Swap, if it is one |
SPOTFWD |
DigitsBeforePips |
Number of digits before the pips |
2 |
NumberOf Pips |
Number of pips, nearly always 2 |
2 |
NumberOfFractionalPips |
Whether Spot Rate has sub-pips or not |
0 or 1 |
Caption |
The text that is to be displayed alongside the name of a currency pair. Typically to denote that the currency pair is different, e.g it is a currency pair for a non deliverable forward. |
NDF |
Trade Leg Fields:
| Field Name | Value | Example |
|---|---|---|
L1_AllInRate |
The rate that the client traded on. This should be either the L1_AllInBidRate or L1_AllInAskRate sent on the Open message, depending on whether the client wanted to do a buy or a sell. |
1.23456 |
L1_BuySell |
Buy/Sell indicator, in base currency terms. |
BUY |
L1_Amount |
The amount that the client traded specified in the dealt currency. |
500.00 |
L1_ContraAmount |
The amount that the client traded specified in the non-dealt currency. |
617.28 |
L1_FwdPips |
The forward points used the rate. In scaled format, i.e. sent as 4.50 but would be used as say 0.000450. |
4.50 |
L1_NumberOfFractionalPoints |
Number of decimals places for Forward Points. |
2 |
L1_Tenor |
The tenor of the leg. |
6M |
L1_SettlementDate |
The actual date for the tenor. |
20130614 |
L1_FixingDate |
The fixing date, should be not sent if the trade is not for an NDF CurrencyPair. The Fixing Date is usually two business days before the settlement date. |
20130612 |
L1_RegulatoryID |
Unique transaction Id for the deal. (Optional) |
Long string, 35+ |
If the trade is a swap, then we want L2_ fields for each of the L1_ fields above, representing the second leg of the swap.
Expire Message [c]
At various states (see the trade model above) the server may send an Expire message. A state will be made to transitioned to the Expired state in certain instances, for example if the stream was kept open for the total amount of time without a quote being traded on it.
| 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 client wants to make in the state model |
Expire |
Withdraw Message [c]
At various states (see the trade model above) the server may send a Withdraw message. The state will be made to transition to the either the PickedUp state or the Error state depending on what state the transition is made from. The withdraw message is sent to notify the client that the back-end trading system has withdrawn the current quote stream, and that we are awaiting a new set of price updates.
| 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 client wants to make in the state model |
Withdraw |
Reject Message [s]
Error Message [s]
Hold Message [s]
ClientClose Message [s]
ClientCloseAck Message [s]
See also: