Congress Trade Tracker

A searchable database of U.S. House and Senate stock trades, built directly from the government's own disclosure filings — no third-party API in between, and fully cloud-hosted (works even when your own machine is off).

How it works

Members of Congress must disclose stock trades within 45 days via a Periodic Transaction Report (PTR).

House — filed as a PDF with the Office of the Clerk:

1. Downloads the Clerk's public yearly index (disclosures-clerk.house.gov/public_disc/financial-pdfs/{year}FD.zip), which lists every filing and its DocID.
2. Downloads each PTR PDF (.../ptr-pdfs/{year}/{DocID}.pdf) and extracts the transaction table (asset, ticker, buy/sell, dates, amount range) with a regex-based parser tuned to the Clerk's PDF layout.

Senate — filed as an HTML report with the Office of Public Records:

1. efdsearch.senate.gov blocks plain HTTP requests at the network edge (Akamai), even with a real browser user-agent — the same wall that ended the original Senate Stock Watcher project — and also blocks Playwright's bundled Chromium build specifically. Getting past it needs Playwright driving a real, separately-installed Chrome build (channel: "chrome"), which is what ingest/src/ingest/senate/browser.ts does.
2. That browser accepts the site's access agreement, paginates the DataTables-based PTR search results, and opens each report.
3. Electronic reports are parsed directly from their HTML transaction table. Paper/scanned filings have no such table — ocrPaperReport.ts instead OCRs the scanned page images (Tesseract.js) and reconstructs the transaction grid by classifying each checkbox "X" mark against the known column positions of the standard Senate PTR schedule. Filings that don't match that template (an older layout with a different, wider set of dollar brackets was in use through at least 2024) are declined rather than risk misreading a mismatched grid, and stay parse_status = 'unsupported'. Rows recovered this way are stored as parse_status = 'ocr' — a genuinely less certain read than text-native extraction, and flagged as such everywhere they appear in the UI (an "OCR" badge, linking to the original scan) rather than presented with the same confidence.
4. Senate filings carry no district-style key, so senators are matched to members_reference by a synthetic SEN:{normalizedlastname} key instead of the real state_district join House uses — see normalizeLastName.ts.

Both chambers share the rest of the pipeline:

3. Stores everything in a Postgres database (hosted on Neon).
4. A Next.js site (hosted on Vercel) serves the search UI and the REST API (as Next.js API routes) straight off that database, with a House / Senate / Both toggle (defaults to House).
5. A scheduled GitHub Actions workflow re-runs both ingests every 4 hours, so the dataset stays current with nothing needing to run on your own machine.
6. Separately, each member's official photo and party are synced from the public unitedstates/congress-legislators dataset into a members_reference table — House by state_district, Senate by the synthetic last-name key above. Photos are hotlinked from congress.gov's own CDN.
7. Also separately, syncMarketCaps.ts enriches trades with the current market cap of the company traded (not a historical value as of the trade date — a free-tier API has no practical way to provide that), via Finnhub, on a monthly schedule (market cap doesn't move meaningfully day to day the way filings do). Most House OCR rows have an asset name but no ticker, so a one-time-per-name search step resolves a ticker from the name first — accepting only an exact company-name match, since a fuzzy guess here would silently attach the wrong company's market cap to a trade. A trade whose ticker (direct or resolved) isn't found, or isn't a public company Finnhub has a cap for, shows as Undefined rather than guessed at.
8. Once a day, sendDailyReport.ts emails a rollup (via Resend) of everything the pipeline touched in the preceding 24 hours — filings split into successful (a transaction was recovered) vs. undefined (nothing could be extracted), plus how many new transactions were added.
9. After every ingest run, sendAlerts.ts emails CongTrade Pro subscribers whose saved alerts match anything that just arrived. The matching SQL is not written there: it comes from , the same module the account screen uses to an alert before it's saved — one implementation, so a preview that promised 12 matches can't quietly deliver a different 12. Each alert keeps a ledger of what it has already sent, keyed on a hash of the trade's content rather than its row id, because re-ingesting a filing deletes and reinserts all of its rows: an id-keyed ledger would re-send a member's entire filing every time its parse improved.

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗