SEC Form 4 Insider Cluster-Buy Monitor

One insider buying is a data point. Several different officers, directors or 10%-owners of the same company buying in the open market within a few days of each other is a signal — and there is no existing Apify Actor that watches for it. Everything else in the SEC Form 4 space is a one-shot list or a single-trade tracker.

This Actor watches the companies you pick and tells you exactly when that cluster forms.

How it works

1. For each company (cik), fetch the official SEC EDGAR Submissions API — no scraping, no key, just a descriptive User-Agent (SEC's fair-use policy).
2. Find new Form 4 filings since the last check, fetch and parse each one from EDGAR Archives.
3. Keep only filings that are: a single reporting owner (not a joint/institutional group filing — see "Honest limits"), who is an officer, director, or 10%-owner, with at least one open-market purchase (transactionCode = P, acquiredDisposedCode = A — not an award, option exercise, gift, or sale).
4. Keep a rolling window of these purchases per company. When N distinct insiders (default 2) have bought within W days of each other (by transaction date, default 5), that is a cluster — you get one row with every purchase behind it.

Input

{
  "monitorId": "my-watchlist",
  "userAgentContact": "you@example.com",
  "watches": [{"watchId": "acme", "cik": "320193"}],
  "clusterWindowDays": 5,
  "minDistinctInsiders": 2
}

Output row

Field	Meaning
distinctInsiders	how many different people bought
windowStart, windowEnd	transaction-date span of the cluster
totalShares, totalValueUsd	summed across the cluster (null components are omitted, not zeroed)
purchases	each purchase: insider name, title, transaction date, shares, price

A cluster that later grows (a new insider joins) is delivered again as a new, larger event — that is a materially stronger signal, not a duplicate. The exact same set of purchases is never billed twice.

Pricing

Pay per event:

• insider-cluster-detected — charged once per newly-formed or newly-grown cluster, after the row is written to the dataset. No charge for runs that find nothing.

What happens if a run is interrupted. This Actor keeps a durable four-state delivery ledger (intent → written → charge started → billed) in its own per-monitor key-value store. The honest guarantee, stated precisely rather than rounded up: delivery to the dataset is at-least-once — a crash between a confirmed write and the transport acknowledging it can produce a duplicate row on retry, which we accept because a duplicate row costs you nothing. Charging is at-most-once, with a tracked uncertain window: a row is never billed before it is confirmed written, never billed twice for the same content, and the one case the ledger cannot resolve on its own — a crash inside the charge call itself — is never re-charged automatically; it is counted in the run's coverage record (chargeUncertainRows) for manual reconciliation instead of being guessed at.

Honest limits

• Group/institutional filings are excluded. Some Form 4s are filed jointly by several related entities under one accession number (measured live: a single filing by Goldman Sachs group entities covering 8+ affiliated filers). The raw filing gives no reliable way to attribute individual transactions to individual filers in that case, and most such filings are funds, not people with Section 16 insider status anyway. This Actor only processes single-owner filings.
• P (open-market purchase) only. Grants, awards, option exercises, gifts and sales are not purchase signals and are excluded, even though they appear in the same filings.
• Calendar days, not trading days, for the cluster window — simpler, and the difference does not matter at the window sizes this product uses.
• New watches see a live window, not history. The window is pruned to the last clusterWindowDays on every run, so a brand-new watch cannot retroactively "discover" an old cluster from months ago — only purchases whose transaction date is genuinely recent ever count.

Coverage record

Every run writes a coverage record: per-watch status and reason, new Form 4 filings seen, fetch errors (filings that failed to parse are retried next run, never silently dropped), current window size, clusters delivered and billed. If part of the run failed, the record says which part and why.

Author: OmniCoder (https://t.me/OmniCoder)