Data engineering · Banking
Risk data aggregation and lineage (BCBS 239)
We build risk data aggregation and lineage for BCBS 239: an inventory of critical risk data, clear ownership, automated lineage from source to report, quality controls and reconciliations, and risk reporting that can be produced accurately, completely and quickly, including in a crisis. The aim is data that supervisors can test and that risk managers trust, and you own the platform and the code.
Requirements pack · Banking finance
Bank reporting and controlling requirements pack
A requirements pack for regulatory reporting, treasury and liquidity reporting, and management controlling systems in a bank: data, definitions, calculations, validation, lineage, close and governance.- 01Eight requirement areas shared by regulatory, treasury and controlling reporting.
- 02What to ask for on data definitions, lineage and reconciliation.
- 03Close, sign-off and change-management items auditors check.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Critical data inventory
Identification of the data elements that drive risk reports, with business definitions, owners, sources and the reports that use them. - 02
Governance and ownership
Named data owners and stewards, decision rights, policies and a forum to resolve conflicts, recorded in the system and not only in documents. - 03
Automated lineage
Lineage captured from pipelines and queries, from source field through transformations to risk report cell, with impact analysis for changes. - 04
Data quality framework
Rules for accuracy, completeness, timeliness, consistency and uniqueness on critical elements, with scores, trends, owners and escalation. - 05
Reconciliation
Automated reconciliation of risk data to the general ledger, source systems and prior reports, with breaks explained and tracked to closure. - 06
Exposure aggregation
Aggregation of exposures by counterparty, group, sector, country, product and other dimensions, with consistent hierarchies and identifiers. - 07
Ad hoc and stress reporting
The ability to produce new cuts and stress scenarios quickly from the same governed data, including requests under time pressure. - 08
Risk reporting production
Scheduled and on-demand risk reports with validation, review and sign-off, and a clear statement of the limits of the data. - 09
Self-assessment and evidence
Mapping of controls to the BCBS 239 principles, with gaps, action plans and evidence for the board and for supervisory reviews.
Reference architecture.
Standards and interfaces
What we design against.
- BCBS 239
- The Basel Committee's principles for effective risk data aggregation and risk reporting: governance, data architecture, accuracy, completeness, timeliness, adaptability and supervisory review.
- Supervisory guidance on risk data
- Guides and assessments by supervisors, such as the ECB's guide on risk data aggregation and risk reporting, which set out expectations in detail.
- Data management frameworks
- DAMA-DMBOK and ISO 8000 for data quality and governance practice.
- Legal entity and instrument identifiers
- LEI (ISO 17442) and instrument identifiers for consistent counterparty and product aggregation.
- Open lineage standards
- OpenLineage and metadata standards for capturing lineage from pipelines automatically.
- Reporting and accounting standards
- The regulatory returns and accounting bases to which risk data has to reconcile.
Data model
The core entities.
- Critical data element
- Name, definition, owner, steward, sources, reports using it and criticality.
- Lineage graph
- Source and target elements, transformations, run identifiers and versions.
- Quality rule and result
- Rule, dimension, threshold, outcome, trend and owner.
- Reconciliation
- Comparison, difference, explanation, approver and date.
- Exposure
- Counterparty, group, instrument, amount, currency, sector, country and the hierarchy used.
- Report and cell
- Report, cell definition, value, data cut-off and sign-off.
- Principle assessment
- BCBS 239 principle, controls, gaps, actions, owner and evidence.
When custom development is the right call.
Controls designed in, not added later.
Controlled access
Risk data is classified, access is role-based, and sensitive counterparty data is masked for those who do not need it.Change control
Changes to definitions, rules and aggregation logic are approved, tested against history and dated.Immutable reports
Issued risk reports are stored with their inputs and can be reproduced exactly.Lineage integrity
A break in lineage or a failed quality rule on a critical element is flagged before the report is issued.Resilience in a crisis
Capacity and procedures for fast reporting under stress, tested regularly.
From discovery to a system you run.
- 01
Gap assessment
We assess current practice against the principles with risk, finance and data teams, and rank the gaps by supervisory attention and risk. - 02
Inventory and governance set-up
Critical data elements are inventoried, owners named and the governance forum and tooling set up. - 03
Lineage and quality on the first reports
Automated lineage, quality rules and reconciliations are built for the most important risk reports. - 04
Aggregation and ad hoc capability
Exposure aggregation and fast ad hoc and stress reporting are added on the same governed data. - 05
Self-assessment and sustain
Evidence is produced from the platform for self-assessment, and the process runs as business as usual.
Relevant work
Where to see our work.
Common questions.
- Does BCBS 239 only apply to the largest banks?
- It was written for global systemically important banks, and many supervisors apply it, or its principles, to domestic systemically important and other banks. Smaller banks use it as a benchmark for good practice.
- What does automated lineage give us over documentation?
- It stays accurate. Lineage captured from the pipelines is generated from what actually runs, so it changes when the pipelines change, and impact analysis tells you what a change will affect.
- How fast can we produce a new risk cut?
- As fast as the governed data allows. Once critical elements are modelled and reconciled, new aggregations and stress cuts are queries and not projects.
- Does this replace our risk systems?
- No. Risk engines remain. The platform makes the data that feeds them and the reports that follow consistent, traceable and reconciled.
- Who owns the platform and code?
- You do. The code, the rules and the data stay yours.