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:

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 number

  • 1 — a required tag is missing

  • 2 — a tag isn’t defined for this message type

  • 3 — a tag is undefined

  • 4 — a tag has no value assigned

  • 5 — an assigned value is incorrect (out of range) for this tag

  • 6 — an incorrect value data format

  • 7 — an issue related to decryption

  • 9 — an issue related to CompID

  • 10 — an accuracy issue related to <52> SendingTime

  • 11 — an invalid <35> MsgType

  • 12 — an XML validation error

  • 13 — the same tag appears more than once

  • 14 — a tag is specified not in the required order

  • 15 — a wrong order of repeating group fields

  • 17 — 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 recognized

  • 1 — a duplicate <262> MDReqID

  • 2 — insufficient bandwidth

  • 3 — insufficient permissions

  • 4 — the specified <263> SubscriptionRequestType isn’t supported

  • 5 — the specified <264> MarketDepth isn’t supported

  • 6 — the specified <265> MDUpdateType isn’t supported

  • 8 — 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 to 1.

  • When the order is fully filled, <39> OrdStatus is set to 2.

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