About Validation Rules

• Calculation Status. These validation rules focus on the performance calculation process itself by providing important information at various calculation checkpoints. They enable you to compare your calculated returns to benchmark returns, test your returns for sensibility, and compare returns to previous days' returns. You can also specify performance test model changes, materiality check results, commit tolerance check results, and return statuses. Validation rules based on calculation status are run by the Performance Calculation engine for the entities and effective dates you specify. Calculation Status validations should be grouped in a separate Data Quality Rule from your Data Quality validations. These rules are categorized into stage details of performance commit and return calculations.

Data Quality Validation Rules

Data quality validation rules monitor the quality of positions, entities, securities, cash activity, performance data, FX rates, and prices. You can also compare the cash activity, position, and FX rate update date to the performance update date. You can create your own tests or use a system defined test.

The following data quality system defined tests are grouped by stage detail:

• Cash Activity
  –  Cash Activity Source Check. Validates that the cash activity found is from the primary source in the source rule.
  –  Cash Activity Update Date Check. Produces an exception if cash activity has been updated after your performance returns have been committed. Compares the cash activity update date against the latest performance update date.

• Position
  –  Position Source Check. Validates that the positions found are from the primary source in the source rule.
  –  Position Update date Check. Compares the position update date against the latest performance update date to find positions that have been updated after your performance returns have been committed.

• Entity Reference
  NOTE: For entities without performance data you should use Calculation Status/Return Calcs validations to check entity reference data. 

  –  Primary Benchmark Assignment Check. Validates that an entity has a primary benchmark assigned for the specified effective date.

  –  Secondary Benchmark Assignment Check. Validates that an entity has a secondary benchmark assigned for the specified effective date.

• FX Rates
  –  Composite FX Rate Change Threshold Check. Produces an exception if the FX rate has changed beyond the threshold you defined.
  –  Null Composite FX Rate Check. Produces an exception if an FX rate is null for the effective date.
  –  Null Port/BM FX Rate. Produces an exception if an the FX rate from the benchmark to the portfolio is null for the effective date.
  –  Port/BM FX Rate Change Threshold Check. Produces an exception if the FX rate from the benchmark to the portfolio has changed beyond the threshold you defined.
  –  FX Rates Update Check. Produces an exception if an FX rate has been updated after the last time performance has been calculated.
  –  FX Rates Source Check. Determines if the FX rates found are from the primary source in the source rule.

• Performance Commit
  –  Client Side Commit Check. Produces an exception if the client side commit has been used to commit performance rather than the server side or automated commit process.

• Price
  –  Price Source Check. Produces an exception if the prices found are not from the primary price source in the source rule.

• Performance
  –  Validations can be set up with metadata to check for missing returns or returns which are out of the normal range.
  NOTE:  For entities without performance data, you should use Calculation Status/Return Calcs validations to check performance data.  

Calculation Status Validation Rules

A calculation status validation rule provides important checkpoint information about the performance calculation process. The following system defined tests are available for calculation status validation rules:

• Performance Calculation Tolerance Check. Produces an exception if a return is out-of-tolerance and committed as preliminary. The Out-of-Tolerance Preliminary commit option must be selected in the profile. 

• Materially Different and Returns Re-Committed. Produces an exception if the return is materially different and overwrites the previously committed return. The Material Difference Check commit option must be selected in the profile.

• Perf Cal Alpha Reference Check. Produces an exception if a value is produced by this field and written to the Commit Journal table. An Alphanumeric reference must be specified in the field rule.  

• Perf Cal Returns Status Check. Checks for returns not in Final status.

• Perf Calc Performance Model Check. Produces an exception if a performance calculation creates a new performance dictionary node or results in an unknown node.

• Materiality Check Not in Use. Creates an exception if a performance calculation report does not use the Materiality Check option.

• Materially Different and Commit Tolerance Failed. Creates an exception if the new return is materially different and also out-of-tolerance. The Out-of-Tolerance Preliminary and the Material Difference Check options must be turned on. 

• Materially Different in Final Commit to Alt Source. Produces an exception if the new return is materially different but the committed return is in final status. The Material Difference Check option must be turned on.  

• Materially Not Diff-Commit to Alt Source. Produces an exception if the new return is not materially different from the committed return. The Material Difference Check option must be turned on.  

• Perf Calc Numeric Tolerance Check. Produces an exception if the numeric reference amount is beyond the threshold selected when creating the validation.

Metadata Field Attributes

You can construct validation rules using metadata field attributes available in the logic builder. To be available in the logic builder, field attributes must be published to Position Reports Multi-Period.
The following types of field attributes are available, grouped by stage and stage detail:

• Data Quality Field Attributes
  –  Cash Activity. The field types available for validations are cash adjustment, holdings, detail calculation, advanced holdings, entity, and security. For example, you can use a detail calculation field to test if a security level cash flow is greater than or less than a specified percentage of the beginning market value. The detail calculation determines the percentage based on cash activity and holdings fields and the validation rule compares that percentage to a threshold percentage.  
  –  Position. You can build position security level check validation tests with position fields that use the position detail table and security fields. You can build total level validation tests with position fields that use the position table. You can test security level prices using security, advanced security, or price fields. You can build security reference validation tests using any security fields.
  –  Entity Reference. The field types available for validations are entity and entity extension. For example, you can use an entity field to test for valid inception dates by checking for dates that are null.
  –  Performance Data. The performance analysis field type is available for validating performance data. For example, you can test that an entity has a prior day committed return by using a performance analysis field to check for null values.

• Calculation Status Field Attributes
  –  Return Calcs. The field types available for validations are detail calculation, rollup, rollup calculation, and rollup inference. These field types are run with the performance calculation engine and are ideal for validating calculated returns. For example, you can test security level returns for reasonableness by using a rollup calculation field to see if any return is greater than or less than a specified percentage.