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):
- Trade Level: used when submitting transaction, public, valuation, or collateral at trade level.
- Portfolio Level: used when submitting collateral at the portfolio level.
- 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.
- 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.
- Relationship: used to populate entity static data for fields which are based on the relationship between two entities.
- 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.
- 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);
- Multiple Hub functions (left of the source field, applied when going from an ingestion to a submission)
- Multiple Reg functions (right of the source field, applied when going from a submission to a regulatory message)
- 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)
- External mappings should by default display on the UI set up and are not editable
- Implicit mappings should display on the lineage rule
- Include the output implicit mappings
- Each rule has a unique identifier that is randomly generated
- 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)
- Identifier + version is always tracked on message when applied
- Identifier + version Is visible to the client
- One Rule can be a member of zero, one, or multiple rule sets
- The same KDM field can have multiple rules although only one rule can be active within a rule set
- 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