Financial Risk Reporting: Building a Risk Metadata Foundation

Regulations, such as BCBS 239, are driving banks to reexamine the way they manage financial risk management data.

Building a connected data foundation supports a world of innovative uses of your enterprise data – including 360-degree visibility of your customers, detecting and preventing fraud, proactively assessing credit applications and driving what-if scenarios that improve productivity and profitability.

In this series, we describe how connected data and graph database technologies are transforming risk reporting in modern banks to help them meet stringent demands of risk reporting compliance.



Last week, we explored key data challenges associated with BCBS 239 compliance. This week, we’ll take a closer look at how a federated approach to risk management drives compliance – and creates a foundation for business value. We’ll also discuss how to choose the right graph database technology for risk reporting compliance.

Using a Federated Approach to BCBS 239 Compliance

Integrating information into a single, enterprise-wide logical data model is very difficult and time consuming. In some cases, the structure and location of much of the data makes it all but impossible to address in a single, centralized data store. And ironically, moving everything into a single repository makes tracing data lineage even more difficult.

After earlier failed attempts to centralize enterprise information in data warehouses and operational data stores, most banks have accepted their data will remain in silos.

Given these complications, many banks are now embracing a federated model that leaves the data dispersed in its original locations, while maintaining control of the model using centralized metadata.



Federated metadata models make it considerably easier to relate entity identities, maintain data consistency, and describe end-to-end data lineage.

Building a Financial Risk Metadata Foundation

Banking institutions have no choice but to address to BCBS 239 regulations. But rather than reactively responding to the new mandates, progressive banks are using BCBS 239 as justification for building a strong metadata foundation for risk management, regulatory and analytic applications.

Traditional metadata management technologies might appear to be an obvious choice for building your new metadata foundation. But they are not capable of handling highly-connected risk-management data, tracing data lineage or adjusting for temporal inconsistencies in reports.

The complexity of the risk management and BCBS 239 require more than just simple metadata managers. To tackle the modeling and management requirements of the new regulations, you need to use graph database technology.

Choosing the Right Graph Database Technology

Data management experts agree that metadata challenges should be solved using graph databases, and not old, traditional technologies. But all graph technologies are not the same; many are thin veneers built atop old relational or NoSQL engines with inherent problems.

Relational Databases Aren’t Graph Ready

Relational databases masquerading as graph technologies are fraught with systemic faults. As complex queries traverse a graph model, query hops translate into a flurry of relational table joins that use computing resources inefficiently and cripple application performance. In sharp contrast, native graph databases use graph methods to store and query graph-based metadata. The result is fast, consistent data retrieval, presentation and management.

Non-Native NoSQL Databases Provide No Solution

Non-native NoSQL databases also fall short of core BCBS 239 requirements. Instead of storing data relationships as native graph elements, they add a graph translation layer that reduces query performance. And NoSQL engines lose transactions and relationships regularly, making them unreliable for tracing data lineage back to original information sources.

Neo4j: Native Graph Platform Ready for Financial Risk Compliance

The most popular and successful graph database is Neo4j, which is used in a large majority of graph installations worldwide. As a 100% native graph database, Neo4j eliminates the data consistency and corruption problems caused by non-native approaches to graph applications. And its dependable query performance delivers instant results, even for Value at Risk, Potential Future Exposure and other complex risk-reporting requests.

Conclusion

By choosing Neo4j for risk reporting compliance, you get a lot more than the world’s leading graph database. Neo4j supports global financial terminology standards is backed by professional services that guarantee success and provide new visibility into your compliance efforts and day-to-day operations.

Next week, we’ll explain how the Financial Industry Business Ontology (FIBO) and graph technology complement one another to solve risk reporting challenges. We’ll also explore real-world risk reporting solutions.


Catch up with the rest of the financial risk reporting blog series:

• The Connected Nature of Financial Risk