Skip to main content

Downloads

FIX Specification XML

FIX 5.0 SP2 specification file for the Drop Copy API
The FIX Drop Copy API provides a complete record of orders and trades. It uses two distinct message types depending on the trade type:
The FIX Drop Copy gateway is designed for direct access users: clients placing orders through one of the Starbase order entry gateways. Non-direct users (e.g. orders placed via the Web UI or WebSocket API) are not supported.

Connection and Authentication

FIX Version

The gateway uses FIX 5.0 SP2 (FIXT.1.1). The BeginString field in the logon message must be set to FIXT.1.1. Connections using an older version (e.g. FIX.4.4) are rejected before parsing can identify the sender, so no reject message is returned.

Logon Fields

  • Execution Reports (35=8) cover orders and trades that occur in the order book.
  • Trade Capture Reports (35=AE) cover trades that occur outside the order book.
Mass quotes (submitted via the SBE Mass Quote API) appear in the Drop Copy feed only when they result in fills. Unexecuted quotes are not included.

Open Order Snapshot on Connect

When a new Drop Copy session is established, Starbase immediately sends Execution Reports for all currently open orders. These snapshot messages are sent automatically (no request is needed) and are marked with a snapshot indicator to distinguish them from live messages. This allows clients to synchronize their order state on connect without requesting an ER replay.

Report Types

Order book trades: Execution Reports

Execution Reports are sent for all activity that goes through the order book:

Reported trades: Trade Capture Reports

Trade Capture Reports are sent for trades that bypass the order book entirely:

Drop Copy Message Types

Parties Repeating Group (453)

The new PartyRole=3 (Client ID) entry carries the name of the ITM (clearing account) that the order actually used. When firm/ITM overrides are enabled on Order Entry, this value reflects the overridden ITM; otherwise it matches the user’s default ITM.

Orders

ExecutionReport <8> | 150=0/4/5/A/E

New (150=0), Canceled (150=4), Replaced (150=5), Pending New (150=A), and Pending Replace (150=E) reports share the same subset of Execution Report tags.
  • New (150=0): Confirms a new order in response to any request to generate a new order, such as NewOrderResponse(200) via the SBE Order Entry API. Sent for every new order, even those matched immediately.
  • Canceled (150=4): Confirms an order is canceled in response to any request to cancel an order, such as CancelOrderRequest(120) via the SBE Order Entry API or to an unsolicited cancel.
  • Replaced (150=5): Confirms order is replaced in response to any request to amend an order such as AmendOrderRequest(110) via the SBE Order Entry API.
  • Pending New (150=A): Sent when a new order is speed bumped and queued pending entry to the book. Followed by a New (150=0) report once the speed bump period expires and the order is placed.
  • Pending Replace (150=E): Sent when an amended order is speed bumped and queued pending re-entry to the book. Followed by a Replaced (150=5) report once the speed bump period expires and the order is placed.

Trades

ExecutionReport <8> | 150=1 or 150=2

Sent for trades on orders.

TradeCaptureReportRequest <AD>

By sending a TradeCaptureReportRequest on a drop copy connection, a replay of non-order book trades (block trades, position moves) is triggered as a series of sequential TradeCaptureReport (35=AE) messages. The replay starts from the ExecID specified in the request. Trades are available for 24 hours. For a full history of all trades, the Websocket APIs should be utilized.

TradeCaptureReport <AE>

Sent for each non-order book trade (block trade, position move), both proactively as trades occur and in response to a TradeCaptureReportRequest.

Fill Execution Report Replay

The Drop Copy connection supports on-demand replay of fill Execution Reports (150=1 or 150=2) using two message types. Non-fill Execution Reports (150=0/4/5/A/E) are not replayed; use the open order snapshot to recover order state after a reconnect. Fill reports are retained for 24 hours. ExecIDs are sequential integers assigned per member and track fill events only. The typical flow is to first request the current last fill ExecID as a baseline, then request a replay starting from that point.

LastFillExecIDRequest <F1>

Sent by the client to retrieve the server’s current last fill ExecID for this member. Response: LastFillExecID <F2>

EventResendRequest <F3>

Requests replay of fill Execution Reports (150=1 or 150=2) within an ExecID range. The server streams all matching reports in order, then sends EventResendComplete. Only fill events within the 24-hour retention window are available.
Replayed fill Execution Reports are identical in format to live fill reports. There is no flag or field distinguishing a replayed message from a live one.
Response: EventResendComplete <F4> Sent after all replayed reports have been delivered. Reject: EventResendReject <F5>
BEGIN_EXEC_ID_TOO_SMALL means BeginExecId is older than the 24-hour retention window, or no fill Execution Reports exist yet for this member. Send a LastFillExecIDRequest to re-establish a valid baseline.END_EXEC_ID_TOO_LARGE means EndExecId refers to an event that does not yet exist. Omit EndExecId to replay up to the current last fill event.