Real Time Event Data API details

Event data is highly structured factual information related to breaking events that trading firms can use to make reliable, real-time programmatic decisions. This form of information is structured and distributed more like market data than other forms of textual news. 

When large public companies announce their earnings several markets can be impacted:  

• Underlying equity traded on the NASDAQ, NYSE, Arca, and BATS in the US 
• Underlying equity of dual listed companies in foreign markets such as the LSE or Eurex 
• Exchange Traded Funds (ETFs) 
• Futures indices on the CME and Eurex 

• Peer companies (e.g. Apple’s earnings release may impact Google and Microsoft) 

Selerity has two primary data feed delivery options – ultra-low latency, UDP binary over multi-cast and the SeleritySync API, which is a JSON format over TCP/HTTPS. Most of Selerity’s latency sensitive clients take the binary feed over a fiber cross connect co-located in one of Selerity’s datacenter points-of-presence (POP)’s.

Clients can access static data either through SeleritySync.com or the SeleritySync API. 

Selerity has two ultra-low latency distribution POPs – Equinix CH1 (Chicago, IL), Equinix NY2 (Secaucus, NJ). Each POP has three environments1 – production A, production B, and integration. Two production stacks allows Selerity to deliver hot-hot feeds. Selerity’s integration environment allows Selerity to test new search & extraction algorithms and also allows clients to test their parsers on simulated event data publications.  

An observation message is a message containing a factual element associated with an event and its attributes. For example it will contain the entity the fact is related to (e.g. Microsoft), the measure (e.g. EPS), and the measurement (e.g. 2.11). It also contains other important metadata for machine-consumption. Please see the Event Data Service Specification and Data Model Document for details.  

Selerity uses multiple types of search & extraction algorithms with different characteristics to ensure ultra-low latency. For example, Selerity has an extraction algorithm based on a special technology that might take longer to produce, but has a higher accuracy score. We also run fully redundant sites that each produce their own extractions. Furthermore, there are typically several copies of a source document for a particular event that Selerity’s technology will extract from, which also creates their own Observation Messages. 

No. It is very important to always take into account the Period associated with the measure (e.g. WE-4W-2010- Nov-19) to ensure you’re looking at the desired data point and the Observation Status field. Observation Status tells you important information on how to interpret the extracted data. For more information on all of the different types of status, please refer to your Reference Data documentation.

All of Selerity’s relevant extraction algorithms for every event, so if an event occurs but the extraction algorithm could not find any data in the report, it will publish NOT_OBSERVED. For example, a company may choose to omit earnings guidance in their earnings release.

In very rare occasions, Selerity’s extraction algorithm will find a piece of targeted data, but will not be confident the extracted data is accurate. In these rare instances, the Observation Status will equal INVALID. These messages should always be discarded and not used. 

Specification Files allow recipients to decode observation messages. A message specification is a data structure which explicitly defines the fields that can be expected within a given type of message and provides instructions for how to extract those fields from the underlying datagram’s payload. This allows Selerity to manage entitlements without impacting latency (i.e. all event data content sets are broadcasted over the Selerity network, but recipients need the right .SPEC files to make use of their associated messages).