Jake note - details pulled from Pricing Tables and Pricing Center Whitepaper docs attached to below JIRA:
https://eagleinvsys.atlassian.net/browse/DOC-1631
RDC Prices allows you to validate and composite security pricing data from external vendors and internal sources, creating one or more "Gold Copies" that downstream systems can leverage. At a high-level, a traditional pricing workflow consists of the below steps:
...
A more detailed description of each step in the workflow follows.
Demand Prices
Create Demand
The first step in a pricing workflow is to identify the securities for which prices are required. During the create demand phase, the data strategy criteria are evaluated to determine which security prices to request. Criteria can consist of security criteria and holding criteria, or just security criteria. For each security evaluated, a shell record is created in the composite SECURITYDBO.PRICE tablefor the security, composite field, and composite source. A record is also created in the price vendor table for each security, price type, exchange, and vendor source defined in the vendor source rule for the data strategy.
...
Value | Description |
|---|---|
0 | Demand Created |
6 | Securities Requested |
5 | Price is loaded (record not validated) |
2, 3, 4, and 7 | After running validation |
2 | Pass With Warnings |
3 | Hold |
4 | Pass |
7 | Skip |
Vendor Request
Once the list of securities is determined, the security data is converted into a vendor required format, and a requestor file is created. These requestor files include security details such as the Primary Asset ID, Base Currency, and Exchange. They are then typically sent out to the respective vendors at a scheduled time. After requesting files from a vendor, the final validation status is modified to ‘6-Securities Requested’ in the PRICE_STATUS table.
Vendor Response
After vendors receive the requestor files, they send back a price response file. A basic vendor file validation is done to make sure that the correct data was received. This initial basic validation is only related to checking that the data file is valid. These checks oftentimes include checking for an empty file, junk file, or number of records in a file.
Load Prices
The vendor files are then loaded via a client’s preferred ETL methodology, such as an EagleML stream. These typically include business logic, such as a current date check. The ETL process then passes the information to the relevant fields in the panels, which receive the values, and load them to the Eagle tables. The panels typically include additional business checks.
...
| Info |
|---|
Prices only load to the PRICE_STATUS table if demand had been generated Within EagleML, there is a flag required to route to the RDC process defined as useRdcPricing which must be set to Y on the record or a global value W_USE_RDC_PRICING that may be set as part of the system configuration. Global parameters should be specified in the /eagle_ml-2-0_custom_cm/w_config_custom.inc. |
Validate Prices
...
In this stage, the prices that were received from various vendors are then checked against pre-determined rules contained in the Price Data Strategies. These rules are set to catch any discrepancies, or large price movements. When a Price Data Strategy is submitted for the validation phase, validation test results post to the RULESDBO.PRICE_VALIDATION_STATUS_DETAIL table.
Based on Data Strategy release logic and the results of the individual test, the PRICE_STATUS.FINAL_VALIDATION value updates. This result determines whether the price record has a proper value to composite, if it is the highest record in the hierarchy. The system value for this column joins to the RULESDBO.PRICE_EDIT table to display the description such as Released to determine whether it should be composited.
See Manage Reference Data Center Pricing Validations
Review Exceptions
Once prices have been loaded, analysts typically review the exceptions, and decide to override data, or release exceptions. Users can review data, approve validation edits, and make any necessary price changes. Pending User Entitlements, when applying overrides, Comments and a Reason for the Override may be required as well as the ability to add attachments.
Hierarchy Determination
At this point in the process, prices from various vendors have been loaded for each security. Now vendor hierarchy rules are run to determine final prices for a security and Gold Copies are created. The Gold Copy prices are loaded to the PRICE table.
| Info |
|---|
Different funds can have different rules in terms of vendors. As a result, there can be multiple Gold Copies per security and there may be multiple Data Strategies. For example, both Fund A and Fund B hold Apple stock, but Fund A wants to use Bloomberg prices, and Fund B wants to use IDC prices. As a result, the PRICE table stores both the Bloomberg and IDC prices. |
Composite Gold Copy Prices
The final phase is the Composite/Enrichment phase. Post the validation phase, a composite of the data strategies needs to be executed to produce the best of breed price. The composite phase identifies the highest price record in the data strategy’s source rule in a validation status allowed to composite for each security. During this phase, enrichments are also applied to the relevant records. When a Price Data Strategy is submitted for the Composite Price phase, the RULESDBO.PRICE_RULE_SECURITIES, RULESDBO.PRICE_WIP, and SECURITYDBO.PRICE tables are updated with successfully composited prices. If setup in the source rule and defined within the hierarchy, if no Vendor Price is Released for validation, a security may be Priced at Cost. Complete records flow downstream once this phase is complete.