Time-series data occupies an unusual position in regulated data infrastructure. Its volume is large. Its query patterns are specialised, dominated by range queries, downsampling, gap-filling, and rate-of-change calculations. Its retention requirements are long. And its regulatory obligations are specific. BCBS 239 requires risk data to be accurate, complete, and reproducible at any historic point in time, which imposes immutability requirements that most time-series databases do not enforce by default.
Time-Series Database Architecture for Financial Data
TimescaleDB extends PostgreSQL with hypertable partitioning and native time-series functions while inheriting PostgreSQL's transactional guarantees, ACID compliance, and mature access control model. For regulated financial data, this PostgreSQL foundation provides compliance properties that native time-series databases lack: row-level security, column-level privileges, logical replication, and audit logging through pgAudit. A risk metrics platform built on TimescaleDB can use the same access control model as the rest of the PostgreSQL-based data estate, simplifying the compliance audit surface.
InfluxDB and its Telegraf-based data collection ecosystem excel at infrastructure monitoring and IoT sensor data ingestion. For financial regulatory data that requires point-in-time reproducibility, InfluxDB's default write semantics present correctness risks because last-write-wins for duplicate timestamps. InfluxDB 3.0 with Apache Arrow and Apache Parquet storage addresses some of these concerns, but the access control model remains less mature than SQL-based alternatives. For financial data under BCBS 239 or MiFID II where data accuracy is a board-level accountability, the performance benefits of InfluxDB must be weighed against the compliance tooling maturity of SQL-based time-series databases.
Point-in-Time Correctness for Regulatory Reconstruction
BCBS 239 Principle 2 states that a bank should be able to produce risk data aggregation results as of any historic date, including the ability to reconstruct what the risk figures were at the time they were reported, not what they would be if calculated today with current data. This bi-temporal data requirement distinguishes regulatory time-series from operational time-series: operational data cares only about the latest value; regulatory data must preserve both when something happened and when it was known to the system.
Implementing bi-temporal semantics in a time-series database requires storing each data point with both an event timestamp and a system timestamp, and querying by both dimensions when reconstructing historic regulatory reports. TimescaleDB handles this naturally as a multi-column partitioned table. For InfluxDB, bi-temporal data requires storing event time in a tag field separate from the native timestamp. The regulatory reporting pipeline that reconstructs last quarter's LCR as of market close on a specific date requires the bi-temporal query pattern to be implemented correctly or the reconstruction capability does not exist.
Retention Policy Architecture for Long-Term Compliance
Time-series database retention policies typically reduce storage costs by automatically deleting old data. For regulated financial and operational data, retention policies must align with regulatory minimums rather than operational convenience. MiFID II requires seven-year retention for transaction records. SEC Rule 17a-4 requires six to seven years for broker-dealer records. NERC CIP requires six-year retention for bulk electric system event data. These retention periods exceed the default retention configuration of every major time-series database.
The architecture that satisfies both cost efficiency and regulatory retention is a hot-warm-cold tier progression. The hot tier retains the operational window required for current analytics. A nightly job copies data approaching the end of the hot retention window to a warm tier of compressed Parquet files in object storage, queryable through Athena, BigQuery, or Databricks. The cold tier holds data for the full regulatory retention period. Each tier transition is logged as an audit event. The warm and cold tiers must be queryable for regulatory reconstruction, not just archived for disaster recovery purposes.
Energy and Utilities: NERC CIP Time-Series Obligations
Operational technology time-series data in energy and utilities carries NERC CIP obligations that differ from financial regulatory requirements. NERC CIP-007 requires that Bulk Electric System cyber assets log security-relevant events with sufficient detail to support incident investigation. NERC CIP-009 requires that recovery time objectives for BES Cyber Systems be defined and tested. The time-series data from industrial control systems serves both operational and compliance purposes.
OSIsoft PI System, now AVEVA PI System, is the dominant historian platform for energy utilities, with a proprietary data model and a specific compliance evidence package for NERC CIP assessments. Integrating PI System data with enterprise analytics platforms requires the PI OLEDB Provider or the PI Web API, which have specific configuration requirements for encrypted data transport under NERC CIP requirements. Engineering teams that connect PI System to cloud analytics platforms must verify that the integration path does not create a compliance gap in the NERC CIP electronic security perimeter.
Data Quality and Immutability Controls
Time-series data quality failures in regulated contexts have a specific character: they are often silent and retrospective. A sensor reporting incorrect values due to miscalibration may produce months of plausible-looking data before the error is detected. For regulatory time-series data, immutability controls are as important as the quality checks that prevent errors at ingestion. The time-series database architecture for regulated data must distinguish between immutable raw time-series and corrected time-series, with full lineage from correction back to the correction authorisation event. The regulatory reconstruction request that asks what the risk figure was at a specific point in time must be answerable from the raw immutable record, not only from the corrected view.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.