Introducing

Understanding Trade Eligibility

May 26, 2020

The conditions that are taken into consideration when creating aggregate bars are quite complex. Users trying to recreate the aggregate Open, High, Low, Close and Volume values from our tick data API often get confused about why their values do not match ours or other popular data sets like Yahoo Finance, Bloomberg, etc.. This can also cause confusion for users seeing trades come in through the real-time WebSocket connection that appear to be higher or lower than the High and Low values made available through our Aggregates or Snapshot endpoints.

There are specific ‘rules’ that revolve around the ‘Sale Conditions’ defined in the UTP and CTA plan specifications that must be followed to calculate these aggregate values correctly.

Here, we’ll attempt to clear up any confusion that these highly technical documentations stir up.

CTA and UTP? What’s that? Great Question! We plan on making a separate write up because this can be just as confusing, but for now, let’s stick to the basics: The CTA and UTP feeds are Security Information Processors (SIPs) that every US stock exchange must report their trades and quotes to. These SIPs serve as the sources of truth for all US equities price data.

CTA Plan

The CTA plan specification thoroughly describes every aspect of how price data is disseminated in a not so short 93 pages. To save time, we’ve outlined some of the most vital information:

• Sale Condition - Denotes the sale condition associated with a trade. Also noted is the impact of Sale Conditions on the Open, Last, High and Low calculations both on a Consolidated and Participant basis.

These sale conditions are the raw codes, not what we send out in our real-time and historical ticks APIs.

The Consolidated Update guidelines should be used if you're looking to create aggregates representative of the entire market. The Participant Update guidelines should be used if you're planning on creating aggregates representative of each individual exchange.  

Four notes can deviate the way calculations are made for the OHLC Values. Think of these as conditions for the conditions.

• Note 1 - YES, if it is the only qualifying last; OR If is that participant’s first qualifying last; Otherwise NO

- According to the table, it will only be applied to the Market Center Opening Trade. So, this will determine the eligibility for the condition to update the price of the Last executed qualifying trade.

• Note 2 - YES, if it is the only qualifying last; Otherwise NO

- So, this will determine the eligibility for the condition to update the price of the Last executed qualifying trade.

• Note 3 - YES, if it is the only qualifying last; OR If it is from the same participant as the last; OR If it is from the LISTING MARKET for that Security; OTHERWISE NO

- Same as the first two Notes, but this one is only applied to the Sold Last trades (trades that are reported late)

• Note 4 - YES, if it is the first qualifying or only qualifying trade of the day; OTHERWISE NO.

- This will determine the eligibility for the condition to update the Open Price

- In instances of multiple Market Center Opening Trades, the latest trade takes precedence.

Many conditions may apply to each trade, so what if the eligibility of these conditions contradict each other?

• If all of the Sale Conditions indicate that the trade qualifies, it will be included in the calculations.
• If any one or all of the Sale Conditions indicate ‘NO’, the trade does not qualify, the ‘NO’ takes precedence and the trade will not be included in the calculations.
• If all of the Sale Conditions indicate that the trade qualifies, including a Sale Condition whose criteria deviates from a trade’s qualification (i.e., above Notes #1, #2, #3 and #4) the trade qualifies, the ‘Note Criteria’ takes precedence and the trade will be included in the calculations.
  

That is the TLDR for the CTA’s specification regarding Sale Conditions and their eligibility to be calculated into the OHLC aggregates. If you still yearn for more information, check out pages 62-64 of the following document: https://www.ctaplan.com/publicdocs/ctaplan/notifications/trader-update/CTS_BINARY_OUTPUT_SPECIFICATION.pdf

UTP Plan

Like the CTA specification, the UTP plan has its own rules and regulations regarding the eligibility of trades to update aggregates. While the CTA Plan specification pertains to the updates of the OHLC values, the UTP plan uses these conditions to determine when to update the HLCV or High, Low, Close, and Volume values.

The UTP Sale condition matrix is available on our Conditions and Indicators page. Most questions asked about the eligibility for trades to update the volume value is denoted by this spec.

Similar to the CTA matrix, this table represents the eligibility of each value to get updated according to two guidelines; the Consolidated Processing Guidelines and the Market Center Processing Guidelines. The Consolidated processing guidelines refers to the consolidated tape, in this case the UTP SIP feed, while the Market Center Processing Guidelines are specific to the individual participants (exchanges). Again, if you're looking to build aggregates to represent toal market volume, use the consolidated processing guidelines. If you're looking to build aggregates to represent each exchange, use the market center processing guidelines.

Much like the CTA plan, there are conditions applied to the conditions. These superscript values appear in a few of the table cells and are defined under the table.

• 1 UTDF Subscribers should only update the field values if the trade is the first or only last sale eligible trade transaction of the business day from any UTP participant.

- This is just saying that anybody receiving this data should only update the field if the trade is the first or last eligible transaction of the business day.

• 2 UTDF subscribers should update the consolidated last sale field if received prior to the End of Last Sale Eligibility Control Message (16:00:10). After the End of Last Sale Eligibility Control Message is received the transaction would only update the market center’s specific last sale value but not the consolidated last sale value.

- Data recipients should only update the last sale if the trade is received prior to the EOLS control message. This message signals the closing of the trade-reporting window for consolidated last sale calculation eligibility.

- Under the UTP plan, participants (exchanges) are required to report trade transactions that may impact the last sale price within 10 seconds of the normal market session close. This message will be generated 10 seconds after the market close message from the primary market. (Page 34)

• 3 Please note that direct data recipients, which maintain individual market center open values, should use the “Q” value as the official market center opening value and populate data displays accordingly

- This one states that if the data recipient is tracking the participant’s open values, they should use the condition code ‘Market Center Official Open’ and adhere to those rules.

Other notes to consider when making these adjustments are:

• For the sale condition modifier of “M” (Market Center Close Price), UTDF subscribers should note that this value is available to, but may not be supported by, all UTP participants. If a UTP Participant does not provide this sale condition code, UTDF subscribers should continue to show its final last sale eligible trade as the closing price for the market center.
• The “M” sale condition modifier will update the last sale price for the market center, but not the consolidated market. If the market center responsible for the consolidated last sale price submits a separate “M” transaction, it is possible that the two last sale values will not match.
• For the sale condition modifier of “Q” (Market Center Open Price), UTDF subscribers should note that this value is available to, but may not be supported by, all UTP participants.
• For statistical update of the High/Low/Last, if there are multiple sale conditions within the trade record, a “no” update for any one of the statistics will take precedence for that related statistical record and no update will occur for the related value.
  

For more information, refer to pages 42 - 47 of the following document: https://www.utpplan.com/DOC/UtpBinaryOutputSpec.pdf

Each trade condition, their definitions, update rules, and CTA/UTP mappings can now be found in our Conditions API endpoint:

{
   "asset_class": "stocks",
   "data_types": [
    "trade"
   ],
   "id": 2,
   "name": "Average Price Trade",
   "sip_mapping": {
    "CTA": "B",
    "UTP": "W"
   },
   "type": "condition",
   "update_rules": {
    "consolidated": {
     "updates_high_low": false,
     "updates_open_close": false,
     "updates_volume": true
    },
    "market_center": {
     "updates_high_low": false,
     "updates_open_close": false,
     "updates_volume": true
    }

Polygon.io takes both of these specifications into consideration when calculating the aggregate bars that we provide. We follow the consolidated update guidelines of both the CTA and UTP plans. If you’re planning to recreate bars from our tick data yourself, these are the guidelines you will need to follow. We have carefully created a system that takes every condition that is applied to a trade into consideration to curate the most accurate data possible. Polygon normalizes the conditions between the SIPs into one uniform list. The condition codes you will need to follow are on the Conditions and Indicators page, and are also available through our Condition Mappings endpoint.

If you ever have any additional questions or concerns, please don’t hesitate to contact us. We’re always happy to help any way we can.

• 

  jack

  Jack Bell

  Read More