There is a critical difference between directEDGAR’s Search Architecture and that of all of our competitors. Our search is run locally and theirs is run on the web. We are the only SEC filing search provider that uses local search.
So why are we different? That is an easy question to answer – we just want to save you time. A web search might initially look faster. If I type the phrase audit committee met in my Google search box I will get access to over 15 million documents in 0.40 seconds. But now what am I going to do?
Google lists ten results per page. Some of our competitors list 50 to 100 per page. Suppose I want to randomly look at the results, I have to click on the next button at the bottom of the page repeatedly to move to the next batch. This can quickly get tiring.
By localizing the search we can push all of the results to your computer and so you can look at any search result almost instantly. In the image the search found over 58,000 instances of our search phrase and with the scroll bar we can easily ‘look’ at any number that we like.
And while the example image above shows 58,646 documents, it is usually not the case that our users want all 58,646 results. Instead most users want to limit the results to a particular subset of registrants. That is a difficult task to accomplish on a web platform. I have seen some of our competitors allow searching by a limited number of CIKs but I have not yet seen anyone provide a robust way to search with a large set of CIKs. With our application any size list (well truthfully this has not been tested – the most we have ever tested with before is 12,000 CIKS) of CIKs can be pasted into the filter box or a file with the CIKs can be selected.
For this blog post I decided to set a new record and used 14,314 unique CIKs! The beauty of our search is not only will the Search Extraction & Normalization Engine limit the search to those specific CIKs it will also generate a list of all CIKs that did not have any documents in the search results. Again, the last time we checked, none of our competitors offer this critical feature.
Here is an image of the CIK filtering process where we add the CIKs to the search.
And after the search the application reports not only the number of documents but the number of missing CIKs.
None of this would be useful unless we can report back to you who had missing documents. That is easily available by hitting the View Misses button. As you can see in the image below, we provide options so you can directly save the results to a file or select and paste them somewhere else.
While I can provide additional examples, I think I have supported my primary point – our localized search architecture is better because we can add more features than if we were serving search results over the web. With a local search we can provide you almost instant access to any search result and we can implement robust CIK filtering that not only limits documents but reports back those that were missing.