Trust is the cornerstone on which the banking industry is built. When consumers lose trust in a bank’s ability to manage risk, the system stops working. We’ve seen what follows—financial crises, bailouts, destruction of capital, and losses of jobs. Put simply, consumers trust banks to keep their money safe and return the money when requested.
But there’s trust on the business side, too. Banks and their employees place trust in their risk models to help ensure the bank maintains liquidity even in the worst of times. This trust depends on an understanding of the data that inform risk models: where does it come from, where is it being used, and what are the ripple effects of a change?
Maintaining trust in data
Today, large banks are implementing data governance solutions to streamline data discovery, ensure the quality of data assets and manage data privacy. Moreover, banks must stay in compliance with industry regulations like BCBS 239, which focus on improving banks’ risk data aggregation and risk reporting capabilities. To help stay compliant, these organizations need to verify the accuracy and completeness of the data elements used in risk models. This can ensure that the decisions made are reliable and of high quality.
Before a bank can start the process of certifying a risk model, they first need to understand what data is being used and how it changes as it moves from a database to a model.
Data lineage, the process of tracking the flow of data over time from origin to destination within a data pipeline, is essential to understand the full lifecycle of data and ensure regulatory compliance. The value of data lineage applies across all industries, but there are three key focuses when you consider it for banking use cases:
1. Mapping data movement
Data lineage solutions help banks map data movement from source systems and databases through processing and transformation pipelines to end use in risk models or reports. With an accurate view of the entire system, banks can more easily track down issues like missing or inconsistent data.
2. Auditing processes and impact analysis
With an automated lineage solution, banks can audit their processes and complete impact analysis to identify potential compliance violations before they become a problem by delivering a comprehensive view of data. This level of visibility also helps ensure that changes made over time don’t introduce new risks into the organization, can make it easier for banks to stay within regulatory guidelines, and helps ensure banks can respond quickly to changing business needs.
3. Maintaining precise risk management reports
An automated data lineage solution allows banks to maintain a high level of precision in their risk management reports without the need to manually crawl through source code. This is crucial for helping comply with regulatory principles, such as the ones outlined in BCBS 239, that require banks to generate risk data accurately and in a timely fashion.
Data lineage solutions provide banks with the tools and technology to ensure compliance, maintain data trust, and improve their risk models. By understanding the flow of data throughout the organization, banks can be more confident that they are accurately reporting on risks. This level of transparency is essential to maintaining consumer confidence in banking institutions around the world.
IBM’s data lineage solution for banking regulatory compliance
For helping clients take advantage of data lineage, we recommend IBM Cloud Pak for Data for several reasons. Data engineers can scan data connections into IBM Cloud Pak for Data to automatically retrieve a complete technical lineage and a summarized view including information on data quality and business metadata for additional context. Users can capture data lineage consistently and accurately through automated scanning of 3rd party technologies like databases, ETL jobs, and BI tools using Data lineage in Watson Knowledge Catalog, which is included in IBM Cloud Pak for Data.
Simply put, with the data lineage capabilities of Cloud Pak for Data, every operation—whether in a database, integration, or an analysis tool—is reverse-engineered to create a map telling the story from data source to end application providing the deep technical lineage that data engineers need, historical versioning to view changes over time, and business context so that any user can quickly understand the journey of the data used in a risk report.