Cancellations and Corrections

This page explains how to apply cancellations and corrections data.

Cancellations and corrections data is stored in the date partitioned CanCor table.

The getTicks API can be prompted to apply cancellation and correction data to an original transaction data table by passing in the boolean-type parameter `applyCanCor; for example:

    args: (!) . flip (
        (`table;            `Trade                          );
        (`startTS;          2023.07.28D09:00:00.000000000   );
        (`endTS;            2023.07.28D10:00:00.000000000   );
        (`idList;           `AMD                            );
        (`applyCanCor;      1b                              )
     );

    last gw(`getTicks;args;`callback;()!())

(where gw is a handle to the service gateway)

To illustrate how the cancellations and corrections data is applied, consider these raw data subselections from the Trade and CanCor tables:

Trade

CanCor

There are three corrections. getTicks overwrites the price and volume of the raw Trade data using newPrice and newVolume in the CanCor data and returns the amended data to the caller. There are two cancellations. getTicks removes the matching rows before returning the amended data to the caller.

The returned result is:

To clarify, the two trades at 09:50 and 09:55 have been removed and the price and volume cell values for the three trades at 09:05, 09:15 and 09:30 have been updated.

• The columns to match CanCor data to any type of transaction data are defined in config .api.cfg.cancorSettings, which is defined in api.config.q script. For example:

  table	canCorTable	columnsToMatchCancelsTo	columnsToMatchCorrectionsTo	columnsToCorrectWith
  Trade	CanCor	`eventTimestamp`instrumentID`origPrice`origVolume	`eventTimestamp`instrumentID`origPrice`origVolume	`newPrice`newVolume

• The default match columns in the FX accelerator packages are `eventTimestamp, `instrumentID, `origPrice, `origVolume, however, they may be changed depending on user preference. If any of `origPrice and/or `origVolume are used to match with, they are matched to `price and/or `volume respectively.

• To match cancels, we find the rows with equal match column values with the ? (search) function and remove those rows from the aggregated DAP results.

• To match corrections, in addition to the columns to match on, we set the columns to correct in the config .api.cfg.cancorSettings. Altogether, we left join on the CanCor data to the main transaction data using the match cols and overwrite the cols to correct. If any of `newPrice and/or `newVolume are used to correct, they overwrite `price and/or `volume respectively.

• The CanCor data is selected in the DAPs alongside the main transaction data being queried (the table argument to getTicks) and only applied to that data in the aggregator. It is subject to the exact same `startTS/`endTS restraints as the main transaction data is. It is selected in the DAPs by the call of .api.cancor.getCancor inside getTicks and temporarily stored in the args parameter.

• The CanCor data is then extracted from the args parameter in the aggregator by the call of .api.join.extractRefTabs inside .api.join.apis. It is then applied to the main transaction data by the call of .api.join.applyCanCor inside .api.join.apis.

• The CanCor data is then dropped in the aggregator, as are all values in the args parameter, as only data is returned from .api.join.apis. However, if a user wants to query CanCor data directly, either getTicks or getData can be called in the gateway directly with `table=`CanCor.