Financial Services & Neo4j: Data Lineage & Metadata Management

Regulatory compliance requires financial services firms to have visibility into data lineage, information and process flows. The Sarbanes-Oxley Act (SOX), for example, requires public firms to understand who has access to what data, what data resides in which systems, and how data flows across the organization.

In this series on Neo4j and financial services, we’ll be looking at how today’s finance enterprises are effectively solving emerging challenges in the industry. Last week, we took a closer look at financial asset graphs.

This week, we’ll take a closer look at data lineage and metadata management using Neo4j.

Data Lineage using a Metadata Graph

Tracing data lineage and access across systems and across time is a significant challenge for the IT department of any financial services enterprise.

Specifically, data lineage compliance can be a challenge because the same data can be replicated across many different systems. For example, security master data sourced from Bloomberg might be spread across 150 systems, while the master set of the firm’s products might be replicated across 200 different systems not counting the systems mentioned earlier.

Knowing your data lineage and how data moves is not only necessary for regulatory compliance efforts, but it also helps speed up projects that depend on that data. Financial services are using Neo4j to model their data lineage and data flows as a metadata graph to get a complete understanding of data and systems across the organization.

Case Study: Global 500 Financial Services Company

A Global 500 financial services firm, residing near the median of that list, wanted to build an integrated data distribution platform.

A key component of the platform is a knowledge base that would allow the firm to describe the lineage of the datasets and attributes from master systems to consumers. The firm chose to store the metamodel for the knowledge base in Neo4j.

The Global 500 financial services firm encountered several challenges while building its knowledge base, one of them being coverage. Not all datasets had been entered into the platform, so flexibility was essential in order to accommodate new data sources, datasets, consumers and rules.

What’s more, the knowledge base needed to be able to easily answer numerous questions such as:

• What datasets and attributes do we provide?
• How are the datasets related?
• Which consumers are using which attributes?
• How are users receiving our data?

Neo4j’s flexible schema enabled the global firm to model all its data flows and rapidly answer questions about how and where its data is used. Given the success realized with Neo4j, the firm plans on widening its coverage of datasets and offering the solution to other parts of the bank.

Conclusion

While data lineage and metadata management are often internal concerns with a large financial services enterprise, they are essential for both regulatory compliance and sustainable competitive advantage. An enterprise whose data management process is both flexible and responsive in real time can better respond to the evolving compliance landscape while offering more competitive products and services to customers. In terms of both flexibility and performance, Neo4j is far and away the best database to manage these growing and interconnected datasets.

In the coming weeks, we’ll take a closer look at other graph technology use cases within the financial services industry, including fraud prevention, anti-money laundering, IT infrastructure monitoring, identity and access management, cybersecurity, and customer experience management.


Catch up with the rest of the financial services and Neo4j blog series:

• Financial Asset Graphs