All Resources
R-50
Technology
Bitemporal Data Isn't Optional for Regulated Workloads
Knowing what was true at a point in time, and knowing what your system thought was true at a point in time, are different questions. Regulators ask both. Most databases can answer neither.
PAR2 Labs
August 29, 2026
2 min
A bank examiner walks into a meeting and asks: what was Customer X's risk rating on the morning of March 18th — and what did the system display to the relationship manager who approved their loan on that same morning? Those are two different questions. If your database can only answer one, you have a compliance problem.
01
Valid time vs. transaction time
Every fact has two timestamps that matter:
Valid time — when the fact is true in the real world. A customer's address is valid from the day they moved in to the day they moved out.
Transaction time — when the fact was recorded in your system. The customer might have moved on the 5th but reported it on the 12th. The fact is valid from the 5th but recorded from the 12th.
These two clocks diverge constantly. Backdated trades. Retrospective corrections. Late-arriving sensor data. Insurance claims that reference an incident from last year. A single-clock model — “this is the current value” — loses the entire history of when you knew what.
02
Why regulators care
Almost every modern compliance regime — Basel III, GDPR, EU AI Act, BCBS 239 — explicitly requires demonstrable reconstruction of past system state. Not “what is true now” but “what did the system show when this decision was made.”
With a single-clock database, the only way to answer this is to keep a parallel audit log and hope it stayed consistent. With bitemporal storage, the answer is just a query: ask for the state as it stood — in the real world, or as the system knew it — at 09:30 on the morning of March 18th, and read the risk rating straight off the result.
Bitemporal storage is what you build so you don't need the audit log.
03
How Tessera does it
Every fact carries both a valid-time interval (when it was true in the world) and a transaction-time interval (when the database learned it). The engine indexes both, so a query can filter on either or both, and ask three distinct kinds of “give me history”: what was true as of a moment, what the database believed as of a moment, and what was valid across a range. The historical reconstruction isn't a separate audit log — it's the same data the application reads every day.
Audit logs are what you build when your database can't answer time-travel questions. Bitemporal storage is what you build so you don't need the audit log.
04
The hidden cost of not doing this
Most teams discover they need bitemporal data the hard way — when a regulator requests a reconstruction and they spend three weeks gluing together event logs, backup snapshots, and audit tables to produce something approximate. The cost is real; it just gets amortised across many small panics instead of one architectural decision.
05
When you don't need it
Honest answer: most consumer-facing workloads don't. If you're building a chat app, bitemporal is overkill. If you're building anything where someone might ever ask “what did the system think on date X” — claims processing, lending decisions, risk-rated trading, medical records, journalism, scientific data — start with bitemporal. It's much cheaper than retrofitting.
Key Takeaways
01
Valid time is when a fact was true in the world; transaction time is when the system recorded it.
02
Regimes such as Basel III, GDPR, the EU AI Act and BCBS 239 require reconstruction of past system state.
03
Tessera indexes both intervals, so history is an ordinary query rather than a parallel audit log.
04
Most consumer apps do not need it; anything where someone may ask what the system thought on a date should start bitemporal.
PAR2 Labs · Technology
Work With Us