BCBS 239, introduced by the Basel Committee on Banking Supervision in 2013, has been with us for over a decade, and yet it still appears in supervisory conversations as if it were new. That is because the core problem it addresses has not gone away: many banks still struggle to prove that the risk reports they produce are accurate, complete, timely, consistent, and reproducible under stress.

European supervisors, including the ECB, continue to treat RDARR (risk data aggregation and risk reporting) as an active priority. Over time, expectations have only increased. What was once framed as a post-crisis remediation exercise is now a standing supervisory standard.

In this context, the management of market data continues to be an area where many institutions face challenges. Despite significant investment in risk infrastructure, market data is often:

• managed in silos
• poorly governed
• subject to manual corrections
• lacking central quality controls
• inconsistently used across departments

This is problematic because market data feeds into virtually all pricing, valuation, and risk models. Weaknesses at this level translate directly into compliance, operational, and reputational risk.

This blog highlights five critical focus areas in market data management where institutions frequently fall short of BCBS 239 expectations, and explains what is needed to address them in a sustainable way.

Focus area 1: lack of data lineage and traceability

What’s the issue?

BCBS 239 requires firms to trace every risk-relevant data point back to its origin. For market data, this includes the source, timestamp, transformations, overrides, and downstream usage of each value. In many institutions, fragmented sourcing and local calculations make this traceability incomplete or impossible.

As a result, when a risk metric such as VaR suddenly changes, institutions often know that something changed, but not which market data input changed, which version was used, or how that data was transformed along the chain.

Why does this matter?

Without clear data lineage, banks cannot reliably reproduce historical reports, explain anomalies, or assess the impact of changes in feeds or rules. From a supervisory perspective, an unexplained number is already a compliance failure.

In the VaR example, when an institution cannot explain why the result changed, which market data was involved, or how it was processed, it is unable to reproduce or defend the reported outcome. Investigating the issue then turns into a manual forensic exercise across market data, risk, and IT teams. From a BCBS 239 perspective, this lack of traceability directly undermines reproducibility, auditability, and the ability to defend risk reports to supervisors.

How BIQH addresses this

The BIQH Market Data Platform centralises sourcing, normalisation, and distribution, capturing lineage once and making it available across consumers. This replaces fragile point-to-point dependencies with a controlled and auditable data foundation.

Focus area 2: manual processes without control (the four-eyes principle)

What’s the issue?

Manual intervention remains common in market data operations, especially when data appears incomplete or incorrect and time pressure is high. Market data teams are often expected to “fix” issues quickly to avoid delays in daily risk reporting. BCBS 239 allows manual intervention, but only within a controlled framework that enforces clear accountability and review by more than one person, in line with the four-eyes principle.

However, in practice this still leads to market data being exported to spreadsheets, manually adjusted, and re-uploaded before the risk run. These quick fixes are often applied outside formal workflows, without proper review, documentation, or approval.

Why does this matter?

When manual overrides bypass the four-eyes principle, institutions lose control over which data was actually used in risk calculations. A seemingly small adjustment can feed directly into valuation inputs, VaR, stress testing, and regulatory or internal reporting.

When questions arise later about why a reported value differs from the original vendor data, the institution may be unable to demonstrate who made the change, who approved it, or which controls were applied. From a BCBS 239 perspective, this undermines data integrity, governance, and reproducibility.

How BIQH addresses this

The BIQH Market Data Platform embeds manual interventions in governed workflows with task assignment, review, approval, and full audit trails. Expert judgement remains possible, but always within a controlled and transparent process that can be evidenced to auditors and supervisors. Read more about how task assignment supports four-eyes controls in this blog.

Focus area 3: data quality that is not demonstrable or measurable

What’s the issue?

BCBS 239 requires institutions to demonstrate that risk data is accurate, complete, timely, and consistent. For market data, this means that data quality must be objectively controlled rather than implicitly trusted. In practice, many institutions still assume data quality based on the fact that a vendor feed arrived successfully and no immediate errors were reported.

As a result, issues such as stale prices, missing instruments, incorrect currencies, or unprocessed corporate actions may remain undetected. Risk and valuation processes continue to run on data that appears “green” at a high level, while specific quality problems remain hidden beneath the surface.

Why does this matter?

When market data quality is not measurable, institutions cannot demonstrate that the inputs to their risk reports were reliable at the time of reporting. Problems are often discovered only after results are questioned, at which point there is no objective evidence showing what checks were performed or whether issues were detectable beforehand.

From a BCBS 239 perspective, this represents a clear control gap. Without demonstrable quality controls, institutions cannot substantiate accuracy, completeness, or timeliness of market data, nor show that data risks are consistently identified and managed, particularly under stressed conditions.

How BIQH addresses this

The BIQH Market Data Platform supports a structured approach to market data quality by enabling validations and quality checks to be defined, executed, and reviewed within a controlled environment. Both standard and business-specific checks can be applied, with exceptions handled through governed workflows.

This enables institutions to move away from implicit trust in upstream feeds and establish objective evidence around market data quality, in line with BCBS 239 expectations. Read more about how validations support demonstrable market data quality in this blog.

Focus area 4: inconsistent data usage across departments

What’s the issue?

BCBS 239 requires risk data to be aggregated consistently across the enterprise. In practice, however, different departments often consume different versions of the same market data, driven by historical choices, tooling constraints, or local optimisation.

As a result, front office, risk, and finance may rely on different prices for the same instrument, each sourced from a different vendor or internal file. While each source may be defensible in isolation, the lack of alignment leads to multiple “truths” co-existing within the same institution.

Why does this matter?

BCBS 239 requires consistent aggregation of risk data across the enterprise. When different departments use different market data inputs, valuations, sensitivities, and risk metrics no longer reconcile. P&L explanations break down, finance challenges trading marks, and risk reports cannot be easily tied back to the balance sheet or management views.

From a BCBS 239 perspective, such inconsistencies undermine confidence in internal reporting and raise supervisory concerns. If senior management receives different answers depending on which department is asked, the institution cannot credibly demonstrate consistent aggregation, transparency of definitions, or effective control over its risk reporting, particularly under stressed conditions.

How BIQH addresses this

The BIQH Market Data Platform supports a centralised approach to sourcing, normalisation, and symbology mapping of market data. This helps institutions align data usage across departments while allowing different consumers to access data in a consistent and controlled manner.

By reducing discrepancies at the market data level, reconciliation becomes an exception rather than a recurring operational process, supporting BCBS 239 expectations around consistency and aggregation.
Read also our collaboration piece with Viewwave highlighting the importance of consistent data definitions.

Focus area 5: lack of monitoring for timeliness and completeness

What’s the issue?

BCBS 239 assumes that risk data used for reporting is not only accurate, but also complete and available on time. For market data, this requires active monitoring of whether all required inputs have arrived within defined cut-off times.

In practice, many institutions still treat technical process completion as a proxy for data readiness. If the batch job finishes successfully, risk processes proceed, even though parts of the expected market data set may be missing, delayed, or stale.

Why does this matter?

When completeness and timeliness are not actively monitored, institutions can produce risk reports on time that are nonetheless based on incomplete data. Vendor feed delays, missing instruments, or stale prices may be silently accepted or replaced by fallback values, allowing VaR, sensitivities, and stress results to be calculated without visibility into what data was actually missing at reporting time.

From a BCBS 239 perspective, this represents a clear control gap. If an institution cannot demonstrate what data was expected, what was received by the cut-off, when it arrived, and which reports were impacted by gaps or delays, it cannot evidence completeness, timeliness, or control effectiveness. Delivering a report on time does not mitigate the compliance risk if the underlying data was incomplete or unreliable.

How BIQH addresses this

The BIQH Market Data Platform supports a structured approach to monitoring market data delivery by enabling institutions to define expected datasets and assess whether required data has arrived within agreed timelines. This helps create objective evidence around data completeness and timeliness at reporting cut-off, supporting BCBS 239 expectations for reliable and resilient risk reporting.

Conclusion

BCBS 239 is ultimately about proof. Institutions must be able to demonstrate that their risk data is accurate, complete, consistent, timely, and reproducible, especially under stress.

Market data is often where this proof breaks down, sitting at the intersection of external complexity and internal fragmentation. Weaknesses in data lineage, manual controls, data quality, consistency across departments, or monitoring of timeliness and completeness may not always be visible in day-to-day operations, but they surface quickly when results are challenged or market conditions become volatile. Addressing these weaknesses requires more than local fixes; it requires a clear operating model for market data, supported by governance, transparency, and demonstrable control.

One example of how BCBS 239 expectations can be translated into controlled and auditable day-to-day market data operations is the BIQH Market Data Platform. It addresses the core challenges institutions face by supporting demonstrable data lineage, controlled manual interventions, systematic and reviewable validations, consistent data usage across departments, and effective monitoring of timeliness and completeness.

Different institutions may choose different architectures or tools, but these principles remain constant if BCBS 239 compliance is to be achieved and sustained.

If you want to explore how these principles are applied in practice, you can:

• explore our interactive processing overview to see how these key market data processes are structured, or
• contact BIQH to discuss how a BCBS 239-aligned market data operating model could work in your environment.