Most of the data an investment team depends on arrives on someone else’s schedule. A vendor’s file lands by SFTP before the open; an API refreshes after an economic release. When a delivery is late or incomplete, or a vendor quietly restates its history, the first sign is usually a number in a model that looks wrong, and by then nobody can say what the feed contained that morning.

I set up checks that watch each feed from the outside, timed to when each delivery is due. They record what arrived and when, compare it with what should have arrived, and keep the evidence. I explain how in Checking whether your data feeds deliver what you pay for.

What the checks catch

  • A delivery that hadn’t arrived by its deadline, with the last check that lacked it and the first check that found it.
  • Records missing from the expected set, such as a ticker absent from a constituents file or a series that stopped updating.
  • History that changed without notice: past values that differ from what the feed delivered before.
  • Changes to format, units or identifiers that would break the code reading the feed.

Each finding names the file or request, the times it was checked, and the data behind it. A hypothetical example: a daily prices file due at 6:00 a.m. arrived at 7:40, and 212 of its 3,100 rows repeated the previous day’s closing prices.

A record of what you received

Because the checks keep what each delivery contained and when it arrived, you build your own history of the feed as it was delivered. When a vendor restates its history, a backtest run on the restated data uses numbers you didn’t have at the time. With the delivered history, you can run it on what you actually received. We agree beforehand which data the checks may keep under your vendor contracts.

If you sell data

The same checks work from the other side. With the access a customer has, they show what your customers receive, which internal dashboards can miss: last month’s figures served from a cache, or an endpoint that missed an update. A hypothetical example: a monthly series due at 8:30 a.m. was missing from its observations endpoint in the 8:45 and 9:00 checks and present at 9:15, with all three responses attached.

How it’s set up

Each expectation comes from outside the feed: the delivery schedule in your contract, the coverage you pay for, a release calendar, or another source for the same data. An expectation built from the feed itself could never catch a record the feed failed to send.

You provide access to the feeds, through credentials or the location where files land, the delivery terms you’re paying for, and someone who knows what each feed should contain. We agree where the checks run and how credentials are stored. Before the review starts, I run the checks against cases with known answers, such as a past late delivery, to confirm they catch what they should.

A check sees a feed at one moment, so the last check without a delivery and the first check with it bound when it arrived; the exact minute stays unknown. A check that didn’t run is a gap, and the report says so. A late vendor can be told apart from a late source only when the source’s own release time is known.

Afterward

The review ends with a report of every finding and its evidence, a table of every check that you can export, the configuration for running the checks again, and a walkthrough with your team. A review can finish without finding a problem. The checks can keep running afterward, with alerts once you’ve decided who receives them and how quickly they should respond. Fixing a vendor’s pipeline isn’t part of this; the evidence is what you take to the vendor.

Message me on LinkedIn with the feeds you rely on, when each is due, and any delivery problems you’ve already had.