In this section we will cover:
- An Introduction to trade Models and FX Workflows
- Streaming FX data
- Trading with FX data
- A worked example showing how ESP trade messaging works
Trade Models and FX Workflows
In this section we will take a quick look at what takes place when executing a trade on an FX Tile. A simple state based communication system is used by tiles for sending trades to the right place. This system helps to create the trade workflow needed to submit and execute trades. A trade model represents this type of workflow and is used to define and control the life-cycle of a trade.
FX Tiles - Example Trade Model
For a simple FX Tile that implements ESP trading, the trade model will provide a natural workflow in which the trade starts in an "initial" state, progresses to an "executing" state (as a buy or sell button is pressed) then a trade message is sent to the server, and ends in a "complete" state once a message is received back from the server confirming that the trade was successful. Additionally, it is very possible for a trade to go into a "failed" state if the server sends back a message saying that the trade was unsuccessful, or if the client waits too long for a reply from the server.
Below is a basic illustration for the simple state transitions that take place during the execution of a trade:
The trade model not only defines the FX workflow for an FX Tile, but it also defines the trade submission process and simple event management needed when clicking buttons and performing trade actions. Each Trade object created is associated with one trade model, hence determining what messages can be passed between that trade and the server-side systems used to book the trade.
When using FX Tiles for trading or viewing live rates, behind the scenes all trade requests are communicated to server-side systems that handle the integration and distribution of data. Server-side APIs interact with the tile to handle the exchange of financial messages each time a trade is submitted or a request to stream live rates is initiated. This exchange of messages is done by making subscriptions to a ‘Record’ – this is an object that acts as reference to a specific item such as FX price information.
Therefore in order to stream live GBPUSD rates to an FX Tile, a subscription is made using the subject /FX/GBPUSD/ to access the pricing information contained within this record - see the subscription diagram below.
FX pricing information stored within a record such as /FX/GBPUSD is represented as group of data fields. These fields include raw data for “Bid” (the bid price), “Ask” (the asking price), and “Amount” (this is the GFA). Following a subscription to a record, rates displayed on a tile are refreshed using update messages. Each time the value belonging to a data field within a record changes, it is sent back to the tile in real-time using update messages. These messages are communicated by the server-side systems, and only contain FX pricing information that has changed. See the Example further down for more details on this process.
Every rate that is sent to the tile as part of an update message will have an associated QuoteID (also known as priceID) sent along with it. This ID is used as to verify that any rates sent through originated from an authentic source (i.e. the rate wasn't forged). When a rate is clicked on a tile to execute a trade, the QuoteID for that specific rate is sent back to the origin (FX Pricing System - subscription diagram above), this is to verify that the rate clicked was a valid one.
Example - Subscribing to rates
A user intends to trade GBPUSD using an FX tile.
- As soon as this currency pair is set, a request is made to stream GBPUSD exchange rates directly to the tile. This is done by making a subscription to the record /FX/GBPUSD/ as depicted in the subscription diagram previously.
When the subscription is made it will include all data and options currently set up on the tile, such as the trade amount submitted and the specified Dealt Currency. Information on the settlement date specified or Tenor is also sent e.g. SPOT, 1M, 2W. An example subject for a subscription would look like:
Following a successful subscription to GBPUSD, a Price Update Message (for streaming rates) is received. The message is in the form of a record that may contain a set of fields and values. These values will include exchange rates for GBPUSD as well as other data required to display rates correctly on an FX tile. Fields and values sent as part of an update message may include the following:
Field name Value GFA 50000000 BidRate 1.2245 AskRate 1.3356 BidQuoteID 1CSO>F5UZ<U9ee7g;jMrAY AskQuoteID 1CSO>F5UZ<U9ee7g;jMrAY NumberOfFractionalPips 2 NumberOfPips 2
The BidRate and AskRate fields contain the buy and sell rates respectively. Rates update several times a second - whenever the field value for buy or sell rate changes, the tile is updated with the new value. So if the value of the AskRate field changes, only this field and value is streamed back to the tile as: /FX/EURUSD AskRate=1.3450
For explanations on all types of fields sent, see ESP Trade Messages. For detailed information on making subscriptions see:
- Subjects, symbols and fields
- Active subscription model
- Data and subscription management
Trading with FX data
When a trade is performed on an FX Tile, it is done using the ESP trade protocol which means that the prices for trading are streamed to the FX Tile before the trade is started.The ESP protocol implements a trade state model that is used to handle trade executions using FX Tiles - where a trade is either accepted or terminated. The trade model defines the FX workflows that take place during execution:
Trade messages are exchanged across the server-side systems and communicated to the external FX Pricing System (subscription diagram) according to the protocol defined by the trade state model above. As explained earlier with Streaming FX data, a typical format for a message is a record that is identified by a subject and consists of number of fields and values for FX rates etc. Besides these, an ESP trade message will also contain a field labelled ‘Message Type’ – this field is used to identify where and when on the trade state model that the message is being communicated or handled.
For example when a user submits a trade using the FX Tile, an ESP Submit message is created in the Submit state. This particular message will be sent from the client, and will contain a specific set of data fields that describe the amount submitted, the settlement date, the currency pair, the Dealt Currency etc.
For a full list of all ESP trade message types that are communicated using the ESP trade protocol see: ESP Trade Messages
Here is a list of the various records and containers used specifically with ESP trade messages:
See Messages in the FX Professional Motif for more information.
Worked example - ESP trade messaging
The user has an FX Tile open that is subscribed to GPBUSD streaming rates. User data has been entered on the tile - at this point, trade processes enter the Initial state on the trade state model. The user clicks on the SELL GBP streaming rate to execute a trade, an ESP Submit message is then created in the Submit state and sent to the server.
After the message is sent, trade processes are progressed to the Submitted state. The ESP Submit message will contain various data in the form of fields and values, these include:
SPOT TradingAssetClass FX CurrencyPair GBPUSD
1436288431268 TimePriceOnScreen 14362288033877
SELL SettlementDate 20151307
1750 Tenor SPOT Price
In the Submitted state, an ESP SubmitAck message is expected to be sent back to the client by the server to acknowledge that the trade submitted on the tile has been received. The SubmitAck message will send back a ‘TradeID’ which is an identification code that is unique for the submitted trade and the user who submitted it:
SubmitAck TradeID 1234567
Next, the trade will enter a Queued state where it can either be picked up for further processing by a dealer, or become closed due to expiration or other errors. Assuming it has not been closed, the trade will progress to the PickedUp state. Here, a PickUp message is sent by the server confirming the TradeID sent previously, and that the trade is now being processed by server-side/external systems.
Data MsgType PickUp TradeID 1234567
Finally, once the trade has been picked up by a dealer (an external Pricing or Trading system) and processed, it enters the TradeConfirmed state. At this point, the trade will have been finalised and acknowledged as being successfully executed. A Trade Confirmation message is sent to the FX Tile containing the details of the trade such as the execution rate and the amount traded:
Data MsgType TradeConfirmation TradeID 1234567 ContraAmount
For information on messages sent during other states such as Reject, Error etc. see Common Messages.
FX Tiles Documentation:
- Section 1 - Using an FX Tile
- Section 2 - Using other FX Tile components
- Section 3 - Validation and Error messages
- Section 4 - One-way pricing
- Section 5 - NDF Tiles
- Section 6 - Integrating FX data with a tile
- Section 7 - System Availability and Permissioning
- Section 8 - Code architecture