Back Reporting: Corrective & Missed Reporting Case Studies

Addressing Back Reporting Challenges in Trade Repository Submissions

In the highly regulated financial markets, accurate and timely reporting to trade repositories (TRs) is a core obligation for firms subject to transaction reporting requirements. However, firms often encounter instances where reports are missed, incomplete, or inaccurate, necessitating a process known as "back reporting." Back reporting refers to the correction or submission of previously unreported or incorrectly reported data to the relevant trade repository after the initial reporting window has passed.

Back reporting presents significant operational and compliance challenges, including:

• Identifying reporting gaps or inaccuracies in near real-time;
• Diagnosing the root cause of reporting failures;
• Maintaining auditable processes for correction and reconciliation; and
• Minimizing regulatory risk and potential penalties associated with late or erroneous reporting.

KOR’s reporting services are designed to assist clients in both proactively identifying reporting anomalies and reactively managing the back reporting process. Through automated reconciliation tools, robust exception management workflows, and clear data lineage tracking, KOR empowers firms to:

• Detect issues earlier in the reporting lifecycle;
• Analyze and resolve breaks programmatically; and
• Ensure corrections are submitted promptly and in accordance with regulatory expectations.

This article outlines how KOR’s technology and service offering address back reporting challenges, helping firms enhance reporting accuracy, reduce regulatory exposure, and establish a more resilient compliance framework.

Key considerations when configuring rules and reconciling update outcomes:

1. If a previously ineligible trade becomes eligible, submit the record with Action Type = NEWT.
2. If a previously ineligible trade remains ineligible, no regulatory message will be generated.
3. If a previously eligible trade becomes ineligible, submit the record with Action Type = EROR.
4. If a previously eligible trade remains eligible, submit the record with Action Type = CORR.
   
   

Trades reported to an end point Trade Repository via the KOR Reporting Services application:

Case Study 1 - Misreported Messages

Scenario A - Misconfigured Rule Set in KOR

A rule configuration was misconfigured/client’s compliance has updated their interpretation of how the reporting should occur which would require a rule configuration change. 

• No new UTI is required
• No messages were missed
• Messages that were reported need to be corrected via a CORR action
  • If the configuration affects eligibility, this may result in an EROR if the message is no longer reportable, or a NEWT if it becomes newly reportable.

Assumptions:

• Trades were submitted via KOR RS
• Reprocessing the trades validations will meet the current regulatory technical specifications validations

Note: If impacted trades are not aligned with the current regulatory validation version, they will need to be upgraded—potentially through a new configuration rule set. Otherwise, any missing fields must be either resubmitted from the source system or manually updated in the report before resubmission.

Remediation Process - 1

Step 1: Identify Impacted Rules

Determine which rule(s) and rule version(s) require updates. This could involve issues with value mapping, transformation logic, or field sourcing errors.

Examples:
The “Effective Date” field was erroneously sourced from the “e_Date” header in the source data, instead 

Step 2: Correct the Impacted Configurations (e.g., Rules/Mappings)

Apply the necessary corrections to the affected rules and value mappings. Ensure the changes are properly tested and approved to guarantee accurate processing for all future messages.

Step 3: Identify Messages for Re-submission or Reprocessing

Identify messages previously processed using the impacted rule(s) or value mappings.

Considerations:

• Identify the relevant timeframe to review.
• Generate a report listing all affected messages, including the impacted rule set, rule version, and/or value mapping.
• Determine whether the impacted messages are submission messages or regulatory messages.

Submission Messages:
If the changes could impact eligibility determinations, clients should identify the affected submission message identifiers. This may include generating regulatory messages for transactions that were not previously submitted. 

Regulatory Messages:
If the changes only impact regulatory reporting, clients should identify the affected regulatory message identifiers. This helps reduce potential “duplicate message” rejections.

Step 4: Submit for Reprocessing

When submitting for reprocessing, specify a ruleset with the corrected configurations and set the action type to CORR (Correction), when NEWT or EROR would not be applicable on a change to eligibility.

Process Tip:
This can be achieved by copying the corrected rule set configuration and applying the necessary modifications to enable the correction process.

Scenario B – Incorrect Source Data in Client System

Examples:

• A required field was missing, but its validation was optional.
• Header names were switched in the client’s source system (e.g., “Leg 1 Direction” and “Leg 2 Direction” were flipped), but the enumerated values still passed validations. Although the enumerations were technically acceptable and processed by the trade repository (TR), the data was still incorrect.

Assumptions:

• Trades were submitted via the KOR Reporting Service (RS).
• The issue must be corrected in the client’s source system and resubmitted.
• No configuration changes are required in KOR.
  
  

Note:
If the issue can be resolved through a new or updated rule set rather than resubmission from the source system, the steps under Use Case 1 – Scenario A would apply.

Remediation Process - 2

Step 1: Identify the Source Data Issue
KOR may have limited visibility into the client’s upstream source data. Therefore, depending on the root cause, KOR and the client may need to collaborate to determine which records require back-reporting.

Step 2: Resubmit Corrected Data
Once the impacted data is identified and corrected, it must be resubmitted using Action Type = CORR. Upon submission, KOR will apply the relevant eligibility rules and perform pre-validation checks.

If any errors arise (e.g., invalid enumerations or missing mandatory fields), clients must follow the standard investigation process to determine whether the root cause is a configuration issue, source data quality issue, or outdated static data, and take corrective action accordingly.

If the corrected data passes all validations, KOR will generate the appropriate regulatory messages, which can then be routed to the designated TR.

Submission Options:

• Clients may set Action Type = CORR directly in their data prior to submission to KOR.
• Alternatively, clients may establish a new data feed in KOR with the same rule configuration, but with Action Type automatically defaulted to CORR to facilitate the back-reporting process.

Scenario C – Incorrect Static Data

(e.g., Configuration referenced entity or product static data via an internal identifier)

Assumptions:

• Trades were submitted via KOR RS.
• Reprocessing the trades will align them with current regulatory technical specification validations.

Remediation Process:
Follow Remediation Process 1, with the exception that the report must reference the static internal ID used and the Client must upload a corrected static data report prior to reprocessing.

Case Study 2 - Messages/Trades are identified as not reported when should have been 

Scenario A – Trades Not Received by KOR

Remediation:

1. Client generates all reportable events for each missed trade.
2. Reference an existing rule set, or create a new one if required.
3. Submit events in sequential order.

Scenario B – Trades Received, but Deemed Ineligible by Eligibility Engine

(e.g., the client disagrees with the eligibility determination based on valid values)

Remediation:

1. Run the eligibility report to identify submissions marked as non-reportable under current criteria.
2. Client proposes a rule change to Droit.
3. If Droit implements the rule change, reprocess the trades accordingly.
4. If Droit does not approve the change, reprocess using Droit override indicators.
5. Update future configurations to apply override flags on new submissions as needed.

Scenario C – Trades Received, but Valuations Missing

Assumption:
The missing valuations pertain to trades that were reported via KOR.

Remediation:

1. Run the Missing Valuations Report to identify gaps.
2. Client generates and submits the required valuation messages.
3. Rerun the Missing Valuations Report to confirm all valuations have been successfully reported.

Scenario D – Trades Received, but Collateral Missing

Assumption:
The missing collateral pertain to trades that were reported via KOR.

Remediation:

1. Run the Missing Collateral Report to identify gaps.
2. Client generates and submits the required collateral messages.
3. Rerun the Missing Collateral Report to confirm all valuations have been successfully reported.
   
   

Case Study 3 – Trades Reported with Incorrect LEIs

In this case, trades were reported with an incorrect Legal Entity Identifier (LEI) and require correction. The following remediation approaches are similar to those outlined in Remediation Process 1.

Scenario A – Incorrect LEI Submitted on Trade Message (Counterparty 2)

Remediation Steps:

1. Identify impacted trades using a report filtered by the incorrect LEI.
2. Enable configuration logic to automatically generate:
   • EROR/NEWT messages upon LEI change, or
   • CORR messages, as required by jurisdiction-specific rules.
3. Perform a bulk edit via ingestion feed or submit a correction file based on the identified population.
   
   

Scenario B – Incorrect LEI Assigned in Static Data Mapping to Internal Identifier (Counterparty 2)

Remediation Steps:

1. Identify impacted trades using a report filtered by internal identifier + LEI mapping.
2. Update static data to reflect the correct LEI.
3. Enable configuration logic to automatically generate:
   • EROR/NEWT messages upon LEI change, or
   • CORR messages, as required by jurisdiction-specific rules.
4. Perform a bulk edit via submission feed or submit a correction file based on the identified trade population.

Case Study 4 – Identifying Open Trades Requiring Upgrade Due to Regulatory Change

Scenario A – Open Trades Can Be Upgraded by Reprocessing Existing Messages to Apply Updated or Default Values

Remediation Steps:

Note: This process should be tested well in advance of the regulatory change and re-tested closer to the effective date, as the population of open trades may evolve over time.

1. Run the Open Trades Report to identify the population of trades that remain active and require upgrade (e.g., open trades report).
2. Develop a New Rule Set to apply necessary data transformations or default values.
   • This rule set can be based on an existing one but must be tailored per original rule set if the trades were processed under multiple rule sets.
   • Each original rule set must be mapped to a corresponding new rule set to ensure accurate upgrade processing.
3. Reprocess Regulatory Messages using the new rule set(s).
   • Important: Reprocessing should target only the regulatory messages (not full submissions) to avoid affecting the reporting logic for other jurisdictions, especially where reportability is not impacted.

Scenario B – Source System Must Submit Missing Data to Upgrade Trades

This applies when a regulatory update introduces new required fields that cannot be defaulted through reprocessing. These fields exist in the client’s trade capture system and must be submitted via updated trade messages.

Remediation Steps:

1. Run the Open Trades Report to identify the population of trades that remain active and require upgrade.
2. Develop a New Rule Set that incorporates the updated regulatory logic and field requirements.
   • This rule set is typically a copy of the existing rule set, modified to meet the new validation requirements.
   • If multiple original rule sets were used, corresponding upgrade rule sets should be created.
3. Submit the Affected Trades from the Source System using the applicable upgrade rule set.
   • Note: If applicable, static data rule sets (e.g., entity or product mappings) must also be reviewed and updated prior to submission to ensure consistency and avoid validation issues.

Scenario C – Manual Update or Export of Regulatory Messages to Upgrade Trades

This scenario mirrors Scenario B, but the client is unable to resubmit the updated trades from their source system. Instead, the remediation is performed through manual intervention.

Remediation Steps:

1. Export the Relevant Submission Messages from KOR per the open trades report.
2. Manually Update the Exported Report to include the missing fields required by the regulatory change.
3. Submit the Corrected Messages using the same process outlined in Scenario B, ensuring they are routed through the appropriate rule set.

Case Study 5 – Trades Reported to an Endpoint Trade Repository Outside of KOR (e.g., Prior to Using KOR)

When a client identifies a reporting issue related to trades submitted before transitioning to KOR Reporting Services, the remediation may either:

• Be addressed as part of the initial integration scope (if identified in advance), or
• Require a new Statement of Work (SOW) if discovered post-onboarding—handled either as a one-off effort or as part of ongoing managed change.

KOR does not generally backload trades beyond open swaps during onboarding because:

• Each backreporting scenario typically requires one or more new rule sets tailored to the specific issue.
• If no reporting issue is identified, it is inefficient to proactively load historical trades due to evolving regulatory validations.
• A trade that is no longer open at the time of a regulatory change is not subject to automatic upgrade, but any correction to that trade must conform to the current regulatory validation rules.
  
  

Remediation Steps:

1. Client Identifies the Reporting Issue.
2. Client Determines the Scope of impacted trades and associated jurisdictions.
3. Client Engages with KOR to define a remediation plan and work scope.
4. Rule Set Development:
   • KOR and the client collaborate to build new rule sets for backreporting, or
   • The client may use self-service configuration tools to implement the rule sets.
5. Client Submits Trades using the newly created rule sets for KOR to send the correction to the endpoint TR.