Better data quality: the key to satisfying the regulators
The ramifications of failing to satisfy the reporting demands of your banking regulators are serious: financial penalties, unwanted press coverage, operating under the cloud of an MRIA (Matter Requiring Immediate Attention), even suspension of business.
Yet, like many, you may be finding it increasingly difficult to provide what the regulators want: an enterprise-level view of your data, all your data classified using consistent taxonomies, and the ability to tie out your numbers from one report to another. Where do you start when it comes to delivering on what can sometimes seem like an impossible task? Focusing on data quality is key.
Improving data quality will allow you meet the regulators' current reporting demands more efficiently and with greater confidence, and reduce regulatory scrutiny. It also establishes a platform for meeting future regulatory requirements, which look set to become increasingly onerous.
A coordinated program focused on improving data quality demonstrates to the regulators that your firm is serious about data quality, especially when you establish measures to highlight the program's impact. Your program should focus on the following five key actions:
1. Strengthen validation at the point of data entry
For efficiency's sake, improving data quality should start at the point of data entry. Here, defining and automating rules for validating data can save the substantial time, money, and effort involved in improving data quality downstream.
It's the automation of rules that really ensures data quality. Otherwise, this depends on system users and how well trained they are. Sacrificing automated rules in the interest of swifter system implementation, reducing the cost of customizing vendor software, or giving system users greater flexibility is a false move. When this happens, the needs of the few end up outweighing the needs of the enterprise as a whole.
2. Implement consistent standards across systems
Source system data entry processes and reference data are often inconsistent across systems. For example:
- one system might group and aggregate all loans overdue by 90 days while another might age loans overdue by 90, 120, 150, and 180 days
- one business unit might enter the country of exposure for a loan based on the customer's billing address while another might enter it based on where the loan originated
- one system might use NAICS industry codes as the standard while another might use the older SIC standard.
Inconsistencies like these cause regulators to question how data is aggregated for regulatory reporting. Agreeing a consistent set of reference data and standards for the enterprise and establishing transparent business rules for ensuring source data conforms to that set can quell their concerns. The transparency is key. It boosts regulator confidence in the consistency of your enterprise reference data. For traceability purposes, make sure you use conformed data to enrich source data, not to replace it.
3. Monitor for anomalies
When you cannot strengthen data validation at the point of entry or impose data standards across the enterprise, consider a Plan B. This involves using a data quality monitoring solution to profile data after it has been captured into a source system database. Data that doesn't pass validation is then reported as an exception for correction.
Management needs to be involved in setting the ground rules for this approach. Key questions to answer are:
- what should be monitored?
- who will define the rules for monitoring?
- who will be responsible for monitoring?
- who will be responsible for remediation?
- how will remediation be tracked and measured?
4. Consolidate data for reporting into a single source
As the number of systems within an enterprise grows, producing regulatory reports becomes increasingly complex. Data must be pulled from multiple sources at just the right time to produce each report and, with the involvement of several business functions in each one, consistency of data becomes an issue. Consolidating data into a single source that all business functions can draw on for regulatory reporting addresses these problems and maximizes the consistency of reported data.
5. Establish enterprise-level data definitions
Regulators are often referred to as 'examiners' and for good reason: they notice when the numbers don't tie across from one report to another. This happens when there's no single set of data definitions for the whole enterprise. As a result, the same term may be used to refer to two or more different data elements or several different terms may be used to refer to a single data element.
Providing the regulator with a precise and distinct definition for each reported data element removes the confusion. But getting to that precise and distinct definition means you'll need to overcome the following challenges:
- the way different businesses within an enterprise label their data is often deeply entrenched, so they are generally reluctant to re-label their data
- the process of getting to a precise and distinct definition requires subject matter expertise and is often plagued by the need to consider slight variations or exceptions. Most businesses are reluctant to commit their experts to such a time-consuming task
- managing the change associated with adopting enterprise-level data definitions requires considerable effort, yet businesses across the enterprise are unlikely to appreciate the outcome.
Regulatory reporting is only going to become more challenging in the future. It is a data-centric process that will require greater enterprise-level oversight and control. Do yourself and the regulators a favor. Don't wait for ramifications of poor data quality to hit your firm. Take action to improve data quality now.
To find out how PA can help you meet regulatory reporting requirements more efficiently, please contact us now.