Section 6 - Integrating FX data with a tile

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.

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 — see Validate all data sent from clients) 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.

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.

For information on messages sent during other states such as Reject, Error etc. see Common Messages.

FX Tiles Documentation: