Point-in-Time Data: Why Every Record Needs Two Timestamps

How source and processing timestamps on every Bourse API record prevent look-ahead bias in backtests and show how fresh insider and Congress data really is.

A backtest that uses a trade date as if the trade were known that day is wrong. Congress members can report up to 45 days later, Form 4 arrives within two business days, and a data vendor needs time to parse it. Every record in the Bourse API now carries two timestamps so you can model exactly what was knowable and when.

Key takeaways

• filed_at_source_timestamp: when the source published the filing, for example the SEC acceptance time of a Form 4 or the disclosure date of a Congress report. It is null when the source gives no time.
• processed_by_bourse_timestamp: when Bourse stored the record, in UTC.
• The difference between the two is our processing delay, measured per record instead of promised on a landing page.
• Use processed_by_bourse_timestamp (or the filing time) as the "available at" time in backtests, never the trade date.

Example

`` { "ticker": "NVDA", "transaction_date": "2026-11-07", "filed_at_source_timestamp": "2026-11-10T21:04:05Z", "processed_by_bourse_timestamp": "2026-11-10T21:31:40Z" } ``

Here the trade happened on Friday, the SEC accepted the filing on Monday evening and Bourse stored it 27 minutes later. A strategy could act on Tuesday's open at the earliest.

Notes

Some sources publish only a date (Congress disclosures, OGE reports); those values are dates at midnight UTC. Records stored before November 2026 in a few datasets have no processing time. Details per dataset are in the API reference and on the developer page.

Bourse provides financial data and editorial information, parts of which are generated by AI. This page is for general education only. It is not personalised investment advice or a recommendation to buy or sell any financial instrument. Make your own decisions.