Look into CRSP/Compustat link table

The link history table (CCMXPF_LNKHIST) is the primary table used for WRDS CCM web queries. In this post, I explain this table in detail.

Background

We know that a company may issue multiple securities, one of which is considered primary for the company. On CRSP, this suggests that one PERMCO (the company-lever identifier) may have multiple PERMNOs (the security-level identifier). Because CRSP collects security-level data such as price and trading volume, we should consider CRSP as breaking down to the security level.

It is well known that Compustat provides financial statement data of a company. The micro unit on Compustat is each and every company. However, it is less known that Compustat also provides security data. In addition, because the coverage of Compustat is more extensive than that of CRSP, Compustat contains addtional security data that are unavailable on CRSP.

Historically, Compustat included only one (primary) security per company. Since mid-April in 2007, all securities issued by a company are available on Compustat with a new identifier, IID, which is used along with GVKEY to identify all securities tracked by Compustat. A marker item, PRIMISS, indicates whether a security is primary or secondary. Therefore, like PERMCO on CRSP, one GVKEY may have multiple IIDs currently.

Let me summarize the identifiers used by Compustat and CRSP:

DatabaseIdentifierDescription
CompustatGVKEYCompustat’s permanent company identifier.
CompustatIIDCompustat’s permanent security identifier. An identifying relationship exists between IID and GVKEY. Both must be accessed as a pair to properly identify a Compustat security. One GVKEY may have multiple IIDs.
CompustatPRIMISSThis item indicates whether a security is primary (P) or secondary (J). P identifies a primary security with the highest average trading volume over a period of time. J identifies a joiner (secondary) security.
CRSPPERMCOCRSP’s permanent company identifier.
CRSPPERMNOCRSP’s permanent security identifier. One PERMNO belongs to only one PERMCO. One PERMCO may have one or more PERMNOs.

The last piece of background information is that the link between CRSP and Compustat (at both company level and security level) may change over time.

The linking process

Prior to the introduction of IID, Compustat included only one (primary) security per company. The link between CRSP and Compustat was between CRSP PERMNO and Compustat GVKEY. Because PERMNO is a security identifier and GVKEY is a company identifier, this link may be a many-to-one relationship, i.e., multiple PERMNOs may be linked to a single GVKEY.

Because Compustat security-level information is now available, CRSP started to build security-level links in April 2007.

The linking history table

The main product of CRSP’s laborious linking efforts is the link history table. This table is Compustat-centric, that is, this table is organized and identified by Compustat identifiers which are then linked to CRSP identifiers. All Compustat records are retained, regardless of whether or not the securities (defined by GVKEY-IID) are in the CRSP universe.The following is a slice of the table (Please note that IID, PERMCO, and PERMNO have the prefix “L” in the link history table.):

GVKEYLINKPRIMLIIDLINKTYPELPERMNOLPERMCOLINKDTLINKENDDT
COMPUSTAT global company keyPrimary link markerSecurity-level identifierLink type codeHistorical CRSP PERMNO link to COMPUSTAT recordHistorical CRSP PERMCO link to COMPUSTAT recordFirst effective date of linkLast effective date of link
10411P1LC63773523019811215.E
10411P1NR1974112919811214
10411J7LC9065552302005051620120131
10411J6NR2005042920060131
10411J2NR19940331.E
10411J4NR2002013120060131

LIID is based on Compustat’s IID. Because Compustat’s company data range extends earlier than its security data range, there are time periods during which no IID is assigned by Compustat for a GVKEY. In these cases, CRSP assigns a dummy IID ending in “X” as a placeholder in the link table. This GVKEY-dummy IID may or may not be linked to a CRSP PERMNO.

LINKPRIM is a marker item that indicates whether a GVKEY-LIID is a primary security. This marker is based on Compustat’s Primary/Joiner flag (PRIMISS). However, due to missing primary issue markers from Compustat for early history, calendar ranges of overlapping, and different treatment for US and Canadian security issues, CRSP overides Compustat’s primary issue marker in many cases. The purpose is to produce one primary security throughout the company history. “P” represents the primary security issue identified by Compustat, while “C” represents the primary security issue identified or overridden by CRSP. In most applications, we only need the primary security.

Another important item is LINKTYPE. In short, LC and LU are considered as the most accurate links. They are also the default link types used for WRDS CCM web queries. LX and LD are considered as “soft” links of low accuracy. Old merging sample codes also include LS in addition to LC and LU. But by definition below, I do not think that LS should be included.

LINKDT and LINKENDDT are straightforward. They mark the period during which the link is valid.

Please see the detailed description of each item:

ITEM NAMETYPEDESCRIPTION
GVKEYinteger, primary key (1)Compustat GVKEY
LIIDchar(3), primary key (2)Compustat IID. A dummy IID with an “X” suffix is assigned by CRSP as a placeholder if no IID is assigned by Compustat for a GVKEY in early history.
LINKDTinteger (date), primary key (3)First effective calendar date of link record range
LINKENDDTinteger (date)Last effective calendar date of link record range
LPERMNOintegerLinked CRSP PERMNO, 0 if no CRSP security link exists
LPERMCOintegerLinked CRSP PERMCO, 0 if no CRSP company link exists
LINKPRIMchar(3)Primary issue marker for the link. This marker is based on Compustat Primary/Joiner flag (PRIMISS), but may be overridden by CRSP in some cases. Values are:

P – Primary, identified by Compustat in monthly security data.

J – Joiner secondary issue of a company, identified by Compustat in monthly security data.

C – Primary, assigned by CRSP to resolve ranges of overlapping or missing primary markers from Compustat in order to produce one primary security throughout the company history.

N – Secondary, assigned by CRSP to override Compustat. Compustat allows a US security and a Canadian security issued by the same company to both be marked as Primary at the same time. For purposes of the link, CRSP allows only one primary at a time and marks the others as N.
LINKTYPEchar(3)Link type code. Each link is given a code describing the connection between the CRSP and Compustat data. Values are:

LC – Link research complete. Standard connection between databases.

LU – Unresearched link to issue by CUSIP

LX – Link to a security that trades on another exchange system not included in CRSP data.

LD – Duplicate Link to a security. Another GVKEY/IID is a better link to that CRSP record.

LN – Primary link exists but Compustat does not have prices.

LS – Link valid for this security only. Other CRSP PERMNOs with the same PERMCO will link to other GVKEYs.

NR – No link available, confirmed by research

NU – No link available, not yet confirmed

I download the link history table as of January 30, 2015. I delete records without a link found (about 67% of all records; remember the link history table is Compustat-centric and the Compustat universe is bigger than the CRSP universe). For remaining records with a link found, I present the following statistics to give you a sense of the values of LINKPRIM, LINKTYPE, and LIID. As you can see, the vast majority of the primary issue marker is identified by Compustat, and “LC” and “LU” types of links constitute about 90% of all identified links.

The merging code

You may notice the following announcement on the CCM product:

As of the February 2014 release, USEDFLAG is no longer used in the WRDS CCM web queries.  Please select LINKTYPES LC, LU, and LS for the same results. These represent the vast majority of the links between CRSP securities and Compustat companies, without introducing duplicate data.

The WRDS-created linking dataset (ccmxpf_linktable) has been deprecated. It will continue to be created for a transition period of 1 year. SAS programmers should use the Link History dataset (ccmxpf_lnkhist) from CRSP.

This suggests that many old merging codes should be updated accordingly. Based on the explanation above, the most important query filters are LINKPRIM, LINKTYPE, LINKDT and LINKENDDT. LINKPRIM is used to select only primary security. LINKTYPE is used to ensure accuracy. LINKDT and LINKENDDT are used to ensure validity of a link at a give time. I believe that the following code is better than most sample codes I have seen:

 

Finally, I acknowledge that the information mainly comes from the official CRSP/Compustat Merged Database Guide.

This entry was posted in Learning Resources, SAS. Bookmark the permalink.

10 Responses to Look into CRSP/Compustat link table

  1. Carolina Magda says:

    Very good!!!

  2. Jing Xu says:

    Thanks. This is helpful.

  3. Soheila says:

    Thanks so much. These codes are very helpful.

  4. Soheila says:

    Thanks. These codes are very helpful.

  5. Victor says:

    Good stuff! Very helpful!

    I have a question for you. I saw this on the web:

    usually linkdt and linkenddt is a date, but linkdt can be ‘B’ (beginning) and linkenddt
    can be ‘E’ (end).

    How do you handle this when linkdt and linkenddt have values of ‘B’ or ‘E’?

    Thank you!

  6. Chandler says:

    Thanks for sharing, it was really helpful.
    Just was wondering if you have the merging code in STATA , as well?

    Cheers,

    • Kai Chen says:

      It may be done in Stata, but I highly recommend not doing that in Stata. Data merge will be best done via SQL, but Stata only has “baby” SQL functionality.

  7. LIZ says:

    Hi Professor,

    Thank you for sharing! It’s very helpful. I’m currently working on Stata though. Do you know the code to merge using Stata? Thank you very much!

    • Kai Chen says:

      It may be done in Stata, but I highly recommend not doing that in Stata. Data merge will be best done via SQL, but Stata only has “baby” SQL functionality.

Leave a Reply

Your email address will not be published. Required fields are marked *