One governance layer. Three regulators. Today.
BCBS 239, Basel III Endgame / FRTB and DORA were written separately, by different supervisors, in different decades. They converge on one requirement: every input to a risk, capital or reporting decision must be traceable, auditable, controllable and reproducible on demand — as system behaviour, not as documentation about the system.
The gap is not in policy. It is in infrastructure.
Most institutions still rely on data warehouses and SQL pipelines that were never designed to produce supervisor-grade governance. Patching that with documentation — Confluence pages, lineage spreadsheets updated quarterly, access-review tickets — is what generates the Pillar 2 add-ons. The supervisor finds the gap because the documentation never quite matches the system.
As of 2023, only 2 of 31 G-SIBs had achieved full BCBS 239 compliance — and that was before FRTB and DORA raised the bar further.
| Regulator / framework | Specific requirement | Status |
|---|---|---|
| BCBS 239 / RDARR | Principle 2 (data architecture), Principle 3 (accuracy & integrity) and Principle 4 (completeness) all require provable lineage and access control at the infrastructure layer — not in spreadsheets that document the lineage. | ECB supervisory finding |
| Basel III Endgame | Internal-model approval requires every capital input traceable to its source; back-testing and risk-attribution require the calculation to be reproducible. Without lineage at the data layer, the internal-model approach becomes economically unviable. | Approval-blocking |
| DORA | Every technology process must be documented, traceable and controllable — including data movement, transformations and access events. The audit artefact is the system, not the spreadsheet describing it. | In force · Jan 2025 |
Banks pay twice: the penalty, then trapped capital every quarter the gap stays open.
A Pillar 2 capital add-on of 0.25% (total P2R 2.25%) was attributed by the ECB to required improvements in BCBS 239 compliance and the internal rating-based approach — not a fine, but a permanent capital cost until remediation is verified.
A $400m civil penalty for enterprise-wide deficiencies in risk management, data governance and internal controls. Four years later, with deficiencies still unremediated, regulators assessed a further $135.6m; the 2020 consent order remained in force for five years.
The question is not whether your institution has gaps. It is whether your regulator finds them first.
Governance enforced at the catalog, not described in spreadsheets.
Most data-governance vendors layer documentation on top of warehouses after the fact. Lakekeeper enforces governance at the catalog layer where the data lives — Apache Iceberg-native, open standard, built for the regulatory reality your data team is already accountable to.
| What it does | Which requirement it closes |
|---|---|
Iceberg-native access control Table- and view-level enforcement at the catalog. Not a wrapper or a layer on top — the access decision is part of the metadata operation. | BCBS 239 Principle 2 (architecture) DORA — access events are traceable technology processes |
Declarative data security Policies declared as state, enforced by the catalog, versioned like code. No standing privileges. No shared keys. Every access scoped to a specific request. | BCBS 239 Principles 3 & 4 (accuracy, completeness) DORA — ICT third-party risk & access management ECB SREP data-governance expectations |
Audit trail at the metadata layer Every read, write and transformation captured as a system event. The audit artefact is the catalog itself, not a quarterly export. | BCBS 239 Principles 3 & 4 (accuracy, completeness) DORA — every technology process documented & traceable |
Lakekeeper does not just manage data.
It manages liability.
Bring your specific BCBS 239 gap, FRTB lineage requirement or DORA evidence challenge — we show you how Lakekeeper closes it against your data, not a demo dataset. Right team: your CDO or head of data architecture, plus whoever owns your catalog.