Home FIX API

FIX API

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.

Note

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:

Tag	Name	Required	Datatype	Description
8	BeginString	Y	String	Marks the beginning of a new message and indicates the FIX version (FIX.4.4). Always the first field in a message.
9	BodyLength	Y	int	The message length, in bytes. Always the second field in a message.
35	MsgType	Y	String	The message type. Always the third field in a message. See Supported message types for a list of supported values.
34	MsgSeqNum	Y	int	The message sequence number. This value is incremented by 1 for each consecutive message.
49	SenderCompID	Y	String	The B2CONNECT-supplied identifier of a client sending requests to the FIX server.
52	SendingTime	Y	Timestamp	The date and time when a message was sent, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.
56	TargetCompID	Y	String	The B2CONNECT-supplied identifier of a server receiving client messages.

Standard trailer

Along with a Standard Header, all FIX messages must also contain a Standard trailer.

The Standard trailer includes the following fields:

Tag	Name	Required	Datatype	Description
10	CheckSum	Y	int	A three-digit simple checksum indicating the end of a message. Always the last field in a message.

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:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = 0
112	TestReqID	N	String	The identifier of a Test Request in response to which this Heartbeat message is sent.
	Standard trailer	Y

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:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = 1
112	TestReqID	N	String	The identifier of this Test Request in response to which a Heartbeat message will be sent.
	Standard trailer	Y

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:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = 2
7	BeginSeqNo	Y	int	The number of the first message in a sequence to resend.
16	EndSeqNo	Y	int	The number of the last message in a sequence to resend: if <7> BeginSeqNo = <16> EndSeqNo, a single message in a sequence is resent if <16> EndSeqNo = 0, all messages in a sequence following the one defined in <7> BeginSeqNo are resent
	Standard trailer	Y

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.

Note

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:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = 3
45	RefSeqNum	Y	int	The sequence number of a rejected message (<34> MsgSeqNum).
371	RefTagID	N	int	The tag number of a field that caused message rejection.
372	RefMsgType	N	int	The type of a rejected message (<35> MsgType).
373	SessionRejectReason	N	int	The reason why a message is rejected. See Possible reasons for a list of possible values.
58	Text	N	String	The detailed information about the rejection reason.
	Standard trailer	Y

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:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = 4
123	GapFillFlag	N	Boolean	Indicates that this message replaces missing messages that won’t be resent: Y — gap fill, <34> MsgSeqNum is valid and indicates the beginning of the gap fill range N — sequence reset, <34> MsgSeqNum is ignored. As it may lead to losing messages, this mode should only be used in case of a disaster recovery situation.
36	NewSeqNo	Y	int	The new sequence number.
	Standard trailer	Y

Logon

This message is sent by the client to initiate a FIX session.

The Logon message includes the following fields:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = A
98	EncryptMethod	Y	int	The message encryption method. This value must always be 0, indicating that no encryption method is used.
108	HeartBtInt	Y	int	The heartbeat interval, in seconds. Indicates how often the FIX server sends messages to the client as part of a connection health check. The maximum value is 60.
141	ResetSeqNumFlag	Y	Boolean	Indicates whether both parties of a FIX session should reset the currently used sequence numbers. It’s recommended to set the flag to Y for Quoting sessions.
553	Username	N	String	The client username. It should be specified if provided as part of the FIX credentials.
554	Password	Y	String	The client password, as provided by B2CONNECT.
	Standard trailer	Y

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:

Tag	Name	Required	Datatype	Description
	Standard header	Y		<35> MsgType = 5
58	Text	N	String	The detailed information about the reason for logging out.
	Standard trailer	Y

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.

Note

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = V
262	MDReqID	Y	String	The identifier of a market data request. This value must be unique for the duration of each session. If <263> SubscriptionRequestType is set to 2, the <262> MDReqID field indicates the ID of a previous Market Data Request to be discarded.
263	SubscriptionRequestType	Y	int	The type of response expected from the FIX server: 1 — subscribe (to receive updates as the market status changes) 2 — unsubscribe (to stop streaming the market data for the specified ticker symbol)
264	MarketDepth	Y	int	The market depth for an order book snapshot: 0 — to obtain a full order book 1 — to obtain top-of-the-book prices other value greater than zero — to obtain a specific number of price layers
265	MDUpdateType	Y	int	This value must always be 0, indicating that all order book data should be updated every time in response to any change in the market data (as opposed to incremental updates related only to price levels that have changed at the time).
267	NoMDEntryTypes	Y	int	The number of <269> MDEntryTypes requested. This value must always be 2.
→ 269	MDEntryType	Y	int	The side of a quote: 0 — bid 1 — ask
146	NoRelatedSym	Y	int	The number of ticker symbols included in a subscription. This value must always be 1. To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol.
→ 55	Instrument	Y	String	The ticker symbol to subscribe to (such as BTC/USDT).
	Standard trailer	Y

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = Y
262	MDReqID	Y	String	The identifier of a rejected Market Data Request.
281	MDReqRejReason	N	int	The reason why a request is rejected. See Possible reasons for a list of supported values.
58	Text	N	String	The detailed information about the rejection reason.
	Standard trailer	Y

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = W
262	MDReqID	Y	String	The identifier of an originating Market Data Request.
55	Instrument	Y	String	The ticker symbol that’s being quoted (such as BTC/USDT).
268	NoMDEntries	Y	int	The number of market data entries (bids or asks) listed in a request.
→ 269	MDEntryType	Y	int	The side of a quote: 0 — bid 1 — ask
→ 270	MDEntryPx	Y	Price	The price for a market data entry.
→ 271	MDEntrySize	Y	Qty	The tradable volume of a market data entry.
→ 299	QuoteEntryID	N	String	The unique identifier of a quote.
	Standard trailer	Y

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = D
1	Account	N	String	The client-defined account name.
11	ClOrdID	Y	String	The client-provided identifier of an order. This value must be unique across all previous trading sessions.
55	Instrument	Y	String	The ticker symbol (such as BTC/USDT).
54	Side	Y	int	The order side: 1 — buy 2 — sell
38	OrderQty	Y	Qty	The order amount.
40	OrdType	Y	Char	The order type: 1 — market 2 — limit (when choosing this option, the <44> Price field must be specified)
44	Price	C	Price	The order price. This field is required for limit orders.
58	Text	N	String	The additional comments about an order.
59	TimeInForce	Y	Char	The time-in-force option applied to an order: 1 — GTC (Good till Canceled) 3 — IOC (Immediate or Cancel) 4 — FOK (Fill or Kill)
60	TransactTime	Y	Timestamp	The date and time when an order was created, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.
21	HandlInst	Y	int	This field is ignored. Execution is always treated as if the supplied value was 1 (Automated execution order, private, no Broker intervention).
	Standard trailer	Y

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = F
41	OrigClOrdID	Y	String	The <11> ClOrdID of an order to be canceled.
11	ClOrdID	Y	String	The client-provided unique identifier of the Order Cancel Request.
	Standard trailer	Y

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = 9
37	OrderID	Y	String	The unique identifier assigned to an order by the FIX server. This value is NONE if <102> CxlRejReason = 1.
41	OrigClOrdID	Y	String	The <11> ClOrdID of an order to be canceled.
11	ClOrdID	Y	String	The client-provided unique identifier of the Order Cancel Request.
39	OrdStatus	Y	Char	The current order status by the moment of message generation: A — the order is open and awaits execution 1 — the order is open, some part of it may already be filled 2 — the order is filled in the full amount 4 — the order is canceled, some part of it may already be filled 8 — the order is rejected, no part of it is filled
102	CxlRejReason	Y	int	The reason why a cancellation request is rejected: 0 — too late to cancel (the order has already been canceled or filled) 1 — order unknown (the order with a specified ID wasn’t found by the FIX server)
434	CxlRejResponseTo	Y	int	The type of a request that’s rejected. This value must always be 1, indicating the Order Cancel Request.
60	TransactTime	Y	Timestamp	The date and time of the last transaction made as part of order processing, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss.
	Standard trailer	Y

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:

Tag	Name	Required	Value Type	Description
	Standard header	Y		<35> MsgType = 8
11	ClOrdID	Y	String	The unique identifier assigned to an order by the client as part of a New Order Single request.
37	OrderID	Y	String	The unique identifier assigned to an order by the FIX server.
17	ExecID	Y	String	The unique identifier assigned by the FIX server to an individual execution. An empty string, if <150> ExecType differs from F (Fill).
39	OrdStatus	Y	String	The current order status by the moment of message generation: A — the order is open and awaits execution 1 — the order is open, some part of it may already be filled 2 — the order is filled in the full amount 4 — the order is canceled, some part of it may already be filled 8 — the order is rejected, no part of it is filled
150	ExecType	Y	String	The type of a received report: F — the order is partially or fully filled (the report indicates the complete execution or specifies the part filled) A — the order is placed and awaits execution 4 — the order is canceled, some part of it may already be filled 8 — the order has been rejected, no part of it is filled
55	Instrument	Y	String	The ticker symbol of an instrument listed in the original order request, such as BTC/USDT.
54	Side	Y	int	The order side: 1 — buy 2 — sell
38	OrderQtyData	Y	Qty	The order amount, as indicated in the initial order.
40	OrdType	Y	int	The order type: 1 — a market order 2 — a limit order
44	Price	N	Price	The order bid or ask price. This field is included in the execution report for limit orders only.
59	TimeInForce	Y	Char	The time-in-force option applied to an order: 1 — GTC (Good till Canceled) 3 — IOC (Immediate or Cancel) 4 — FOK (Fill or Kill)
31	LastPx	N	Price	For reports signaling a trade execution (<150> ExecType = F), indicates the price of the last fill.
32	LastQty	N	Qty	For reports signaling a trade execution (<150> ExecType = F), indicates the amount of the last fill.
151	LeavesQty	Y	Qty	For reports signaling a trade execution (E<150> xecType = F), indicates the remaining order amount awaiting execution, taking into account the amount filled most recently.
14	CumQty	Y	Qty	The total order amount filled so far, including the amount filled most recently.
6	AvgPx	Y	Price	The average price calculated based on all order parts filled so far, taking into account the most recent execution. This value is 0 for orders that are still awaiting execution (<150> ExecType = A).
64	SettlDate	N	Date	For reports signaling a trade execution (<150> ExecType = F), indicates the UTC date of a trade settlement, in the YYYYMMDD format.
75	TradeDate	N	Date	For reports signaling a trade execution (<150> ExecType = F), indicates the UTC date of a fill, in the YYYYMMDD format.
103	OrdRejReason	N	int	For reports signaling an order rejection (<150> ExecType = F), indicates the rejection reason.
58	Text	N	String	For canceled (<150> ExecType = 8) or rejected (<150> ExecType = 4) orders, provides the reason why an order is discarded.
60	TransactTime	C	Timestamp	The date and time of the most recent change in the order status, in UTC time with milliseconds precision: YYYYMMDD-HH:MM:SS.sss. This field is omitted for orders that are still awaiting execution (<150> ExecType = A).
	Standard trailer	Y