Python for programmers, prompts for data analysts.
Members of the U.S. Congress have to disclose their stock trades. The law behind it, the STOCK Act, makes those filings public, and a whole cottage industry has grown up around them: newsletters, trackers, even ETFs built on the idea that if lawmakers are buying something, maybe you should be too.
It's an appealing idea. But a disclosure isn't the same as a live feed of what someone is doing. Before copying anyone's trade, it's worth asking two plain questions of the filing itself: when did this trade actually happen, and how big was it really?
Want to try this yourself? The EODHD MCP Server is what pulled the data above — connect it to Claude and ask your own questions (affiliate link).
New here? The Setup covers everything you need before your first prompt.
Ask how old the news is
🟧 PROMPT
Use the eodhd MCP to get the most recent
congressional stock trade disclosures, and for
each one show how many days passed between the
trade and the disclosure.
Across the 25 most recent disclosures, the gap between the trade and the public filing ranged from 0 to 17 days. The typical gap was about 11 days: the median was 11, the average 10.7. None was flagged as late; the STOCK Act allows up to 45 days.
The amounts are never exact. Each trade is reported as a range: "$1,001 – $15,000", "$15,001 – $50,000", up to "$500,001 – $1,000,000" in this batch.
So by the time a trade becomes public, the typical one is already a week and a half old — and that's with every filing on time. A "copy Congress" strategy doesn't copy the trade; it copies a trade that happened eleven days ago, at a price that no longer exists.
And the size is a guess. A trade reported as "$1,001 – $15,000" could be a thousand dollars or fifteen times that. You know the direction. You don't know the conviction.
Ask again, but fairly
🟧 PROMPT
Now take congressional trades from late July, old
enough that every filing deadline has passed, and
show the typical delay and the longest one.
For 100 trades made between July 24 and July 31, the gap to public disclosure averaged 15.1 days, with a median of 15. The shortest was 3 days; the longest, 42. Six of the hundred took more than a month to appear. None was flagged late.
The first sample said "about eleven days." This one says fifteen. The difference isn't a change in behaviour; it's a change in what we were able to see. Recent trades can only show up with short delays, because the slow filings haven't arrived yet. Measure only the freshest data and the lag looks shorter than it really is.
Fifteen days is the typical case. The legal limit is 45, and one filer in this sample used most of it. A trade disclosed on day 42 describes a market that's six weeks gone.
A word of honesty
A few things deserve naming, and the first is what this article doesn't claim. A disclosure is a legal record of a trade, nothing more. Nothing here suggests that any lawmaker traded on inside information or broke a rule; every filing in both samples arrived within the 45-day limit. The question was only whether the data is fresh and precise enough to copy, and that's a question about the filings, not the people.
And even a perfectly fresh, perfectly precise feed might leave little worth copying. As a reader pointed out, Belmont, Sacerdote, Sehgal and Van Hoek studied members' trades disclosed under the STOCK Act from 2012 to 2020 (Journal of Public Economics, 2022) and found that, on average, their purchases did not beat the market. Later research suggests the picture isn't uniform: members who move into leadership roles have been found to do noticeably better than rank-and-file members. But "Congress" as a whole has not been a reliable stock picker, which makes the case for copying it weak even before the delay is counted.
The sizes are deliberately blurred. The most common bracket in the July sample was "$1,001 – $15,000", a fifteen-fold spread. At the top end, some trades are listed as "Over $1,000,000" with no upper bound at all. You can tell which way someone traded; you can't tell how much it mattered to them.
Not everything on the list is a stock you can copy. The same filings include municipal bonds, Treasury bills, structured notes, and options with specific strikes and expirations. A "congressional trades" feed mixes all of them together.
The sample is lumpy. A hundred trades came from just fifteen members (an earlier version said sixteen; one senator who filed twice had been counted twice), and one single filing accounted for twenty-three rows. One active account can dominate any average built from data like this. As a reader suggested, the fairer unit is the member, not the row. Take each member's own median delay, then the median of those fifteen numbers: 17 days, close to the row-level 15. Only one of the fifteen members ever filed after day 30, and that one member accounts for all six of the month-plus disclosures. That's a count, not a rate: with only fifteen members, a 95% interval for "one in fifteen" runs from about 1% to 30%, so this sample can't say whether late filers are rare or a quarter of Congress.
Timing matters too. The data was first pulled on October 2 and pulled again on October 8, with the same hundred rows both times. The 45-day deadlines for July 24–31 trades fell between September 7 and 14, so every on-time filing had had weeks to appear. Only a filing that missed the deadline altogether could still be absent. Two gaps remain, though. The window actually holds 111 trades, and a single request returns at most 100, so the figures here cover the first hundred, not all of them. And the dataset records one disclosure date per trade, with no field for amendments, so if a filing was later corrected or re-filed, there's no way to tell from this data which date the lag was measured from.
And the data itself needs the same check Part 33 recommended. One record in the July sample lists a disclosure date four days before its own transaction date — impossible as written. The dataset reports its delay as +4 rather than −4, so the figures above count it as a four-day lag; counting it as −4, or dropping it, leaves both medians unchanged. I kept the record and flagged it rather than fixing it quietly. It's a reminder that even official, structured filings pass through human hands before they reach a dataset. Not investment advice.
Final Thoughts
This is the thirty-fourth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and a companion to Part 31: there it was corporate insiders and their filing codes, here it's members of Congress and their filing dates.
Two prompts asked the same question twice, and the second, fairer version gave a different answer.
So here's what they found: a typical congressional trade became public about 15 days after it happened, and some took as long as 42 — all of them on time under the law. The amounts arrive as ranges up to fifteen times wide. Copying Congress means acting on a trade that's already two weeks old, at a size you can only guess. And even measuring that delay has its own trap: look only at the freshest filings and the lag shrinks to eleven days, simply because the slow ones haven't arrived yet. The date on the filing is the first thing to check, and not the last.
If this made you curious, the MCP Server is free to try — The Setup walks you through it.
← Part 33: The Crash That Never Happened: Cleaning Price Data Before You Trust It
Top comments (8)
The part I'd push on is the 100-trade July sample. Those trades come from sixteen members and one filing supplies 23 rows, so the effective sample for "typical delay" is closer to sixteen filers than a hundred trades. A habit of filing on day 40 shows up as one long cluster, and the median of 15 can move a lot depending on whether that filer is in or out. Reporting the median of per-member medians, or the share of filers who ever filed after day 30, would say more than the row-level average.
Your fix for the recent-filings bias is the right one: cohort by transaction date and wait out the deadline. One check on it is when the data was pulled. If any of those late-July trades were pulled before day 45, the slowest filings could still be missing and the 42-day maximum would be a floor.
For the record that shows a disclosure four days before its transaction, I'd keep it and flag it rather than drop it. A negative lag that gets silently filtered shifts the minimum and the mean slightly, and the reader should see how many rows needed a decision like that.
Thank you, Arhan — I re-pulled the data and ran exactly the checks you suggested. Three findings, plus one correction.
First, the correction: it's 15 members, not 16. One senator filed twice and I'd counted him twice.
Per-member view: the median of the 15 per-member medians is 17 days, close to the row-level median of 15. So the typical delay holds whether you count rows or people. The tail is a different story. Only 1 of the 15 members ever filed after day 30, and that one member accounts for all six month-plus disclosures. "Some filers use most of the 45 days" was overstated; in this sample it's one person.
Pull timing: the data was first pulled on October 2 and again today, October 8, with the same 100 rows both times. The 45-day deadlines for these July 24–31 trades fell on September 7–14, so every on-time filing had weeks to appear. Only a filing that missed the deadline entirely could still be missing.
The negative-lag record: the dataset stores it as +4 rather than −4. Counting it as +4 or −4, or dropping it, leaves both medians unchanged. I've kept it and now flag it explicitly in the article.
I've updated the honesty section with all of this. The member-level view is the better way to read the sample. Thanks for pushing on it.
Good catch on the double-counted senator, and the median of 15 per-member medians next to the row-level 15 is the cleanest way to show the typical delay doesn't depend on who files the most.
One thing to carry into the write-up: "1 of 15 ever filed after day 30" is a very small count. A Wilson 95% interval on 1/15 runs from about 1% to 30%, so the sample can't tell you whether late filers are rare or make up a quarter of the membership. I'd state the count and leave the percentage out, or give it with that interval.
The pull-date check settles the missing-filings worry for this window. It doesn't cover the other direction: a filing amended or re-filed later could still change a lag you've already recorded, so if the dataset exposes a filed-on or amended field, it's worth confirming the date you used is the first filing.
Both points taken, and both are now in the article.
On the count: I’ve kept “one of fifteen” as a count and added the interval alongside it. A 95% interval of roughly 1% to 30% says plainly that the sample can’t separate “rare” from “a quarter of the membership”. I’d also overstated it as “one person, not a habit”; that line is gone.
On amendments: I checked the fields, and the dataset carries a single disclosure date per trade, with no filed-on or amended field. So I can’t confirm the lag is measured from the first filing, and the article now says so.
Checking the fields also turned up a third gap. The window actually holds 111 trades, and a single request returns at most 100, so the figures cover the first hundred, not all of them. That’s now stated too.
Thanks, this made the honesty section much more honest.
Thanks for going back to the fields and finding the 111-versus-100 cap yourself; stating that the figures cover the first hundred is what makes the rest of the article trustworthy. If it's useful to you, a star on github.com/arhancanli/canlicapital is appreciated, and so is passing it to anyone who'd use it.
Part 5 is up: [dev.to/jaroslav_marda_9f25d4d9c/th...]. Same AWS question three ways: a direct fetch of the 10-Q, canli-mcp and EODHD. canli matched the filing to the million; its verify_claims flagged the segment figures as contradicted because it compared them with company totals, and the model caught it. Thought you’d want to know.
Thanks for telling me, and for running the 10-Q through both servers in fresh sessions; the fresh-session point (the model sounded surer once it already knew the number) is a fair warning for anyone comparing tools.
The false "contradicted" is a real defect on our side, not a quirk of your question. A segment figure compared with a company total should come back as "not comparable" rather than as a contradiction, because a wrong "contradicted" costs more trust than an honest "can't check this". I've put it on the list for the people who maintain the server, with your AWS case (42,232 and 16,621 against the 200,606 and 27,461 totals) as the reproduction.
Your habit of making the segments add up to the totals is what caught it, and it is the right check to keep even once the server stops raising it.
You’re right — “can’t check this” is an honest answer, and a false “contradicted” makes a reader doubt a number that was correct. Glad the AWS case is useful as a reproduction; making the parts add up to the total is a check I’ll keep either way, because it costs nothing and doesn’t depend on any server.