EMRR: a crucial component to successful risk management

  • 924

    EMRR: a crucial component to successful risk management

    Exceptions, or processing failures due to erroneous data, are a daily occurrence for market participants as they fulfill their regulatory reporting obligations. However, as regulators seek more granular data for over-the-counter (OTC) derivatives trading activity, exceptions are becoming more frequent and more complex. That’s driving the need for exception management in regulatory reporting (EMRR), which is the process of identifying, investigating and resolving conflicts during data reporting transfers. In this article, Basu Bishal and Rohit Narula explain why EMRR should be a component of every trading firm’s risk management system and how effective implementation can minimize compliance costs while freeing up personnel to address other needs and opportunities.


    In today’s more regulated environment, firms must report a considerable amount of trade data to regulators in real time. Because this regulatory reporting process is done at the trade level, it requires capturing, enriching, processing and reporting multiple messages within multiple fields across trades, source systems and asset classes.

    As regulations have increased, and with more expansive data reporting on the way due to regulations such as Markets in Financial Instruments Directive (MiFID) II, financial institutions are realizing they need an efficient method to address exceptions in order to avoid penalties and minimize compliance costs.

    Annual worldwide spending on handling exceptions is estimated to be in the billions, making faster and more accurate exception resolution a significant benefit for both the revenue and cost sides of a business. Exception management can also help firms rapidly identify data errors and create a credible reputation with regulatory authorities by providing a smooth path to report correct data within a stipulated timeframe.


    Regulatory reporting exceptions can occur as a result of excessive data reporting or underreporting. Such instances are driven by reference data issues, incorrect business rules, poor transaction data quality or limited infrastructure capabilities.

    Specifically, reference data issues can arise when transactional data undergoes business rules validation and enrichment with the appropriate details configured in the reporting system. When the configuration is wrong, an exception occurs. For example, consider a scenario in which a deal fails to get registered with a trade repository because a data field contains an invalid value. Upon closer inspection, one can see that the field is populated by the wrong configuration set in the trade reporting application, resulting in an exception.

    Exceptions can also occur if business rules are not correctly implemented. For instance, a transaction for the Commodities Futures Trading Commission (CFTC) regulation may be over reported due to an undiscovered bug in the reporting system for a specific business case.

    Other major causes of exceptions are transaction data quality or internal infrastructure issues. If the incoming transaction data contains erroneous values in multiple fields, then the subsequent business rules validations are bound to fail. Further, environments that are incapable of handling large volumes of transaction loads can lead to exceptions, such as bottlenecks in processing, incomplete file generation, in-between stage misses and data reporting failures.

    These and other examples of poor exception management directly contribute to higher operational risk and inefficiencies. They also lead firms to spend more time and a majority of their budgets on managing exceptions. Poor exception management occurs when:

    • Exceptions are given equal treatment irrespective of their severity and associated risks.
    • The root cause of the exception is not identified and addressed.
    • Exception investigation is largely labor intensive and benchmark timeliness is absent to determine a resolution.
    • A common platform is not in place that users can leverage to see, track and resolve daily exceptions.
    • There is an inadequate knowledge base for handling exceptions.
    • Exception analysis and pattern identification is nonexistent.


    By discovering an exception at an early stage, firms can avoid transferring it to the processing stages of data reporting. Ultimately, this will save time, minimize the impact on resources and safeguard organizations against penalties for noncompliance. The key stages of exception management include identification, investigation, resolution and data analytics.

    1. Identification
    Exceptions need to be identified and validated as they occur to prevent them from reaching further reporting stages. Their severity is determined by running business cases that identify a deviation from the normal process flow in the system. This sets the stage for further investigation. For instance, a business user logs an issue stating that a deal already reported and successfully registered with a trade repository has bypassed certain business checks. To identify an exception, test cases are run to make a comparison and decipher the differences in the data that caused an exception.

    2. Investigation
    After an exception is identified, the focus shifts to investigating the root cause of the exception, understanding the exception’s impact and assigning a priority. Once the root cause of the exception is uncovered through test case comparisons, firms must determine the appropriate steps toward a resolution.
    The process should involve running test cases to isolate the root cause and identify the areas that have resulted in an exception.

    3. Resolution
    The resolution stage consists of the steps taken to address an exception. It requires collaboration between different entities, such as clients, front-office personnel, clearing teams and IT, and involves reusing the data and configuration structure currently in the system. If a firm discovers errors in the transaction data from the source system, the business user must correct the data and rectify the configurations in the system.

    4. Data Analytics
    Analytics help to identify the exceptions in the system that need to be fixed and the time they have been pending, using details collected from the previous stages. This process helps to capture the type of exception, the frequency of the exception, the steps taken to resolve it and the collective depiction of the pattern for the entire exception management process.

    For example, if 100 issues are reported in a particular month, data analytics would show the category of incidents reported, the associated priorities, the resolutions and a pictorial or graphical pattern depicting exception management trends. This step helps firms develop a long-term solution that will address an exception’s root cause.

    Figure 1. The dataflow in exception management.


    Regulatory reporting at the trade level requires capturing, enriching, processing and reporting multiple messages within numerous fields across trades, source systems and asset classes. Meeting these requirements and managing the growing number of exceptions pose a considerable challenge for market participants. The goal of EMRR is to identify and resolve exceptions at any stage of the regulatory reporting process in the most efficient and cost-effective manner. By designing and implementing an effective process, firms can address the need of today’s mandates and more easily tackle those from future regulations. The following best practices can help firms design their EMRR approach:

    Keep Business and Technical Exceptions Segregated
    For many firms, regulatory reporting is comprised of multiple processes to extract the final set of data that regulators demand. Since exceptions emerge at various times during the reporting cycle, it is important that the processes in exception management are independent of each other. Consider a situation in which a transaction fails in the system due to its dependency on a previously reported deal and a technical breakdown. The error should be explicitly displayed for each cause of failure along with a suggested resolution, which will ultimately save the firm time, money and resources.

    Firms should also keep the business and technical exceptions properly segregated and well depicted in the exception identification processes. An exception that occurred as a result of a business rule failure requires different expertise and experience than that of a technical exception. Keeping this separation enables the right resources to be deployed to tackle the problem from the start.

    Use a Life Cycle Approach
    The life cycle approach in exception management refers to the handling of an exception in different stages. It begins with the identification of an exception by confirming a deviation has occurred. Once detected, the exception is classified by type and a root cause analysis is performed. Resolution tactics are then developed and data is captured in different systems for data analytics.

    This life cycle approach offers many benefits. First, a structured approach in handling exceptions provides a predictable outcome. Second, exception handling can be automated for scenarios, including business rules validation and other issues, to help firms take corrective steps to address the exception’s root cause. For example, automated emails can be sent out to specific teams to immediately address the issue. Finally, the life cycle approach provides scope to tackle exceptions based on analytical outcomes and training to address common exceptions.

    Leverage Models for Greater Automation
    A model-driven approach allows the knowledge about exceptions and their resolutions to be captured for analytics in both a human-readable and machine-readable format. When these details are captured as models, the information is easier for analysts to interpret. A variety of models can be used to document the intricate knowledge in exception management, including:

    • Process models to capture data for independent business logic flow in the reporting system. If an exception is caused by a configuration error by one of the reporting entities, the process for its investigation and ultimate resolution can be standardized and used to address similar issues.
    • The classification of exceptions can be described using business rules. In regulatory reporting, determining the jurisdiction requires evaluating several parameters in incoming transactional data from the business user. The entire process to determine a reporting jurisdiction can be contained in an exception management module.
    • Exception definitions, error codes and associated document definitions can be described in error dictionaries. The entire exception handling procedure would be more efficient if the end user is able to determine the cause
      of the error and its resolution through a screen in the reporting tool that is used to identify the issue.
    • Whenever possible, firms should use automated methods to handle exceptions in the system. Consider a situation in which the transactional data to be reported fails due to issues that require a re-drop from the source. In this case, if the reporting application provides ways to correct the configuration and reprocess the data from the application, it would streamline the process and save considerable time and effort.

    Use Repositories for Effort Optimization and Analytics
    A key element of a model-driven approach is a model repository for storing and managing the various artifacts critical to exception processing. With exceptions emerging at different stages, a repository-based approach can address an exception at the point of its occurrence. In the transaction data stage, for example, a repository-based system provides an easy mechanism to rectify and reprocess the data by archiving incoming data.

    Additionally, when errors occur as a result of configuring static data used for reporting enrichment, the repository systems can provide steps to change the configuration. Further, if business rules are incorrectly implemented, the system can offer a way to correct and reprocess the rules with minimal manual intervention. Data repositories can also provide predefined methods to assist in the recovery of lost data.

    Resolve and Prevent Issues with Effective Business Process and Rules Management
    Resolving an exception is typically a complex and multi-step process. Many exceptions require human intervention, especially in the early phase of an exception management project, because it takes time to collect data and recognize different patterns that arise while processing data. As experience and knowledge of exception management increases, the exception handling process should be captured, optimized and automated. The underlying business process management (BPM) system needs to support both automated and manual process steps.

    A business rules management (BRM) system is required to support a flexible exception classification system. It is also helpful in many areas within the exception management life cycle, including data validation, skills-based workflow assignment and guided manual exception investigation utilizing decision trees. Effective BPM can help automate the steps needed to resolve recurring issues, whereas BRM can restrict invalid data with data validations and system checks.

    Apply Regular Analytics on Exception Trends to Improve Processes and Manage Costs
    Information should be logged at each step of an exception’s life cycle. Over a period of time, a repository of exceptions is created with data processing details, business rules, reference data and other key information. This repository helps balance the workload in real time based on exceptions logged over a period of time, and historical reporting for cost analysis and data analytics. The real-time information can help balance the current workload, while the historical information is useful for cost analysis and resource allocation.


    Regulatory reporting exceptions are a time-consuming and costly reality for trading firms. In an environment with a growing number of regulations and costly penalties for non-compliance, simply automating the reporting process is not enough. Financial institutions have realized that to expand the business and meet regulatory requirements over multiple jurisdictions and regulations, they need a better, more efficient way to handle exceptions. An effective, best-practice-based exception management system and process can help firms apply a more structured approach to managing and mitigating recurring exceptions. This not only helps improve the quality of data reported, it helps minimize the costs associated with exception management.

    The Authors
    Basu Bishal

    Basu Bishal
    is an Associate within Sapient Global Markets’ Solutions group based in Gurgaon. He leads a team that provides Level-2 support for multiple regulatory reporting solutions for US and UK-based clients. With over three years of experience in regulatory reporting and business consulting, he is focused on various regulatory change initiatives happening within the capital markets.

    Rohit Narula

    Rohit Narula
    is a Senior Associate at Sapient Global Markets based out of Gurgaon. He has over six years of experience designing and implementing solutions for the OTC derivatives space, as well as for the oil and gas industry. More recently, Rohit has been helping firms implement solutions for EMIR and HKMA regulations and is currently working on the analysis, design and implementation of a MiFID II solution.

    Leave a Comment