Connectivity	Start of Day / End of Day Procedures	Appendix 1: Symbology
Supported Order Types	FIX Message Details Administrative Messages Order message types Market Data message types Account message types	Appendix 2: Field Types Change Log

Introduction

This document details the connectivity protocol and set-up for clients wishing to trade on Bequant Global Exchange.

Purpose of this document

This document is intended for clients who wish to trade through Bequant Global Exchange and who wish to access Bequant Global services by using the Financial Information Exchange (FIX) protocol, to allow them to understand the functionality offered by Bequant Global and to configure their software appropriately.

The FIX protocol enables access to the trading services and security information within Bequant Global , using a messaging standard developed for real-time exchange of security transactions.

Bequant Global FIX server is designed to closely follow the official FIX Protocol FIX 4.4 specifications. This document should therefore be read in conjunction with the FIX specifications on the FIX Protocol website (http://www.fixprotocol.org).

Note that optional fields are listed with a yellow shaded background and italicised. Members of repeating blocks are prefixed with ">>".

Functional Overview

Connectivity

Bequant Global offers two transport mechanisms for clients wishing to connect via FIX: VPN and Co-location.

VPN

Standard connectivity to Bequant Global FIX Gateway is via a Virtual Private Network (VPN) over public internet. Bequant Global uses OpenVPN – see https://openvpn.net/ for more details. Each Bequant Global client will be provided with individual connection VPN details for UAT and Production during the onboarding process.

Note that there are two FIX end-points, with different network addresses:

FIX Trading end-point: interface for trading (placing new orders, order status requests, execution reports, order cancellation).
FIX Market data end-point: interface for market data subscription.

Co-location

In Q2 2019 Bequant Global will be offering latency-sensitive FIX clients the ability to connect directly via our presence in the Equinix LD4 Data Centre in Slough, UK.

By Q4 2019 Bequant Global will be offering Co-location clients the ability to connect using FIX 5.0 in addition to FIX 4.4.

Additionally, by Q4 2019, Bequant Global will be offering co-location clients the ability to consume Market Data via a high-performance multicast mechanism.

For more details of co-location, including pricing, please contact Bequant Global Sales.

Trading Session

Bequant Global runs a continuous 24-hour trading session. Clients are able to trade at any time, seven days a week.

Day (session) orders automatically expire at UTC 00:00. Note that there is no automated cut-off and rollover to the next trading day i.e. if a day order is placed at UTC 23:59:00 it will expire after one minute at UTC 00:00:00.

Trading is not available during system maintenance. Clients will be notified well in advance of any such maintenance downtime.

Clients are limited to a single concurrent session per user, and are limited to sending 300 messages per second. Message rates in excess of 300/second may result in message rejection. Clients can request multiple user logins.

Clock Synchronisation

Timing issues may arise if clocks are out of synchronisation. Clients should verify with their system administrator that their FIX engine host’s clock is synchronised via a properly-configured NTP service.

Supported Order Types

The Bequant Global FIX Server supports the following Order Types:

Market Orders

Market Orders are orders to buy or sell a particular quantity of a currency pair at the prevailing price at the time the order was received.

Market Orders on Bequant Global will execute at a price not worse than 10% away from the best available price; any remainder will be expired.

Limit Orders

A standard Limit Order requests a trade of some quantity of a currency pair, at the requested price or better. If the prevailing market price is already better than the request price at the time the order is received, the order fills immediately. Otherwise, the order waits for execution until the price stipulation is met or the order expires as per its Time-in-Force.

Limit Orders requesting Day, Fill-or-Kill (FOK), Immediate-or-Cancel (IOC), Good-‘til-Cancel (GTC) or Good-‘til-Date (GTD) behave as described below.

Stop-Market Orders

A Stop-Market order is a Market Order that remains inactive until the market reaches a specified Stop Price.

Stop Limit Orders

A Stop-Limit order is a Limit Order that remains inactive until the market reaches a specified stop price.

Stop-Limit Orders requesting Day, Fill-or-Kill (FOK), Immediate-or-Cancel (IOC), Good-‘til-Cancel (GTC) or Good-‘til-Date (GTD) behave as described below.

Time in Force

All orders sent to Bequant Global must specify a Time-in-Force.

Day Orders

Orders placed with TimeInForce of Day stay on the order book until they are filled, cancelled, or until UTC 00:00:00 at which point they expire.

Fill-or-Kill (FOK) Orders

Orders placed with TimeInForce of Fill-or-Kill (FOK) are executed immediately if the price and quantity stipulations are met at the time the order is received. If they are not met, the order is cancelled in full.

Because FOK orders are always Limit or Stop orders, the Price (field 44) or StopPx (field 99) tags are required, as appropriate.

Immediate-or-Cancel (IOC) Orders

Orders placed with TimeInForce of Immediate-or-Cancel (IOC) are executed immediately if the price stipulation is met, up to the available quantity for execution, and the remaining quantity is cancelled.

Because IOC orders are always Limit or Stop orders, the Price (field 44) or StopPx (field 99) tags are required, as appropriate.

Good ‘til Cancel (GTC) Orders

Orders placed with TimeInForce of Good-‘til-Cancel (GTC) remain on the order book until they are filled or cancelled.

Good ‘til Date (GTD) Orders

Orders placed with TimeInForce of Good-‘til-Date (GTD) remain on the order book until they are filled, cancelled, or until the date stipulated is reached at which point they expire.

Order Management

All orders submitted through the FIX interface should be modified or cancelled through the FIX interface.

Market Data

Clients can obtain Market Data from the Bequant Global FIX Server, either by requesting a onetime Market Data snapshot, or a requesting a snapshot plus a subscription to a stream of incremental updates.

Account Management

The Bequant Global FIX Server supports Position Request messages (message type AN) and in response returns a Position Report (message type AP). This should be used to review account balances.

Duplicate and Resend Message handling

Duplicate messages are typically handled in the session layer. However, clients may wish to implement additional safety checks to protect themselves from duplicate messages.

For example, tag 43 in the standard header of each message indicates potentially duplicate information. The rules for processing this situation are defined within the FIX protocol itself and the FIX Engine session layer typically handles this. However, Clients may decide to improve on the session level handling of duplicates in their own platform, implemented one level above the session layer, and hence serving as an additional safeguard against duplicate information.

Disaster Recovery

In the case of a Bequant Global FIX Server failure there may be a brief interruption of service. In order to return to normal operating conditions Clients will need to reconnect and synchronise message sequence numbers i.e. resend any unsent messages, receive and process any messages not previously received, etc.

If an internal system fault occurs following receipt of a New Order message the Client will receive an Order Reject message with the specific reason “Too late to enter”. Note that in such a situation the order may actually have been placed.

We therefore recommend that upon receipt of an Order Reject message with the specific reason “Too late to enter” clients cancel all their open orders, close their FIX connection, open a new FIX connection, and then resubmit all orders.

We recommend that all Orders are sent with ExecInst (tag 18) set to 'o' – this instructs the FIX engine to cancel that order automatically on connection disconnect. Alternatively, Clients can set tag 10001 (Cancel on Disconnect) to “Y” in the Logon message – this will automatically cancel all orders upon FIX engine disconnection regardless of the value of ExecInst on the individual order messages.

In case of a severe fault the FIX session may be forcibly reset. In this case Clients will receive a Sequence Reset (type 4) message from the server, and should synchronise their state via an Order Mass Status Request (type AF) message.

For Co-location clients we can offer the option of a secondary cross-connect for added redundancy.

Symbology, Tick sizes and Lot sizes.

Clients must pass the identity of the currency pair they wish to trade via the Symbol (tag 55) field.
Quantity is represented in lots (e.g. 1 lot of BTCUSD is 0.00001 BTC), and must be supplied as an integer.
Price is represented in natural value (e.g. 550$ for BTC).

For a list of all supported currency pairs, their lot size and their tick size refer to Appendix 1.

Note that the symbol you must supply when sending orders via FIX can differ from the symbol displayed on the Bequant Global website, for example, the FIX symbol for BCH is BCHABC.

Start of Day / End of Day Procedures

The Bequant Global FIX Server runs 24/7, so there is no official start-of-day / end-of-day. Clients should set appropriate start and end times for their FIX sessions when connecting to Bequant Global in line with their own requirements.

Counterparty Identification

When initiating a connection to the Bequant Global FIX Server, clients will need to populate the SenderCompID (tag 49) and TargetCompID (56) fields.

Bequant Global will inform each client what values to set for these two fields as part of the onboarding process.

FIX Message Details

Headers and Trailers

Standard FIX Header and Trailers should be added by the Client to each message sent to the Bequant Global FIX Server.

Header

Tag	Name	Values	Type	Comments
8	BeginString	FIX.4.4	String
9	BodyLength	Message length in bytes	String	Message length, in bytes, forward to the CheckSum (tag 10) field
35	MsgType	0 - Heartbeat 1 - Test Request 2 - Resend Request A - Logon 5 - Logout D - NewOrderSingle F - Order Cancel Request H - Order Status Request V - Market Data Request AF - Mass Status Request AN - Request For Positions	String
49	SenderCompID	Will be in the format "login_<userID>”		Note that only one connection can be established with the same SenderCompID Bequant Global will inform client of appropriate value for <username>
56	TargetCompID	<TargetCompID>	String	Bequant Global will inform client of appropriate value for <TargetCompID>
34	MsgSeqNum	<sequence number>	SeqNum	Integer message sequence number
43	PossDupFlag	‘Y’ or ‘N’	Boolean	Indicates possible retransmission of message with this sequence number. If not supplied, defaults to N.
52	SendingTime	<Time message sent>	UTCTimestamp	In UTC
122	OrigSendingTime	<Time original message sent>	UTCTimestamp	Populated for messages resent as a result of a ResendRequest. If data is not available will be set to same value as SendingTime (tag 52)

Trailer

Tag	Name	Values	Type	Comments
10	CheckSum	Checksum of the message	String	Three byte simple checksum as per the standard FIX spec.

Administrative Messages

Logon

The Logon message (message type A) authenticates the Client establishing a connection to the Bequant Global FIX Server. In addition to the standard fields, clients will need to populate two additional fields – Username (tag 553) and Password (tag 554). Bequant Global will inform each client what values to set for these two fields during the onboarding process.

Clients can optionally populate custom tag 10001 (Cancel on Disconnect) in the Logon message with the value “Y”; this instructs the FIX engine to cancel all orders upon disconnection of the FIX session. If this tag is populated with “Y” then there is no need to populate ExecInst (tag 18) with value “o” on each New Order Single (type D) message.

Tag	Name	Values	Type	Comments
Header
35	MsgType	A	String	Logon message
Body
98	EncryptMethod	0	Integer	Should always be set to 0 (None)
108	HeartBtInt	Any numeric value in seconds e.g. 30	Integer	Desired heartbeat interval in seconds
141	ResetSeqNumFlag	Y or N	Boolean(optional)	Optional flag instructing Bequant Global Exchange to reset the connection sequence numbers. If not supplied defaults to N
553	Username	<username>	String	Will be supplied by Bequant Global
554	Password	<password>	String	Will be supplied by Bequant Global
10001	CancelOnDisconnect	Y or N	Boolean(optional)	Optional flag instructing Bequant Global to cancel all open orders should the Client’s FIX session unexpectedly disconnect. If not supplied defaults to N

Logout

The Logout message (type 5) initiates or confirms the termination of a FIX session. It can optionally contain the Text field (tag 58) which is populated with the reason for the Logout.

Tag	Name	Values	Type	Comments
Header
35	MsgType	5	String	Logout Message
Body
58	Text	<reason for logout>	String	Optional string which if populated contains the reason for the logout where initiated by Bequant Global .

Heartbeat

The Heartbeat message (type 0) monitors the status of the communication link and identifies when the last of a string of messages was not received. A Heartbeat is sent every x seconds, as defined in the HeartbeatInterval field in the Logon message, as well as in response to a TestRequest message.

Inclusion of the optional TestReqID field (tag 112) indicates that this Heartbeat is a response to a TestRequest message.

Tag	Name	Values	Type	Comments
Header
35	MsgType	0	String	Heartbeat message
Body
112	TestReqID		String	Optional string which if populated contains whatever was passed in the Test Request message that this Heartbeat is responding to.

Test Request

The test request message (type 1) forces a heartbeat from the opposing application. It can be initiated both from the Client and from the Bequant Global server.

Tag	Name	Values	Type	Comments
Header
35	MsgType	1	String	TestRequest message
Body
112	TestReqID	Any value	String	Custom identifier which will be returned in the resulting Heartbeat

Resend Request

A ResendRequest (type 2) message can be sent by either the Client or the Bequant Global FIX Server to request the retransmission of a previous message or a range of messages.

This function is used if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialisation process.

If request is for a single message then BeginSeqNo should have the same value as EndSeqNo. If the request is for all messages subsequent to a particular message defined in BeginSeqNo, then EndSeqNo should be set to ‘0’.

Tag	Name	Values	Type	Comments
Header
35	MsgType	2	String	Resend Request
Body
7	BeginSeqNo	<sequence number>	SeqNum	Message sequence number of the first message in range to be resent
16	EndSeqNo	<sequence number> or 0	SeqNum	Message sequence number of the last message in a range to be resent. If request is for a single message BeginSeqNo = EndSeqNo. If request is for all messages subsequent to a particular message, EndSeqNo = "0"

Reject

A Reject (type 3) message is issued when a message is received but cannot be properly processed due to a session-level rule violation. Whenever possible, it is strongly recommended that the cause of the failure be described in the Text (tag 58) field.

Tag	Name	Values	Type	Comments
Header
35	MsgType	3	String	Reject
Body
45	RefSeqNum	< sequence number>	SeqNum	MsgSeqNum of rejected message
371	RefTagID	<tag id>	Integer	The tag number of the FIX field being referenced.
372	RefMsgType	<message type>	String	The MsgType (field 35) of the FIX message being referenced.
58	Text		String	An optional message explaining the reason for the rejection

SequenceReset

A Sequence Reset (type 4) message instructs the receiving FIX Server to set the next expected message sequence number to a new value, which is contained in the FIX message in the NewSeqNo (tag 36) field.

The Sequence Reset (type 4) message has two modes: Gap Fill mode and Reset mode.

Gap Fill mode

Gap Fill mode is used in response to a Resend Request (type 2) message when one or more messages must be skipped over for one of the following two reasons:

During normal resend processing, the sending application may choose not to send a message (e.g. an aged order).
During normal resend processing, a number of administrative messages are skipped and not resent (such as Heart Beats, Test Requests).

Gap Fill mode is indicated by GapFillFlag (tag 123) field = "Y".

If the GapFillFlag (tag 123) field is present and equal to "Y", the MsgSeqNum (tag 34) in the Header should conform to standard message sequencing rules i.e. the MsgSeqNum (tag 34) of the Sequence Reset Gap Fill mode message should represent the beginning MsgSeqNum (tag 34) in the Gap Fill range because the remote side is expecting that next message sequence number.

Reset mode

Reset mode involves specifying an arbitrarily higher new sequence number to be expected by the receiver of the Sequence Reset Reset message, and is used to re-establish a FIX session after an unrecoverable application failure.

Reset mode is indicated by the GapFillFlag (tag 123) field being set to "N" or if the field is omitted entirely.

If the GapFillFlag (tag 123) field is not present, or set to N, it can be assumed that the purpose of the Sequence Reset message is to recover from an out-of-sequence condition. In Sequence Reset - Reset mode, the MsgSeqNum (tag 34) in the header should be ignored i.e. the receipt of a Sequence Reset - Reset mode message with an out of sequence MsgSeqNum (tag 34) should not generate resend requests.

Note that ‘Sequence Reset – Reset’ should NOT be used as a normal response to a Resend Request message. The Sequence Reset - Reset should ONLY be used to recover from a disaster situation which cannot be recovered via the use of Sequence Reset - Gap Fill. Note also that the use of Sequence Reset - Reset may result in the possibility of lost messages.

Tag	Name	Values	Type	Comments
Header
35	MsgType	4	String	Sequence Reset
Body
123	GapFillFlag	N or Y	Boolean	Indicates that the Sequence Reset message is replacing administrative or application messages which will not be resent. If this field not supplied, value defaults to N.
36	NewSeqNo		SeqNum	New sequence number

Order message types

New Order Single

The New Order (type D) message is used by clients wishing to electronically submit orders to Bequant Global Exchange for execution.

The Cancel on Disconnect logic is as follows:

Check the value of optional tag CancelOnDisconnect (10001) in the New Order message. If that is set to Y then this order will be cancelled upon session disconnect. If it is set to N then this order will not be cancelled upon session disconnect, regardless of the session-level setting.
If CancelOnDisconnect (10001) is not supplied in the Order message then the value of tag CancelOnDisconnect (10001) that was sent in the Logon message (i.e. the session-level setting) will be used to determine whether this order will be cancelled upon disconnect.

Tag	Name	Values	Type	Comments
Header
35	MsgType	D	String	New Order Single
Body
11	ClOrdID	<client defined>	String	Unique identifier for Order as assigned by the Client. Uniqueness must be guaranteed within a single trading day. Clients, particularly those who submit multi-day orders, should ensure uniqueness across days, for example by embedding a date within the ClOrdID field. Has to be <= 32 characters
453	NoPartyIDs	1	NumInGroup	Bequant Global expects each order to be single, hence only details of one counterparty will be supplied.
>>448	PartyID	Will be in the format "user_<userID>”	String	Client’s Bequant Global Exchange user ID Member of the Parties component repeating / block.
1	Account	Will be in the format "account_<userID>”	String	Account mnemonic as agreed between Client and Bequant Global
55	Symbol	<currency pair>	String	See appendix for list of symbols
54	Side	1 – Buy 2 – Sell	Char
60	TransactTime	<order time>	UTCTimestamp	Time in UTC this order request was sent by the Client
38	OrderQty	<quantity>	Integer	Quantity ordered. Must be compliant with Lot Size for this symbol (see Appendix 1)
40	OrdType	1 – Market 2 – Limit 3 – Stop 4 – Stop Limit	Char
44	Price	<price>	Price	Required for Limit and Stop Limit orders. Should not be specified for Market and StopMarket orders.
59	TimeInForce	0 - Day 1 - Good ‘Til Cancel (GTC) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) 6 - Good ‘Til Date (GTD)	Char	Day orders expire at UTC 00:00:00 Note that this field is mandatory.
99	StopPX	<stop price>	Price	Required for Stop Limit and Stop orders. Should not be specified for Market and Limit orders.
126	ExpireTime	<utc datetime>	UTCTimestamp	Date/Time when GTD orders should expire, in UTC. Required for GTD orders, not needed for others.
18	ExecInst	6 = Post-Only (aka participate don't initiate)	String	If ExecInst (18) = 6 then the order will only be placed onto the order book if does not immediately trigger a transaction. If the order would have immediately triggered a transaction then it will be immediately expired. In this situation the client will receive two Execution Report messages – a New followed by an Expired.
10001	CancelOnDisconnect	Y or N	Boolean	If set to Y, instructs Bequant Global to cancel this order if the client’s FIX session is disconnected.

Execution Report

The Execution Report (type 8) message is used to:

confirm the receipt of an order.
confirm changes to an existing order (i.e. accept cancel and replace requests).
relay order status information.
relay fill information on working orders.
reject orders.
report post-trade fees calculations associated with a trade.

Each execution report contains two fields which are used to communicate both the current state of the order as understood by the broker - OrdStatus (tag 39) - and the purpose of the message - ExecType (tag 150).

Note that OrdStatusReqID (790) is not populated on execution reports which are responding to an OrderStatusRequest message.

Tag	Name	Values	Type	Comments
Header
35	MsgType	8	String	Execution Report
Body
37	OrderID	<order id>	String	Order ID allocated by Bequant Global
11	ClOrderID	<client order id>	String	Client’s Order ID
41	OrigClOrdID	<client order id>	String	ClOrdID of the previous accepted order when cancelling or replacing an order. Only populated if this execution report is in response to an OrderCancelRequest message.
17	ExecID	<execution ID>	String	Unique identifier of execution message as assigned by Bequant Global
527	SecondaryExecID	<execution ID>	String
150	ExecType	0 - New 4 - Cancelled 5 - Replaced 8 - Rejected 9 - Suspended C - Expired F - Trade (partial fill or fill) I - Order Status	Char	Describes the purpose of the execution report.
39	OrdStatus	0 - New 1 - Partially filled 2 - Filled 4- Cancelled 8 – Rejected 9 - Suspended C - Expired	Char	Describes the current state of the order.
103	OrdRejReason	1 - Unknown symbol 2 - Exchange closed 4 - Too late to enter 5 - Unknown Order 6 - Duplicate Order (e.g. dupe ClOrdID (11)) 11 - Unsupported order characteristic 15 - Unknown account(s) 99 - Other	Char	Only populated if this Execution Report is rejecting a previously placed order i.e. 150=8
1	Account	Will be in the format "account_<userID>”	String	Account mnemonic as agreed between Client and Bequant Global
55	Symbol	<currency pair>	String	See appendix for list of symbols
54	Side	1 – Buy 2 – Sell	Char
60	TransactTime	<order time>	UTCTimestamp	Time in UTC this order request was sent by the Client
38	OrderQty	<quantity>	Qty	Quantity ordered.
40	OrdType	1 – Market 2 – Limit 3 – Stop 4 – Stop Limit	Char
44	Price	<price>	Price	Only populated for Limit orders
59	TimeInForce	0 - Day 1 - Good ‘Til Cancel (GTC) 2 - Immediate or Cancel (IOC) 4 - Fill or Kill (FOK) 6 - Good ‘Til Date (GTD)	59	Day orders expire at UTC 00:00:00
126	ExpireTime	<time>	UTCTimestamp	Expiration time (if Good Til Date order)
18	ExecInst	6 - Post-Only (aka participate don't initiate)	String
99	StopPX	<stop price>	Price	Only populated for Stop & Stop Limit Orders
32	LastQty	<quantity>	Qty	Quantity bought/sold on this fill. Required if ExecType = Trade
31	LastPx	<price>	Price	Price of this fill. Required if ExecType = Trade
851	LastLiquidityInd	1 - Added Liquidity 2 - Removed Liquidity	Char	Indicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity. Applicable only for OrdStatus of Partial or Filled.
151	LeavesQty	<quantity>	Qty	Quantity open for further execution. If the OrdStatus is Cancelled, DoneForTheDay, Expired, Calculated, or Rejected (in which case the order is no longer active) then LeavesQty could be 0, otherwise LeavesQty = OrderQty - CumQty.
14	CumQty	<quantity>	Qty	Currently executed quantity
6	AvgPx	<price>	Price	Calculated average price of all fills on this order.
137	MiscFeeAmt	<trading fee amount>	Amt	Exchange fee associated with this trade
138	MiscFeeCurr	<trading fee currency>	Currency	Currency that the trading fee is denominated in
139	MiscFeeType	4 – Exchange Fees	Char	Indicates that Fee is an Exchange Fee
584	MassStatusReqID	<client-defined ID>	String	Required if responding to an Order Mass Status Request. Echoes back the value provided by the requester.
912	LastRptRequested	N - There is at least one more execution report Y - This is last execution report	Boolean	Can be used when responding to an Order Mass Status Request to indicate that this is the last Execution Reports which will be returned as a result of the request.

Order Cancel Request

The Order Cancel Request (type F) message requests the cancellation of all of the remaining quantity of an existing order.

Each Cancel Request is assigned a unique ID in the ClOrdID (tag 11) field, and is subsequently treated as a separate entity. If rejected, the ClOrdID (tag 11) of the cancel request will be sent in the Cancel Reject (type 3) message, as well as the ClOrdID (tag 11) of the actual order in the OrigClOrdID (tag 41) field. The ClOrdID (tag 11) assigned to the cancel request must be unique amongst the ClOrdID (tag 11) fields assigned to regular orders and replacement orders.

Tag	Name	Values	Type	Comments
Header
35	MsgType	F	String	Order Cancel Request
Body
41	OrigClOrdID	<order id>	String	ClOrdID of the order the client is requesting to cancel.
11	ClOrdID	<order id>	String	Unique ID for this Cancel Request as assigned by the client.
1	Account	Will be in the format "account_<userID>”	String	Account associated with the order that the client is requesting to cancel
453	NoPartyIDs	1	NumInGroup	Number of counterparties (always one) in the following Party Component Repeating Group
>>448	PartyID	Will be in the format "user_<userID>”	String	Client’s Bequant Global Exchange user ID Member of the Parties component repeating / block.
>>447	PartyIDSource	D = Proprietary	Char	Member of the Parties component repeating / block.
>>452	PartyRole	3 = Client ID	Integer	Member of the Parties component repeating / block.
55	Symbol	<currency pair>	String	Symbol associated with the order the client is requesting to cancel
54	Side	1 – Buy 2 – Sell	Char	Side associated with the order the client is requesting to cancel
60	TransactTime	<order time>	UTCTimestamp	TransactTime of the order the client is requesting to cancel
38	OrderQty	<quantity>	Qty	OrderQty = CumQty + LeavesQty of the order the client is requesting to cancel.

Order Cancel/Replace Request

The Order Cancel/Replace Request (type G) message can be used to change the details of an existing order.

An order will lose its time priority in the order book if any of its parameters are amended via a Cancel/Replace Request.

The following attributes of an order may be amended via the Order Cancel/Replace Request message:

Quantity.
Price.

Bequant Global will respond with an Execution Report or Order Cancellation Rejection to confirm or reject the amendment request respectively.

Stop Market/Stop Limit orders cannot be amended whilst they are suspended i.e. prior to the order becoming active. Once a Stop Market/Stop Limit order has become active, the quantity and where applicable the limit price may be amended.

If an order receives one or more fills while an amendment request is in flight, the system will not reject the incoming amendment request provided its quantity after amending will still be greater than the filled quantity. If this is not the case the amendment request will be rejected.

When processing a Cancel/Replace the existing order is cancelled and a new order is placed on the order book. This is executed as a single atomic transaction. However, the newly-placed order loses its order book time priority. Hence, if the intention is to increase the quantity of an existing order we recommend clients send a New Order message for the increased quantity rather than a Cancel/Replace.

Clients should not use this message to cancel the remaining quantity of an outstanding order, instead they should send an Order Cancel Request (type F) message.

The Cancel/Replace Request will only be accepted if the order being cancelled can successfully be pulled back from the exchange without executing. Requests which cannot be processed will be rejected using the Cancel Reject (type 3) message.

Each Cancel/Replace Request is assigned a unique ID in the ClOrdID (tag 11) field, and is subsequently treated as a separate entity. If rejected, the ClOrdID (tag 11) of the cancel request will be sent in the Cancel Reject (type 3) message, as well as the ClOrdID (tag 11) of the actual order in the OrigClOrdID (tag 41) field. The ClOrdID (tag 11) assigned to the cancel request must be unique amongst the ClOrdID (tag 11) fields assigned to regular orders and replacement orders.

Tag	Name	Values	Type	Comments
Header
35	MsgType	G	String	Order Cancel/Replace Request
Body
37	OrderID	<order id>	String	ID of the Order assigned by Bequant Global that the client wishes to cancel & replace. Must be supplied if OrigClOrdID missing.
453	NoPartyIDs	1	NumInGroup	Number of counterparties (always one) in the following Party Component Repeating Group
>>448	PartyID	Will be in the format "user_<userID>”	String	Client’s Bequant Global Exchange user ID Member of the Parties component repeating / block.
>>447	PartyIDSource	D = Proprietary	Char	Member of the Parties component repeating / block.
>>452	PartyRole	3 = Client ID	Integer	Member of the Parties component repeating / block.
11	ClOrdID	<order id>	String	Unique ID for this Cancel Request as assigned by the client.
41	OrigClOrdID	<order id>	String	ID of the Order assigned by the Client that the client wishes to cancel & replace. Must be supplied if OrderID missing.
1	Account	Will be in the format "account_<userID>”	String	Account associated with the order that the client is requesting to cancel/replace
55	Symbol	<currency pair>	String	Symbol associated with the order the client is requesting to cancel/replace
40	OrdType	1 = Market 2 = Limit 3 = Stop 4 = Stop Limit	Char	Order Type
54	Side	1 – Buy 2 – Sell	Char	Side associated with the order the client is requesting to cancel/replace
38	OrderQty	<quantity>	Qty	New Order quantity. Must be greater than CumQty.
44	Price	< price>	Price	New Price. Required for Limit and Stop-Limit orders
99	StopPx	<stop price>	Price	Required for Stop and Stop-Limit orders. Can not be modified from original order.
126	ExpireTime	<utc datetime>	UTCTimestamp	Date/Time when GTD orders should expire, in UTC. Required for GTD orders, not needed for others. Can not be modified from original order.
60	TransactTime	<order time>	UTCTimestamp	TransactTime of the order the client is requesting to cancel

Order Cancel Reject

The Order Cancel Reject (type 9) message is issued by Bequant Global upon receipt of a Cancel Request message which cannot be honoured.

Tag	Name	Values	Type	Comments
Header
35	MsgType	9	String	Order Cancel Reject
Body
37	OrderID	<order id>	String	Order ID of the order the client attempted to cancel. If CxlRejReason=”Unknown order”, value of this tag will be “NONE”
11	ClOrdID	<order id>	String	Unique order id assigned by Client to the cancel request that was rejected
41	OrigClOrdID	<order id>	String	ClOrdID which could not be cancelled. ClOrdID of the previous accepted order (NOT the initial order of the day) when cancelling an order.
39	OrdStatus	0 - New 1 - Partially filled 2 - Filled 4 - Cancelled 8 - Rejected 9 - Suspended C - Expired	Char	OrdStatus value after this Cancel Reject is applied. If CxlRejReason = "Unknown Order", value will be “Rejected”.
434	CxlRejResponseTo	1 = Order Cancel Request 2 = Order Cancel/Replace Request	Char	Identifies the type of request that a Cancel Reject is in response to
102	CxlRejReason	0 = Too late to cancel 1 = Unknown order 99 = Other	Integer

Order Status Request

The Order Status Request (type H) message is used by Clients to request order status for one of their orders. Bequant Global will respond with an Execution Report (type 8) message with ExecType (tag 150) ="Order Status".

In case of any errors for example if the Order is not found, Bequant Global will respond with a Reject message.

Tag	Name	Values	Type	Comments
Header
35	MsgType	H	String	Order Status Request
Body
11	ClOrdID	<order id>	String	Unique order id assigned by Client to the order they want status for.
790	OrdStatusReqID	<client defined>	String	Can be used to uniquely identify a specific Order Status Request message. When supplied this is echoed back on the subsequent execution report message.
1	Account	Will be in the format "account_<userID>”	String	Account associated with the order that the client is status for.
453	NoPartyIDs	1	NumInGroup	Number of counterparties (always one) in the following Party Component Repeating Group
>>448	PartyID	Will be in the format "user_<userID>”	String	Client’s Bequant Global Exchange user ID Member of the Parties component repeating / block.
>>447	PartyIDSource	D = Proprietary	Char	Member of the Parties component repeating / block.
>>452	PartyRole	3 = Client ID	Integer	Member of the Parties component repeating / block.
55	Symbol	<currency pair>	String	Symbol associated with the order the client is requesting status for.
54	Side	1 – Buy 2 – Sell	Char	Side associated with the order the client is requesting status for.

Order Mass Status Request

The Order Mass Status Request (type AF) message requests the status for all orders for the Client in the supplied Account.

A mass status request is assigned a ClOrdID (tag 11) and is treated as a separate entity.

Execution Reports with ExecType (tag 150) ="Order Status" are returned for all orders matching the criteria provided on the request (i.e. for the Client/Account). Such an Execution Report will have the MassStatusReqID (tag 584) field filled in, and the very last one will have the LastRptRequested (912) flag populated.

Tag	Name	Values	Type	Comments
Header
35	MsgType	AF	String	Order Mass Status Request
Body
584	MassStatusReqID	<client defined>	String	Unique ID of mass status request as assigned by the Client. Echoed back on the execution report responses.
585	MassStatusReqType	7		All orders
1	Account	Will be in the format "account_<userID>”	String	Account associated with the orders that the client is asking status for.
453	NoPartyIDs	1	NumInGroup	Number of counterparties (always one) in the following Party Component Repeating Group
>>448	PartyID	Will be in the format "user_<userID>”	String	Client’s Bequant Global Exchange user ID Member of the Parties component repeating / block.
>>447	PartyIDSource	D = Proprietary	Char	Member of the Parties component repeating / block.
>>452	PartyRole	3 = Client ID	Integer	Member of the Parties component repeating / block.

Business Message Reject

A Business Message Reject (type j) message is sent by Bequant Global when a Client message cannot be processed.

Tag	Name	Values	Type	Comments
Header
35	MsgType	j	String	Business Message Reject. Note that this is lowercase i.e. j not J.
Body
45	RefSeqNum	<sequence number>	SeqNum	MsgSeqNum of rejected message
372	RefMsgType	<message type>	String	Message type of the FIX message being referenced.
380	BusinessRejectReason	0 = Other 1 = Unkown ID 3 = Unsupported Message Type 4 = Application not available 5 = Conditionally Required Field Missing 6 = Not authorized	Integer	Code to identify reason for a Business Message Reject message.

Market Data message types

Market Data Request

Clients can use the Market Data Request (type V) message to both subscribe to and unsubscribe from real-time receipt of Market Data from Bequant Global Exchange.

When making a Subscription Request, Clients must supply the Symbols they are requesting market data for and whether they want the entire order book or just the top of the book. Clients can request a one-time Snapshot, or a Snapshot plus ongoing streamed updates.

When Unsubscribing, the Client must pass the ID of the Subscription Request they wish to cancel.

A successful Market Data Subscription Request returns one or more Market Data (type W or type X) messages, each containing one or more Market Data Entries. Each Market Data Entry can be a Bid, an Offer or a Trade associated with a currency pair.

Requesting just the top of book will result in receipt of just the Best Bid and Best Offer. For a full book, the Bid and Offer side may each have several Market Data Entries.

A Snapshot causes the current state of the market to be sent. A Snapshot + Updates causes the current state of the market to be sent along with any updates as they occur, until the client requests that the Snapshot + Updates be disabled.

When just a Snapshot is requested, the complete data for only one currency pair will be returned in the FIX Market Data Snapshot Full Refresh message.

When Snapshot + Updates is requested, the updates are streamed incrementally. Several incremental updates of market data entries for different instruments can be included in one FIX Market Data message. Note that you may receive incremental updates before a Snapshot is received; these should be ignored.

Trades are not supplied in a Snapshot but are supplied in Snapshot + Incremental Update.

A Market Data Request Reject (message type Y) may be sent in response to a request that cannot be honoured.

Tag	Name	Values	Type	Comments
Header
35	MsgType	V	String	Market Data Request
Body
262	MDReqID	<client defined unique id>	String	Either unique if this is a new request, else the ID of the previous Market Data Request to disable if SubscriptionRequest Type = 2 (Disable previous Snapshot + Updates Request).
263	SubscriptionRequestType	0 - Snapshot 1 - Snapshot + updates 2 - Disable previous Snapshot + Update Request (Unsubscribe)	Char
264	MarketDepth	0 - Full Book 1 - Top of Book	Integer	Required for subscription requests.
146	NoRelatedSym	<number of instruments>	NumInGroup	The number of entries in the InstrmtMDReqGrp repeating group (i.e. how many tag 55s). Required for subscription requests.
>>55	Symbol	<symbol>	String	Currency Pair Symbol that you are requesting market data for. There can be multiple tag 55s as part of the InstrmtMDReqGrp repeating group. Required for subscription requests.

MarketDataRequestReject

A MarketDataRequestReject (type Y) message is sent to a Client if a MarketDataRequest cannot be honoured by Bequant Global.

Tag	Name	Values	Type	Comments
Header
35	MsgType	Y	String	Market Data Request Reject
Body
262	MDReqID	<client defined unique id>	String	ID of the Market Data Request this reject pertains to.
281	MDReqRejReason	0 = Unknown Symbol 1 = Duplicate MDReqID 4 = Unsupported Subscription Request Type 5 = Unsupported Market Depth 6 = Unsupported MDUpdate Type 8 = Unsupported MDEntry Type	Char	Optional field which may be populated to explain why the request was rejected.
58	Text	<reason for rejection>	String	Optional text.

MarketDataSnapshotFullRefresh

The Market Data Snapshot Full Refresh message (type W) is used as the response to a Market Data Request (type V) message.

Market Data messages sent as the result of a Market Data Request message will specify the appropriate MDReqID (tag 262).

Market Data messages can take two forms - a static Snapshot, or a Snapshot plus incremental streamed Updates.

A Snapshot is the current state of the order book at the time of the request; it contains only bids and offers for the depth specified in the request. Each one message contains the order book just for one symbol, snapshots never contain trades.

A Snapshot is sent in response to a Snapshot Request, or when subscribing to Snapshots + Updates. When subscribing, one Snapshot is sent, and after that only Updates are published.

Tag	Name	Values	Type	Comments
Header
35	MsgType	W	String	Market Data Snapshot Full Refresh
Body
262	MDReqID	<client defined unique id>	String	ID of the Market Data Request this message pertains to.
55	Symbol	<currency pair symbol>	String	Currency pair this message contains market data for.
268	NoMDEntries	<number of entries>	NumInGroup	Number of MD Entries in the repeating group
>>269	MDEntryType	0 – Bid 1 – Offer	Char	Member of repeating group of MD entries
>>270	MDEntryPx	<price>	Price	Member of repeating group of MD entries
>>271	MDEntrySize	<quantity>	Qty	Quantity or volume represented by the Market Data Entry. Member of repeating group of MD entries
>>272	MDEntryDate	<date>	UTCDateOnly	Member of repeating group of MD entries
>>273	MDEntryTime	<time>	UTCTimeOnly	Member of repeating group of MD entries

MarketDataIncrementalRefresh

A Market Data Incremental Refresh message (type X) can also be sent in response to a Market Data Request (type V) message. They contain details of incremental updates to a previously supplied Snapshot addition, deletion or level changing to the Order Book as well as details of any trades that have taken place.

Note that Tag 271 (MD Entry Size) will be set to zero if the price level of this MD Entry was removed from the Order Book.

Each message will only contain information about one currency pair but can contain details of multiple Order Book increments and Trades.

Tag	Name	Values	Type	Comments
Header
35	MsgType	X	String	Market Data Snapshot Full Refresh
Body
262	MDReqID	<client defined unique id>	String	ID of the Market Data Request this message pertains to.
268	NoMDEntries	<number of entries>	NumInGroup	Number of MD Entries in the repeating group
>>279	MDUpdateAction	0 – New 1 – Change 2 - Delete	Char	In the case of a level removal MDEntrySize will be 0 Member of the MD Entries repeating group
>>269	MDEntryType	0 – Bid 1 – Offer 2 – Trade	Char	Member of the MD Entries repeating group
>>55	Symbol	<currency pair symbol>	String	Currency pair this message contains market data for.
>>270	MDEntryPx	<price>	Price
>>271	MDEntrySize	<quantity>	Qty	Quantity or volume represented by the Market Data Entry.
>>272	MDEntryDate	<date>	UTCDateOnly	Member of repeating group of MD entries
>>273	MDEntryTime	<time>	UTCTimeOnly	Member of repeating group of MD entries
>>278	MDEntryID	<trade ID>	String	Contains ID of the trade that generated this Market Data Update(where applicable)

Account message types

RequestForPositions

The Request for Positions message (type AN) is used by the Client to request a Position Report from Bequant Global .

Bequant Global only supports one-time snapshot of positions, hence the value of the PosReqType (tag 724) field will always be 0, as well the value of the SubscriptionRequestType (tag 263) field.

Tag	Name	Values	Type	Comments
Header
35	MsgType	AN	String	Request For Positions
Body
710	PosReqID	<client defined unique id>	String	Unique ID of this Position Request
724	PosReqType	0 - Positions	Integer	Bequant Global only supports request for positions hence value always 0
263	SubscriptionRequestType	0 - Snapshot	Char	Bequant Global only supports snapshots positions hence value always 0
453	NoPartyIDs	0	NumInGroup	Bequant Global returns all positions for the client, hence this value is set to 0.
1	Account	Will be in the format "account_<userID>”	String	Client Account Identifier
581	AccountType	8 – Joint Backoffice Account	Integer	Hardcode to 8
15	Currency	<currency>	Currency	Identifies currency used for price.
715	ClearingBusinessDate	Now in format YYYYMMDD	LocalMktDate	Ignored but mandatory, pass “now”
60	TransactTime	Now in UTC	UTCTimeStamp	Ignored but mandatory, pass “now”

PositionReport

The Position Report (type AP) message is returned by Bequant Global a position in response to a Request for Position message from the Client. The purpose of the message is to report all aspects of a position and may be provided on a standing basis to report end of day positions to an owner.

The report contains a repeating group of Position Amount entries.

Tag	Name	Values	Type	Comments
Header
35	MsgType	AN	String	Request For Positions
Body
721	PosMaintRptID	<id>	String	Unique ID of this Position Report
710	PosReqID	<client defined unique id>	String	Unique identifier for the Request for Positions associated with this report
728	PosReqResult	0 - Valid request 1 - Invalid or unsupported request	Integer	If the request is processed successfully this field is not populated, hence is missing can be assumed to have a value of 0
715	ClearingBusinessDate	19810711	LocalMktDate	Mandatory but not used hence dummy value.
453	NoPartyIDs	0	NumInGroup	Bequant Global returns all positions for the client, hence this value is set to 0.
1	Account	Will be in the format "account_<userID>”	String	Client Account Identifier
581	AccountType	8 – Joint Backoffice Account	Integer	Hardcode to 8
15	Currency	<currency>	Currency	Identifies currency used for price.
720	SettlePrice	0.0	Price	Mandatory but not used hence dummy value.
731	SettlePriceType	1 = Final	Integer
734	PriorSettlPrice	0.0	Price	Mandatory but not used hence dummy value.
702	NoPositions	0	NumInGroup	Number of position entries.
753	NoPosAmt	1 or 2	NumInGroup	1 indicates an error.2 indicates a success.
>>707	PosAmtType	CASH (Cash Amount) CRES (Cash Residual Amount)	String	CASH (Cash Amount Corporate Event) is the total amount of this currency on the user's account. CRES (Cash Residual Amount) is the amount of this currency not blocked by the position that is, available for opening positions. Member of Position repeating group
>>708	PosAmt	<amount>	Amt	Account balance or 0 in case of errorMember of Position repeating group
58	Text	“15 (Currency)” “1 (Account)” “710 (PosReqID)”	String	Contains incorrect tag in case of wrong message

Appendix 1: Symbology

Symbol	FIX Symbol	Base Ccy	Quote Ccy	Lot Size	Tick Size	Fee Ccy
BTCUSDT	BTCUSD	BTC	USDT	0.00001	0.01	USDT
BTGBTC	BTGBTC	BTG	BTC	0.001	0.0000001	BTC
BTGUSDT	BTGUSD	BTG	USDT	0.001	0.00001	USDT
EOSBTC	EOSBTC	EOS	BTC	0.01	0.00000001	BTC
EOSUSDT	EOSUSD	EOS	USDT	0.01	0.00001	USDT
ETCBTC	ETCBTC	ETC	BTC	0.01	0.0000001	BTC
ETCUSDT	ETCUSD	ETC	USDT	0.01	0.00001	USDT
ETHBTC	ETHBTC	ETH	BTC	0.0001	0.000001	BTC
ETHUSDT	ETHUSD	ETH	USDT	0.0001	0.001	USDT
LTCBTC	LTCBTC2	LTC	BTC	0.001	0.0000001	BTC
LTCUSDT	LTCUSD	LTC	USDT	0.001	0.0001	USDT
NEOBTC	NEOBTC	NEO	BTC	0.01	0.0000001	BTC
NEOUSDT	NEOUSD	NEO	USDT	0.01	0.00001	USDT
XRPBTC	XRPBTC2	XRP	BTC	0.1	0.000000001	BTC
XRPUSDT	XRPUSD2	XRP	USDT	0.1	0.000001	USDT
BTCEURS	BTCEURS	BTC	EURS	0.00001	0.01	EURS
EOSEURS	EOSEURS	EOS	EURS	0.01	0.00001	EURS
ETHEURS	ETHEURS	ETH	EURS	0.0001	0.0001	EURS
LTCEURS	LTCEURS	LTC	EURS	0.001	0.0001	EURS
NEOEURS	NEOEURS	NEO	EURS	0.01	0.00001	EURS
XRPEURS	XRPEURS	XRP	EURS	0.1	0.000001	EURS
BTCDAI	BTCDAI	BTC	DAI	0.00001	0.01	DAI
ETHDAI	ETHDAI	ETH	DAI	0.0001	0.001	DAI
EOSDAI	EOSDAI	EOS	DAI	0.01	0.00001	DAI
USDTDAI	USDDAI	USDT	DAI	0.01	0.00001	DAI
NEODAI	NEODAI	NEO	DAI	0.01	0.00001	DAI
LTCDAI	LTCDAI	LTC	DAI	0.001	0.0001	DAI
XRPDAI	XRPDAI	XRP	DAI	0.1	0.000001	DAI
EURSDAI	EURSDAI	EURS	DAI	0.01	0.00001	DAI
BTCGUSD	BTCGUSD	BTC	GUSD	0.00001	0.01	GUSD
ETHGUSD	ETHGUSD	ETH	GUSD	0.0001	0.001	GUSD
USDTGUSD	USDGUSD	USDT	GUSD	0.01	0.000001	GUSD
EOSGUSD	EOSGUSD	EOS	GUSD	0.01	0.00001	GUSD
BCHBTC	BCHABCBTC	BCH	BTC	0.0001	0.000001	BTC
BCHUSDT	BCHABCUSD	BCH	USDT	0.0001	0.001	USDT
BSVBTC	BCHSVBTC	BSV	BTC	0.001	0.000001	BTC
BSVUSDT	BCHSVUSD	BSV	USDT	0.001	0.0001	USDT
BTCPAX	BTCPAX	BTC	PAX	0.00001	0.01	PAX
ETHPAX	ETHPAX	ETH	PAX	0.0001	0.001	PAX
USDTPAX	USDPAX	USDT	PAX	0.01	0.000001	PAX
EOSPAX	EOSPAX	EOS	PAX	0.01	0.0000001	PAX
BTCUSDC	BTCUSDC	BTC	USDC	0.00001	0.00001	USDC
ETHUSDC	ETHUSDC	ETH	USDC	0.0001	0.000001	USDC
USDTUSDC	USDUSDC	USDT	USDC	1	0.00000001	USDC
DAIUSDC	DAIUSDC	DAI	USDC	0.1	0.00000001	USDC
BTCKRWB	BTCKRWB	BTC	KRWB	0.00001	1	KRWB
USDCKRWB	USDCKRWB	USDC	KRWB	0.01	0.01	KRWB
USDTKRWB	USDKRWB	USDT	KRWB	0.01	0.01	KRWB
EOSETH	EOSETH	EOS	ETH	0.01	0.0000001	ETH
ETCETH	ETCETH	ETC	ETH	0.01	0.0000001	ETH
BTGETH	BTGETH	BTG	ETH	0.001	0.000001	ETH
NEOETH	NEOETH	NEO	ETH	0.01	0.0000001	ETH
XRPETH	XRPETH2	XRP	ETH	0.1	0.00000001	ETH
TRXBTC	TRXBTC	TRX	BTC	1	0.0000000001	BTC
TRXETH	TRXETH	TRX	ETH	1	0.000000001	ETH
TRXUSDT	TRXUSD	TRX	USDT	1	0.0000001	USDT
TRXEOS	TRXEOS	TRX	EOS	1	0.00000001	EOS
BTCEUR	BTCEURB	BTC	EURB	0.00001	0.01	EURB
ETHEUR	ETHEURB	ETH	EURB	0.0001	0.001	EURB
EOSEUR	EOSEURB	EOS	EURB	0.01	0.00001	EURB
EUREURS	EURBEURS	EURB	EURS	0.01	0.00001	EURS
EURUSDT	EURBUSD	EURB	USDT	0.01	0.00001	USDT
BCHETH	BCHABCETH	BCH	ETH	0.0001	0.00001	ETH
BCHDAI	BCHABCDAI	BCH	DAI	0.0001	0.001	DAI
BCHTUSD	BCHABCTUSD	BCH	TUSD	0.0001	0.001	TUSD
BCHEURS	BCHABCEURS	BCH	EURS	0.0001	0.001	EURS
BTCTUSD	BTCTUSD	BTC	TUSD	0.00001	0.01	TUSD
ETHTUSD	ETHTUSD	ETH	TUSD	0.0001	0.001	TUSD
TUSDDAI	TUSDDAI	TUSD	DAI	0.01	0.00001	DAI
USDTTUSD	USDTUSD	USDT	TUSD	0.01	0.000001	TUSD
BTCUSD	BTCUSDB	BTC	USDB	0.00001	0.01	USDB
ETHUSD	ETHUSDB	ETH	USDB	0.0001	0.001	USDB
EOSUSD	EOSUSDB	EOS	USDB	0.00001	0.001	USDB
TUSDUSD	TUSDUSDB	TUSD	USDB	0.01	0.00001	USDB
USDTUSD	USDUSDB	USDT	USDB	0.01	0.00001	USDB
DAIUSD	DAIUSDB	DAI	USDB	0.01	0.00001	USDB
BTCEOSDT	BTCEOSDT	BTC	EOSDT	0.00001	0.01	EOSDT
ETHEOSDT	ETHEOSDT	ETH	EOSDT	0.0001	0.001	EOSDT
EOSEOSDT	EOSEOSDT	EOS	EOSDT	0.01	0.00001	EOSDT
USDTEOSDT	USDEOSDT	USDT	EOSDT	0.01	0.00001	EOSDT
USDTUSDT20	USDUSDT20	USDT	USDT20	0.01	0.00001	USDT20
BTCUSDT20	BTCUSDT20	BTC	USDT20	0.00001	0.01	USDT20

Appendix 2: Field Types

Type	Comment
Amt	A float field typically representing a Price times a Qty
Boolean	A single character taking values Y or N
Char	Single Character
Currency	String field representing a currency type using ISO 4217 Currency code (3 character) values.
Float	Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits.
Integer	Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. "00023" = "23").
LocalMktDate	Date of Local Market (as opposed to UTC) in YYYYMMDD format.
NumInGroup	Integer field representing the number of entries in a repeating group. Value must be positive.
Price	Float field representing a price. Note the number of decimal places may vary.
SeqNum	Int field representing a message sequence number. Value must be positive.
String	Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. BEQUANT != Bequant).
UTCTimestamp	String containing a time/date combination represented in UTC (Universal Time Coordinated, also known as "GMT") in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-HH:MM:SS.sss (milliseconds) format.
UTCDateOnly	String field representing Date represented in UTC (Universal Time Coordinated, also known as "GMT") in YYYYMMDD format
UTCTimeOnly	String field representing time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss* (milliseconds) format, colons, and full stop required

Change Log

Date	Version	Change
1.0	5.April.2019	Initial Publication
1.1	6.April.2019	Minor formatting changes.
1.2	9.April.2019	Minor corrections/amendments to Reject, Execution Report, Cancel/Replace, Order Status Request, Order Mass Status Request, Market Data Request , MarketDataSnapshotFullRefresh, MarketDataIncrementalRefresh and PositionReport messages.
1.3	11.April.2019	More detail regarding Cancel/Replace plus a minor correction to the definition of OrderQty in the Cancel/Replace message. Revised definition & explanation of the MarketDataIncrementalRefresh message
1.4	30.April.2019	Made clear that it’s currently not possible to modify the Stop Price when doing a Cancel/Replace on a Stop Order.
1.5	7.June.2019	Updated symbology appendix
1.6	12.July.2019	Updated symbology appendix
1.7	17.July.2019	Updated New Order Single message specification, notably Time In Force options, and added extra Time and Date fields to Market Data response messages
1.8	27.August.2019	Fixed typo – ExecInst is tag 18 not 8
1.9	16.September.2019	Removed erroneous reference to tag 278 in the Market Data section
2.0	27.September.2019	Added reference to new functionality that returns Fees in Execution Report (MiscFeeAmt and MiscFeeCurr)
2.1	22.October.2019	Cleaned up symbology table
2.2	28.November.2019	Added tag 278 to X message