Tick History – the dreaded “Settings” button

Most academic users of the Tick History database are interested in efficient extraction of data, rather than the technical intricacies of the database. At times however it just pays to spend a few minutes understanding how to configure the database to help with data requests. The good news is that this configuration is usually a set & leave, rather than something which has to be frequently updated.

Click on the Settings button from the product menu bar, you will be presented with “Preferences”, “Default Settings”, “Change Password” and “Change Security Question”. For obvious reasons we will concentrate on the “Preferences” and “Default Settings”.

1. Preferences

Click on “Preferences” and you will be presented with three sub categories.

(i) Expand Chain RIC

As we consider this it is important to remember that the date which is showing in the bottom left of the set up screen defines the point in time over which the database is operating. A chain has been defined in a previous post, click here for more details. It is obviously made up of a group of assets which can, and usually do, vary over time. Imagine how the constituents of a stock market index change over time for instance. This setting tells the database how to handle chain expansion requests, either by snapshoting the constituents of the chain at the “From:” date, or at the “To:” date (obviously both of these dates are defined by the user). Alternatively, you can collect all the constituents of the chain over the entire date range. Finally, it is possible to eliminate the chain expansion capability fully by checking the “Never” button.

This earlier post gives you more about this setting.

(ii) Verify RICs

RIC verification checks whether your specified RICs actualy existed. It safeguards against unwanted data requests both from mistyped RICs and mistaken specifications, either in tickers or exchange identifiers. So it saves you from requesting data that does not exist. It is important to realise that RIC verification occurs over specified intervals. Three options are specified here. If you are confident about when a RIC exists you can choose “Over date range:”. TRTH then searches for your RIC only in the sample period defined by your “From” and “To” dates. This option is faster than searching the entire data set, which is what happens when you choose from “1996 onwards”. However, choosing “1996 onwards” is a better choice when you are less sure of trading dates because it is equivalent to asking if your RIC ever existed in TRTH. A second advantage of choosing “1996 onwards” is that all available information is gathered about changes connected with each RIC over the life of TRTH. This change related information is what you see reported in the New Request screen. In contrast, “Over date range” only delivers that change data as it was observed in your sample period. The final RIC verification option is “Never”. It is appropriate when you do not want RIC verification and its attendant reporting of changes.

(iii) Others, including timeout default

The timeout default is pretty self explanatory. The other three check boxes are worth considering. The first and second box ask the user whether they want to be presented with the previous search request amd results, this reflects the fact that users tend to spend a bit of time fine tuning their requests before submitting them, and as a result it helps not having to set up the search again every time a refinement is required. The third box asks for confirmation that you are happy working with the Reuters Instrument Code symbology.

2. Default Settings

Click on “Default Settings” and you will be presented with three sub categories.

(i) General

This tab is important in that it sets the clock at either “Local Exchange Time” or “GMT/UTC Time”. Local Exchange Time will relate to the clock associated with a specific exchange, it is obviously pretty meaningless for the purposes of comparing exchanges which sit across different timezones, or for asset classes and data which does not sit on an exchange.

Users can also set their preferred date format (European versus US etc).

The three check boxes are important in that they populate otherwise empty fields that have not changed over time, allow you to include the current RIC for the instrument in the data request, and, if available, will adjust the data for any applicable corrections and cancellations which may have been published by a venue subsequent to the original data being recorded.

(ii) Scheduling

Where a user would like to set up a regularly scheduled database retrieval request, this is where the defaults for this are established.

(iii) Data Delivery

This allows you to define maximum individual files sizes from 10MB up to a maximum of 500MB. Under file format you can choose to split large data requests into separate files per instrument. Finally, you can avail yourself of FTP push functionality if the default FTP pull from your university email address restricts you. This, along with a post about API access to the database, will be subject of a future post.