Skip to content
Case Study · Financial Services

Identity data that answers the regulator's questions

FoundryOS put a bitemporal data store at the heart of their identity platform, so every compliance question is just a SQL query, not a forensic exercise.

FoundryOS is building the future fabric of financial services. Their composable platform enables banks and fintechs to configure and deploy regulated customer journeys in a fraction of the time typically required. Identity lifecycle management sits at the centre: onboarding, KYC, risk profiling, and ongoing monitoring all flow through a single platform.

As FoundryOS put it on their own blog: when Compliance or the Regulator asks about historic customer data, the answers are often buried in audit tables across different systems, or in process state. Piecing it all together is a massive, often manual challenge. They didn't think it should be that hard.

"What did you know when, and how is that maintained as time moved on? On what basis did you make the decisions you made at that time?"

Identity data is inherently temporal. Documents expire. Risk classifications change. Corrections propagate backward through a customer's history. Satisfying both the operational requirement (current customer status) and the compliance requirement (what was known and when) typically requires bespoke versioning logic, shadow tables, or a parallel audit database. All of these carry ongoing maintenance burden and the risk of divergence between what the system shows now and what it actually recorded at the time.

FoundryOS took a different approach: a bitemporal data store at the heart of the platform. Every piece of identity data (customers, counterparties, and anyone who interacts with them) is stored with two dimensions of time: when the event occurred (valid time) and when the data was stored (system time). This means the platform can always provide:

  • The most accurate data possible as you know it now
  • Data as you knew it at any point in time
  • When and why the data changed

Building on XTDB meant that full bitemporal history was automatic from day one. Every status change, document update, and risk reclassification is recorded on both valid time and system time without a single line of custom history logic. Any compliance question is answered by querying the database directly. No reconstruction from logs, no reconciliation against a shadow table, no bespoke audit export.

0
lines of custom history logic
Day 1
full bitemporal audit history from first write
SQL
standard query interface for all compliance questions

FoundryOS's platform approach means that the same bitemporal foundation underpins every product built on top, not just KYC. From onboarding through to ongoing monitoring, every decision is backed by the most accurate data available. As new components are added, the audit and compliance properties are inherited automatically, with no per-feature instrumentation required.

FoundryOS are design partners of XTDB 2.0. Read more about their approach to identity data on the FoundryOS blog.