BCBS 239, in the tool
Risk data aggregation and reporting compliance is normally a consulting engagement and a spreadsheet that goes stale the week after it is signed. In Qrly it is a module inside the BI platform that already holds the connections, the questions and the lineage — 14 principles held in code, executable data-quality rules, column-level lineage, sign-off and an audit trail over every state change.
Why risk data gets audited
What BCBS 239 asks for, and why the usual answer does not survive a supervisory visit.
Fourteen principles, not a checklist
BCBS 239 is the Basel Committee's set of principles for effective risk data aggregation and risk reporting. Principles 1 and 2 cover governance and data architecture. Principles 3 to 6 cover the aggregation capability itself — accuracy and integrity, completeness, timeliness, adaptability. Principles 7 to 11 cover the reporting practice built on top of it. Principles 12 to 14 are addressed to the supervisor rather than to the bank.
They are principles, not a control list, which is precisely what makes them hard to evidence. A supervisor does not want a policy document saying your data is accurate. They want to see the aggregation working, the definitions agreed, the failures counted and the remediation tracked.
The spreadsheet is the finding
The standard artefact is a workbook: one tab per principle, a maturity score, a paragraph of rationale, and a column of links to evidence stored somewhere else. It is authored once, reviewed by a committee, and is out of date before the next reporting period because nothing in it is connected to the data it describes.
The gap between the assessment and the data is the whole problem. If a critical data element loses its owner, or a feed starts arriving two days late, or a reference table drifts, the workbook does not notice. Someone has to notice, and then remember to update it.
The tool already knows the answer
Lineage is the part institutions most often buy separately, and it is the part a BI platform is uniquely placed to know for free. Qrly already tracks which connection feeds which table, which table feeds which question, which question feeds which dashboard, alert and subscription — as a graph rebuilt from the source-of-truth tables rather than maintained by hand.
The BCBS 239 module adds the layer above it: directed column-level edges between critical data elements, each carrying transformation text and a confidence of MANUAL, AI or INFERRED, rendered server-side as a Mermaid flowchart with every node coloured from its latest data-quality result.
Machine-drafted stays labelled
AI will write a principle rationale faster and more consistently than a risk analyst under deadline. The question a supervisor asks is not whether you used it — it is whether you can still tell which sentences a model wrote.
Every AI assist in the module is recorded under its own audit code: drafting a rationale, suggesting a gap action, reviewing a report, proposing a score, auto-filling an assessment. They are five distinct codes, not one generic "AI" flag, so the trail says what was generated and where. That is the detail that decides whether the assist is an efficiency or a finding.
The 14 principles, grouped
Not free text in a template. The principles are enumerated in the application, with translated labels, and every assessment scores against them.
Governance and data architecture
- The foundation the other twelve rest on — ownership, oversight and the IT infrastructure that has to survive a crisis
- Scored 0–4 with rationale, an evidence URL and a gap action, like every other principle
- Owners are recorded per critical data element, so governance is evidenced against real columns rather than asserted
Accuracy, completeness, timeliness, adaptability
- The four principles that executable data-quality rules speak to directly
- Accuracy and integrity map to range, regex, referential and custom-SQL checks; completeness to not-null; timeliness to freshness
- Pass percentages are reported per quality dimension, so a score against principle 4 has a number behind it
Accuracy, comprehensiveness, clarity, frequency, distribution
- The risk-report register carries frequency, recipients and sign-off, which is the evidence principles 10 and 11 ask for
- An AI review reads a linked report's text against principles 7 to 9 and reports where it falls short
- An hourly sweep marks overdue reports OVERDUE without waiting for anyone to check the calendar
Review, remedial action, cooperation
- Addressed to the supervisor rather than the bank, but assessed and evidenced in the same structure
- Remedial action is the issue tracker: severity, owner, due date, status and a resolution timestamp
- The overall assessment score is the mean of the scored principles — unscored principles do not silently flatter the average
One assessment per project, per period
A lifecycle with states that mean something, rather than a file named final_v3_signed.xlsx.
DRAFT → SUBMITTED → APPROVED
An assessment belongs to a project and a reporting period. Scoring is only possible while it is in DRAFT — once submitted, the numbers stop moving. Every state change is written to the audit trail with who made it and when.
- Score each principle 0–4. Each of the 14 principles carries a score, a rationale, an evidence URL and a gap action. The overall score is the mean of the principles actually scored, so an incomplete assessment reads as incomplete rather than as a high average over three answered questions.
- Draft with assistance, keep it labelled. The module can draft a rationale, propose a single principle score, suggest a gap remediation, or auto-fill an entire assessment as a starting point. Each of those is a separate audit code, so a reviewer can see exactly which content arrived from a model and which a human wrote.
- Submit. The assessment leaves DRAFT and scoring is closed. What was scored, by whom, and against which reporting period is now fixed.
- Approve. Sign-off moves it to APPROVED. The prior period stays intact — assessments are per period, so the trend across periods is the artefact a supervisor actually wants to see.
- Print the pack. A dedicated print stylesheet renders the full BCBS pack — overview, data quality, issues, lineage, reports and the assessment itself — with animations disabled and charts re-rendered for paper.
Seven data-quality check types
Each rule is attached to a critical data element — a connection, table and column with a business term, definition, owner, risk category and materiality — and compiled to that connection's dialect. Rules run on a read-only connection with a statement timeout.
| Check type | ExecutedWhat it countsAgainst the real table | Quality dimensionRolled up per run |
|---|---|---|
| NOT_NULL | NULLs in the column | Completeness |
| RANGE | Values outside a minimum, a maximum or both — bounds bound as parameters, never interpolated | Accuracy · validity |
| REGEX | Values that do not match a pattern, via a negated operator per engine | Validity |
| FRESHNESS | Whether the maximum timestamp is older than a maximum age, evaluated on the source | Timeliness |
| REFERENTIAL | Values absent from a reference column | Integrity |
| UNIQUENESS | The surplus of the count over the distinct count | Uniqueness |
| CUSTOM_SQL | An author-supplied scalar failure count — the only user-authored SQL path, run through the sanitizer | Any dimension |
The honest caveat about REGEX on SQL Server
The regex check compiles to a negated regular-expression operator per engine: Postgres !~, MySQL NOT REGEXP, BigQuery NOT IS_REGEXP_MATCH. SQL Server has no native regular-expression operator, so on SQL Server the check degrades to NOT LIKE. It still executes, still counts failures and still reports them — it simply cannot express a full regular expression on that engine, and you should design the rule accordingly.
Every rule also carries a quality dimension (accuracy, completeness, timeliness, integrity, validity, uniqueness), a severity (info, warning, error, critical), an enable flag and its own statement timeout. A rule that is itself broken is reported as a failed result — it never aborts the sweep and takes the rest of the run down with it.
A run is project-wide
Every enabled rule, on every critical data element in the project, in one pass — synchronously, or asynchronously with polling for the large ones.
Numbers, not a red light
- Passed or failed, the failed row count, and sample failing values so an analyst can start work immediately
- The error text where a rule could not run, and the duration of every check
- Pass percentages per quality dimension, plus an overall average for the run
- Trend and timeline history across runs — the artefact that shows remediation actually working
A critical failure opens an issue
- When a rule with critical severity fails, the run automatically opens an issue in the tracker
- The issue records source DQ_RULE with a reference back to the rule that raised it
- Nothing depends on somebody noticing a red cell on a dashboard the following Monday
- Issues carry severity, owner, due date, principle link and a status of OPEN, IN_PROGRESS, RESOLVED or ACCEPTED_RISK
Built for the review meeting
- Overview: compliance gauge, principle radar, coverage heatmap, DQ radar and trend, coverage bar, issue and report summaries
- Data quality: a CDE treemap, the run history, the rule list and a four-step rule wizard
- Issues: a severity donut, a burndown and a filtered list
- Lineage, the risk-report register with timeliness gauges, the assessment editor — and a print pack covering all of it
Column lineage, report register, issue tracker
The three artefacts a supervisor asks for after the assessment itself.
Edges with a confidence attached
- Directed edges between critical data elements, each carrying the transformation applied
- Confidence is explicit: MANUAL where a human asserted it, AI where a model proposed it, INFERRED where the platform derived it
- Rendered server-side as a Mermaid flowchart, with each node coloured from that CDE's latest data-quality result
- Upstream and downstream traversal from any node, plus automatic edge inference to seed the graph
Promote a report to regulatory output
- Any existing report or dashboard can be promoted to regulatory-output status — no parallel reporting stack
- Frequency of daily, weekly, monthly, quarterly or ad-hoc, with named recipients
- Status moves PENDING → GENERATED → SIGNED, with sign-off recorded, or → OVERDUE
- A due-date calendar plus an hourly overdue sweep that marks slippage without human intervention
Remediation with an owner
- Severity, status, owner, due date and a resolution timestamp
- Source is recorded as MANUAL, DQ_RULE or AI, with a reference to whatever raised it
- Each issue can be linked to the principle it threatens, so the assessment and the backlog point at each other
- ACCEPTED_RISK is a first-class status — a decision that was taken, not an issue that was quietly closed
A module, not an engagement
The same work, done in the system that already holds the connections, the questions and the lineage.
Qrly BCBS 239 module
Included in the platform · per project · priced on revenue, not per seat
- Principles 14, held in code
- Assessment lifecycle DRAFT → SUBMITTED → APPROVED
- Data-quality rules 7 types, executed
- Column-level lineage Rendered from the register
- Report sign-off Register + hourly overdue sweep
- Remediation Issue tracker, auto-opened
- AI provenance Own audit code per assist
- Refresh cost Re-run the sweep
It lives where the data lives.
The lineage graph, the connections, the questions being assessed and the reports being signed off are already in the platform. Nothing is exported to be assessed.
The usual approach
Consulting engagement plus a workbook plus a separate lineage tool
- Principles One tab each
- Assessment lifecycle Filenames and email
- Data-quality rules Described, run by hand
- Column-level lineage A separate purchase
- Report sign-off A calendar reminder
- Remediation An action-item column
- AI provenance Untracked
- Refresh cost Another engagement
The workbook is accurate on the day it is signed. Every day after that, its accuracy depends on somebody remembering to update it — which is the finding the next review writes up.
Common questions
What is BCBS 239?
BCBS 239 is the Basel Committee's set of principles for effective risk data aggregation and risk reporting. There are 14. Principles 1 and 2 cover governance and data architecture, 3 to 6 cover the aggregation capability, 7 to 11 cover reporting practice, and 12 to 14 are addressed to the supervisor.
Qrly holds all 14 in code, grouped GOVERNANCE, AGGREGATION, REPORTING and SUPERVISORY, with translated labels — so an assessment scores against enumerated principles rather than against free text in a template.
Are the data-quality rules actually executed against our data?
Does the regex check work on every database?
!~, MySQL NOT REGEXP, BigQuery NOT IS_REGEXP_MATCH. SQL Server has no native regular-expression operator, so there the check degrades to NOT LIKE. It still runs and still counts failures; it simply cannot express a full regular expression on that engine.What happens when a critical rule fails?
Can we tell which text was drafted by AI?
Is any of this sent to a third-party model provider?
Which databases can hold the critical data elements?
Can this run entirely inside our own network?
Related pages
The platform underneath the compliance module.