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:
FTC FIX Specification 4.4
FTC FIX Specification 5.0 SP2
Refer to the FTC documentation on the FTC website
Contents
- 1 Products Supported
- 2 Analytic Timings
- 3 System Schedule
- 4 Historical Data and Recovery
- 5 Session Management
- 6 Trade Capture Report Flows
- 7 Trade Capture Report FIX Message Definitions
- 7.1 Trade Capture Report Request (35=AD)
- 7.2 Trade Capture Report Request Ack (35=AQ)
- 7.3 Trade Capture Report (35=AE)
- 7.3.1 Party Role Definitions
- 7.3.2 Sub Party Role Definitions
- 7.4 EBS Analytic Name
- 7.5 Example FIX Messages
- 7.5.1 Example Vanilla Streaming TradeCaptureReportRequest
- 7.5.2 Example Vanilla Snapshot TradeCaptureReportRequest (Trade Date)
- 7.5.3 Example Vanilla Snapshot TradeCaptureReportRequest (Trade Date) for T+1 day only
- 7.5.4 Example Vanilla Snapshot TradeCaptureReportRequest (Transact Time)
- 7.5.5 Example Streaming TradeCaptureReportRequest filtering on a Floorcode (Party Role)
- 7.5.6 Example T+5 min TradeCaptureReport for an LP
- 7.5.7 Example T+1 day TradeCaptureReport for an LP
- 7.5.8 Example T+5 min TradeCaptureReport for an LC
- 7.5.9 Example T+1 day TradeCaptureReport for an LC
- 8 Contact Details
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.
Time | Action |
|---|---|
19:00 Sunday | Start FIX session. |
00:00 Mon-Fri | System rollover, FIX session will remain connected but historical data for the previous calendar |
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.
Tag | Field Name | Req | Ver | Comments |
|---|---|---|---|---|
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)
Tag | Field Name | Req | Ver | Comments |
|---|---|---|---|---|
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.
Tag | Field Name | Req | Ver | Comments |
|---|---|---|---|---|
112 |
How was your Client Systems Wiki Experience? Submit Feedback
Copyright © 2024 CME Group Inc. All rights reserved.