Regulatory reporting pipelines carry a unique characteristic that distinguishes them from operational analytics: the output is submitted under attestation to a regulator who has examination authority. A COREP capital adequacy submission error is not an operational incident that can be quietly corrected in the next run. It is a regulatory filing that may require notification, correction submission, and in material cases, supervisor engagement. The CRO who signs the ICAAP attestation and the CFO who certifies the FR Y-9C are personally accountable for the accuracy of data that their engineering teams produce. Building regulatory reporting pipelines to the evidentiability standard that these attestations require is a distinct engineering discipline from building operational analytics pipelines.
Source-to-Report Data Lineage
BCBS 239 Principle 2 states that a bank should be able to capture and aggregate risk data in a timely manner from across the organisation, with complete data lineage from source to report. For a capital adequacy report, this means being able to answer: for every number on the COREP submission, which trades produced it, which system were those trades in, which transformation steps produced the aggregated figure, and which version of the regulatory technical standard was applied in each step. This lineage chain must be reconstructable not just for the current report but for any historic report date within the regulatory retention period.
dbt lineage graphs, Apache Atlas lineage maps, and OpenLineage event streams each capture parts of this chain. The integration challenge is connecting source system change data capture events to the data warehouse ingestion layer, from the ingestion layer to the transformation models, from the transformation models to the reporting aggregation layer, and from the reporting layer to the submission artefact. Each handoff between systems is a lineage gap unless explicit lineage metadata is emitted at each step. An OpenLineage-instrumented dbt pipeline that connects to an Atlas lineage graph populated by CDC event metadata closes the source-to-report lineage gap, but only if the instrumentation is implemented correctly across all components.
Reconciliation Architecture
Regulatory reports must reconcile against source system totals. A capital calculation that produces a total RWA figure must be reconcilable to the sum of individual position RWAs from the front-office risk system. A FINREP balance sheet must reconcile to the general ledger. Reconciliation failures are themselves regulatory findings that must be explained, documented, and remediated.
The reconciliation architecture runs in parallel with the reporting pipeline and must complete before the submission deadline. A reconciliation framework that queries both the regulatory report output and the source system independently, computes the difference, and routes differences above a materiality threshold to a break investigation workflow implements the control. Differences below materiality are documented as rounding or timing differences in a reconciliation sign-off record. Differences above materiality halt the submission until investigated and either resolved or submitted with documented explanation. The reconciliation results including break amounts, investigation conclusions, and sign-off timestamps are the evidence that demonstrates the attestation was supported by a functioning control.
Regulatory Technical Standard Version Control
Regulatory reporting requirements change. COREP templates are updated with each CRR amendment. FR Y-9C instructions are revised annually. MiFID RTS amendments change field definitions and validation rules. The regulatory reporting pipeline must produce correct output against the version of the regulatory technical standard in effect at the reporting date, not the current version. A pipeline that was rebuilt to comply with a standard update must still be able to reproduce historic reports under the prior standard for regulatory reconstruction requests.
Version controlling the transformation logic that maps source data fields to report fields, and tagging each version with the regulatory technical standard version it implements, is the technical requirement. The deployment process for standard updates must maintain the prior version as a branch that can be executed against historic data. For organisations using dbt, semantic versioning of the reporting model project with version tags tied to regulatory standard versions provides the version control structure required.
Timeliness Monitoring and SLA Architecture
Regulatory submissions have fixed deadlines. CCAR results are submitted by specified dates. MiFID transaction reports are due by T+1 close. COREP quarterly reports have national competent authority deadlines. Missing a deadline is a regulatory event with notification and potential fine implications. Regulatory reporting pipeline monitoring must distinguish between data availability delays, processing delays, and validation delays.
SLA monitoring for regulatory reporting pipelines must be configured conservatively relative to the submission deadline: alerting when the pipeline is at risk of missing the deadline, not after it has been missed. A COREP submission with a 17:00 local time deadline must have pipeline SLA alerts that fire by 14:00 if the pipeline has not completed successfully, providing three hours for investigation and manual intervention if needed. Incident management routing for regulatory pipeline SLA breaches must reach the regulatory reporting operations team, not just the general platform operations team, because regulatory pipeline failures require coordinated response involving reporting officers and potentially regulator notification.
Submission Artefact Management
The submitted regulatory report, whether an XBRL instance document, CSV submission file, or API call payload, is itself a regulated record that must be retained for the applicable retention period. Each submission artefact must be stored with its submission timestamp, the submission confirmation from the regulator or collection agent, the reconciliation sign-off record, and the version of the pipeline and regulatory standard that produced it. An artefact management system that stores all of this metadata alongside the submission file creates the complete submission record that regulatory investigation and internal audit requires. Without this, the organisation can demonstrate that a report was submitted but not definitively that the submitted content matched the reconciled data or was produced by the correct version of the pipeline: exactly the questions that regulatory investigations ask.
EU AI Act: What CTOs Actually Need to Do Before August 2026
DORA Is Live. Here's What 'Operational Resilience' Means for Your Codebase
FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant
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.