Establishing Data Lineage: An Imperative to BCBS 239 Compliance

During the financial crisis that began in 2007, data architecture and IT inadequacies that prevailed in a banking infrastructure constrained banks’ ability to aggregate exposures and manage risks in a timely manner. To address this conclusively and to improve resiliency of financial services industry, global regulators defined BCBS 239, a guideline for effective Risk Data Aggregation and Reporting. Today banks have to report few hundred metrics to regulators and often these metrics are generated from diverse systems with the data flow from source to report always left undocumented.

Let us take an example of Value at Risk (VaR) reported on market risk disclosure. This metric is produced after aggregating positions/ trades across asset classes, configuring reference data, running Monte Carlo Simulations and finally aggregating VaR from several asset classes and legal entities prior to reporting. Substantiating this process requires data lineage to be documented.

However, risk IT departments do not have a visual representation of the processes at the enterprise level. Documenting data lineage begins with documenting the process in detail. This is followed by cataloging data terms, applications, data stores, conceptual and physical data models used to generate the metric. The next step is to link the components - which can be automated by using tools to scan and link metadata from databases, data modeling tools and applications. The key roadblock will be process components which do not hold any metadata, for e.g. a C++ process used for VaR computation and so on. This roadblock can be addressed manually by creating the mapping or using advanced tools to scan code. The process documentation, metadata scanning and linking can be managed using metadata management platforms like IBM Infosphere, Informatica Meta Manager, Adaptive or Rochade.

Collectively this provides banks the ability to draw lineage graphs and visually analyze the flow of information across the enterprise systems before it is reported. The effort will result in a large metadata universe which must then be managed by a team of lineage managers or stewards. Building lineage for all its Regulatory and MIS reporting data is complex but banks will benefit considerably from this undertaking. Some of the benefits are:

Clarity on Reports and metrics generated
Identify and eliminate duplication of data elements and processes
Enable banks to manage a consistent business glossary across
Reduce effort spent by Regulatory Reporting Departments and Business in data analysis
Simplify impact analysis of change to data models, applications and processes

From our experience in helping banking clients, we recommend setting up a Metadata factory with its own target operating model that accepts work packages for implementing data lineage using state of the art tools like ASG-Rochade, IBM, and Informatica etc. The metadata factory will ensure consistency in approach, tools and process used for defining and managing critical metadata and data lineage - an imperative for robust data governance and BCBS 239 compliance.

About the Author

Sunil Pai has more than 19 years of experience in the Finance and Risk domain managing implementation of Risk and Compliance solutions, Finance - Risk data integration. He is an expert in Basel II/III and Regulatory reporting.

Service Offerings

Service Offerings

Client Themes

Client Themes

Establishing Data Lineage:

An Imperative to BCBS 239

Compliance

About the Author

Service Offerings

Industries

Cloud

Cybersecurity

Digital

EngineeringNXT

Holmes

Contact Us

About Wipro

Careers

Location

Leadership

Investors

Innovation

News and Events

Insights

Analyst speak

Products & Platforms

Partner Ecosystem

Sustainability

Contact Wipro