Data Monitoring Case Study of an MDM System

The Investment Banking industry is becoming very conscious of the need to reduce and if possible eliminate operational risk inherent in the data. At the same time, there are significant efforts to reduce costs on all fronts. In Nomura Securities, both of these drivers were particularly relevant in when a decision was made to upgrade a major Master Data Management (MDM) system.

Yet, the link between data integration and data quality presented a considerable challenge.

At Nomura Securities, the trading desks heavily relied on the MDM solution for Financial Instrument and related market data for their trading decisions. This solution consolidated information from internal and external sources. Data such as ratings, coupon rates, pool factors, prices and securities reference data determined what positions would be kept or liquidated. Unfortunately, as with many global banks, all this data was dispersed among a variety of systems, and locations, making integration difficult.

As a result, the Bank experienced a number of issues that were ultimately found to have been caused by data quality. To reduce its vulnerability to this form of operational risk, the Bank turned to iceDQ Soft for their data quality and monitoring solution.

To minimize the impact of bad data on trading decisions, business was keen to find the best way to get good data to the trading desks. Their focus was on proactive monitoring, notification, and prevention of recurrence of detected data quality problems.

Data quality issue detection and prevention is a continuous process. That is why the iGOVERN tool, a dedicated iGOVERN Data Quality Monitoring Framework, was implemented for securities data quality monitoring.

Next, iGOVERN was configured to support a Monitoring Framework to achieve goals of communication, accountability, global collaboration and visibility to management.

Data is consumed in vast amount and variety for different purposes. It is very difficult, if not impossible, to watch each and every data elements. The very first task was to identify the critical data elements that are required for key trading decisions. The data elements were classified as “Blocker”, “Critical”, and “Warning”. These were defined as follows:

Business Blocker Data Elements: Business cannot continue without considerable monetary or reputational risk being put at stake. Also, these data elements if loaded incorrectly would create a situation that will be difficult to reverse.

Business Critical Data Elements: Business can continue but there will be some undesirable financial impact.

Business Warning Data Elements: These will have minor impact on business and should be fixed in the near term.

This effectively provided the high-level requirements for iceDQ to come up with a solution to monitor or control the quality of data elements. The next step was to identify methods to monitor them. Regardless of the level of data exceptions, the way to monitor them differed depending on the characteristics of data and nature of the source.

Some data elements were compared with the source data before and after a load. Other data elements were compared with their past state to figure out if they were same with no deviation. For some elements, the reconciliation principle had to be applied – they were compared internally with other subject areas, and externally with data vendor feeds. There were some situations where data had no known values to compare with other than those based on business requirements.

Once the logic for validating data was known, the rules were coded by data quality teams into physical rules. The rules got executed either within the ETL processes, or on a predetermined schedule based on inputs of the business users and technical team.

As in any MDM system, the integration of identifiers is the most critical task. In this case, the integration was based on alternate securities identifiers such as CUSIP, ISIN, SEDOL, etc., and other supporting attributes such as Maturity Date and Exchange Code. But the rules-based integration is not enough, it needs to be governed. iGOVERN successfully deployed within the securities integration framework and constantly monitored the breaks with effective distribution of reports to the concerned SMEs and technical team for action. This constant feedback found many dormant issues and kept them on a manageable scale.

iGOVERN also monitored the supporting attributes of security master such as country and currency that detected new domain values and thus preventing breaks in the reports.

For securities market data such as prices, pool factors, and ratings, iGOVERN monitored its trend and reported exceptions about the probability of data issues.

The dashboard provided visibility to actual status of the health of the MDM environment. Rapid feedback in the form of reports of data with material and drill down abilities enabled quick decisions and actions.

A well thought framework and agile toolset provided many tangible and intangible benefits.

The following lessons were learned from the successful implementation of the data quality governance on the Securities MDM system:

The success of iGOVERN is its continued and consistent reporting. iGOVERN acts as an independent data auditor creating a bridge of trust between IT and business stakeholders.

iceDQ empowers organizations to ensure data trust and reliability throughout the data life cycle.

Our comprehensive platform combines data testing, data monitoring, and data observability into a single solution, enabling data engineers to proactively manage data quality and eliminate data issues before they impact business decisions.

Leading companies across industries, including prominent players in banking, insurance, and healthcare, rely on iceDQ to continuously test, monitor, and observe their data-driven systems. This ensures trustworthy data that fuels informed decision-making and drives business success.