EBS Analytics API Rules of Engagement

Quant Analytics provides greater insight into your trading performance so you can improve your results with every trade. Using real-time, historical and end-of-day data, the platform gives you a clear picture of FX trading.

The EBS Analytics API streams trade information, market impact and alpha calculations on a trade-by-trade basis to clients. Using benchmark data taken from the entire EBS ecosystem, the Quant Analytics platform provides insights that allow clients to analyze trade flows, optimize execution efficiencies and benchmark their performance against the EBS community, including statistics on averages for like trades.

This topic represents a FIX 4.4 compliant specification for integration with the Quant Analytics system. Some tags are borrowed from FIX 5.0SP2.

See also:

Refer to the FTC documentation on the FTC website.


Contents

Products Supported

Instruments Supported

EBS Analytics API supports the following instruments at launch:

  • Spot
  • NDFs
  • Precious Metals


The below instruments are NOT supported but will be in the future:

  • Forward Outrights
  • Swaps

Markets Supported

The following markets are supported:

  • EBS Direct


The below markets are NOT supported but will be in the future:

  • EBS Market

Analytic Timings

T+5 analytics are provided between 5.5 and 10.5 minutes after the trade takes place. This is approximate because trades are processed in batches which can affect timing. More accurate calculations are performed by 6am GMT on a daily basis and at this time the analytics will include metrics not available at T+5 minutes.

Connectivity

Connectivity will be available by SSL over Internet at launch; other connectivity methods may be introduced at a later date.

Concurrent Subscriptions

To safeguard systems, by default 10 concurrent subscriptions are allowed, attempts to stream more than this will be rejected.

System Schedule

EBS Analytics FIX Servers are available from 7pm on Sunday until 8am on Saturday (GMT).

The ideal configuration is for clients to connect on a weekly basis. This will ensure there is no interruption to a client's T+5 minutes feed.

TimeAction

19:00 Sunday

Start FIX session.

00:00 Mon-Fri

System rollover, FIX session will remain connected but historical data for the previous calendar
day is not available at this point.

06:00 Mon-Fri

Latest time T+1 day calculations are published.

08:00 Saturday

Stop FIX session, reset sequence numbers.

Historical Data and Recovery

At launch it is possible to request historical data going back to midnight GMT:

  • On the current calendar day for T+5 mins analytics.
  • On the previous calendar day for T+1 day analytics.

This applies to both snapshot and snaphot+update requests.

Any T+5 min data missing prior to midnight will be restored by 6am GMT when T+1 day analytics are produced at the latest. If further historical data is required then it is possible to use the web dashboard to extract data in CSV format.

Session Management

Clients initiate FIX sessions with the EBS FIX engine which is the acceptor. Most clients will only need a single session, but if you are both an Liquidity Consumer (LC) and an Liquidity Provider (LP) then you will require separate sessions.

Logon (35=A)

A single SenderCompID/TargetCompID may have only one active FIX connection at a time. If a duplicate Logon request for the same SenderCompID/TargetCompID is received while a FIX connection is active, there will be no response to the new Logon request.

TagField NameReqVerComments

98

EncryptMethod

Y

4.4

Always '0' = None

108

HeartBtInt

Y

4.4

Heartbeat interval in seconds. Must be > zero.

141

ResetSeqNumFlag

Y

4.4

Should be set to 'Y' as persistence is not supported.

553

Username

Y

4.4

User name assigned by EBS to a user.

Logons without 141=Y will be rejected with a Logout (35=5) message.

Failed Logon Attempts

If a client Logon request has passed network layer authentication and initial message validation, but the Logon request cannot be completed for any reason, EBS will reply with a Logout message indicating the reason for the Logon failure in the Text field. The Logon request must include a valid SenderCompID/valid TargetCompID combination. After sending the Logout message, EBS will immediately terminate the network connection.

Connection attempts which do not pass network layer authentication will not be responded to. Similarly, malformed Logon messages (missing required field, invalid data type, invalid header or trailer) will be ignored.

Clients are cautioned not to repeatedly attempt to log on following an unsuccessful log on attempt. Client applications should wait a configurable time interval before re-attempting a successive logon. Logon attempts more frequent than the EBS provided configured maximum logon frequency will not be responded to.

Heartbeat (35=0)

TagField NameReqVerComments

112

TestReqID

N

4.4

Included when the Heartbeat is in response to a Test Request message. Echoes back the TestReqID of the Test Request message.

Test Request (35=1)

Sent to request a Heartbeat from the other side. FIX protocol recommends using the current timestamp as the TestReqID.

TagField NameReqVerComments

112

TestReqID

Y

4.4

Unique identifier of the Test Request message to be echoed on the Heartbeat message sent in response to the Test Request message.

The FIX protocol recommends using the current timestamp.

Resend Request (35=2)

A Resend Request message may be sent by either party to request retransmission of missed sequence numbers.

TagField NameReqVerComments

7

BeginSeqNo

Y

4.4

First sequence number requested to be resent.

16

EndSeqNo

Y

4.4

Last sequence number requested to be resent.

  • To request retransmission of a single message, set BeginSeqNo = EndSeqNo.
  • To request all messages subsequent to a particular message, set EndSeqNo = "0" (representing infinity).

Sequence Reset (35=4)

TagField NameReqVerComments

123

GapFillFlag

N

4.4

  • "Y" indicates that the Sequence Reset message is replacing administrative or application messages which will not be resent.
  • "N" indicates that the Sequence Reset message is being sent in a scenario where the sender has experienced an unrecoverable loss of state.

36

NewSeqNo

Y

4.4

Contains the sequence number of the next message which will be transmitted by the sender.

Session Level Reject (35=3)

A generic message which can be used by either side to reject a FIX message which fails session-level validation. It contains fields to indicate the FIX MsgType and FIX tag of the invalid data.

If a message contains multiple session-level rule violations which would cause rejection, only the first detected error will be indicated in the Reject message. To avoid rejection loops, errors in a Reject message should not themselves be rejected.

A Session Level Reject message is not sent when a FIX message cannot be decoded or fails CheckSum or BodyLength validations. In this case, it must be assumed that the communication channel has become corrupted. The recipient of the malformed message will send a Logout message with reason code indicating "Malformed message received" and will then terminate the session without waiting for a Logout Ack.

TagField NameReqVerComments

45

RefSeqNum

Y

4.4

FIX sequence number of the rejected message.

372

RefMsgType

N

4.4

Message type of the rejected message.

371

RefTagID

N

4.4

The FIX tag number of the offending field. (Only the first tag number with an error will be provided.)

373

SessionRejectReason

N

4.4

Code to identify reason for the Session Level Reject message.

58

Text

N

4.4

Free-form text message to explain the reason for the rejection.

Logout (35=5)

The Logout message may be sent by either party to initiate proper, controlled shutdown, or to indicate that an unrecoverable connectivity error has occurred. A good practice is to issue a TestRequest and receive the corresponding heartbeat before Logout.

Logout may occur due to receipt of a malformed message, a heartbeat timeout, or a scheduled shutdown period. To assist with troubleshooting, a Logout reason should be provided on each Logout via the free-form Text field. After sending the Logout Request, the logout initiator should not send any additional messages other than responding to an incoming ResendRequest.

When one side receives a Logout request from the other, it should flush any queued messages and then respond with the Logout message. This indicates to the other side that it will not receive any more messages from the other and that it can close its connection. A configurable timeout will be implemented so that if a Logout response is not received after that time, EBS will unilaterally close the connection.

TagField NameReqVerComments

58

Text

N

4.4

Human-readable string indicating reason for logout.

Supported logout reasons:

  • Normal (scheduled) logout initiated.
  • Logout request acknowledged.
  • Malformed message received.
  • Heartbeat timeout.
  • Session Reset required.

Trade Capture Report Flows

EBS will configure the client session for either LC or LP data as appropriate. Clients can stream both T+5 mins and T+1 day analytics and make snapshot requests to recover data where needed.

Streaming 2 Ticket Flow

As and when data is available T+5 fills are sent out with 150=F and approximate analytics.

During the end of day calculation process:

  • Fills are sent out with 150=D to indicate this is an update to an existing fill the client has and that these are the final analytics.
  • Misses/Rejects are sent out with 150=4 indicating this is a miss/reject and that these are the final analytics.

Historical Catchup

Historical data can be queried going back to midnight GMT for the current calendar day for T+5 min analytics and up until midnight GMT for the previous calendar day for T+1 day analytics.

Time ranges specified on TradeCaptureReportRequests relate to the time the transaction took place (as opposed to the time the analytics were generated). Therefore, for T+1 analytics, it is necessary to query the previous calendar day to obtain the analytics that the client would have received during the current calendar day.

When requesting a snapshot + updates (263=1) subscription, the ordering of updates is not guaranteed; therefore, it is possible the client may receive some real-time updates prior to the completion of transmission of historical data.

It is also important to note that in the event a historical subscription is established in close proximity to the EOD calculation process at 6am GMT, it is possible that the client may receive a TCR with final analytics (150=D) prior to the TCR with the approximate analytics (150=F) message in the case of fills.

Clients should ensure that when they receive historical data (indicated by 570=Y) that it is only processed if the client has not already received final analytics (indicated by 150=D) for the same TradeID(1003). TCRs received with 150=F can be discarded if the client has already received a TCR for the same tradeid with 150=D.

Snapshot 2 Ticket Flow

A time range is specified in the request. All available data within that time range (and matching any criteria specified if applicable) is sent to the client.

Snapshot 1 Ticket Flow

A time range and an ExecPriceType(484) is specified in the request, this allows the client to request only T+5 min or T+1 day analytics if the client only wishes to receive one or the other.

The below requests T+1 day analytics only:

Trade Capture Report FIX Message Definitions

Trade Capture Report Request (35=AD)

Rows from tag 150 (ExecType) until the end of the Parties Group are only valid on criteria based TradeRequestType (569=1). All values act as a filter, the absence of a value is treated as a wildcard for that criteria.

TagTagNameReqVerDescription

568

TradeRequestID

Y

4.4

Unique Identifier of the Trade Capture Report Request. Should be unique over lifetime of FIX session.

569

TradeRequestType


Y


4.4

  • 0 = All trades
  • 1 = Trades matching criteria provided on request (upcoming functionality)

Must be 1 on Snapshot (263=0) requests.

263

SubscriptionRequestType

N

4.4

  • 0 = Snapshot (Historical only)
  • 1 = Snapshot + Updates (Historical + Realtime)
  • 2 = Unsubscribe (Only valid when sending on a real-time stream)

If not provided defaults to 1.


484

ExecPriceType


N


4.4*

Can be used to filter request to receive only T+5 min or T+1 day analytics.

  • y = Approximate Analytics (T+ 5 mins)
  • x = Final Analytics (T+1 day)

Custom value, custom field for this message type.

55

Symbol

N

4.4

Currency pair in CCY1/CCY2 format.

TrdCapDtGrp

580

NoDates

C

4.4

Date Range.

The start date can optionally be specified on streaming subscriptions (263=1). If the start date is supplied, then historical reports going back to the start date will be sent. An end date cannot be supplied on streaming subscriptions and if supplied will result in a reject.

Both start and end date must be supplied on snapshot subscriptions (263=0).

→75

TradeDate

C

4.4

If 580=1 this is the start date (all trades up until now will be queried).

If 580=2 the earliest trade date will be considered the start date and the latest trade date will be considered the end date. If both dates are the same, only trades for that TradeDate will be replayed.

In the event that a date earlier than today is specified, the request will still be accepted but only data going back to the supported time for historical queries (midnight GMT today) will be provided.

YYYYMMDD format

Conditionally required if 580>0.

→60

TransactTime

N

4.4

If 580=1 this is the start date and time (all trades up until now will be queried).

If 580=2 the earliest entry will be considered the start date and time and the latest entry will be considered the end date and time.

In the event that a time earlier than that supported for historical queries (midnight GMT today) is specified, the request will still be accepted but only data going back to the supported time will be supplied.

If supplied, the date in tag 60 must match tag 75.

YYYYMMDD-HH:MM:SS.sss format

END – TrdCapDtGrp





Trade Capture Report Request Ack (35=AQ)

Version 4.4 of the FIX protocol requires tag 55 (Symbol) be present on this message; however, in this regard we will adhere to FIX 5.0SP2 (which doesn't require this tag).

TagTagNameReqVerDescription

568

TradeRequestID

Y

4.4

Unique Identifier of the Trade Capture Report Request. Echoed from 35=AD.

569

TradeRequestType

Y

4.4

  • 0 = All trades
  • 1 = Trades matching criteria provided on request

748

TotNumTradeReports

N