Regulatory Reporting Pipeline
A data pipeline whose output goes to a regulator, where correctness, reproducibility and demonstrable lineage matter more than latency or elegance.
These pipelines have a different quality bar from analytics, and treating them as ordinary reporting is how firms end up restating submissions.
The properties that define them. Reproducibility: the exact figure submitted must be regenerable months later, which means the input data as it stood at the reporting moment must be retained, along with the code and configuration version that produced it. Point-in-time correctness is a hard requirement, not a nice one, and it is why immutable snapshots and versioned transformations appear in these designs.
Lineage: for any submitted number, you must be able to trace it to source records through every transformation. Regulators ask this directly, and an answer assembled by hand after the question takes weeks.
Controls and sign-off: reconciliation against source systems, variance checks against prior periods, and a documented human attestation, since a person is accountable for the submission.
Correction handling: restatements happen, and the pipeline must support producing an amended submission with a clear record of what changed and why.
The architectural consequence is that these pipelines should be separated from the general analytics estate, even at the cost of duplication. Sharing transformation logic with dashboards means every optimisation someone makes for a chart is a change to a regulated calculation, and the change control that implies is not what a BI team signed up for.