INGESTION_DATE

This is the date that the report was ingested in the Propellant platform.

This can be used for bitemporal queries of the data, because it informs you what data was available in your Propellant platform “as-of” a certain date.

This is especially useful for backtesting, where the strategy which you are testing should use only the information that was available at the point in time that is being simulated in the test.

A trade report was published on a certain date but it was only ingested to the Propellant platform a few days later. In this instance, the PUBLICATION_DATE_AND_TIME will be lesser than the DATE.

TRADING_DATE_AND_TIME

This is the timestamp showing when a given trade was executed.

This is not the same as the publication timestamp (PUBLICATION_DATE_AND_TIME), i.e. when a report was published, but refers specifically to when the trade was executed.

There should only ever be one value for the trading timestamp, because it was only executed once, but there will be a new publication timestamp for each event that gets reported, such as amends and cancels.

Use this field to understand when a trade was actually executed.

PUBLICATION_DATE_AND_TIME

This is the timestamp showing when the report was published by a Trading Venue or APA.

This is not the same as the trading timestamp (TRADING_DATE_AND_TIME), i.e. when the trade was actually executed, but refers specifically to when a report was published.

There should only ever be one value for the trading timestamp, because it was only executed once, but there will be a new publication timestamp for each event that gets reported, such as amends and cancels.

Use this field to understand when a report was actually published. This is helpful for seeing the chronology of events on a trade.

POST_TRADE_DATE_AND_TIME

This field is equal to the trading timestamp (TRADING_DATE_AND_TIME) or, if the trading timestamp is unavailable, it is the timestamp when the report was published (PUBLICATION_DATE_AND_TIME).

You should always use POST_TRADE_DATE_AND_TIME when you want to filter for trades executed in a given period.

Propellant created this field from the trading and publication timestamps so that all reports are aligned on a consistent time series. The logic uses the more accurate timestamp, i.e. trading, when available but there will always be at least a timestamp for when the report was first published.

The primary reason why TRADING_DATE_AND_TIME would be null is because the trade was eligible for one of the aggregation supplementary deferral flags. In these cases multiple trades have been bundled together and reported in aggregate, so there's no single timestamp that could be used.

When trade reports are eventually disaggregated, and the individual execution timestamps become available, Propellant automatically back-populates these trades so that they appear at the time when they were executed.

EVENT_ID

Hexadecimal code assigned by Propellant to uniquely identify each report.

Every row will have a unique EVENT_ID but events for the same trade will share the same TRADE_ID.

EVENT_ID is unique and every single row has one, so it can be used for precisely referencing particular record.

The report identifier provided by each source is not always unique within the given source, nor necessarily across sources. The EVENT_ID, generated by Propellant, overcomes this issue by being unique both within and across all sources.

For example, there are multiple amendments and cancellations on a particular trade. Each of these amendments and cancellations has its own unique EVENT_ID assigned to it.

TRADE_ID

Hexadecimal code assigned by Propellant to uniquely identify a trade.

The same TRADE_ID is shared across all events relating to that trade - e.g. all cancels and amends on the original trade report first published.

This TRADE_ID is unique across all sources and follows a consistent format.

This field can be used to look-up a specific trade, including all events associated with it.

SEQUENCE_NUM

A counter, starting from 1, that chronologically sequence EVENT_IDs within particular TRADE_ID by PUBLICATION_DATE_AND_TIME and standard sequence of operations NEWF-CANC-AMND. Trade created with NEWF, might be cancelled with CANC, or might be amended multiple times with CANC-AMND pairs.

Use this field to sort records within same TRADE_ID and fiend first/last record per TRADE_ID.

This field can be used to look-up a specific trade, including all events associated with it.

TRANSACTION_IDENTIFICATION_CODE

Alphanumerical code assigned by Trading Venues and APAs to each event on a given trade.

This field is used to identify each event, while the ORIGINAL_TRANSACTION_IDENTIFICATION_CODE identifies the original trade report.

It is broadly equivalent to EVENT_ID, but note that this field is specific to each Trading Venue and APA, so there is no consistent format nor guarantee that it is unique.

Use this field if you would like to look-up a specific event in the underlying source data.

However, we do not recommend using this field for finding specific reports across the whole dataset because it is not specific within a source nor between sources.

Instead, we recommend using EVENT_ID because the EVENT_ID is generated by Propellant to be unique across all sources and it follows a consistent format.

ORIGINAL_TRANSACTION_IDENTIFICATION_CODE

Alphanumerical code assigned to reports by Trading Venues and APAs for referencing the original trade when there is a new event.

This field is used when an amendment or cancellation event happens on a trade. It references the original new trade that is being updated.

It is broadly equivalent to TRADE_ID, but note that this field is specific to each Trading Venue and APA, so there is no consistent format nor guarantee that it is unique.

Many sources do not include an ORIGINAL_TRANSACTION_IDENTIFICATION_CODE on the initial, new trade report. Rather, the TRANSACTION_IDENTIFICATION_CODE for the first report will be used as the ORIGINAL_TRANSACTION_IDENTIFICATION_CODE in subsequent amendments and cancellations.

Use this field if you would like to investigate a given trade’s lineage in the underlying source data.

We do not recommend using this field for grouping together events on a given trade. Instead, we recommend using TRADE_ID because the TRADE_ID is generated by Propellant to be unique across all sources and it follows a consistent format.

SOURCE

Name of the venue or vendor group that has published the report.

Propellant has categorised Trading Venues and APAs by their corporate group. For example, any report published by a Bloomberg entity will have SOURCE = “BLOOMBERG”.

Use this field to more easily identify which provider published the trade report.

The individual Trading Venue- and APA-level information is still provided in other fields, but Propellant has identified an overall SOURCE grouping to make it easier to refer to a particular provider.

VENUE_OF_PUBLICATION

Identifies the Trading Venue or APA which published the report.

This is the Market Identifier Code (MIC) of the Trading Venue or APA.

Trades executed on-venue must be reported by that same venue, so they will likely have the same value for the VENUE_OF_EXECUTION and VENUE_OF_PUBLICATION.

This field can be used to spot patterns in reporting conventions.

Trading Venues and APAs sometimes show idiosyncrasies in their reporting decisions, so being able to identify the VENUE_OF_PUBLICATION can help to understand and handle particular reporting methodologies.

VENUE_OF_EXECUTION

Identifies the Trading Venue where the transaction was executed.

This is the Market Identifier Code (MIC) of the Trading Venue.

For off-venue trades, e.g. OTC trades, executed by a Systematic Internaliser (SI), the value “SINT” is used.

For off-venue trades where no SI is involved, only one or more investment firms, the value “XOFF” is used.

Use this field to filter for trading activity by venue type or specific venue.

INSTRUMENT_IDENTIFICATION_CODE_TYPE

The name of the type of identifier used to identify the instrument that has been traded.

This informs you what type of identifier to expect in INSTRUMENT_IDENTIFICATION_CODE.

In practice, this code will always be an International Securities Identification Number, or “ISIN” (ISO 6166). This is a 12-character long alphanumeric string representing instrument reference data that can be looked-up.

However, there is regulator and industry discussion around the possibility of using the Unique Product Identifier, or “UPI” (ISO 4914), in future too.

In future, if new types of identifiers become eligible options for describing instruments, you could use this column to assist with parsing the INSTRUMENT_IDENTIFICATION_CODE correctly according to its type.

INSTRUMENT_IDENTIFICATION_CODE

The identifier for the instrument that has been executed. The type of identifier used is noted in the INSTRUMENT_IDENTIFICATION_CODE_TYPE.

In practice, this code will always be an International Securities Identification Number, or “ISIN” (ISO 6166). This is a 12-character long alphanumeric string representing instrument reference data that can be looked-up.

However, there is regulator and industry discussion around the possibility of using the Unique Product Identifier, or “UPI” (ISO 4914), in future too.

The ISIN value provided in this field can be used to join the content with instrument reference data.

Each ISIN corresponds to a record containing instrument reference data that varies by instrument type.

A meaningful selection of instrument reference data is reported to ESMA’s and the FCA’s Financial Instruments Reference Data System (FIRDS) and this content is available in your Propellant instance.

PRICE

Traded price of the transaction excluding, where applicable, commission and accrued interest.

The price convention should follow standard market practice and it is described by the PRICE_NOTATION field.

Prior to 01-Jan-2024, this PRICE field sometimes contained the string values, “PNDG” (“pending”) or “NOAP” (“not applicable”). After this date, ESMA required that PRICE should only contain the actual price or is left null where the price is pending or not applicable.

Use this field to see the price at which a trade was executed.

PRICE_NOTATION

Identifies the pricing convention used.

The price notation should follow market standards, but further guidance is provided for certain instrument types.

Credit default swaps (CDS): Price in basis points.

Bonds (other than ETNs and ETCs): Price in percentage of notional amount, except where the alternative notations are the market practice for the particular instrument.

This field can be left null where the price is pending or not applicable.

Use this field to understand the convention that has been used to express the price.

PRICE_CURRENCY

Currency in which the price is expressed (applicable if the price is expressed as monetary value).

This should always be a major currency, not minor (e.g. GBP instead of GBp)

Use this field to understand that currency a trade was priced in.

QUANTITY

The number of units of the financial instrument that have traded.

This field is null where the concept of a tradable “unit” of the instrument is not applicable.

Note that some sources use the QUANTITY field to indicate the number of transactions included in an aggregated report, the same way that TRANSACTION_COUNT is used.

Use this field to understand how many individual contracts were traded in an execution.

However, NOTIONAL_AMOUNT is a more useful field if you wish to understand the volume of the trade in monetary terms.

NOTIONAL_AMOUNT

Identifies the volume traded.

Generally, this is the face value, or nominal value, of the trade that indicates the total amount executed.

This differs from the QUANTITY field, in that QUANTITY is used for indicating the number of units traded as opposed to a total monetary value.

NOTIONAL_CURRENCY

Currency in which the notional is denominated. This should always be a major currency, not minor (e.g. GBP, GBp).

For FX derivatives, or other instruments where there are multiple currencies involved, this is the currency for leg 1.

Use this field to identify the currency in which the trades’s volume is denominated.

NOTATION_OF_THE_QUANTITY_IN_MEASUREMENT_UNIT

The number of units of a commodity or emission allowance traded, using the unit of measurement identified in NOTATION_OF_THE_QUANTITY_IN_MEASUREMENT_UNIT.

Use this field to understand how much of the underlying commodity or emission allowance was traded.

However, NOTIONAL_AMOUNT is a more useful field if you wish to understand the volume of the trade in monetary terms.

QUANTITY_IN_MEASUREMENT_UNIT

The number of units of a commodity or emission allowance traded, using the unit of measurement identified in NOTATION_OF_THE_QUANTITY_IN_MEASUREMENT_UNIT.

Use this field to understand how much of the underlying commodity or emission allowance was traded.

However, NOTIONAL_AMOUNT is a more useful field if you wish to understand the volume of the trade in monetary terms.

TRANSACTION_COUNT

This is the total number of transactions included in a given trade report.

This is primarily relevant for aggregated reports which bundle multiple trades into one report.

Use this field to assume certain values for individual trades when all that is available is an aggregated reported.

TRANSACTION_TO_BE_CLEARED

Code to identify whether the transaction will be cleared.

Use this field to filter-in / -out cleared transactions.

NEWF

New transaction flag. Identifies a new trade and is always the first event for a given TRADE_ID.

Use this flag to to filter-in rows where NEWF = True to see the original trade details, prior to any amendments or cancellations.

AMND

Amendment flag. Identifies updated versions of a given report.

Amendments behave like “overwrites”, fully replacing the previous version of a trade.

When making an amendment, the reporter will first publish a cancellation that matches the details of the original trade, but with the cancellation flag included (CANC = True), before then publishing the updated version of the trade with the amendment flag (AMND = True).

Use this flag to filter-in rows where AMND = True to see the lineage of trade amends.

If you are only interested in seeing the latest state of a trade, then the best and most convenient way to achieve this is to filter for trades where RELEVANT = True.

CANC

Cancellation flag. Identifies cancelled versions of a given report.

Cancels are used both to identify where a trade has been cancelled, but they are also used in the report amendment workflow.

When cancelling a report, the report will publish a copy of the entry they are cancelling that matches its details exactly, except that the cancellation flag is included (CANC = True).

If the trade has been fully cancelled, then the cancellation entry will be the final event on the trade. If the cancellation has been reported as part of the amendment workflow, then you will see a subsequent event on the same trade with the amendment flag included (AMND = True).

Use this flag to filter-out rows where CANC = True to remove any cancelled trade reports.

If you are only interested in seeing the latest state of a trade, then the best and most convenient way to achieve this is to filter for trades where RELEVANT = True.

BENC

Identifies whether the transaction was executed in reference to a benchmark price, such as a volume- or time-weighted average price.

Use this flag to filter-in rows where BENC = True to see trades whose price was driven by another reference value.

ACTX

Identifies trades executed on an agency basis.

Use this flag to filter for all rows where ACTX = True to return agency trades.

NPFT

Non-price forming transaction flag.

This flag is used to identify transactions that are more operational in nature, rather than a new trade executed for the purposes of hedging or risk.

This includes the following types of transactions:

Use this flag to filter-out reports relating to executions which might not be commercially relevant or accurately reflecting liquidity.

LRGS

Post-trade LIS transaction flag.

Identifies reports for trades whose size was above the “large in scale” (LIS).

Such reports are not published until 19:00 local time on the second working day after the execution date.

Note that this type of deferral can be combined with a Supplementary Deferral and the report’s publication thereby delayed for longer.

Also, a trade report should only have either the LRGS or the SIZE flag, not both. If the size of the trade is greater than both thresholds then the flag representing the higher threshold should be used. Typically the large in scale threshold is higher than the size specific to instrument threshold.

Use this flag to identify aggregated, deferred, and/or partially-masked reports.

ILQD

Illiquid instrument transaction flag.

Identifies reports for trades in instruments deemed illiquid. Such reports are not published until 19:00 local time on the second working day after the execution date.

Note that this type of deferral can be combined with a Supplementary Deferral and the report’s publication thereby delayed for longer.

Use this flag to identify aggregated, deferred, and/or partially-masked reports.

SIZE

Post-trade SSTI transaction flag.

Identifies reports for trades whose size was above the “size specific to the instrument” (SSTI).

Such reports are not published until 19:00 local time on the second working day after the execution date.

Note that this type of deferral can be combined with a Supplementary Deferral and the report’s publication thereby delayed for longer.

Also, a trade report should only have either the LRGS or the SIZE flag, not both. If the size of the trade is greater than both thresholds then the flag representing the higher threshold should be used. Typically the large in scale threshold is higher than the size specific to instrument threshold.

Use this flag to identify aggregated, deferred, and/or partially-masked reports.

TPAC

This identifies trades that are part of a package transaction. Such transactions are defined as a trade involving the execution of two or more financial instruments, where:

Use this flag to identify trade reports that are actually all part of the same package transaction.

XFPH

Identifies trades executed as to enable an exchange for physical transaction.

An “exchange for physical” is defined as a transaction in a derivative contract, or other financial instrument, which is contingent on the simultaneous execution of an equivalent amount of an underlying physical asset.

Use this flag to filter for those trades which represent the actual transfer of an underlying asset, as opposed to trades that reference an underlying asset but where the trade is settled in cash (according to the asset’s value).

LMTF

Identifies reports published with only limited details, excluding volume, during the deferral period.

The unmasked version of the report, including the information on volume, is published after the standard deferral period, which is by 19:00 local time on the second working day after the execution date.

Use this flag to identify aggregated, deferred, and/or partially-masked reports.

FULF

Full details flag for trades which had previously been reported without their volume under the LMTF supplementary deferral.

A report where FULF = True contains the full details for a trade which was previously reported without its volume, under the LMTF supplementary deferral flag.

When a post-deferral report is published it has RELEVANT = True and Propellant automatically updates the original, aggregated version with RELEVANT = False.

This means that partially-masked reports are not “over-counted” once the individual details are released.

DATF

Daily aggregated transaction flag.

Identifies reports for trades that have been aggregated. Such reports aggregate all trades in the same instrument that were executed in the same calendar day.

The report details include the weighted average price, the total volume traded, and the total number of transactions.

There must be at least five transactions available to aggregate in each given calendar day. If there are fewer than five trades in the instrument, then no aggregated version of the report is published during the deferral period.

The disaggregated versions of the report, i.e. where the individual trade details are available, are published after two business days.

Use this flag to identify aggregated, deferred, and/or partially-masked reports.

FULA

Full details flag for trades which had previously been reported only in an aggregated format under the DATF supplementary deferral.

A report where FULA = True contains the full details for a trade which was previously reported only in an aggregated report, with other trades, under the DATF supplementary deferral flag.

When a post-deferral report is published it has RELEVANT = True and Propellant automatically updates the original, aggregated version with RELEVANT = False.

This means that aggregated reports are not “over-counted” once the individual details are released.

VOLO

Volume omission flag.

Identifies reports published with only limited details, excluding volume, during the deferral period.

The unmasked version of the report, including the information on volume, is published after four weeks.

Use this flag to identify aggregated, deferred, and/or partially-masked reports.

FULV

Full details flag for trades which had previously been reported without their volume under the VOLO supplementary deferral.

A report where FULV = True contains the full details for a trade which was previously reported without its volume, under the VOLO supplementary deferral flag.

When a post-deferral report is published it has RELEVANT = True and Propellant automatically updates the original, aggregated version with RELEVANT = False.

This means that partially-masked reports are not “over-counted” once the individual details are released.

FWAF

Four weeks aggregation flag.

Identifies reports for trades that have been aggregated for four weeks.

Use this flag to identify reports that currently only show aggregated details for trades executed within a given time window, but which will be replaced by reports with the full individual trade details the next working day.

FULJ

Full details flag for trades which had previously been reported only in an aggregated format under the FWAF supplementary deferral.

A report where FULJ = True contains the full details for a trade which was previously reported only in an aggregated report, with other trades, under the FWAF supplementary deferral flag.

When a post-deferral report is published it has RELEVANT = True and Propellant automatically updates the original, aggregated version with RELEVANT = False.

This means that aggregated reports are not “over-counted” once the individual details are released.

IDAF

Indefinite aggregation flag.

Use this flag to identify reports for sovereign debt trades that are published in an aggregated format.

Such reports aggregate all trades in the same instrument that were executed in the same calendar week. The report details include the weighted average price, the total volume traded, and the total number of transactions.

There must be at least two transactions available to aggregate in each given calendar week. If there is only one trade in the instrument in a given calendar week, then it will not be published in aggregate until the next calendar week that another trade in the instrument occurs and then they are published together in aggregate (along with any other eligible trades published that same calendar week).

The disaggregated version of the report, i.e. where the individual trade volumes are available, will never be published. This type of aggregation is indefinite.

Identifies aggregated, deferred, and/or partially-masked reports.

Note that there is still a transaction count provided with this type of aggregated report, so a simple average volume can be calculated.

COAF

Consecutive aggregation flag (post volume omission for sovereign debt instruments).

Identifies reports for sovereign debt trades that already had limited details published, excluding their volumes, and now after four weeks have passed are published in an aggregated format with aggregated volumes.

Such reports aggregate all trades in the same instrument that were executed in the same calendar week. The report details include the weighted average price, the total volume traded, and the total number of transactions.

There must be at least two transactions available to aggregate in each given calendar week. If there is only one trade in the instrument in a given calendar week, then it will not be published in aggregate until the next calendar week that another trade in the instrument occurs and then they are published together in aggregate (along with any other eligible trades published that same calendar week).

The disaggregated version of the report, i.e. where the individual trade volumes are available, will never be published. This type of aggregation is indefinite.

The initial version of the report, identifying individual trades but without their volume, has VOLW = True and the subsequent aggregated version, including aggregated volume, has COAF = True.

Use this flag to identify aggregated, deferred, and/or partially-masked reports. Note that there is still a transaction count provided with this type of aggregated report, so a simple average volume can be calculated.

RELEVANT

This field indicates which report for a given trade is the most useful, accurate, and latest.

RELEVANT is True for the latest chronological event on a trade, providing the post-deferral version of the trade where this is available.

This is a fundamentally important field. You should filter your results to RELEVANT = True to always retrieve the latest state of each trade and exclude any reports that are no longer valid.

RELEVANT is False for any trades in a final cancelled state and for any deferred versions of reports that have been superseded by post-deferral version with more details.

ACTIVE

Identifies the latest state of a trade report, as long as it has not been cancelled. Note that this field differs from RELEVANT.

An aggregated, masked, or deferred report will still have ACTIVE = True even after it has been superseded by a later report, whereas these same aggregated, masked, or deferred reports would have RELEVANT = False in these instances.

Filter for all rows where ACTIVE = True to return the latest version of every live trade report, including deferred and masked reports.

Note that the RELEVANT field is a more useful filter than ACTIVE in most cases. This is because RELEVANT can be used to remove aggregated, deferred, or masked reports that have been superseded by a later report.

CANCELLED

Identifies reports that are not the latest, valid version of a trade.

In practice, CANCELLED = True where the event is simply not the latest chronological event for a given trade, or where it is the latest event and that event is officially a cancellation report (CANC = True).

It is possible for CANCELLED to be true where CANC is false. Any “old” amendment reports (AMND = True) will be identified as CANCELLED if they are not the latest event because, while not technically a cancellation message, they are still not the latest, valid version of a trade.

Use this flag to filter-out rows where CANCELLED = True to remove all old, invalid events on a given trade so that you are left with only the most recent, valid event. However, if you are interested in seeing the latest, most accurate state of a trade, then the best and most convenient way to achieve this is to filter for trades where RELEVANT = True.

AMBIGUOUS

Identifies events that are associated with the same trade and have the same exact timestamp, but their other fields differ.

These events are identified as AMBIGUOUS because it is not possible to distinguish which event represents the latest state of the trade.

Use this flag to filter-out rows that are AMBIGUOUS = True to avoid considering trade events that are likely erroneous.

LAST_TRANSACTION

Flag for identifying what is currently the last event reported for a given trade.

When ordering the events associated with a given trade by order of PUBLICATION_DATE_AND_TIME, the event that was published latest will have LAST_TRANSACTION = True.

Use this flag to quickly find the most recent event on a trade. However, if you are interested in seeing the latest, most accurate state of a trade, then the best and most convenient way to achieve this is to filter for trades where RELEVANT = True.

FUTURE_PUBLICATION_DATE

This field indicates the date on which the report’s deferral period should end and the full version of the report(s) is published.

This field only applies to reports which have one of the deferral flags. Any report that was never deferred, or is itself the post-deferral version of the report, will not have a FUTURE_PUBLICATION_DATE.

Use this field to understand when the full version of a report will be published. This is helpful if you want to know when to check back for the full details of a trade that is currently in its deferral period.

CFI_CODE

Identifies the category of instrument using a six-letter code. Each letter corresponds to a subcategory that further defines the instrument’s characteristics.

The look-up table for finding what each character refers to can be found in the ISO 10962 standard.

Use this field to filter for trades in particular types of instrument.

INSTRUMENT_FULL_NAME

Long-form description of the instrument that has been traded.

This is a human-legible name of the instrument, sometimes including reference data (e.g. maturity date in the case of bonds).

Use this field to understand what type of instrument is being reported.

CFI_GROUP_NAME

Describes, in human-legible terms, the type of instrument. This description is based on the second character of the CFI code.

Use this field to understand what type of instrument is being reported. This field could also be used to filter your results to include only particular types of instrument.

NOTIONAL_AMOUNT_USD

Represents NOTIONAL_AMOUNT converted to USD using last exchange rate available a day before POST_TRADE_AND_TIME.

Use this field understand traded volume in USD.

NOTIONAL_AMOUNT_EUR

Represents NOTIONAL_AMOUNT converted to EUR using last exchange rate available a day before POST_TRADE_AND_TIME.

Use this field understand traded volume in EUR.

NOTIONAL_AMOUNT_GBP

Represents NOTIONAL_AMOUNT converted to GBP using last exchange rate available a day before POST_TRADE_AND_TIME.

Use this field understand traded volume in GBP.

DUPLICATE

Identifies trades that have been reported multiple times in the same jurisdiction.

All fields are exactly the same except for the report identifier provided by the source used to index the reports (e.g. TRANSACTION_IDENTIFICATION_CODE).

Use this flag to filter-in / -out trades repeatedly reported in the same jurisdiction. To avoid double counting select records with DUPLICATE=false.

DUPLICATE_HASH

A key for grouping, under the same identifier, multiple reports whose fields match entirely, except for the venue of publication’s report identifier (e.g. TRANSACTION_IDENTIFICATION_CODE).

Use this field to see the individual reports which are likely the same trade that has been reported multiple times within the same jurisdiction due to a reporting error.

DUAL_REPORTED_HASH

A key for grouping, under the same identifier, different reports that are likely the same trade that been reported multiple times, across different jurisdictions.

Use this field to see the individual reports which are likely the same trade that has been reported multiple times across different jurisdictions.

ALL_TO_ALL

Identifies trades that have been reported separately, but which are likely two sides of the same trade brought about by matching interests on a Trading Venue.

Use this flag to filter-in / -out trades executed through orders crossing on a platform. To avoid double counting select records with ALL_TO_ALL=false.

ALL_TO_ALL_HASH

A key for grouping, under the same identifier, trades that have been reported separately, but which are likely two sides of the same trade brought about by matching interests on a Trading Venue.

Use this field to see the individual trades which have been grouped together as the same “all-to-all” transaction.

CROSS_VENUE

Identifies trades that have been reported multiple times by different Trading Venues or APAs.

Use this flag to filter-in / -out trades reported by different Trading Venues or APAs. To avoid double counting select records with CROSS_VENUE=false.

CROSS_VENUE_HASH

A key for grouping, under the same identifier, different reports that are likely the same trade that been reported multiple times by different Trading Venues or APAs.

Use this field to see the individual reports which are likely the same trade that has been reported multiple times by different Trading Venues or APAs.

CROSS_VENUE_TYPE

The are 2 cross venue types:

• ELECTRONIC_INITIATED type identifies trade executed electronically and reported by Trading Venue (MTF or OTF) and additionally reported multiple times by APAs.
• VOICE_INITIATED type identifies trade executed by voice and reported by 2 or more different APAs.

ENRICHMENT_ID

The hexadecimal code assigned by Propellant to uniquely identify each record enrichment with analytical fields, required by local replication.

VALID_FROM

This field indicates the date on which a given record was published and accurate.

Use this field in the local replication process (see specific documentation for a guide) or for bitemporal queries. This field can be used for bitemporal queries because it indicates the date on which a given record was published as the latest, most accurate version. Therefore you can search for a version of an event “as-of” a certain date.

BACKFILL

An indicator for identifying trades (and events), usually historical, that were not published in the usual workflow and have been inserted later.

The BACKFILL=TRUE records come with VALID_FROM on the day of the backfill (not on the day the data should have been loaded originally).

Use this field to control when, and whether, to ingest large volumes of historical content.

LAST_SUCCESSFUL_RUN

This is the timestamp for the most recent successful update to the local replication table.

This indicates when the local replication content was last refreshed.

Use this field to help determine when to run your local replication process. For instance, if this timestamp is not today’s date then you can assume that the content in the local replication table is not yet refreshed with the latest content and you should not start your download yet. The latest local replication content should be available for you to download by 06:00 UTC each day. This timestamp provides validation that it is ready.