How to make a fast SEC filing detection system

Note: if you do not want to roll your own infrastructure, you can use Datamule's Fastest SEC Filings Websocket for $0.25/connection/day or Websocket which has one connection free, and also supports webhooks and email notifications.

RSS

The SEC's RSS feed is considered the standard fastest way to get SEC filings. I have found a faster way, see Anticipation.

The RSS feed is fast. There are two issues with it:

1. It occasionally misses filings. This is why EFTS is important - it is slower but complete.
2. It is cached.

Lets talk about caching, because it is tricky. Say I send a request from LA and NY to the RSS feed arriving at the same time. One feed will likely have new filings that do not show on the other feed. This is because the feed is load balanced, meaning split across multiple servers. Each server contains a page that is cached for ballpark 60 seconds.

If I ask Claude Code to write code to scrape the SEC's RSS feed every second, the code will likely use connection pooling, which is a way to reduce the cost of creating a connection across the internet for multiple requests. This is bad, because it means that each request will hit the same server, until the cache expires.

Below is an plot of an approach that requests a new connection each time versus one that does not. Datamule's Fastest SEC Filing's Websocket has been updated to use the new secinfra code without connection pooling, unlike the Normal Websocket which uses pooling. Fastest SEC Filing's Websocket is considerably faster.

Note: secinfra is a rust rewrite of my more popular python package datamule.

Note: I have not tested behavior of RSS scrapers across multiple locations. Both websockets run in us-east, either on GCP or AWS. My guess is that adding multiple locations would yield faster detection.

EFTS

This is EFTS. It is the backend for EDGAR Full Text Search.

Unlike RSS, it is complete. However it takes longer to update. For intuition, assume 1min30s slower than RSS. EFTS has some quirks, such as only allowing 10,000 results. This is a problem as some days have more than 10,000 filings. A solution is implemented in both secinfra and datamule.

Note: I believe EFTS is also cached. So similar tricks used for RSS would also work here.

Note: A full list of parameters for EFTS can be found here.

Anticipation

Both Datamule's Fastest SEC Filings Websocket and Websocket implement this, although Fastest SEC Filings Websocket is considerably better. This is detection_type = 'index_url' for Fastest SEC Filings Websocket and 'anticipate' for Websocket.

Below is a comparison of anticipation on the fastest websocket versus the minimum of rss and efts from the normal websocket.

This method works by exploiting how the SEC updates after a new filing is accepted. When a new filing is accepted, a filing metadata page is immediately published. This may be seconds, minutes, or even days before the filing's original SGML file is published. The SGML file may be published seconds or minutes before the filing is released on the RSS feed.

The trouble is how do you know that this page exists?

Well, you need to guess the accession number. The accession number, e.g. 0001104659-23-015159, is made up of three numbers:

1. The cik of the company actually filing the filing. This is confusing terminology, so I will explain further. The above filing is a Tesla SC 13G/A. The two companies referenced in it are Tesla and Vanguard. Neither have CIK "0001104659". That is the cik of company used to actually submit the filing to EDGAR.
2. The year. Well, usually the current year.
3. The sequential sum of filings that thhe company that actually submitted the filings has filed this year. Well, most of the time. Also the sequence might jump randomly due to filings not shown to the public.

There is one other piece of the puzzle. Ten filers make up 40% of filings. From Who Submits SEC Filings Over Time .

So for those filers, a rudimentary algorithm comes down to:

1. Get history of filers
2. Predict whether sum is +1, -1, +2,...

Note: most people (and generative AI) think that cik is needed for a SEC filing index page. This is not true. When I open sourced The fastest way to get SEC filings in January 2026, several trading firms reached out because they had been trying to crack the problem while including cik. This is expensive, requiring the leasing of massive numbers of IP addresses.

Note 2: Gabriel Brull, PhD @ Boulder, did some poking around sec.gov IP logs mid 2026. I believe he found evidence of companies attempting to use this method on a very limited (ineffective) scale. If you go looking now, you should find evidence of my approach.

Even faster?

Here are the second day benchmarks for Fastest SEC Filings Websocket. There is considerably room to improve.

For example, the RSS feed begins emitting filings at 6:00 AM. and stops by midnight. From Reverse Engineering How the SEC's EDGAR Works.

However about 10% of filings have acceptance datetime between midnight and 6:00 AM. This is when their metadata page is created.

This means that overnight, one can be more generous with anticipation guesses. Using the pool of guesses to try rarer ciks and combinations.

Another way is to use a smarter model/algorithm that can incorporate:

1. How companies batch together their filings.
2. How the SEC's system handles load. I've observed that the SEC seems to have two ways of processing filings. (i) an instant on demand worker, and (ii) a worker on a consistent schedule. I believe (ii) is triggered when the SEC is under significant load or when a filing OOMs the instant worker.

The final way (ofc) is to optimize the rss feed by triggering the RSS feed from more locations.