Testing
      Back to home
      1. Knowledge Base
      2. Administration & Onboarding
      3. Testing

      Onboarding: RS Testing - Backload Testing (BT)

      There are three primary goals to keep in mind:

      1. Validate Backloading Before Production Execution
         Confirm that your historical and open trade data can be successfully loaded into KOR’s systems without structural or validation issues. This mitigates the risk of production errors during the actual backload process.
      2. Run a Reconciliation Against Your Current Trade Repository
         Reconcile your open trade state submitted to KOR with your current Trade Repository (TR) production state. This process helps:
        • Identify potential over- or under-reporting by your current TR and/or KOR.
        • Validate the correctness of field-level reporting values.
        • Inform corrective actions either pre- or post-KOR go-live.

      Note: It is essential that your “open trades” reflect the current state in your internal system of record—not simply what exists in your TR. Using stale or incomplete TR data as input undermines the accuracy of this test and misrepresents the eligibility logic.

      3. Verify KOR Reporting Configurations
      Test how KOR interprets and transforms your full current trade state, including derived fields and enrichment logic. Any gaps or discrepancies identified here can be addressed before production use.

       

      What KOR Does

        • Does a wipe of the environment
          • If Client is in dedicated environment this can be scheduled as needed
          • If the Client is operating in a shared environment, alignment with other clients will be required; however, this may not always be feasible. For this reason, amended UTIs are used for testing prior to this step.
        • Assists the Client with planning the approach for completing the backload.
        • Provides training on setting up reconciliation processes.
        • Responds to Client questions regarding reconciliation.
        • Reviews all submissions and any associated rejections through KOR’s integration team.
        • Works with the Client to identify required updates to mapping documents and implements the necessary configuration changes.
      • Identifies and prioritizes any development work or fixes required based on testing outcomes.

      What the Client Does

      • Identifies all open trades within their system.
      • Submits all open trades in accordance with KOR’s guidance on timing and process.
      • Configures and runs reconciliations with assistance from KOR.
      • Performs a full review of any mismatches and instances of over- or under-reporting, and develops a remediation plan in collaboration with KOR.
      • Works with KOR to review and approve any configuration changes identified during backload testing.

      Shared Environment Clients

      • All test trades must be configured to error out, and the UTI validation rule must be amended to align with production requirements.

      Estimated Duration:

      • Typically 1 to 4 weeks

      • Must be done after Historical Data UAT

      Items to Consider When Preparing for Backload and Parallel Testing

      • Identify Backload trade set

      KOR does not recommend relying solely on the end-point Trade Repository (TR) data for backloading, as this approach bypasses testing of the eligibility setup. The objective is to extract from your system all transactions that you expect to have been reported, or that could potentially have been reported, and that remain open. This data should then be processed through the eligibility logic and KOR configurations, allowing the system to determine which trades should or should not have been reported. The resulting output can then be reconciled against your current production reporting to validate accuracy and identify discrepancies.

      • Preserve UTIs as Currently Reported
         UTI continuity is critical for matching and regulatory audit trails. Ensure that the UTIs submitted during testing exactly mirror those in current TR submissions.
      • Review Existing Configurations and Adjustments
         Evaluate how your current trade state has been mapped to existing configurations. You may need to:
        • Adjust configuration logic to reflect nuances in your reporting.
        • Provide certain enriched or derived values explicitly in the message (e.g., Prior UTI for post-allocation trades).
        • Supply mapping tables (e.g., for value standardization or legacy data alignment).
      • Assess Completeness and Field Population
        Confirm that all relevant fields (especially conditional or jurisdiction-specific fields) are being accurately populated. Missing or misaligned values may result in validation failures or incorrect reporting downstream.

      • Plan for Reconciliation and Issue Tracking
        Establish a process to reconcile submitted test messages with KOR-generated reports and your existing TR records. Use this to pinpoint inconsistencies and prioritize configuration or source data fixes.

      KOR Backload Configuration and Treatment

      KOR will use your current reporting configurations to process the backload; however, instead of submitting this data to the live Trade Repository (TR), the messages will be pointed to the KOR backload environment. This ensures a safe and isolated test cycle.

      When backloading data through this process:

      • Trade state validations are bypassed.
        This allows you to report your latest open trade state as a full snapshot, rather than attempting to replay the entire lifecycle or historical events.
      • Only current state messages should be submitted.
        This approach avoids duplication, misalignment, or validation conflicts, and ensures that the test accurately reflects how your open positions would be reported going forward using the latest trade state and values.
      • Historical sequencing (NEWT/CORR) is not required.
        Since the backload is treated as a fresh snapshot, there is no requirement to simulate prior lifecycle messages. This helps simplify the testing process while focusing on final state accuracy.

      Reconciliation Considerations During Regulatory Change

      If you are onboarding to KOR during a major regulatory change (e.g., CDE updates, CSA Re-Write, ISO 20022 adoption), please be aware that certain fields in KOR’s reporting may not exist—or may differ in definition or format—from what is currently being reported to your incumbent TR.

      As a result:

      • Field-level reconciliation must be adjusted accordingly.
         Certain fields may need to be excluded during the reconciliation process to avoid false positives.
      • Differences may stem from regulatory updates, not configuration errors.
        Fields such as new data elements, reformatted enumerations, or changes in validation logic may appear as discrepancies even if KOR is producing the correct values for the new regime.
      • We recommend aligning the reconciliation scope to shared reporting fields under both frameworks to maximize accuracy and value during testing.

      KOR will assist in scoping and documenting any field-level exclusions needed to conduct a clean and meaningful reconciliation.

      Next Steps
      KOR recommends coordinating with your onboarding lead to review your trade population, eligibility logic, and reconciliation process before commencing the backload test. Our team is available to support configuration adjustments and answer questions throughout the testing phase.

      If reconciliation issues are identified, testing MUST also include validating the resolution process. This may involve:

      • Submitting a CORR action for open trades to correct reported data.
      • Submitting an UPDATE action for open trades to reflect required changes if there is a tech spec change.
      • Using the EROR action to remove invalid trades from the repository.
      • Reprocessing and submitting a NEWT action for trades that were missed in the original submission.