FIX API
Version 1.2
General information
The B2CONNECT FIX server provides all the functionality necessary for real-time trading and receiving up-to-date market information via the Financial Information eXchange protocol.
In this document, you can find a detailed description of the B2CONNECT FIX API, including the information about how to connect to a demo FIX server.
The B2CONNECT FIX API is based on the version 4.4 of the Financial Information eXchange protocol.
It’s assumed that the reader of this document is already familiar with the FIX protocol. To learn more about the protocol specification, see the FIX Trading Community website.
If your trading engine is powered by Go, take a minute to learn about SimpleFix Go. This open-source library is provided by the B2CONNECT team to help you quickly integrate FIX messaging into your environment. The library is entirely written in Go and supports any FIX API version.
Supported message types
The following message types can be assigned to the <35> MsgType
field of a Standard header:
0
— Heartbeat (Client ↔ B2CONNECT)1
— Test Request (Client ↔ B2CONNECT)2
— Resend Request (Client ↔ B2CONNECT)3
— Reject (Client ← B2CONNECT)4
— Sequence Reset (Client ↔ B2CONNECT)5
— Logout (Client ↔ B2CONNECT)8
— Execution Report (Client ← B2CONNECT)9
— Order Cancel Reject (Client ← B2CONNECT)A
— Logon (Client → B2CONNECT)D
— New Order Single (Client → B2CONNECT)F
— Order Cancel Request (Client → B2CONNECT)V
— Market Data Request (Client → B2CONNECT)W
— Market Data — Snapshot/Full Refresh (Client ← B2CONNECT)Y
— Market Data Request Reject (Client ← B2CONNECT)
Standard header
All FIX messages must start with a Standard header.
The Standard header includes the following fields:
Standard trailer
Along with a Standard header, all FIX messages must also contain a Standard trailer.
The Standard trailer includes the following fields:
Session messages
The messages listed in this section are used to maintain any live FIX session with the B2CONNECT FIX server, including both quoting and trading sessions.
Heartbeat
This message is sent back and forth between the FIX server and the client to check the connection status and in response to Test Request messages.
The Heartbeat message includes the following fields:
Test Request
This message is sent back and forth between the FIX server and the client in response to Heartbeat messages as a means of connectivity check.
The Test Request message includes the following fields:
Resend Request
This message is sent by the client or FIX server to initiate the retransmission of messages, which may be required upon detecting a gap in the sequence numbers or losing a particular message.
The Resend Request message includes the following fields:
Reject
This message is sent by the FIX server upon receiving a malformed message from the client. The possible reason for rejection is specified in the <373> SessionRejectReason
field.
This message is unrelated to a trade-level rejection (Order Cancel Reject) issued when a FIX server is unable to place a requested order.
The Reject message includes the following fields:
Possible reasons
When the FIX server sends a Reject notification informing the client that a session-level request has been rejected, the <373> SessionRejectReason
field can be set to one of the following values specifying the reason for message rejection:
0
— an invalid tag number1
— a required tag is missing2
— a tag isn’t defined for this message type3
— a tag is undefined4
— a tag has no value assigned5
— an assigned value is incorrect (out of range) for this tag6
— an incorrect value data format7
— an issue related to decryption9
— an issue related toCompID
10
— an accuracy issue related to<52> SendingTime
11
— an invalid<35> MsgType
12
— an XML validation error13
— the same tag appears more than once14
— a tag is specified not in the required order15
— a wrong order of repeating group fields17
— a non-“Data” value includes a field delimiter (an SOH character)99
— other (unspecified) reason
Sequence Reset
This message is sent by the client or FIX server to indicate to the recipient the sequence number of the next message from the sender, immediately following the Sequence Reset message. This may be necessary to recover from a disconnect, in case if some messages were lost or their resending is not desirable.
The Sequence Reset message includes the following fields:
Logon
This message is sent by the client to initiate a FIX session.
The Logon message includes the following fields:
Logout
This message is sent by the client or FIX server to terminate a session. When terminated, the possible reason is specified in the <58> Text
field.
The Logout message includes the following fields:
Demo mode
The B2CONNECT FIX server supports a Demo mode that allows clients to establish a test connection and simulate quoting and trading sessions.
Contact your account manager to obtain a set of settings and credentials.
Quoting
After connecting to the FIX server and establishing a live quoting session, the client can send a Market Data Request to subscribe to quote updates streamed by B2CONNECT.
To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol.
Upon successful subscription to a selected symbol, the FIX server starts streaming market data updates by sending Market Data — Snapshot/Full Refresh messages each time the market data is updated. The quote updates are streamed continuously for the entire duration of a FIX session.
If a subscription request can’t be executed for some reason (for example, when a requested symbol isn’t found), the FIX server responds with a Market Data Request Reject message providing detailed information about an error.
To terminate a specific subscription and stop receiving the updates, the client can send a Market Data Request with the <263> SubscriptionRequestType
set to 2
(standing for “Unsubscribe”). Upon sending a Logout request, the current session is closed and subscriptions to all ticker symbols are terminated.
Market Data Request
This message is sent by the client to start receiving up-to-date quoting data for a specified ticker symbol.
The Market Data Request message includes the following fields:
Market Data Request Reject
This message is sent by the FIX server to reject a Market Data Request with invalid values.
The Market Data Request Reject message includes the following fields:
Possible reasons
The <281> MDReqRejReason
field can be set to one of the following values specifying the reason for request rejection:
0
— the specified symbol isn’t recognized1
— a duplicate<262> MDReqID
2
— insufficient bandwidth3
— insufficient permissions4
— the specified<263> SubscriptionRequestType
isn’t supported5
— the specified<264> MarketDepth
isn’t supported6
— the specified<265> MDUpdateType
isn’t supported8
— the specified<269> MDEntryType
isn’t supported
Market Data — Snapshot/Full Refresh
Such messages are continuously sent by the FIX server after the client subscribes to a ticker symbol. A new message is sent with each market data update.
The Market Data — Snapshot/Full Refresh message includes the following fields:
Trading
Place an order
After establishing a trading session with the FIX server, the client can place a new order by sending a New Order Single message.
In response to this, the FIX server sends back an Execution Report with the <150> ExecType
field set to A
, indicating that the order is placed successfully. If the order can’t be placed (for example, due to lack of credit funds or other issues), the report is sent with <150> ExecType
set to 8
.
After placing the order, the FIX server sends a separate report with <150> ExecType
set to F
each the order status changes:
If the order is executed partially,
<39> OrdStatus
is set to1
.When the order is fully filled,
<39> OrdStatus
is set to2
.
Cancel an order
To cancel an open order, the client can send an Order Cancel Request.
If the order is canceled (either explicitly by a trader, or automatically due to timeout), the Execution Report is sent with <150> ExecType
set to 4
. In this case, the <14> CumQty
field indicates the amount that has already been filled by the time the order was canceled, and <151> LeavesQty
indicates the unfilled amount.
If an order can’t be canceled for any reason, the FIX server sends back an Order Cancel Reject message indicating why the order cancellation failed.
New Order Single
This message is sent by the client to place a new order with specified parameters.
The New Order Single message includes the following fields:
Order Cancel Request
This message is sent by the client to cancel an open order in its entire remaining amount. This request is assigned a unique <11> ClOrdID
and is treated as a separate order.
Upon successful cancellation of the order, an Execution Report is sent with the <39> OrdStatus
field set to 4
. In this case, the <14> CumQty
field indicates the amount that has already been filled by the time the order was canceled.
If the order can’t be canceled for some reason, the FIX server sends back an Order Cancel Reject message indicating why the order cancellation failed.
The Order Cancel Request message includes the following fields:
Order Cancel Reject
This message is sent by the FIX server upon receiving an Order Cancel Request that can’t be fulfilled.
The Order Cancel Reject message includes the following fields:
Execution Report
This message is sent by the FIX server upon successfully placing or cancelling an order, or any change to the order status (such as a complete or partial execution). Among other data, the report indicates:
the current order status at the moment of report creation (
<39> OrdStatus
)the most recent change in the order status, which is being reported (
<150> ExecType
)
The Execution Report message includes the following fields:
Last updated