Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Current »

The ultimate goal of RDC Pricing is to produce Gold Copy Price records for a given effective date and a fixed set of securities out of raw prices received from multiple vendors, or by using prior day Gold Copy prices. To achieve this goal, RDC Prices uses Data Strategies, and the concepts of a Main Engine and Rule Engines, to process activity.

Data Strategies

Data Strategies are composite data processing rules made up of Processing Rules. Data Strategies are applied at an individual security level, while Processing Rules are defined based on individual data fields. Data Strategies work by processing activity through the below phases:

Security Selection

  • Data Strategies maintain their own security criteria.

  • Data Strategies can reference one or more security holdings (Portfolios), each with their own selection criteria.

  • The final set of securities subject to processing by a Pricing Data Strategy is determined by first applying the data strategy’s security criteria against the Securities database, then applying all Holdings security criteria to the resulting set when the Holdings criteria is selected to be applied. If holdings are not specified in the filtering criteria, all eligible securities resolved will be included.

Source Hierarchy

  • Data Strategies reference a Source Hierarchy where all participating vendor sources are arranged in order of preferred selection from 1 to N. The lowest value in the hierarchy is processed when validated during the compositing of the Gold Copy.

  • The Prior Day Gold Copy source is optional, and usually assigned the lowest level in the hierarchy for Data Management clients or when actively using Accounting, the lowest level is set as Price at Cost.

Demand Phase

  • The processes that load vendor data into the database define which prices are expected to be sourced for a specific Data Strategy.

  • The Demand Phase is executed in order to create shell records for each combination of security, source from the source hierarchy, exchange, and effective date.

  • The Demand Phase also creates a Gold Copy shell record for each combination of security and effective date.

Validation Phase

  • Data Strategies use Validation Rules to validate source prices during the Validation Phase.

  • Each Validation Rule has its own Selection Security Criteria that is used against the set of securities that was used to generate demand.

  • If a vendor price record fails validation, then it is not used later in Gold Price compositing, unless the validation error is corrected and the validation rerun.

  • Validation rules can be Global or Regular:

    • Global rules are applied to every Data Strategy using global validation rules.

    • Alternatively, Data Strategies can declare use of specific regular validation rules to target specific validation tests and bypass global rules.

Compositing and Release Phases

  • For each security, the direct outcome of the Validation Phase is the Best Vendor Source Price record.

  • The Best Vendor Source Price record is chosen based on the validation results and established source hierarchy rules.

  • During the Compositing and Release Phases, the Best Price record is converted into the Gold Copy Price record.

  • Data Strategies can use specified Enrichment Rules that are applied to the Best Price record as part of the compositing process.

Engines

An engine is a basic execution thread used by PACE servers to perform a specific task concurrently with others. Each engine has independent access to the database and other resources. RDC Prices uses the concepts of a Main Engine and Rule Engines.

Main Engine

Data Strategies are always executed by a single instance of the Main engine. The PACE server launches the Main engine when it detects a request to execute a Data Strategy. Main engines perform the following tasks:

  • Interpret data strategy security criteria to produce a list of security aliases subject to processing.

  • Determine which Data Strategy phases to be executed. For example, Demand, Validation, or Composite.

  • Launch Rule engines for each phase, using a predetermined order and established system configurations.

  • Perform necessary rule engine synchronizations.

  • Orchestrate exception handling and cleanup.

A typical set of input parameters includes data strategy identification, effective date, and the list of requested phases.

Rule Engine

The Rule engines execute specific phases of a data strategy on a limited set of securities. A typical data strategy can include an unlimited number of securities, but each rule engine only operates on a subset with a size that does not exceed the configured maximum. The number of Rule engines required for each phase is determined by the following factors:

  • The maximum number of securities processed by a single rule engine is limited through system configuration

  • One Rule engine can only process one Validation Rule per Data Strategy

A typical set of input parameters includes data strategy identification, effective date, specific phase identification, and a security alias selector. The security alias selector is either a range of security aliases, or a list of values.

  • No labels