Quantitative Portfolio Management

Appendix

A1 Secmaster mappings

When multiple vendor data are provided historically in different symbologies, the data needs to be mapped to a common “house” symbology. The house symbology can be either one of the vendors' or house-specific. Data management can be implemented in one of two ways: (a) remap and store data in house symbology on each vendor data update, or (b) store data in vendor-native symbology. Both approaches have advantages and disadvantages. If all external data is remapped on entry, reader processes do not have to load the secmaster, but all potentially big data storage has to be rerun on any change of (small) secmaster mappings. Storing data in vendor symbology is simpler and more in line with PIT data management (Sec. 2.1.1) but requires remapping to house symbology in reader processes. With suitable implementation, the remapping can be efficient and impose low overhead. Here we describe a possible historical remapping algorithm.

Vendors using their own symbologies, including MSCI Barra, Bloomberg, Thompson Reuters, Refinitive, Compustat, Factset, and many others, provide historical mappings from their security IDs to a few common identifiers such as ticker, CUSIP, SEDOL, ISIN, FIG I, RIC, among others. A vendor secmaster is a data structure implementing a dictionary of histories for each (vendorID, field) tuple as a key. A history is a list of (date, value) tuples. Using common identifier fields, the mapping

(A1.2)

can be inverted to get the inverse ...