{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":18594,"path":"governance-risk-compliance/third-party-risk-management/tprm-validation-roi.md","title":"Validation framework for Register of Information","bundle":null,"doc_type":null,"release":"australia","body":"\n# Validation framework for Register of Information\n\nThe validation framework helps ensure that RoI packages meet regulatory requirements defined by the DORA.\n\n## Validation overview\n\nThe validation framework for the Digital Resilience Third-party Information Register application helps ensure that downloaded RoI packages comply with the structural, formatting, and data integrity requirements defined by the DORA. It supports a real-time, three-level validation system that automatically checks for technical accuracy, regulatory alignment, and business rule compliance during the upload process.\n\n-   Level 1 \\(Technical checks\\): 29 rules validating file encoding, structure, and naming.\n-   Level 2 \\(Data package mode technical checks\\): 12 rules ensuring template and schema alignment.\n-   Level 3 \\(Data package model business rules\\): 70 rules verifying regulatory logic and field dependencies.\n-   Level 4 \\(LEI validation\\): Batch validation of all Legal Entity Identifier codes in the package against the GLEIF database, verifying existence, entity status, registration status, and name and country consistency. Results are included in a downloadable `Level4_LEI_Validation_Report.csv` file in the `Consolidated_Reports.zip` attachment. For more information, see [Validate Legal Entity Identifier codes for DORA reporting](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/governance-risk-compliance/third-party-risk-management/tprm-valid-lei.md) and [Level 4 LEI Validation Report columns](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/governance-risk-compliance/third-party-risk-management/tprm-lei-validation-report.md).\n\n**Note:** The Data Package Model is used to structure and validate RoI packages. TPR admins \\[sn\\_vdr\\_risk\\_asmt.vendor\\_risk\\_admin\\] can view and maintain the DPM business validation rules and related configuration properties by navigating to **All** > **Digital Operational Resilience Management** and then selecting **Properties** or **DPM Business Validation Rules**. For a description of these properties and configuration files, see [Register of information regulatory packages](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/governance-risk-compliance/third-party-risk-management/tprm-dora-roi.md).\n\n## Validation process\n\nValidation is performed automatically when a Register of Information \\(RoI\\)Plain-CSV reporting package is uploaded. As soon as the ZIP package is uploaded using a download/upload request, the system initiates real-time validation without requiring a separate request type. The system performs checks across multiple dimensions:\n\n-   File-level validation: Supports correct encoding, naming conventions, and file structure.\n-   Template-level validation: Verifies that required templates are present and formatted correctly.\n-   Field-level validation: Applies rule expressions to check for missing values, incorrect formats, and invalid references.\n\nValidation results are returned in a downloadable report that includes:\n\n-   Mappings to regulator fields such as Template Code, Row Code, and Column Code.\n-   Rule expressions and descriptions.\n-   Real-world field labels and record identifiers.\n-   Row-level error summaries.\n\nThird-party risk managers \\(sn\\_vdr\\_risk\\_asmt.vendor\\_risk\\_manager\\) can review downloaded RoI packages using the same Plain-CSV Report Package option. After a validation report is generated for a Register of Information \\(RoI\\) package, the system automatically sends an email notification to whoever initiated the download or upload request. This email alerts the user that the process has been completed and provides access to the results. If validation warnings are detected, both the validation report and the CSV package are attached to the request record. If no issues are found, only the CSV package is included. This automated notification helps ensure timely awareness and facilitates efficient follow-up actions for compliance and data correction workflows.\n\nValidation checks help identify structural and business‑rule issues based on DORA‑aligned specifications. Validation results don't represent a regulatory determination, and supervisory authorities may apply additional or updated checks when reviewing submitted data.\n\nTo assist with error resolution, you can cross-reference the validation report with downloadable master templates that mirror the CSV structure. These templates help identify the location and context of each issue, making it easier to correct data in the ServiceNow instance or source system. Validation reports are only generated when errors or warnings are detected. If no issues are found, only the CSV package is returned.\n\nTo improve troubleshooting, the system maps rule expressions to real-world field labels and record identifiers. Even when malformed data is uploaded, the validation API returns meaningful error messages to help you identify and resolve issues efficiently.\n\nExcel master templates are available for download from the **Download/Upload Request** page. These templates mirror the expected CSV structure and provide field definitions, formats, and sample values to assist with validation and error resolution.\n\n## Data quality warnings\n\nStarting with version 23.0.x, several business-rule checks are added to RoI validation for contracts and third-party service providers. Register of Information \\(RoI\\) data quality warning messages are collected in a dedicated `Data_Quality_Warnings.csv` file included in the `Consolidated_Reports.zip` attachment, in addition to appearing in the request record's message field. The following checks generate data quality warnings during Plain-CSV reporting package generation. These checks generate warnings only; they don't block CSV package generation.\n\n-   Supplier identifier consistency: For the same contract, the service provider code in template B\\_02.02 must match the Rank 1 service provider code in template B\\_05.02. The type of ICT services in template B\\_02.02 must also match the Rank 1 type in template B\\_05.02. A mismatch in either field generates a warning.\n-   Duplicate Rank 1 supply chain records: Each contract should have exactly one Rank 1 supply chain record. Duplicate Rank 1 records for the same contract generate a warning.\n-   Orphaned overarching contracts: A contract with contract type set to **Overarching** must have at least one **Subsequent or associated** contract that references it. If no subsequent contract references an overarching contract, the system generates a warning.\n-   Missing overarching contract reference: A contract with contract type \\(template B\\_02.01, field C0020\\) set to **Subsequent or associated** must reference its overarching contract in the corresponding field \\(template B\\_02.01, field C0030\\). If a subsequent contract has no overarching contract reference, the system generates a warning categorized as Missing Overarching Reference. This check is the inverse of the orphaned overarching contracts check above: that check looks for an overarching contract with no subsequent contract pointing to it, and this check looks for a subsequent contract with no overarching contract reference.\n-   Missing assessments: A contract reported in template B\\_02.01 must have at least one corresponding assessment in template B\\_07.01. If a contract has no assessment, the system generates a warning.\n-   Missing Rank 1 supply chain records: A contract reported in template B\\_02.01 must have at least one corresponding Rank 1 supply chain row in template B\\_05.02. This is a defensive check for edge cases such as data migration or backend scripts; a Rank 1 record is normally created automatically when a contract is created. If a contract has no Rank 1 row, the system generates a warning.\n-   Supply criticality consistency: A function marked as critical in template B\\_06.01 requires matching criticality in related templates, evaluated as two categories of checks against template B\\_02.02 fields. Field consistency: sensitiveness of stored data and level of reliance can't both be set to a low value, and the B\\_07.01 exit strategy field can't be set to **No**. Conditional mandatory fields: when the function is critical, fields C0100, C0110, C0120, and C0180 become required. When storage of data \\(field C0140\\) is set to **Yes**, fields C0150 and C0160 also become required. Field C0170 becomes required when the function is critical and storage of data is **Yes**. A missing required field or an inconsistent value generates a warning.\n-   Country-specific codes: Legal-person third-party identifiers that use a country-specific code, such as CRN, VAT, NIN, or PNR, instead of an LEI or EUID generate a data quality warning. The record is not blocked. The primary and additional code type fields are evaluated independently. A single record can generate a separate warning for each field if both use a non-LEI/EUID code type. The warning appears in three places: as a field-level message on the **Type of code** fields, in the upload request's result message when importing third parties, and in the `Data_Quality_Warnings.csv` file.\n\n**Note:** Fields `B_02.02.0100` and `B_02.02.0110` accept a value of `0`.\n\n## Common validation issues\n\nRefer to the following guidance to troubleshoot common validation issues when submitting RoI packages.\n\n-   Validation report is missing: The uploaded package contains no errors or warnings. Check the **Result** section of the request. If no issues are found, only the CSV package is returned and no validation report is generated.\n-   Missing required fields: One or more required fields are empty or incorrectly formatted. Open the validation report and locate the affected row and column. Use the master template to identify the correct field name and expected format. Update the record in the ServiceNow instance or source system and revalidate.\n-   Rule expression failures: The data violates one or more business rules defined in the validation framework. Review the rule expression and description in the validation report. Use the record identifier to locate the affected record and correct the data. Common issues include invalid LEI formats, empty currency fields, or missing contract references.\n-   Invalid use of “Not applicable” values: These values are used in fields that don’t support them. Check the field definition in the master template. Replace “Not applicable” with a valid value or remove it if the field is required. Revalidate the updated package.\n-   Validation report is difficult to interpret: The report lacks context or field labels are unclear. Download the master template and use it to cross-reference the row number, sheet name, and record identifier. This helps locate the affected record and understand the validation error in context.\n-   File size or encoding issues: The uploaded ZIP file exceeds the 5-MB limit or uses unsupported encoding. Compress the file to meet the size requirement and verify all CSV files use UTF-8 encoding. Re-upload the corrected package.\n\n"}}