Forward-looking banks are uniting data silos into an information foundation for building innovative applications. These solutions provide extreme visibility and deep analytical insights that improve compliance efforts and day-to-day decision making.
In this series, we’ll describe how connected data and graph database technologies are transforming risk reporting in modern banks to help them meet the stringent demands of risk reporting compliance.
This week, we’ll discuss risk reporting standards including the Basel Committee’s BCBS 239 and the multifaceted data challenges of complying with this regulation.
The Connected Nature of Financial Risk
The lack of timely risk data was a major contributor to the global financial crisis of 2008 as the collapse of Lehman Brothers sent shockwaves through the banking world.
Without standards for properly aggregating risk in their financial positions, banks were unable to quickly assess the dependency of their various holdings on Lehman stock and assets.
Armed with an understanding of risk data lineage – a visibility of data connections all the way back to authoritative data sources – financial houses could have limited their exposure. Such visibility requires financial data standards and modern software that understands the connectedness of modern investment instruments.
The Emergence of Risk Reporting Standards
Since the 2008 market meltdown, regulators have established standards for recording and tracing financial transactions and for aggregating risk data. The new standards are designed to uncover risk dependencies and adjust capital ratio requirements accordingly.
To create consistency in recording financial contract details, the International Organization for Standardization (ISO) released ISO 17442, the Legal Entity Identifier (LEI) initiative. LEI codes clearly identify parties in transactions, thereby laying a sturdy foundation for deep visibility into financial risk data.
Another crucial data-focused initiative is BCBS 239, the Basel Committee’s 14 principles to be used by banks when aggregating financial risk data.
These new standards collectively enable banks to assess risk, trace data lineage, and understand dependencies on other systems, investments and financial houses.
BCBS 239 Regulatory Principles
The 14 BCBS 239 principles are organized into four data management categories, as shown below.
Governance and InfrastructureTo build their risk reporting systems, banks must utilize data governance and integrated data taxonomies, as well as group-wide metadata including consistent identifiers for entities, counterparties, customers and accounts. The banks must also maintain data systems that handle the requirements of normal operations as well as the high demands and specific requirements of crisis situations.
Risk Data AggregationBanks must be able to generate accurate, consistent and reliable risk data while maintaining full visibility back to authoritative data sources. Any aggregations and transformations must adjust for data latency, so all calculations are based on data values from the same point in time. And the datasets must be able to satisfy a full spectrum of requests made by managers and regulators.
Risk ReportingManagement and regulatory reports must represent risk in a precise and auditable manner, and reconcile to the complexity of the bank’s risk model and operations. They must present risk information in a clear, concise and easily understood manner than facilitates fast, informed decisions. The reports must be distributed regularly to managers and regulators and also be available for on-demand and ad hoc requests.
Supervisory ReviewBank risk supervisors are required to review their institution’s ongoing compliance with BCBS 239 principles. They must have access to the tools required to address any deficiencies they discover in their investigations. Supervisors are also required to cooperate with other regulators and other supervisors in their compliance investigations and implementation of remedial actions.
Key Data Challenges of BCBS 239 Regulations
Building models for risk reporting requires tackling some serious data management issues.
Data LineageAccurate and reliable risk reports require a clear understanding of data lineage. Reporting entities must be able to prove how each number in a report is generated, including its calculation details and source data. Each data item and transformation must be attributed to an owner, a steward, and be profiled with a quality and latency status. Most importantly, data must be traced backwards until its lineage ends with an authoritative source.
Data SilosLines of business often grow their own systems to meet specific business needs or to create independent trading desks for faster decision making. This produces discrete data silos that make tracing data lineage a very difficult task. You must be able to trace data movement through those silos and systems all the way back to their original sources. While data warehouses can assemble information from discrete silos, they do little or nothing to trace data lineage, and can even make the process more complex.
Terminology DifferencesBusiness groups often use their own terminology and algorithms, even within the same organization. For example, the notional value of a derivative contract can mean different things to different people. What is a derivative? Exactly what asset classes are included? Is the data original, copied or calculated? Is the data derived from internal or external sources? Are those sources authoritative?
Legal Entity IdentifiersWith the introduction of the Legal Entity Identifier Act (LEI) and MiFID 2 (the EU’s Markets in Financial Instruments Directive), entities and counterparties in contracts are required to use standard identifiers to describe transactions. While this helps address accountability of the parties, developers must still relate old entity identifiers to the new identifiers on all historical information.
Data Consistency and LatencyThe data appearing in regulatory reports must be accurate and consistent as of a specific time. To achieve such temporal consistency, all transactions must be timestamped. Reports must use those timestamps to assemble accurate snapshots of risk data at any point in time.
Achieving consistency across data silos presents even harder challenges. Risk reports typically pull data from multiple sources, each with its own refresh schedule. To avoid data latency issues and achieve consistency, risk reports must adjust for temporal differences in each silo.
The risk-reporting mandates of BCBS 239 place new demands on data architectures at banks and financial houses worldwide. The need for fast access to real-time data lineage and financial risk information has given organizations solid justification for revisiting the old, relational reporting systems they’ve struggled with for years.
Using a native graph database like Neo4j, banks can provide regulators with all the information that is required by regulations like BCBS 239. At the same time, their connected data serves as the foundation for innovative, real-world risk reporting solutions.
In the coming weeks, we’ll take a closer look at a federated approach to BCBS 239 compliance and why it requires choosing the right graph database technology. We’ll explore how early adopters are utilizing the clarity and flexibility of graph modeling to create an enterprise platform for visualizing, analyzing, reporting and governing financial risk.
Find out how financial services firms use connected data to comply and get a competitive edge in this white paper, The Connected Data Revolution in Financial Risk Reporting: Connections in Financial Data Are Redefining Risk and Compliance Practices. Click below to get your free copy.
Read the White Paper
About the Author
Navneet Mathur , Senior Director of Global Solutions, Neo4j
Nav Mathur is Senior Director of Global Solutions at Neo4j. He is responsible for solutions development and go-to-market activities.