Click to Show Menu

FIX API Communication Model

Introduction

FIX API uses Session Based communication. A session is defined as a communication between two parties, the Initiator (Client), who is the party who initiates the communication and the Acceptor (Server), the party who receives the connection request from the Initiator. The server validates client requests using the logon message.

FIX Session Protocol

Each session maintains bi-directional messages between Client and cTrader entity. A session can include multiple physical connections. A session is maintained using sequence numbers. Every new message within a single session receives unique sequence number starting from 1 (one). Both parties rely on sequence numbers to maintain orderly communication. Missing messages are re-transmitted with a bi-lateral agreement between both parties.

Typical Session Flow

  1. Client starts the session with LOGON Message
  2. Exchange Application Messages with Server
  3. Ends with LOGOUT message

cTrader FIX Protocol Message Categories

As defined in the FIX Protocol, the cTrader FIX server is using two different data levels: System and Application. Please note that this is the minimum set of messages required to support the necessary work flows and is subject to change over time as both business needs and the FIX standard evolve.

System (Admin) Messages

  • Heartbeat (Client ↔ cTrader) - Used to check communication link between two parties
  • Test Request (Client ↔ cTrader) - Used to test the health of the communication link
  • Logon (Client → cTrader) - Client Authentication Message
  • Logout (Client → cTrader) - Normal Termination of Session
  • Resend Request (Client ↔ cTrader) - Request to retransmit the certain application messages
  • Reject (Client ↔ cTrader) - Session level validation failure
  • Sequence Reset (Client ↔ cTrader) - In case of communication problems missing messages are recovered or sequence is reset to ignore the missing messages

Application messages

  • Market Data Request (Client → cTrader) - General request for market data
  • Market Data Incremental Refresh (Client ← cTrader) - Responses to a Market Data Request message
  • New Order Single (Client → cTrader) - Used to electronically submit the orders to a broker for execution
  • Execution Report (Client ← cTrader) - Used to send order status information to a FIX client, such as confirmations, fills, and unsolicited changes
  • Business Message Reject (Client ← cTrader) - Used to reject a FIX client request for non-session reasons

FIX Message Structure

This section explains how the FIX API message is composed. This section also describes the FIX message format and helps to understand the FIX Tag and Value pair concept.

Each message must contain 3 parts:

  • Header: Each administrative or application message is preceded by a standard header. The header identifies the message type, FIX version, message length, destination, sequence number, origin and time.
  • Body: The content in the body of the message is specified by the message type defined in the header .
  • Footer: Each message, administrative or application is terminated by a standard footer. The footer is used to segregate messages and contains the three digit character representation of the CheckSum <10> value.

FIX Message Format

A FIX message is a collection of fields. Each field is a tag-value pair formatted as: {tag}={Value}. For example 54=2 which means Order Type = Sell

Tag
  • FIX uses predefined Tags
  • Each Tag represent the specific field
  • Each tag is assigned a predefined number
  • cTrader FIX specification provides a list of fields and corresponding Tag numbers
Value
  • Values represent the value of the Tag assigned to it
  • Values can only be one of the following Data Types: integer, floating point, character, time, date, data, string

All messages within cTrader FIX API start with "8=FIX.x.y", where x.y is the version of FIX Protocol. At the end of every message there should be a field “10=xyz”, where xyz represents the sum of all binary values in the message called the Checksum. Checksum helps to identify any transmission problems, in particular packet loss by allowing the recipient to know if any of the message is missing.

If Symbol(55) tag is used in a FIX message to cTrader/cServer, you must specify the FIX Symbol ID. That value can be different across brokers. You can find FIX Symbol ID field from that brokers cTrader application in the symbol info-window.

Message Example

8=FIX.4.4|9=126|35=A|34=1|49=theBroker.12345|57=TRADE|50=any_string|52=20170117-08:03:04|56=CSERVER|98=0|108=30|553=12345|554=passw0rd!|10=131|

Tag # Tag Name Value Description
8 BeginString 4.4 FIX Version
9 BodyLength 102 Message Body Length is 102 characters
35 MsgType A Message Type is Logon
34 MsgSeqNum 1 Message Sequence number is 1
49 SenderCompI D broker.1047 ID of the trading party, where “broker” is the unique BrokerUID provided by cTrader and “1047” is the numeric identifier of trading account
57 TargetSubID TRADE Additional session qualifier. Possible values are: "QUOTE","TRADE".
50 SenderSubID QUOTE Assigned value used to identify specific message originator.
52 SendingTime 20131129- 15:40:10.276 Time of message transmission is November 29th, 2013 (YYYYMMDD) at 15:40:10 and 276 milliseconds
56 TargetCompID CSERVER Message target is CSERVER. It is the only valid value within cTrader FIX API
98 EncryptMethod 0 Currently, only valid value is "0" (zero)= NONE_OTHER (encryption is not used)
108 HeartBtInt 30 Heartbeat interval in seconds. Value is set in the 'config.properties' file (client side) as SERVER.POLLING.INTERVAL'. 30 seconds is default interval value. If HeartBtInt is set to 0, no heart beat message is required.
553 Username 1047 The numeric User ID
554 Password MyPassword1 User password
10 Checksum 000 The way to calculate the checksum is as follows: summing every byte of the message up to but not including the checksum field itself, then transforming it into a modulo 256 number prefixed with “0” to receive 3-digit number