FMCSA changed its data in May 2026 — your carrier script may have quietly stopped working
If you pull FMCSA data yourself — a script into a spreadsheet, a nightly job, a TMS integration — this one matters, because the failure is silent.
On 14 May 2026, FMCSA froze its legacy data tables and moved to a new registration system. The old tables still exist. They still respond. They still return well-formed data. They stopped updating.
What that looks like from the outside
A pull built before the cutover keeps running. It returns rows. It fills the spreadsheet. No errors, no warnings, no change in shape.
The data is simply frozen at 14 May 2026, and gets a day staler every day.
A silently stale scraper is indistinguishable from a working one. That is the entire problem. A pull that crashes gets fixed within a day; a pull that returns confident stale answers can run for months.
What actually changed
| Before | After | |
|---|---|---|
| Source tables | Legacy, updated daily | New system, updated daily |
| Legacy tables | Live | Frozen at 2026-05-14 |
| Date format | MM/DD/YYYY | YYYYMMDD |
| Coverage amounts | Thousands (750 = $750,000) | Dollars (750000.00) |
| Form codes | 91X, 84, 34 | BMC-91X, BMC-84, BMC-34 |
| DOT numbers | Zero-padded (04100741) | Unpadded (4100741) |
| Cancellation reasons | 9 values | 2 values |
Every one of those is a silent-failure opportunity:
- Coverage in thousands vs dollars is the worst. Merge them naively and every carrier
reads as $750 of liability — far below the federal minimum. A check for "coverage above $750,000" would flag the entire industry as non-compliant
- Form-code prefixes mean a filter looking for
BMC-91Xfinds nothing in legacy data,
and a filter for 91X finds nothing in the new data
- Zero-padding means joins silently miss
- Date formats mean comparisons produce nonsense rather than errors
How to check your own pull in two minutes
Look at the maximum date in your own data.
``sql SELECT MAX(some_date_column) FROM your_carrier_table; ``
If it is on or around 2026-05-14, you are reading frozen tables and have been for months.
Then check freshness continuously, not once:
- Assert your latest record is within a couple of days of today
- Fail loudly when it is not. A silent zero looks exactly like a quiet week
- Watch volume, not just success. Real activity runs to hundreds of filing changes on a
business day; a weekday pull returning almost nothing means the feed broke, not that the industry paused
That last point is worth dwelling on. We sampled a feed on a Sunday early on and got 17 rows — and briefly concluded the whole source was dead. Weekday volume was 300–400. Judging a feed by a weekend sample is its own trap.
The bit that is genuinely annoying
Historical data lives in the frozen tables. Current data lives in the new ones.
Neither alone is sufficient. The frozen tables hold cancellation history reaching back to 1986 — the record of whether a carrier has lapsed before. The new tables hold everything since May 2026 and nothing prior.
To answer "has this carrier lapsed before, and are they insured today" you need both, reconciled across every difference in the table above.
That is a real piece of work, and it is why a lot of tooling built after the cutover has a three-month-old view of history without saying so.
If you maintain your own pull
1. Check your maximum date today 2. Point current-state queries at the new tables 3. Keep the frozen tables for history, translating formats on the way in 4. Add a freshness assertion that fails loudly 5. Add a volume floor, with weekday and weekend thresholds 6. Snapshot each day's pull — the daily difference feeds are replaced, not appended, so a missed day is unrecoverable
Why we are writing this down
We rebuilt against both eras and hit every one of these. The coverage-in-thousands issue would have put every carrier in America below the federal minimum. The cancellation-reason mapping produced a 24% false-critical rate until we measured it properly.
None of them threw an error. All of them produced confident, wrong answers — which is the characteristic failure of this dataset and the reason to check freshness before trusting anything built on it.