BCBS 239

A bank's risk data aggregation capabilities and risk reporting practices should be subject to strong governance arrangements consistent with other principles and guidance established by the Basel Committee. The board and senior management should review and approve the framework and ensure adequate resources.

• Board-approved risk data aggregation and risk reporting (RDARR) governance framework
• Roles and responsibilities for RDARR (including senior management ownership)
• Board/risk-committee minutes evidencing review and challenge of RDARR capabilities
• Independent validation/audit of the RDARR framework

• RDARR governance not formally owned at board/senior-management level
• No independent validation of risk data aggregation capabilities
• Framework not reviewed when the business or IT environment changes

A bank should design, build and maintain data architecture and IT infrastructure which fully supports its risk data aggregation capabilities and risk reporting practices not only in normal times but also during times of stress or crisis, while still meeting the other Principles.

• Documented data architecture (data dictionary, taxonomies, ownership)
• Integrated data taxonomies and architecture across the group
• Evidence that infrastructure supports RDARR during stress/crisis (capacity, failover)
• Data lineage and metadata management records

• Fragmented or manual data architecture reliant on spreadsheets/EUCs
• No single authoritative data source for key risk metrics
• Stress/crisis scalability of infrastructure untested

A bank should be able to generate accurate and reliable risk data to meet normal and stress/crisis reporting accuracy requirements. Data should be aggregated on a largely automated basis so as to minimise the probability of errors.

• Reconciliation of risk data to source systems and to the general ledger / accounting records
• Controls over automated vs manual aggregation, with documented manual adjustments
• Data quality measurement and accuracy thresholds with monitoring
• Audit trail for risk data from source to report

• Manual aggregation and adjustments not controlled or documented
• No reconciliation between risk and finance data
• Accuracy requirements not defined for stress/crisis conditions

A bank should be able to capture and aggregate all material risk data across the banking group. Data should be available by business line, legal entity, asset type, industry, region and other groupings, as relevant for the risk in question, that permit identifying and reporting risk exposures, concentrations and emerging risks.

• Inventory of material risk data captured across the group (by business line, legal entity, asset type, region)
• Coverage analysis demonstrating all material risks are aggregated
• Ability to disaggregate exposures and concentrations by required dimensions
• Gap analysis for off-balance-sheet and newly acquired entities

• Material risks or legal entities excluded from aggregation
• Inability to break exposures down by the required groupings
• Completeness not reassessed after acquisitions or new products

A bank should be able to generate aggregate and up-to-date risk data in a timely manner while also meeting the principles relating to accuracy and integrity, completeness and adaptability. The precise timing depends on the nature and potential volatility of the risk, including timely production under stress/crisis conditions.

• Defined timeliness requirements per risk type for normal and stress/crisis conditions
• Evidence of meeting reporting deadlines (production logs, SLAs)
• Capability to accelerate aggregation under stress/crisis (tested)
• Time-to-produce metrics for key risk reports

• No defined timeliness requirements differentiating normal vs stress conditions
• Reliance on time-consuming manual processes that fail under stress
• Crisis-reporting timeliness never tested

A bank should be able to generate aggregate risk data to meet a broad range of on-demand, ad hoc risk management reporting requests, including requests during stress/crisis situations, requests due to changing internal needs and requests to meet supervisory queries.

• Capability to produce ad hoc and customised risk reports on demand
• Evidence of meeting ad hoc supervisory and management data requests
• Flexible data aggregation tools (drill-down, re-aggregation, what-if)
• Turnaround records for ad hoc/stress requests

• Ad hoc requests require lengthy manual builds
• Inability to incorporate new risk types or scenarios quickly
• No capability to support supervisory data calls under stress

The board and senior management (or other recipients as appropriate) should set the frequency of risk management report production and distribution. Frequency requirements should reflect the needs of the recipients, the nature of the risk reported, and the speed at which the risk can change, increasing during times of stress/crisis.

• Board/senior-management-approved reporting frequency schedule by report and risk type
• Evidence of increased reporting frequency during stress/crisis events
• Production and distribution logs against the schedule

• Frequency not set or approved by recipients
• No mechanism to increase frequency under stress
• Actual frequency diverging from the approved schedule

Risk management reports should be distributed to the relevant parties while ensuring confidentiality is maintained.

• Distribution lists mapping reports to authorised recipients
• Controls ensuring confidentiality of distributed risk reports (access controls, secure channels)
• Evidence reports reach recipients in time to act
• Distribution audit trail

• Reports not reaching all relevant decision-makers
• Confidentiality controls absent for sensitive risk reports
• No record of who received which report and when

Risk management reports should accurately and precisely convey aggregated risk data and reflect risk in an exact manner. Reports should be reconciled and validated.

• Reconciliation and validation procedures for risk reports prior to distribution
• Defined accuracy requirements and validation sign-offs for reports
• Documentation of report data sources and calculation methods
• Error log and correction process for risk reports

• Reports distributed without validation or reconciliation
• No accountability for report accuracy
• Report figures not traceable to validated source data

Risk management reports should cover all material risk areas within the organisation. The depth and scope of these reports should be consistent with the size and complexity of the bank's operations and risk profile, as well as the requirements of the recipients.

• Risk reporting suite mapped to all material risk types (credit, market, liquidity, operational, etc.)
• Assessment that report depth matches the bank's size/complexity and recipient needs
• Coverage of forward-looking and emerging risks in reporting

• Material risk areas missing from the reporting suite
• Reports not tailored to recipient decision needs
• Emerging/forward-looking risks not reported

Risk management reports should communicate information in a clear and concise manner. Reports should be easy to understand yet comprehensive enough to facilitate informed decision-making. Reports should include meaningful information tailored to the needs of the recipients.

• Risk report templates demonstrating clear, concise presentation tailored to recipients
• Recipient feedback on report usefulness
• Evidence reports support decision-making (linkage to risk-appetite limits, actions)
• Glossary/definitions accompanying reports

• Reports overly technical or voluminous for the audience
• No linkage between reported metrics and risk appetite/decisions
• Inconsistent definitions across reports

Supervisors should periodically review and evaluate a bank's compliance with the eleven Principles above (governance, infrastructure, risk data aggregation and risk reporting).

• Records of supervisory reviews/evaluations of RDARR compliance
• Bank self-assessment against the eleven Principles provided to the supervisor
• Supervisory findings and the bank's responses

• No periodic self-assessment against the Principles
• Supervisory findings not tracked
• Self-assessment not evidenced or independently challenged

Supervisors should have and use the appropriate tools and resources to require effective and timely remedial action by a bank to address deficiencies in its risk data aggregation capabilities and risk reporting practices. Supervisors should be able to use a range of tools, including Pillar 2.

• Remediation plans addressing RDARR deficiencies, with owners and timelines
• Evidence of timely closure of supervisory-identified deficiencies
• Records of supervisory measures applied (including Pillar 2 actions) where relevant

• RDARR deficiencies without time-bound remediation plans
• Remediation repeatedly delayed
• No escalation when remediation stalls

Supervisors should cooperate with relevant supervisors in other jurisdictions regarding the supervision and review of the Principles, and the implementation of any remedial action if necessary.

• Records of home/host supervisory cooperation on RDARR (colleges, information sharing)
• Group-wide RDARR assessment shared across relevant jurisdictions
• Coordination of remedial actions across home and host supervisors

• RDARR assessed only at solo (not group) level across jurisdictions
• No information sharing between home and host supervisors
• Remedial actions not coordinated across the group