How ebomi works, and where the data comes from

Where the data comes from

Every alert originates from public filings on the U.S. Securities and Exchange Commission's EDGAR system. Corporate insiders, meaning officers, directors, and holders of more than ten percent of a company's stock, must report their trades on Form 4. ebomi reads the EDGAR current-filings feed for Form 4 submissions and downloads each filing's complete submission text and header directly from the EDGAR archives. Nothing else feeds the pipeline. There is no data vendor in the middle, no private feed, and nothing you could not fetch yourself from sec.gov.

We fetch politely, in line with the SEC's fair-access guidance. Every request identifies ebomi by name and contact email in its User-Agent header, and the software refuses to start without that identification configured. Requests are smoothed through a token bucket capped by default at six per second, deliberately below the ten-per-second ceiling the SEC declares, because each filing costs several requests and the limiter should never brush the limit. If the SEC answers with a refusal, the fetcher honors any Retry-After header, backs off with increasing delays, and after repeated refusals pauses ingestion entirely for a cool-down period rather than hammering a server that has asked us to stop.

Every alert we send links to the source filing on sec.gov, so you can always check the original document yourself.

How a filing becomes an alert

1. Watch. A worker polls the EDGAR feed on a cycle measured in seconds to minutes. A separate scheduled catch-up job runs every ten minutes and re-scans the last several days of the feed, so a filing the live worker missed is normally recovered.
2. Fetch. For each new Form 4, both the full submission text file and its header file are downloaded from EDGAR.
3. Parse. The software extracts the issuer's CIK, name, and ticker symbol exactly as filed, every reporting owner with their role flags such as director, officer, or ten-percent holder, and each transaction line from the filing's non-derivative table.
4. Filter. Only open-market purchases, transaction code P, and open-market sales, transaction code S, can trigger an alert. Stock grants, option exercises, gifts, tax withholding, and the other transaction codes do not, because those are mostly compensation and administrative events rather than the discretionary trades readers are watching for.
5. Roll up. All qualifying transactions within one filing are aggregated per side into total shares and a volume-weighted average price. The average is computed only over shares that carry a filed price, and the filing's acceptance timestamp is interpreted as U.S. Eastern time and normalized to UTC.
6. Compose. Each subscriber tracking that issuer gets one alert per filing. When a filing contains both purchases and sales, the alert shows both legs, including the case where a headline purchase sits next to a larger sale, because showing only the flattering side would be misleading.
7. Deliver. The email is sent through our mail provider. Failed sends retry with exponential backoff, and an alert that exhausts its retries is set aside and kept for audit rather than silently dropped.

This path deliberately keeps nothing. It records the identifier of each filing it has already handled, so that it does not alert on the same one twice, and stores no filing content of its own. Everything in the catalog comes from the published dataset described below, and the two are kept apart on purpose so that a single source is answerable for what the catalog contains.

What we store

The catalog is a mirror of a published dataset, not a by-product of the alert pipeline above. It is rebuilt from the Layline insider extract, which is itself derived from EDGAR and released under CC0, and it holds one row per submission and one row per transaction line. The alerting path described above stores no filings at all; it records only which filings it has already seen, so that it does not alert twice.

Two consequences follow, and both are stated here rather than discovered. The catalog is as fresh as the extract, not as fresh as the feed: it is refreshed daily, so a filing can appear in an alert before it appears in the catalog. And the catalog does not identify the reporting insider. The extract carries the insider's name as filed but no CIK for them, and a CIK is the only identifier that is stable across filings, so there are no per-insider pages. Rather than offer a page that cannot be trusted to mean one person, there is none.

Rows in the mirror are never edited in place. An amendment arrives as a new filing with its own accession number, and re-loading the same filing is a no-op. The table structure follows the SEC's own insider-transaction table family, the same structure used by the open insider-trading dataset published in Scientific Data by ebomi's author, with column names that track the element names in the SEC's ownership-document XML. Because the catalog now mirrors that dataset rather than merely resembling it, ebomi's records and the open research dataset line up by construction instead of by intention.

Beyond the filings themselves, we keep the account data needed to run the service: your email address, your watchlist, and bookkeeping about which alerts were queued and sent. All filing content we store is public information published by the SEC.

What this catalog does not hold

The catalog holds 3,617,570 of the 4,977,937 filings in the source extract, which is 72.7 percent. Against SEC EDGAR's own index for 2021 to 2026 it holds 83.8 percent of Form 4 filings, and that proportion is flat year over year rather than drifting.

Most of what is missing is missing on purpose. Every filing is tested against four rules before it is stored, and a filing with nothing left after them is not stored at all.

The largest of those is the product's own claim. A Form 4 that reports only derivative activity is a compensation event, and this catalog exists to separate open-market buys and sells from that machinery. Excluding those 769,458 filings is the separation, not a shortfall in it.

Source: the Layline insider extract, build of 2026-08-09, CC0-1.0. Cite as Balogh, A. Insider trading. Scientific Data 10, 237 (2023), doi:10.1038/s41597-023-02147-6.

What we do not do

• No recommendations. ebomi never tells you to buy or sell anything. Alerts report what an insider filed, with a link to the filing. Nothing here is investment advice, and the disclaimer is a design principle, not fine print.
• No black-box signals. We do not sell a proprietary score you have to take on faith. The filtering rules that define an alert are written on this page, and any analytical context we add in the future will name its method and cite the research behind it.
• No pretense of exclusive data. Form 4 filings are public the moment EDGAR posts them. What ebomi provides is speed, filtering, and readability, not privileged access, and we say so plainly.
• No trading. ebomi does not execute trades, connect to brokerages, or automate anyone's orders.
• No dark patterns. We do not sell your personal data, and paid plans can be canceled at any time to stop future charges.

The academic commitment

ebomi is built by a finance professor whose research covers insider trading, and it is run in the spirit of open science. That carries three standing commitments.

• A permanently free academic tier. Students, educators, and researchers will always have free access. This is a commitment of the project, not a promotion, and the verification mechanism for academic accounts is in active development.
• Open source. The codebase is being prepared for public release, so the pipeline described on this page can be audited line by line rather than taken on trust.
• Citable foundations. The record structure aligns with a peer-reviewed open dataset, with data on the Harvard Dataverse. If ebomi supports your research or teaching, we ask that you cite the dataset paper.

Limitations, stated honestly

• The clock starts at the filing, not the trade. Insiders generally have two business days to report a trade on Form 4, so a trade can already be days old before anyone outside the company can know about it. No alert service changes that.
• Alerts take minutes, not seconds. EDGAR posts filings on its own schedule, ebomi discovers them by polling rather than by a real-time stream, and email delivery adds its own delay. Expect minutes between a filing appearing on EDGAR and the alert reaching your inbox, sometimes longer.
• Coverage gaps are possible. The catch-up pass looks back a bounded number of days. An EDGAR outage, an extended block of our requests, or downtime on our side lasting longer than that window can leave a permanent gap in alerts under the current design. When the SEC refuses our requests, ingestion deliberately pauses rather than pushing through, and filings during a pause are picked up by the catch-up pass only within its window.
• Filings can be amended. A Form 4/A can revise or correct an earlier filing. An alert that has already been sent is not retracted or corrected, and the transaction store keeps the original and the amendment as separate rows rather than overwriting history.
• Tickers are as filed, and can be wrong. The ticker symbol in a Form 4 is typed by the filer and can be stale, misspelled, or missing. We patch known display problems with a manually maintained override list, but the authoritative identifier in the pipeline is the SEC's CIK number, not the ticker.
• Parsing has boundaries. Alerts are built from the non-derivative transaction table only. Derivative transactions such as option exercises, holdings without a transaction, and footnote text do not feed into alerts today.
• Best efforts, honestly. ebomi depends on EDGAR, on its file formats staying stable, and on email infrastructure. Any of these can fail, so alerts can be delayed, incomplete, or occasionally missed, as the terms also state.