General Information

Current Security Identifiers & Definitions

The following columns provide information about current identifiers for a security like ticker and company name that are subject to change.

• ticker_current - The ticker for the security on the dataset generation date. Tickers that include a colon are currently inactive stocks. We assign the last used ticker to the security followed by a colon and a number that increments for each new company that becomes inactive with that ticker. For example, XYZ Corp trades under ticker XYZ and goes inactive. We assign the company the ticker XYZ:1 because it is the first company in our system to go inactive using ticker XYZ. If a different company, XYZ Technology, starts trading under ticker XYZ and goes inactive, it will be assigned XYZ:2. A list of tickers and company names is available on our website or through the coverage endpoint of our API.
• company_name_current - The name of the company on the dataset generation date.
• cik_current - The Central Index Key (CIK) used by the SEC on the dataset generation date to identify corporations and individuals who have filed with the SEC. CIK is provided to help map securities from New Constructs to other data sets. For active companies, the CIK is the one in use by the SEC on the dataset generation date. For inactive companies, the CIK is the last one in use by the company prior to its being inactivated.
• stock_exchange_current - The exchange on which a ticker trades on the dataset generation date. For active stocks, the exchange is the one on which the ticker was traded on the dataset generation date. For inactive stocks, the exchange is the last one on which the ticker was traded prior to its being inactivated.
• market_identifier_code_current - The market identifier code (MIC) for the exchange on which a ticker trades on the dataset generation date. MIC is a universal method of identifying exchanges. Please see Market Identifier Codes for details.
• company_status_current - The trading status of the security on the dataset generation date. Actively traded stocks are marked as 'LIVE'. Actively traded stocks we do not currently cover but previously covered are marked as 'DISABLED'. Inactive stocks that have been delisted and no longer traded are marked as 'INACTIVE'.

Point in Time Security Identifiers & Definitions

The following columns provide information about identifiers on a specific historical date for the security like ticker and company name that are subject to change.

• ticker_on_event_date - The ticker for the security on the event_date. Point-in-time identifiers are available starting on May 5, 2006 through the present. For periods before May 5, 2006, this field will be empty.
• company_name_on_event_date - The name of the company on the event_date. Point-in-time identifiers are available starting on May 5, 2006 through the present. For periods before May 5, 2006, this field will be empty.
• cik_on_event_date - The Central Index Key (CIK) used by the SEC on the event_date to identify corporations and individuals who have filed with the SEC. CIKs are provided to help map securities from New Constructs to other data sets.
• stock_exchange_on_event_date - The exchange on which a ticker traded on the event_date. Point-in-time identifiers are available starting on May 5, 2006 through the present. For periods before May 5, 2006, this field will be empty.
• market_identifier_code_on_event_date - The market identifier code (MIC) for the exchange on which a ticker traded on the event_date. MIC is a universal method of identifying exchanges. Please see Market Identifier Codes for details.

Permanent, Standard Security Identifiers & Definitions

The following columns provide information about 3rd-party permanent identifiers for the security that do not change. Note, we do not provide CUSIPs or ISINs for securities.

• figi - The Financial Instrument Global Identifier (FIGI) is an established global standard issued under the guidelines of the Object Management Group (OMG.org, an international, non-profit standards organization), founded in 1989. FIGI is provided to help map securities from New Constructs to other data sets. Please see OpenFIGI for details on OpenFIGI and its use. We do not provide CUSIPs for securities.
• perm_id - PermIDs are open, permanent and universal identifiers where underlying attributes capture the context of the identity they each represent. PermID is provided to help map securities from New Constructs to other data sets. Please see PermID for details.
• lei - Legal Entity Identifiers (LEI) are a unique identification of legal entities participating in financial transactions based on the ISO 17442. LEI is provided to help map securities from New Constructs to other data sets. Please see GLEIF for details.

Fiscal Period & Filing Column Header Definitions

The following columns provide information about the fiscal period and filing applicable to the data row.

• fiscal_year - The fiscal year of the data row.
• fiscal_quarter - The fiscal quarter of the data row. For annual periods, this field will be null. For quarterly periods, this field will show the quarter: 1, 2, 3, or 4.
• filing_type - The filing type of the filing for the data row - generally a 10-K or 10-Q.
• period_type - The fiscal period type for the data row - ANNUAL, TTM, or QUARTERLY. Annual data is shown when a company's latest filing is an annual filing (i.e. a 10-K). Trailing-twelve-month (TTM) data from the prior 4 quarters is shown when a company's latest filing in the relevant fiscal period is a quarterly filing (i.e a 10-Q). TTM data is only available when there is at least 4 quarters worth of data available for the company. Annual and TTM data are directly comparable. Quarterly data is data for one quarter and is not directly comparable to annual or TTM data.
• period_end_date - The period end date of the filing for the data row.
• filing_date - The SEC filing date for the filing for the data row.. In our real-time data feed, filing data are generally available to clients 48 hours after a new filing is filed with the SEC.

Data Processing Column Header Definitions

The following columns provide information about events that create new data, when we receive information about those events, and how long it takes to process that new data and provide it to clients. For more information on how we process filings and the time it takes to make data available to clients, see here.

• event_date - The date of the event that created new or revised data. For new filings, the event_date is equal to the filing_date. For stock splits, the event_date is equal to the stock split date.
• event_type - The type of event that created new or revised data. Event types include any event that creates new data or updates existing data for the company. The possible event_types are:
  • ANNUAL_FILING_FOR_THIS_PERIOD - A new annual filing was made available by the company for the period of this data row. This is commonly the original annual filing (10-K) for a new fiscal year or an amended filing (10-K/A) that revises data for a historical fiscal year.
  • QUARTERLY_FILING_FOR_THIS_PERIOD - A new quarterly filing was made available by the company for the period of this data row. This is commonly the original quarterly filing (10-Q) for a new quarterly period or an amended filing (10-Q/A) that revises data for a historical quarter.
  • ANNUAL_FILING_FOR_OTHER_PERIOD - A new annual filing for another fiscal period generated a revision to data in this period. This commonly occurs when we revise our quarterly models for the 1st, 2nd, & 3rd quarter for a fiscal year when the annual filing is processed. Annual filings generally include more disclosure in the footnotes and management discussion & analysis (MD&A) than quarterly filings. As a result, we revise our models for the prior quarters with information disclosed in the annual filing once it is available.
  • QUARTERLY_FILING_FOR_OTHER_PERIOD - A new quarterly filing for another quarter generated a revision to data in this period. This commonly occurs in 4th quarter models when a 1st, 2nd, or 3rd quarter filing is amended. 4th quarter data is calculated using reported data from the first three quarters and the annual filing. When any of that data changes, the 4th quarter model changes as well. This also commonly occurs in TTM models. Any change to data in one of the 4 quarters that comprise the TTM model will generate revised data for that period. For example, a change to reported revenue in an amended Q1 filing will cause a change to revenue in the Q3 TTM model.
  • STOCK_SPLIT - A stock split requires all calculations that use stock price or shares data as an input be recalculated for all periods prior to the stock split date. This is necessary to keep periods before the stock split date comparable to data after the stock split date. No underlying fundamental data from filings is changed during a stock split.
  • NEW_COVERAGE - Indicates that this security was just added to our coverage universe. A company's historical filings were loaded, processed, and made available to clients. This event_type only appears in live data feeds, not backtest data files.
  • NC_DATA_CORRECTION - Indicates that we made changes to data collected from a filing that had previously been processed in our system. These changes could be a correction to existing data or addition of data that previously wasn't collected. This event_type only appears in live data feeds, not backtest data files. We do not have a record of data corrections made over time.
  • NOT_AVAILABLE_IN_BACKTEST - Indicates a record for a data change that happened between the transition between backtest and live data, or that the data wasn't available in the backtest system.
  • SYSTEMATIC_MODEL_CHANGE - Indicates a systematic change was made to the way we calculate data in our model. The event_description field provides detailed information on the change.
  • COMPANY_STATUS_CHANGE - Indicates that this security has undergone a coverage status change, such as going from being actively traded to being inactive, or from being temporarily removed from coverage to being covered in our system. This event_type only appears in live data feeds, not backtest data files.
  • MULTIPLE - Indicates that multiple event_types occurred on the same date. The event_description field provides detailed information on all of the events that occurred.
• event_description - Provides an English language description of the event. This field is helpful for interpreting the other columns in this section and can provide more detail on the reason for the information in the data row.
• event_record_effect - Indicates whether the event is adding a new record to the data set or revising the results for a previously existing record. The possible event_record_effects are:
  • NEW_RECORD - The event created a data row for a new period not previously included in the data set. This is commonly the result of a new, original filing for a company (a 10-K or 10-Q for a new period).
  • REVISED_RECORD - The event generated revised data for a data row previously included in the data set. An amended filing (a 10-K/A or 10-Q/A) produces an REVISED_RECORD for example.
  • NO_EFFECT - The event occurred but did not change any data reported in this data set. For example, an amended filing provides revised pension plan data that does not impact core earnings. A core earnings data set would indicate that this amended filing had been processed and had no effect on the core earnings data.
• record_checksum - A checksum for the data row. This column serves to check that the data row has or has not changed.
• receipt_date_implied_by_event - The date we would have received information about the event based on our current system and processes. This date may differ from the receipt_date_actual because of changes to our system or policies over time. For example, when adding companies to coverage, we load and process the full history of their filings all at once. If we had covered the company at the time the filings were originally filed with the SEC, we would have received them on the receipt_date_implied_by_event. This field is useful when performing backtests because it shows what the historical data would be given the current capabilities of our system.
• nc_publish_date_implied_by_event - The date we would have published the data in this row to clients based on our current system. This date may differ from the publish_date_actual. In our real-time data feed, filing data are generally published and available to clients 48 hours after a new filing is filed with the SEC. Stock split data are published and available to clients within 24 hours. This field is useful when performing backtests because it shows when historical data would have been available to clients given the current capabilities of our system.
• receipt_date_actual - The date we actually received information about the event. For filings, the receipt_date_actual is the date we loaded the filing into our system. For stock splits, it is the date we received information about the stock split from our market data provider. Receipt_date_actual can be later than the filing_date when we load documents to add a company to coverage or when there is a problem loading SEC filings. Receipt_date_actual is available starting on 1/1/2009. Prior to 2009 we did not track or save receipt dates for data. All filings and data we received between the founding of New Constructs in 2002 and the beginning of 2009 show a receipt_date_actual of 1/1/2009.
• nc_publish_date_actual - The date we actually published the data in this row to clients. In our real-time data feed, filing data are generally published and available to clients 48 hours after a new filing is filed with the SEC. For stock splits, data are generally available within 24 hours. Nc_publish_date_actual is available starting on 1/1/2009. Prior to 2009 we did not track or save publish dates for data. All data we published between the founding of New Constructs in 2002 and the beginning of 2009 show an nc_publish_date_actual of 1/1/2009. We implemented exact timestamps on nc_publish_date_actual beginning on 5/26/2022. Prior to that, the timestamp 00:00:00 or 01:00:00 is used because we're confident those timestamps are after the time when the data was actually available in our systems.
• nc_publish_date_actual_check - This column shows whether the date displayed in nc_publish_date_actual occurred after 1/1/2009 when we began tracking and saving this information. This field will be TRUE when nc_publish_date_actual is a recorded, tracked date reported from our audit records and FALSE when nc_publish_date_actual is 1/1/2009, indicating that the publish date occurred on a date prior to 1/1/2009 but we do not have an audit record of the event.
• data_generation_date - The date this data file was generated. In our real-time data feed, this date will always be the same day the file is delivered to clients. For backtest data sets, this is the date the backtest data file was generated.

Column Definitions

Dataset-Specific Column Header Definitions

See the Data Feeds & Dictionaries documentation for each dataset. Descriptions for each column of data are provided in a dataset's documentation. All data values are reported in ones units. Datapoints that are impacted by stock price changes are marked with an asterisk (*) in the documentation.