1. Knowledge Base
  2. Reporting Services

Reporting Services Terminology

What key terms should I be familiar with in order to configure reporting to KOR from my internal system?


  • Data Feed: Is a set of configurations that are invoked on a submission. The components that make up a Data Feed include:
    • Name: Client defined name to help the Client understand the purpose of the feed selected.
    • Feed Type: Defines a source of data (only one per data feed): 
      1. Trade Level: used when submitting transaction, public, valuation, or collateral at trade level. 
      2. Portfolio Level: used when submitting collateral at the portfolio level. 
      3. Entity: used to populate entity-level static data.  The static data can be used to enrich a trade-level submission or a portfolio-level submission. 
      4. Product Static: used to populate product static data.  The product static data can be used to enrich a trade-level submission or a portfolio-level submission. 
      5. Relationship: used to populate entity static data for fields which are based on the relationship between two entities. 
      6. Reference Data: Unstructured data used for enrichment in a Trade Level, Portfolio Level data feed. Reference data feeds do not have rule sets.  The reference data is used for enrichment in the other Data Feeds. 
    • Source System: Client vendor or proprietary data supply made available to KOR 
    • Delivery Mechanism: how the data can be transmitted to KOR. e.g., API, SFTP, UI (file upload).
      • More than one can be selected. For example, if a Client typically uses the API but their feed id is down if they have UI selected they can manually upload their xml via the UI. 
    • Rule Set: A group of configuration rules selected to apply to the data feed. Only one rule set can be selected at a single time, but multiple can be associated. For example, a rule set may be updated when validations are changed by the regulator. 
    • Supplemental data: can be specified for any of the above data feed types except Reference data. 
      1. If supplemental data included then filter logic and join logic must be specified. 


  • Rule Sets: groups implementation details for the applicable fields per mandate(s) (jurisdiction + message types) and end points.  Multiple rule sets can be created to assist with system and / or regulation changes.  
    • Feed type: must match the feed type for data feeds. Indicates the level of uniqueness at the Submission level (Client Trade Identifier, Client Order Identifier, Portfolio Code(s) or Internal Identifiers).  
    • Jurisdiction: Indicates the applicable jurisdictions for the rule set.  
    • Message Types: Transaction, Public, Trade, Order, Valuation or Collateral.  
    • Target Format: Lists the end point repositories applicable to the clients services (KOR SDR, DTCC GTR etc.). 
  • Rules: configurations used to transform submitted data
    • When creating a rule, you can to assign the rule to an existing or new ruleset, or multiple rulesets, while being made aware which ruleset is active for which data feed. 
    • Within one rule you can have explicit mappings (the rules configured in the UI);
      1. Multiple Hub functions (left of the source field, applied when going from an ingestion to a submission)
      2. Multiple Reg functions (right of the source field, applied when going from a submission to a regulatory message)
      3. If no specific Mandate is indicated then applies to all on the message 
    • And implicit mappings (the mapping based on the Airtable which gets applied in conjunction with the explicit mappings)
      1. External mappings should by default display on the UI set up and are not editable
      2. Implicit mappings should display on the lineage rule
      3. Include the output implicit mappings
    • Each rule has a unique identifier that is randomly generated
      1. New rule identifier is generated when the rule is created and increments the version upon rule change (does not apply to note change, or card placement change)
      2. Identifier + version is always tracked on message when applied
      3. Identifier + version Is visible to the client
    • One Rule can be a member of zero, one, or multiple rule sets
      1. The same KDM field can have multiple rules although only one rule can be active within a rule set 
      2. By assigning a rule to multiple rule sets, updates to the rule will be applicable for all rule sets (they point to the same rule reference). If this is undesired, a rule for the specific field should be set up separately and linked to the different rule sets.
    • A rule can only be associated to a single Feed Type (i.e. Trade, Portfolio, Entity or Static). 
    • Statuses: 
      • Active 
      • Inactive 
      • Archived