As I have described before we have been working to identify those cases where registrants have gone through some type of reorganization that has led to the creation of a new entity that has the successor filing obligations of the original entity.

You have had the ability to use the mapping we have created when you use CIK filtering for tasks with directEDGAR. So if you have a file that has Alphabet in the sample (CIK 1652044) but you are requesting data for a time period when Google was the reporting entity (prior to 2016) our application would return data for both CIKs.

The problem was that you would not know why data for CIK 1288776 was included in the results (of course you would if your sample had one CIK but not if you had hundreds or thousands of CIKs).

To address this problem we are going to add a new field(s) to our data ALT_CIK_#. In English that would read as Alternate CIK #. In most cases there is only one alternate CIK (Google->Alphabet, Oracle -> Oracle). There are cases though where there are several (CIK 23498 -> CIK 1636023 -> CIK 1732845).

We are testing this now and will roll out comprehensively when we have finished the cloud shift. However, at times you will see this new field in some data you extract from our preprocessed core data. You will also see ALT_CIK as a new metadata field in the DEF14 search extractions on the cloud platform.

To illustrate this – suppose I am trying to access director compensation data and I create a request file using the CIK for Alphabet – I know that director compensation data was available beginning in 2007 and so the request file looks like the following:

So after I have created the request file I use the application to select it and to select the Include Historical CIKs checkbox as illustrated in the next image:

Once the inputs have been selected hit the Okay button and the application will work the magic. The results file will have all of the usual data as well as this new field – in the image below I hid the data (CASH/STOCK etc) to make it easier to see the CIK (the value associated with the filing) and the ALT_CIK_1 field.

I will observe that one thought was to replace the CIK with the successor CIK. I don’t want to do that because you could not audit/trace back to the source document the data came from. Further, I can imagine there will be cases where it is significant to control for this shift. We will be pushing this out throughout the platform as soon as we can.