ATS Connectivity Specification

April 12, 2022

Specifications for ATS Connectivity

1. FIX for Market Data
2. FIX for Order Routing
3. Websocket API

Introduction

Coinsquare ATS is accessible to subscribers via FIX (Financial Information Exchange) and Websocket API. This documents outlines the specifications for three separate connection types:

FIX for Market Data
FIX for Order Routing
Websocket API

1. FIX for Market Data

1.1. Disclaimer and Rights Granted

The information contained in this document describing Coinsquare Ltd. implementation of the FIX protocol and any other information or documentation related to Coinsquare ATS Market Data FIX Specifications message formats are provided “as is”, and neither Coinsquare ATS nor any of its affiliates makes any representation or warranty, express or implied, as to the contents of the Coinsquare ATS Market Data FIX Specifications and each such person specifically disclaims any warranty of originality, accuracy, completeness, merchantability, fitness for a particular purpose or that it is error-free. By using the Coinsquare ATS Market Data FIX Specifications, you are agreeing to assume the entire risk associated with its use.

The Coinsquare ATS shall have no liability for damages of any kind arising in any manner out of or in connection with your use of, or your inability to use, the Coinsquare ATS Market Data FIX Specifications, whether direct, indirect, incidental, special or consequential arising under contract or otherwise, whether or not Coinsquare ATS or any of its affiliates has been advised of, or otherwise might have anticipated the possibility of, such damages.

Please note that Coinsquare ATS will require prior certification of any system designed to connect to its trading and market information as well as your participation from time to time in connection with the testing of changes or upgrades to Coinsquare ATS Market Data FIX Specifications.

The information contained in the Coinsquare ATS Market Data FIX Specifications is proprietary and confidential information belonging to Coinsquare ATS and Fix Protocol Limited and/or their respective licensors or service providers, as applicable. Copyright and trade-mark rights and any other intellectual property in the Coinsquare ATS Market Data FIX Specifications belong to the Fundamental Interactions, FIX Protocol Limited and/or its licensors or service providers, as applicable. Your permitted use of the Coinsquare ATS Market Data FIX Specifications, in whole or in part, is limited to the non-exclusive, non-transferable, revocable, non-assignable, personal right for you only to build a connection between your systems and Coinsquare ATS trading system.

Copyright in the FIX Protocol belongs to FIX Protocol Limited: www.fixprotocol.org. FIX Protocol content, documents, information and materials are used solely with permission of FIX Protocol Limited.

1.2. Overview

The information in this FIX document describes the adaptation of the standard FIX 4.2 for vendors and subscribers to communicate with the Coinsquare ATS quotation and execution ATS. FIX 4.2 tags, as described in detail on the Financial Information Exchange Protocol Committee website, www.fixprotocol.org as well as custom tags are used extensively in this document and the reader should familiarize themselves with the latest updates to this release.

If an application message in Financial Information Exchange Protocol version 4.2, or previous FIX versions, is not included in this document, the message is ignored by MPID.

1.3. Data Types

All FIX timestamps are GMT as per FIX standard. Clients are expected to synchronize their clocks with an external time source.

Prices – Clients should program their systems to allow execution prices to be returned with up to six decimals

1.4. Symbology

For inbound FIX message to MPID, the symbology. When using CMS format, we expect customer to send root symbol in tag 55. When using symbology, we expect customer to send everything in tag 55.

Security Categorization	Symbol

Bitcoin in CAD$	BTCCAD
Ethereum in CAD$	ETHCAD

1.5. Recovery

The MPID FIX market data feed provides a primary and secondary site for customer to connect. Two sites are synced in real time, so the session info (such as incoming/outgoing sequence number, etc…) is kept at both sites.

Only one site is active at any time. The inactive site will reject socket connection attempts.

When initiating the connection, customer’s process should first attempt primary site, if fails, then attempt secondary site, and so on…

1.6. Standard Header/Trailer

1.6.1. Message Header

Tag	Field Name	Req’d	Comments
8	BeginString	Y	“FIX.4.2”
9	BodyLength	Y	(Always unencrypted, must be second field in message)
35	MsgType	Y	(Always unencrypted, must be third field in message)
49	SenderCompID	Y	Provided by MPID system administrator, must be specified in all FIX messages to MPID, will be echoed back in TargetCompID in all FIX messages to customers.
56	TargetCompID	Y	Provided by customer, always echoed back in SenderCompID in all FIX messages to customers.
115	OnBehalfOfCompID	N	Required for service bureau connection
34	MsgSeqNum	Y	(Can be embedded within encrypted data section.)
43	PossDupFlag	N	Always required for retransmitted messages, whether prompted by the sending system or as the result of a resend request. (Can be embedded within encrypted data section.)
97	PossResend	N	Ignored by MPID
52	SendingTime	Y	Required
122	OrigSendingTime	N	Required for message resends. If data is not available set to same value as SendingTime (Can be embedded within encrypted data section.)

1.6.2. Message Trailer

Tag	Field Name	Req’d	Comments
10	CheckSum	Y	(Always unencrypted, always last field in message)

1.7. Session Messages

1.7.1.Heartbeat (MsgType = 0)

This message is intended to monitor the status of the communications link during periods of inactivity.

The FIX market data accepts and generates Heartbeat messages as per the FIX specification.

Inbound: Handled as specified
Outbound: In response to a test request or timeout.
Response: None

The heartbeat message should be sent if agreed upon Heartbeatinterval has elapsed since the last message sent. If any proceeding Heartbeatinterval a Heartbeat message need not be sent.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = 0
112	TestReqID	N	Required when the heartbeat is the result of a Test Request message.
	Standard Trailer	Y

1.7.2. Logon (MsgType = A)

The logon message identifies and authenticates the user or member and establishes a connection to the FIX Gateway. The FIX gateway accepts Logon messages as per the FIX specification. Further, the FIX gateway supports the logon sequence required for session authentication. After a successful logon as described in the specification the FIX gateway will:

Initiate retransmission processing via a resend request if the Logon sequence number is greater than the value expected Initiate logout processing via a Logout message with an appropriate error message, then waits for a confirming Logout before disconnecting if the Logon sequence number is less than expected. If the confirming Logout has not been received within a short period of time the session will be disconnected.
Handle retransmission requests
Initiate a Logon using the SenderCompID in the message header.
Will forwarded to the FIX client messages that are waiting in the outbound queue.
Begin regular message communication.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = A
108	HeartBtInt	Y	Heartbeat interval in seconds
	Standard Trailer	Y

1.7.3. Test Request (MsgType = 1)

If a Heartbeatinterval + 1 second have elapsed since the last message received, a Test Request should be issued. If another Heartbeatinterval + 1 second go by without receiving a message, the TCP connection should be dropped.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = 1
112	TestReqID	Y
	Standard Trailer	Y

1.7.4. Resend Request (MsgType = 2)

The resend request message initiates the retransmission of messages. The FIX client or Gateway may generate a resend request when a message sequence number gap is detected. Refer to the FIX protocol documentation for a full description of resend processing.

The FIX system handles resend requests conformant to the FIX protocol. Refer to the FIX 4.2 specification for details on resend processing.

A Resend Request message should be processed even if it is received ahead of sequence. Only after resending the request range (all marked PossDup= “Y”, including gap fills) should Resend Request issued in the opposite direction.

(All marked PossDup= “Y”, including gap fills) should Resend Request issued in the opposite direction.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = 2
7	BeginSeqNo	Y
16	EndSeqNo	Y
	Standard Trailer	Y

1.7.5. Reject (Msg Type = 3)

This message is used by the FIX Gateway to reject messages that violate session level rules and are unable to be processed. The gateway checks inbound messages for the presence of its required tags. It also validates the message type tag session level rejects are used to indicate violations of the session protocol, or missing fields.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = 3
45	RefSeqNum	Y	MsgSeqNum of rejected message
58	Text	N	Where possible, message to explain reason for rejection
	Standard Trailer	Y

1.7.6. Sequence Reset (MsgType = 4)

This message is used to reset the incoming sequence number of the opposing side. This message supports two modes:

Sequence Reset-GapFill – GapFillFlag=Y
Sequence Reset-Reset – GapFillFlag=N (Only used to recover from Disaster)

The GapFill can be used to mark a place of a message(s) or administration messages that are not being resent. To view the complete functionality of the Sequence Reset (Gap Fill) message refer to the FIX protocol.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = 4
123	GapFillFlag	N	Y=Gap fill beginning at NewSeqNo N=NewSeqNo is ignored – manual recovery attempted
36	NewSeqNo	Y	Next requested sequence number
	Standard Trailer	Y

1.7.7. Logout (MsgType = 5)

The Logout message initiates or confirms the termination of a FIX session.

The FIX gateway will receive and generate logout messages as required by the FIX Protocol. The gateway follows the prescribed sequence of messages for the proper termination of the session.

Messages received by the gateway after the client logs out are stored in a log file for transmission to the client once the client logs in again within the same trading day. The messages to be transmitted are dependent on the sequence number reconciliation that occurs on a logon handshake.

Upon receipt of a Logout message:

A confirming logout message will be sent by the gateway to the client; then, 3 The session will be disconnected.

The FIX gateway should never initiate a logoff except when a severe error has occurred.

Either side may issue a logout to close the session.

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = 5
58	Text	N
	Standard Trailer	Y

Note: Logout is not required.

Application Messages – Customer to MPID

1.7.8. Market Data Request (MsgType = V)

Tag	Field Name		Req’d	Comments
	Standard Header		Y	MsgType = V
262	MDReqID		Y	Unique identifier for Market Data Request Must be unique, or the ID of previous Market Data Request to disable if SubscriptionRequestType = Disable previous Snapshot + Updates Request (2)
263	SubscriptionRequestType		Y	Subscription Request Type Valid values: 1 = Snapshot + Updates (Subscribe) 2 = Disable previous Snapshot + Update Request (Unsubscribe)
264	MarketDepth		Y	Depth of market for Book Snapshot The actual value is ignored. MPID reports top of book in snapshot, and reports full book in updates
265	MDUpdateType		N	Specifies the type of Market Data update. The actual value is ignored. When a client subscribes, they will receive incremental refresh Valid values: 1 = Incremental Refresh
266	AggregatedBook		N	Specifies whether or not book entries should be aggregated. The actual value is ignored. When a client subscribes, they will receive aggregated book. Valid values: Y = one book entry per side per price
267	NoMDEntryTypes		Y	Number of MDEntryType fields requested. Actual values are ignored. When a client subscribes, they will receive bid/offer information
->	269 MDEntryType		Y	Type of Market Data Entry the client wishes to receive. Actual value is ignored
146	NoRelatedSym		Y	Number of symbols requested
->	55	Symbol	Y	Must be the first field in the repeating group
->	65	SymbolSfx	N
	Standard Trailer		Y

1.8. Example FIX Message

A request for market data on symbol would appear as

8=FIX.4.29=12435=V49=TESTMD56=TEST34=352=20130819-

19:04:49262=35184372088833263=1264=0265=1266=Y267=2269=0269=1146=155=MSFT10=164

Application Messages –MPID to Customer

Market Data – Top of Book Snapshot (MsgType=W)

Tag	Field Name		Req’d	Comments
	Standard Header		Y	MsgType = W
262	MDReqID		Y	The MDReqID of the MarketDataRequest message.
55	Symbol		Y	Identifier for the symbol
65	SymbolSfx		N
268	NoMDEntries		Y	Number of market data entries in this snapshot.
->	269	MDEntryType	Y	Type of market data entry. Valid values: = Bid = Offer
->	270	MDEntryPx	Y	Price of the market data entry.
->	271	MDEntrySize	N	Number of shares represented by the Market Data Entry.
	Standard Trailer		Y

1.9. Example FIX Message

In response to valid market data request, MPID will report the current best bid and offer in the market. The FIX message would appear as

8=FIX.4.29=13035=W49=TEST56=TESTMD34=352=20130819-

19:04:4955=MSFT268=2269=0270=30.01271=100269=1270=30.99271=100262=3518437208883310=18

Market Data – Incremental Refresh (MsgType=X)

Tag	Field Name		Req’d	Comments
	Standard Header		Y	MsgType = X
262	MDReqID		Y	The MDReqID of the MarketDataRequest message.
268	NoMDEntries		Y	Number of market data entries in this snapshot.
->	279	MDUpdateAction	Y	The Market Data update action type. It must be the first field in the repeating group. The only valid values are 0 = New
				2 = Delete
->	269	MDEntryType	Y	Type of market data entry. Valid values: = Bid = Offer
->	278	MDEntryID	Y	Market data identifier
->	55	Symbol	Y	Identifier for the symbol
->	270	MDEntryPx	N	Price of the market data entry
->	271	MDEntrySize	N	Number of shares represented by the Market Data Entry
->	387	TotalVolumeTraded	N	Trade only, number of shares traded for this security
	Standard Trailer		Y

1.10. Example FIX Message

In response to valid market data request, MPID will provide incremental updates. The FIX message would appear as

8=FIX.4.29=13635=X49=TEST56=TESTMD34=552=20130819-

19:05:40262=35184372088833268=1279=0269=0278=108086391056891905155=MSFT270=30.02271=5 0010=059

8=FIX.4.29=13435=X49=TEST56=TESTMD34=752=20130819-

19:05:57262=35184372088833268=1279=2269=0278=108086391056891905155=MSFT270=30.02271=0 10=224

Market Data Request Reject (MsgType=Y)

Tag	Field Name	Req’d	Comments
	Standard Header	Y	MsgType = Y
262	MDReqID	Y	The MDReqID of the MarketDataRequest message.
58	Text	N	Reason for the rejection.
	Standard Trailer	Y

2. FIX for Order Routing

2.1. Disclaimer and Rights Granted

Copyright in the FIX Protocol belongs to FIX Protocol Limited: www.fixprotocol.org. FIX Protocol content, documents, information and materials are used solely with permission of FIX Protocol Limited.

2.2. Overview

If an application message in Financial Information Exchange Protocol version 4.2, or previous FIX versions, is not included in this document, the message is ignored by MPID.

2.3. Supported Order Types

Coinsquare ATS currently supports limit order types.

Order Type	Description
Limit Order	A limit order is an order to buy or sell an asset at a specific price or better. A buy limit order can only be executed at the limit price or lower, and a sell limit order can only be executed at the limit price or higher. A limit order can only be filled if the asset price reaches the limit price.

2.4. Symbology

For inbound FIX message to Market Participant Identity (MPID), we expect customers to send root symbol in tag 55.

Security Asset Pairs	Symbol examples
Bitcoin in CAD	BTCCAD
Ethereum in CAD	ETHCAD
Solana in CAD	SOLCAD

2.5 Connecting to Coinsquare FIX

2.5.1 Physical Connection

Connections to Coinsquare FIX are established through direct connections. Coinsquare staff will assign IP address and port numbers for connectivity to Coinsquare ATS FIX through your communications provider.

2.5.2. Login Credentials and Connection Procedures

IP address, port number, SenderCompID and TargetCompID are required to establish a connection. The ID assigned to each subscriber is used in the client message header as SenderCompID.

IP Address	Assigned by Staff	Validated during initial connection
Port	Assigned by Staff	Validated during initial connection
SenderCompID	Assigned by Staff	Validated upon TCP connectivity
TargetCompID	Assigned by Staff	Validated upon TCP connectivity

The client establishes a TCP connection through a proprietary or commercial FIX engine using the assigned destination IP address and port.
The incoming IP address and port are examined, and connectivity is established upon successful validation. The connection is refused if the credentials do not pass validation.
The logon message is the first message Coinsquare FIX expects to receive after TCP connectivity. (See the format of the Logon message in section 3 below)
SenderCompID and TargetCompID received in the logon header message is examined and connectivity to the FIX gateway is established upon validation. The TCP connection is terminated if these credentials do not pass validation.
FIX responds with a Logon acknowledge message upon establishing a successful session.

2.6. FIX Messages

This section outlines the FIX messages, how they are supported, and to what extent the business data is translated within the FIX Gateway.

2.6.1. FIX messages supported

The following FIX messages are supported by the FIX Gateway:

Message Category	Message Name	Message Type	Message Direction	Message Function
Administrative	Heartbeat	0	Inbound Outbound	Monitors FIX gateway status during periods of inactivity
Administrative	Logon	A	Inbound Outbound	Identifies and authenticates a user/ member establishing a connection to the FIX gateway.
Administrative	Test Request	1	Inbound Outbound	Verifies communications line and other FIX gateway parameters.
Administrative	Resend Request	2	Inbound Outbound	Initiates a re-transmission of messages from the FIX gateway.
Administrative	Reject	3	Inbound Outbound	Rejects messages that cannot be processed by the FIX gateway.
Administrative	Sequence Reset (Gap Fill)	4	Inbound Outbound	Message has two modes: Sequence Reset – Gap Fill and Sequence ResetReset. Sequence Reset Gap Fill – used to fill or mark the gap Sequence Reset – Reset – used to force synchronization
Administrative	Logout	5	Inbound Outbound	Used to terminate a FIX session.
Customer	New Order – Single	D	Inbound Outbound	Submits a market or limit priced bid or offer order for a security listed within a market. May contain time in force terms such as day, open, good til date.
ATS to Customer	Execution Report	8	Outbound
	Don’t Know Trade	Q	Inbound	Rejects an execution report that was processed and sent by the FIX gateway.
Customer	Order Cancel Request	F	Inbound	Request to cancel an order.
	Order Cancel Reject	9	Outbound	Reject message for an Order Cancel / Replace Request or Order Cancel Request that cannot be processed by the FIX gateway.
	Order Status Request	H	Inbound	Request for querying the details of an order.
	Business Message Reject	J	Outbound	Rejects any message that cannot be processed by the FIX gateway and is cannot be rejected via another message.

2.7. Custom Fix Tags

The following list of FIX tags that extend the FIX 4.2 protocol.

Tag	Field Name	Req’d	Comments
6750	Account Type	N	CL (Client) NC (Non-Client or Pro) IN (Inventory/Principal)
7713	No Self Trade Feature	Y	2 character self-trade prevention NM (default)
7714	No Self Trade Key	Y	This key prevents the order from trading against orders with the same key value.
43211	Execution Venue	No	Specify where the trade happens, can be different from 43210, for example, “CROX”
43212	Execution Contra Broker	No	MPID specific tag. Indicate who your contra broker here is.
43214	Liquidity Indicator	No	Liquidity indicator. ‘P’, provided liquidity ‘T’, took liquidity
43229	FractionBase	Y	If fraction typical value 100000000

2.8. FIX Message Header & Trailer

The message header and message trailer prefix and suffix all FIX messages. They contain the common information to uniquely identify and route the messages. Please refer to the description of each supported message to determine the required header and footer tags.

2.8.1. Message Header

Tag	Field Name	Req’d	Comments
8	BeginString	Yes	“FIX.4.2”
9	BodyLength	Yes	(Always unencrypted, must be second field in message)
35	MsgType	Yes	(Always unencrypted, must be third field in message)
49	SenderCompID	Ye	Provided by MPID system administrator, must be specified in all FIX messages to Coinsquare ATS and it will be echoed back in TargetCompID in all FIX messages to customers.
56	TargetCompID	Yes	Provided by customer, always echoed back in SenderCompID in all FIX messages to customers.
115	OnBehalfOfCompID	No	Required for service bureau connection
34	MsgSeqNum	Yes	(Can be embedded within encrypted data section.)
43	PossDupFlag	No	Always required for retransmitted messages, whether prompted by the sending system or as the result of a resend request. (Can be embedded within encrypted data section.)
97	PossResend	No	Ignored by MPID
52	SendingTime	Yes	Required
122	OrigSendingTime	No	Required for message resends. If data is not available ,set to same value as SendingTime (Can be embedded within encrypted data section.)

2.8.2. Message Trailer (All)

All messages are to contain the following required tags in the trailer.

Tag	Field Name	Req’d	Comments
10	CheckSum	Yes	(Always unencrypted, always last field in message)

2.9. Drop Copy Sessions

The FIX Gateway offers Drop Copy sessions which provide copies of Execution Report messages that were originally sent to other FIX sessions from the same firm. These Drop Copy sessions must be pre-configured by Market Operations, and no special logon is required. All Administrative messages are supported on a Drop Copy session, and retransmission functions as per a regular FIX session.

When a Drop Copy session copies out an Execution Report to a client, this message will be indicated as a copy with CopyMsgIndicator = Y, as well as the OnBehalfOfCompID field providing the CompID of the FIX session to which the message was originally sent.

Execution Report messages where ExecType = 8 (Rejected) will not be copied out by a Drop Copy session. Any attempt by a client to submit an application message on a Drop Copy session will be rejected by the server.

2.10. Administrative Messages

The administrative messages are designed to meet the utility needs of the protocol. As a rule they contain no business information and consequently are handled internally within the FIX gateway. All administrative messages are supported.

Message	MsgType	Comments
Logon	A	This is sent after connection to identify and authenticate the customer and to establish a FIX session.
Heartbeat	0	Sent by FIX servers at predefined interval during login in tag 108.
TestRequest	1	This message will be sent if data has not been received for a within the specified HeartBeat interval.
ResendRequest	2	Notify the opposite party to resend messages that may have been missed.
Reject Message	3	Used in response to a message that could not be processed
Sequence Reset	4	Used to reset the FIX session sequence number
Logout	5	This is sent by the client to terminate the FIX session and perform a clean disconnect.

2.10.1. Heartbeat (MsgType = 0)

The heartbeat message should be sent if agreed upon HeartbeatInterval has elapsed since the last message sent. If any proceeding HeartbeatInterval a Heartbeat message need not be sent.

2.10.2. Logon (MsgType = A)

The logon message identifies and authenticates the user or member and establishes a connection to the FIX Gateway.

The FIX gateway accepts Logon messages as per the FIX specification. Further, the FIX gateway supports the logon sequence required for session authentication.

After a successful logon as described in the specification the FIX gateway will:

Initiate retransmission processing via a resend request if the Logon sequence number is greater than the value expected
Initiate logout processing via a Logout message with an appropriate error message, then waits for a confirming Logout before disconnecting if the Logon sequence number is less than expected. If the confirming Logout has not been received within a short period of time the session will be disconnected.
Handle retransmission requests
Initiate a Logon using the SenderCompID in the message header.
Will forwarded to the FIX client messages that are waiting in the outbound queue
Begin regular message communication.

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = A
108	HeartBtInt	Yes	Heartbeat interval in seconds
	Standard Trailer	Yes

2.10.3. Test Request (MsgType = 1)

This message requests the return of a heartbeat message and verifies the communications line and other FIX parameters.

Inbound test request messages result in the appropriate heartbeat response.

If a Heartbeatinterval + 1 second has elapsed since the last message received, a Test Request should be issued. If another Heartbeatinterval + 1 second goes by without receiving a message, the TCP connection should be dropped.

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = 1
112	TestReqID	Yes	Identifier included in Test Request message to be returned in resulting Heartbeat
	Standard Trailer	Yes

2.10.4. Resend Request (MsgType = 2)

The resend request message initiates the retransmission of messages. The FIX client or Gateway may generate a resend request when a message sequence number gap is detected.

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = 2
7	BeginSeqNo	Yes	Message sequence number of first record in range to be resent
16	EndSeqNo	Yes	Message sequence number of last record in range to be resent. If request is for a single record BeginSeqNo = EndSeqNo. If request is for all messages subsequent to a particular message, EndSeqNo = 0

2.10.5. Reject (Msg Type = 3)

This message is used by the FIX Gateway to reject messages that violate session level rules and are unable to be processed. The gateway checks inbound messages for the presence of its required tags. It also validates the message type tag. In the case where the message type is missing (tag 35 on the inbound message), the reject message issues a value of “Unknown” in tag 58, as the FIX gateway is unaware of what the message is.

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = 3
45	RefSeqNum	Yes	MsgSeqNum of rejected message
58	Text	No	Where possible, message to explain reason for rejection

2.10.6. Sequence Reset (MsgType = 4)

This message is used to reset the incoming sequence number of the opposing side. This message supports two modes:

Sequence Reset-GapFill – GapFillFlag=Y
Sequence Reset-Reset – GapFillFlag=N (only used to recover from Disaster)

Tag	Field Name	Req’d		Comments
35	Standard Header	Yes	MsgType = 4
123	GapFillFlag	No	Y=Gap fill beginning at NewSeqNo N=NewSeqNo is ignored – manual recovery attempted
36	NewSeqNo	Yes	Next requested sequence number
	Standard Trailer	Yes

2.10.7. Logout (MsgType = 5)

The Logout message initiates or confirms the termination of a FIX session.

The FIX gateway will receive and generate logout messages as required by the FIX Protocol. The gateway follows the prescribed sequence of messages for the proper termination of the session.

Upon receipt of a Logout message:

A confirming logout message will be sent by the gateway to the client; then,
The session will be disconnected.

The FIX gateway should never initiate a logoff except when a severe error has occurred.

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = 5
58	Text	No	Free format text string (Note: this field does not have a specified maximum length) If the Logout message has been sent by the FIX gateway, then this field will contain the text “Session closed”.
	Standard Trailer	Yes

Note: Logout is not required.

2.11. Application Messages – Customer

2.11.1. New Order – Single (MsgType = D)

This message is used to submit an order to the trading system for processing.

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = D
11	ClOrdID	Yes	Unique identifier of the order. Must be unique for each session, max 32 chars.
1	Account	No	Optional identifier from customer, will be passed back in Execution Report Account mnemonic as agreed between broker and institution.
18	ExecInst	No	Can contain multiple instructions, space delimited. G = All or None (AON)
21	HandInst	No	Handling Instructions 1 = Automated execution order, private no broker intervention
55	Symbol	Yes	Ticker symbol. Common, “human understood” representation of the security. Examples: BTCCAD ETHCAD DOGECAD
54	Side	Yes	1 = Buy 2 = Sell
38	OrderQty	Yes	Data type (Integer). This represents the number of coins to be traded. Multiplied by the fraction base. See FractionBase, tag 43229
43229	FractionBase	Yes	Fraction Order Qty, always set this value to 100,000,000. Eg. OrderQty = 1 implies 0.00000001 (0.00000001 * 100,000,000 = 1)
40	OrdType	Yes	2 = Limit
44	Price	No	Conditional required for limit Order Type
59	TimeInForce	No	1 = GTC (Good Till Cancel) 3 = IOC (Immediate-Or-Cancel) 4 = FOK (Fill or Kill)
47	Capacity	No	P = Principal A = Agency (Default) If not present, will use default account value
6750	Account Type		CL = Client NC = Non-Client (Default) IN = Inventory
7713	NoTradeFeature	Yes	Self-trade prevention feature to prevent wash trades. Defines the behaviour of self-trade prevention when using NoTradeKey. NM = – (Default) 2 characters (not spaced): 1st character: N = Cancel newest order (the active order is canceled) 2nd character: M = Self-trade prevention at broker level (only orders with the same broker number will be prevented from trading) E – reduce order qty. (Do not use)
7714	NoTradeKey	Yes	This participant generated key prevents the order from trading against orders with the same key value.
109	ClientID	No	Firm identifier used in third party-transactions.
	Standard Trailer	Yes

2.11.2. Order Cancel Request (MsgType = F)

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = F
41	OrigClOrdID	Yes	ClOrdID of the previous order
37	OrderID	No	Unique identifier of most recent order as assigned by broker.
11	ClOrdID	Yes	Unique ID of cancel request as assigned by the institution.
1	Account	No	Optional identifier of customer
40	OrdType	No
55	Symbol	Yes
54	Side	No	‘1’ = Buy ‘2’ = Sell
38	OrderQty	No
47
58	Text	No	Free form text Field will be ignored
59	TimeInForce	No
43229	FractionalBase	No
	Standard Trailer	Yes

2.12. Application Messages – Coinsquare ATS to customer

2.12.1. Execution Report (MsgType 8)

Tag	Field Name	Req’d	Comments
35	Standard Header	Yes	MsgType = 8
37	OrderID	Yes	System assigned order ID
11	ClOrdID	No	Echo from Customer’s request
41	OrigClOrdID	No	Echo from Customer’s request
17	ExecID	Yes	System assigned execution ID Activity ID
20	ExecTransType	Yes
19	ExecRefID	No	Required for Cancel and Correct ExecTransType messages
150	ExecType	Yes
39	OrdStatus	Yes	0=New 1= PartiallyFilled 2=Filled 3=DoneForDay 4=Canceled 6=PendingCancel 7=Stopped 8=Rejected A=PendingNew C=Expired
1	Account	No	Copied from Customer’s request
55	Symbol	Yes	Based on customer’s input.
54	Side	Yes	1 = Buy 2 = Sell
38	OrderQty	Yes
40	OrdType	No	2 = Limit
44	Price	No	Price per share
59	TimeInForce	No
18	ExecInst	No	Can contain multiple instructions, space delimited.
47	Capacity	No	Echo from Customer’s request
32	LastQTY	Yes	Quantity of shares bought/sold on this (last) fill.
31	LastPx	Yes	Price of this (last) fill.
151	LeavesQty	Yes	Amount of shares open for further execution.
14	CumQty	Yes	Currently executed shares for chain of orders.
6	AvgPx	Yes	Calculated average price of all fills on this order.
6750	Account Type	No	Echo from Customer’s request
43211	Execution Venue	No	MPID specific tag. Example CROX
43212	Execution Contra Broker	No	MPID specific tag.
43214	Liquidity Indicator	No	T – Taker P – Passive / Maker

3. Websocket API

3.1 Overview

Welcome to API documentation. These documents outline trading platform functionality, market details, and APIs.

APIs are separated into two categories: Market data feed and trading. Feed APIs provide market data and are public. Trading APIs require authentication and provide access to placing orders and other account information.

3.2. Rate Limits

The API is rate limited to prevent abuse that would degrade our ability to maintain consistent API performance for all users.

WebSocket API

Public Endpoints

We throttle public endpoints by IP: 3 requests per second, up to 6 requests per second in bursts. Some endpoints may have custom rate limits.

Private Endpoints

We throttle private endpoints by user ID: 5 requests per second, up to 10 requests per second in bursts. Some endpoints may have custom rate limits.

3.3. Time Format

The API timestamp fields us the Epoch/POSIX format for WebSocket API Requests. Unix and POSIX measure time as the number of seconds that have passed since 1 January 1970 00:00:00 UTC

Do not provide milliseconds. ‘1614331055’ or ‘1614331055000’ are supported. ‘1614331055123’ is not supported.

3.4. Connectivity

The WebSocket market data feed provides real-time market data updates for orders and trades.

wss://ats-production.coinsquare.com:8081

For testing, use:

wss://exchange.fi.sandbox.coinsquarex.com:8081/

The WebSocket feed uses a bidirectional protocol, which encodes all messages as JSON objects. All messages have a type attribute that can be used to handle the message appropriately.

Please note that new message types can be added at any point in time. Clients are expected to ignore messages they do not support.

In the case of an initial connection failure, ensure to add the required certificates. Please follow the steps detailed in this knowledge base article – Adding the required SSL certificates.

3.4.1. Example Structure: JAVA Script

const WebSocket = require(‘ws’);

process.env[‘NODE_TLS_REJECT_UNAUTHORIZED’] = 0

const ws = new WebSocket(“wss://ws-sandbox.CoinSquare.com:8081/”)

ws.onopen = function() {

ws.send(JSON.stringify(

{

“type”: “TYPE”,

“request”: “REQUEST”

}

))

ws.onmessage = function(response) {

let websocket_response = JSON.parse(response.data);

console.log(websocket_response)

}

ws.close()

}

3.5. Market Data

3.5.1. Get Symbols

Category: Market Data

Permissions: Public

Endpoint: getsymbols

Retrieves the current assets and trading pairs on the platform.

Response

Key Value

security string. The trading pair or asset.

fractionbase string. The number of decimals supported. e.g 100 = 1.00

tradingsymbol string. true if a trading pair, false if an asset

pair_first string. Specifies what the first asset is. e.g. LTC vs CAD

fiat string. true for fiat, false for virtual assets

pair string. true if a trading pair, false if an asset

3.5.2. Example Structure: JAVA Script

# Request

{

“type”: “getsymbols”

}

# Response

{

“result”:”OK”,

“data”:[

{

“security”:”CAD”,

“fractionbase”:100,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”LTCCAD”,

“fractionbase”:10000,

“pair_first”:”LTC”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”LTC”,

“fractionbase”:10000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”ETHCAD”,

“fractionbase”:100000,

“pair_first”:”ETH”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”ETH”,

“fractionbase”:100000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”BTCCAD”,

“fractionbase”:100000,

“pair_first”:”BTC”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”BTC”,

“fractionbase”:100000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”BCHCAD”,

“fractionbase”:100000,

“pair_first”:”BCH”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”BCH”,

“fractionbase”:100000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

}

“type”:”getsymbols”

}

3.6. Subscribe Order Book

Category: Market Data

Permissions: Public

Endpoint: subscribe

Retrieves the latest order book information and then subscribes the user to ongoing market data event updates for the trading pairs specified.

The Subscribe call responds with the response shown below. Messages are then periodically sent in the same format as this response UpdateEvent information when best-bid/best-offer issue, until you close the connection.

Request

Key Value Required

msg string. Specify the type of data to subscribe to. use ‘book’ for order book data. Yes

security string. Specify the trading pair you wish to subscribe to. Yes

dest string. This value will always be set to CROX. Yes

Response

Key Value

security string. The trading pair being subscribed to.

side string. The order side.

act string. The act to Update or Remove orders

price string. The price of the order.

qty string. The size of the order.

time string. The time of the order, in POSIX format.

You can identify multiple trading pairs (security) by using ‘*”.

3.6.1. Example Structure: JAVA Script

# Request

{

“type”: “subscribe”,

“request”: [

{

“msg”:”book”,

“security”:”BCHCAD”,

“dest”:”CROX”

}

]

}

# Response

# order added

{

“security”:”BCHCAD”,

“books”:[

{

“side”:”B”,

“act”:”U”,

“src”:”CROX”,

“price”:”472.33″,

“qty”:”0.46″,

“id”:120947223715360,

“time”:”1626338416747″,

“mpid”:”ANON”,

“key”:”NA”

}

“type”:”book”

}

# order removed

{

“security”:”BCHCAD”,

“books”:[

{

“act”:”R”,

“id”:120947223715360,

“time”:”1626338444101″

}

“type”:”book”

}

3.7. Subscribe Live Trades

Category: Live Trades

Permissions: Public

Endpoint: subscribe

Retrieves the latest trade information and then subscribes the user to ongoing trade event updates for the specified trading pair.

The Subscribe call responds with the response shown below. TMessages are then periodically sent in the same format as this response until you close the connection.

Request

Key Value Required

msg string. Specify the type of data to subscribe to. use ‘trade’ for trade history data. Yes

security string. Specify the trading pair you wish to subscribe to. Yes

dest string. This value will always be set to CROX. Yes

Response

Key Value

security string. The trading pair being subscribed to.

src string. The value will always be set to CROX.

price string. The price of the order.

qty string. The size of the order.

time string. The time of the order, in POSIX format.

type string. The nature of record.

Matched string. The exchange reference ID of the trade.

You must specify a single trading pair for live trades.

3.7.1. Example Structure: JAVA Script

# Request

{

“type”: “subscribe”,

“request”: [

{

“msg”:”trade”,

“security”:”BCHCAD”,

“dest”:”CROX”

}

]

}

# Response

{

“security”:”BCHCAD”,

“src”:”CROX”,

“price”:”471.43″,

“qty”:”0.06969″,

“time”:”1626338546538″,

“type”:”trade”,

“matchid”:”62YNMDOQ2SPR”

}

3.8. Query Trade History

Category: Trade History

Permissions: Public

Endpoint: lshistory

The query returns trade history data will return data from the specified start time. The “total_rec” tells how many records there should be, and “rec_no” tell you the current number of record.

Request

Key Value Required

type string. Specify the type of data to subscribe to using ‘tradehistory’ for history data. Yes

security string. Specify the trading pair you wish to subscribe to. Yes

starttime string. Specify the start time in POSIX format Yes

Response

Key Value

security string. The trading pair being subscribed to.

execprice string. The price of the order.

execqty string. The size of the order.

time string. The time of the order, in POSIX format.

rec_no int. The record number.

starttime string. The start time of the window.

total_rec string. The total records displayed.

You must specify a single trading pair for execution history.

3.8.1. Example Structure: JAVA Script

# Request

{

“type”:”lshistory”,

“security”:”ETHCAD”,

“starttime”:”1630530000000″

}

# Response

{

“result”: “OK”,

“security”: “LTCCAD”,

“data”:

[

{

“security”: “LTCCAD”,

“rec_no”: 1,

“execprice”: “182.51”,

“time”: “1630561535942”,

“execqty”: “0.5702”

}

“total_rec”: “1”,

“starttime”: “1630530000000”,

“type”: “lshistory”

}

3.9. Query Aggregate Trade History

Category: Trade History

Permissions: Public

Endpoint: tradehistory

The query returns the trade history in 1-minute block. If that minute has a trade, a corresponding block will be return with summary of that minute high/low/first/last trade price as well as volume and number of trades information.

There can be multiple responses to one query if there are more than 100 entries in response. Each response will carry maximum of 100 entries. “total_rec” tells how many records there should be, and “rec_no” tell you current number of record

Request

Key Value Required

type string. Specify the type of data to subscribe to using ‘tradehistory’ for trade history data. Yes

security string. Specify the trading pair you wish to subscribe to. Yes

Response

Key Value

security string. The trading pair being subscribed to.

price string. The price of the order.

qty string. The size of the order.

time string. The time of the order, in POSIX format.

numoftrades string. The number of trades.

lastttime string. The last transaction time.

blocktime string.

high price string. The highest price of the window.

lowprice string. The Lowest price of the window.

rec_no int. The record number.

starttime string. The start time of the window.

lastprice string. The last price of the window.

startprice string. The start price of the window.

total_rec string. The total records displayed.

You must specify a single trading pair for execution history.

3.9.1. Example Structure: JAVA Script

# Request

{

“type”: “tradehistory”,

“security”: “LTCCAD”

}

# Response

{

“result”:”OK”,

“security”:”LTCCAD”,

“data”:[

{

“volume”:”0.9375″,

“numoftrades”:”1″,

“lastttime”:”1630497372665″,

“blocktime”:”1630497360000″,

“highprice”:”174.69″,

“lowprice”:”174.69″,

“rec_no”:1,

“starttime”:”1630497372665″,

“lastprice”:”174.69″,

“startprice”:”174.69″

}

“total_rec”:”1″,

“type”:”tradehistory”

}

3.10. Subscribe Trading Pair Status

Category: Trading Pair Status

Permissions: Public

Endpoint: subscribesymbolstatus

Retrieves any changes to trading pair status. Values can be Halt, PreOpening or Normal..

The subscribesymbolstatus call responds with the responses shown below. Messages are sent anytime the status is updated.

Request

Key Value Required

type string. Specify the type of data subscribe to using ‘subscribesymbolstatus’ for symbol status data. Yes

Response

Key Value

security string. The trading pair being subscribed to.

time string. The time of the order, in POSIX format.

status string. The new status for the trading pair.

3.10.1 Example Structure: JAVA Script

# Request

{

“type”: “subscribesymbolstatus”

}

# Response

{

“result”:”OK”,

“type”:”subscribesymbolstatus”

}

# OR

{

“data”: [

{

“security”: “BCHCAD”,

“time”: “1623155345213”,

“status”: “Halt”

}

“type”: “symbolstatus”

}

# OR

{

“data”: [

{

“security”: “BCHCAD”,

“time”: “1623155345213”,

“status”: “PreOpening”

}

“type”: “symbolstatus”

}

# OR

{

“data”: [

{

“security”: “BCHCAD”,

“time”: “1623155345213”,

“status”: “Normal”

}

“type”: “symbolstatus”

}

3.11. Subscribe High and Low Price

Category: Market Data

Permissions: Public

Endpoint: subscribehighlow

Subscribes the user to ongoing market data event updates when there is a new high or low for the trading pairs specified. The time window 01:00 AM GST – 12:59 AM GST + 1

The subscribehighlow call responds with the response shown below. Messages are then periodically sent if there is a new high or low price.

Request

Key Value Required

security string. Specify the trading pair you wish to subscribe to. Yes

Response

Key Value

security string. The trading pair being subscribed to.

openingprice string. The price at 01:01 AM or price after an opening price calculation.

highprice string. The highest execution price.

lowprice string. The lowest execution price.

prevcloseprice string. The execution price at 01:00 AM

You can identify multiple trading pairs (security) by using ‘*”.

3.11.1. Example Structure: JAVA Script

# Request

{

“type”: “subscribehighlow”,

“security”: “*”

}

# Response

{

“security”: “BTCCAD”,

“prevcloseprice”: “35739.34”,

“type”: “highlow”

}

# OR

{

“openingprice”: “2388.1”,

“security”: “ETHCAD”,

“highprice”: “2388.1”,

“lowprice”: “2388.1”,

“prevcloseprice”: “2611.75”,

“type”: “highlow”

}

# OR

{

“result”: “OK”,

“security”: “*”,

“type”: “subscribehighlow”

}

3.12. Authentication

Category: Authentication

Permissions: Trading

Once client establishes the WebSocket connection, the client has 30 seconds to complete the login process. Otherwise, the socket will be closed by CoinSquare.

Challenge

First client needs to send a challenge request to the system.

Response

Key Value

Key string. The string used to encrypt the password

The response contains a “key” field, which contains a public key string the client must use to encrypt the password field. The “key” field is a 64 base ASCII print out of the binary byte array for the corresponding public key of asymmetric public/ private key pair. CoinSquare will hold the private key while sending clients the public key. Client will first convert the ASCII back to binary byte array. Then use that binary byte array to create a “RSA” public key instance. Afterwards, client will use that RSA public key instance to encrypt info required in this order entry API, e.g. password encryption.

You need to use npm package to install jsencrypt library if you are using JavaScript.

3.12.1. Example Structure: JAVA Script

# Request

{

“type”: “challenge”

}

# Response

{

“result”:”OK”,

“type”:”challenge”,

“key”:”MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvBXTe278Lwg2MoI7iGKolSYuF+sNFKrsZplxCN9x0kItU3KIf8+1q60ILLwLewCEf7foxzpWp32j9YYU9vNBghuJ7BHcDYTffTRcv+QdNno491j701Hq7DIw13AGCQQTRcnfclvblnytIEWoQsiUvPJcdiWgqJIX3IQGA47a+uwIDAQAB”

}

global.window = {};

const JSEncrypt = require(“jsencrypt”);

key = response[‘key’];

const encrypt = new JSEncrypt();

encrypt.setPublicKey(key);

let sign = encrypt.encrypt(‘YOUR PASSPHRASE’);

3.13. Login

After encryption of password, the next step is to send in the login request. The string in the “pass” field is from the output result in sample above.

Key Value Required

userid string. The username of the user. Yes

pass string. The pass phrase generated from the challenge and steps above. Yes

Response

Key Value

result string. The response will either contain OK if successful or a rejection reason.

CoinSquare ATS will send current open orders and position information upon login. If a user places a new order, CoinSquare ATS will send an order update automatically. If the user trades, they will receive a trade update and corresponding position updates.

3.12.1. Example Structure: JAVA Script

# Request

{

“type”:”login”,

“userid”:”USERNAME”,

“pass”:”s7UW26iGE/iVfk2ihPYIcyzRqZRi/Ztb23UNMomf3xrBzGKUHKzfNwZe5PIR/0zvfevYvkJnKLQVhR4U9/kObD/Ir0z6mBfLLgFwEcRm08jYI/nk7lDU+W32PqduTOCThlkXYueQslK54vR9rKvMs=”

}

# Response – You will get a ‘result’:’OK’

{

“result”:”OK”,

“firm”:”COIN”,

“need2FA”:true,

“roles”:”OOOOO”,

“active”:”Y”,

“secondary_account”:”TESEGY0101PGHA12345″,

“type”:”login”,

“attr”:

{

“country”:””,

“tax_code”:”SR”,

“last_name”:”USER”,

“first_name”:”USER “,

“email”:”user@mail.com”

“use2fa”:”Y”,

“userid”:”user@mail.com”,

}

# Any open orders will be returned as follows

{

“refno”:”62YNMDOQ2SPSC0″,

“side”:”B”,

“orderstatus”:”Open”,

“type”:”order”,

“userid”:”user@mail.com”,

“execamount”:”0″,

“tif”:”GTC”,

“firm”:”COIN”,

“security”:”BCHCAD”,

“price”:”471.43″,

“liveqty”:”0.49031″,

“qty”:”0.49031″,

“updtime”:”1626342626369″,

“enttime”:”1626342626366″,

“category”:”STAGE”,

“execqty”:”0″,

“account”:”user@mail.com”,

“ordertype”:”LMT”

}

# Your current positions will also be returned

{

“firm”:”COIN”,

“security”:”CAD”,

“curpos”:”1013057.59″,

“cost”:”-841663670.1899977″,

“type”:”position”,

“account”:”user@mail.com”

}

{

“firm”:”COIN”,

“security”:”BCH”,

“curpos”:”128.25376″,

“cost”:”12008212.15″,

“type”:”position”,

“account”:”user@mail.com”

}

{

“firm”:”COIN”,

“security”:”LTC”,

“curpos”:”121.7144″,

“cost”:”1199785.55″,

“type”:”position”,

“account”:”user@mail.com”

}

# OR

{

“result”:”invalid user/password”,

“type”:”login”

}

3.14. Logout

This is for clean logout. Once CoinSquare receives this message, it will immediately terminate the WebSocket connection.

3.14.1. Example Structure: JAVA Script

# Request

{

“type”:”logout”,

}

# Response

{

“result”:”OK”,

“type”:”logout”

}

Error parsing json

This error message indicates that there are typographical errors in your request.

Sample

{“result”:”error parsing json”}

Product

ATS

Legal and Regulatory Documents

Fees

Client Account Agreement

Services

Company

Property as prescribed in the Coverage Policy of the Canadian Investor Protection Fund (CIPF) that is held in customers’ accounts, including cash balances but not crypto assets, is protected by CIPF within specified limits. A brochure describing the nature and limits of coverage is available upon request or at https://www.cipf.ca.

FINTRAC Registered