2018年-ECB欧洲央行_AnaCredit_Validation_Checks_–_Selected_validation_checks_performed_in_AnaCredit_datasets_–_Version_11_39页_1mb
报告摘要
AnaCredit Validation Checks Summary
Introduction
This document outlines the main validation checks used to ensure data quality in AnaCredit, complementing the AnaCredit Reporting Manual. It provides detailed explanations of the rules and logic behind these checks, which are essential for maintaining the completeness and consistency of data in accordance with the AnaCredit Regulation. The document is not legally binding but serves as a guide for reporting agents to enhance their data quality management systems.
The validation checks are categorized into three main types:
- Referential Integrity Checks
- Completeness Checks
- Consistency Checks
These checks are based on the AnaCredit data model and ensure that the data reported aligns with the regulatory framework. Some checks may be subject to national derogations, and additional checks may be implemented by NCBs beyond the minimum standard.
Main Validation Check Categories
1. Referential Integrity Checks
These checks ensure that the information reported to AnaCredit is consistent across related datasets. They are executed based on the dataset being examined and the relationships between records.
Key Features:
- Ensures the existence of necessary records across associated datasets.
- Applies to static datasets, where the presence of a record in AnaCredit is checked, not the transmission itself.
- Some checks are executed quarterly or based on specific conditions.
Examples of Referential Integrity Checks:
| Validation Identifier | Triggering Dataset | Referential Dataset | Description |
|---|---|---|---|
| RI0030 | Financial | Instrument | A financial record must have a corresponding instrument record. |
| RI0040 | Financial | Accounting | A financial record must have a corresponding accounting record, executed quarterly. |
| RI0050 | Financial | Counterparty-instrument | A financial record must have a counterparty-instrument record for a creditor. |
| RI0060 | Financial | Counterparty-instrument | A financial record must have a counterparty-instrument record for a debtor. |
| RI0070 | Financial | Counterparty-instrument | A financial record must have a counterparty-instrument record for a servicer. |
| RI0090 | Instrument | Financial | An instrument record must have a corresponding financial record. |
| RI0100 | Accounting | Financial | An accounting record must have a corresponding financial record. |
| RI0110 | Counterparty-instrument | Financial | A counterparty-instrument record must have a corresponding financial record. |
| RI0120 | Joint liabilities | Financial | A joint liabilities record must have a corresponding financial record. |
| RI0121 | Joint liabilities | Counterparty reference | A joint liabilities record must have a corresponding counterparty reference record. |
| RI0130 | Instrument-protection received | Financial | An instrument-protection record must have a corresponding financial record. |
| RI0140 | Counterparty reference | Counterparty reference | If a counterparty has a head office, its reference data must be reported. |
| RI0150 | Counterparty reference | Counterparty reference | If a counterparty has an immediate parent, its reference data must be reported. |
| RI0160 | Counterparty reference | Counterparty reference | If a counterparty has an ultimate parent, its reference data must be reported. |
| RI0180 | Counterparty-instrument | Counterparty reference | A counterparty-instrument record must have a corresponding counterparty reference record. |
| RI0190 | Counterparty default | Counterparty-instrument / Protection received | A counterparty default record must have a counterparty-instrument record for a debtor or a protection received record. |
| RI0200 | Counterparty risk | Counterparty reference | A counterparty risk record must have a corresponding counterparty reference record. |
| RI0201 | Counterparty risk | Counterparty-instrument / Protection received | A counterparty risk record must have a counterparty-instrument record for a debtor or a protection received record. |
2. Completeness Checks
These checks ensure that all required attributes are reported for each element in the AnaCredit data model. They are divided into two subcategories:
- Counterparty Reference Dataset Checks
- Credit Relevant Dataset Checks
Key Features:
- Completeness checks are based on the scenarios outlined in Annexes II and III of the AnaCredit Regulation.
- Some attributes may be exempt from checks if they are subject to derogations by NCBs.
- LEI and national identifiers are always checked for completeness, even if flagged as optional.
Changes in Version 1.1:
- Removed CC0160, CC0170, and CC0180 from Table A and B.
- Removed CC0100 and CC0110 from Table C and D.
- Added CD0060 based on AnaCredit Q&As.
- Removed CT0350 as it forms the primary key.
3. Consistency Checks
These checks ensure that the values of data attributes are logically consistent with each other and with the AnaCredit data model. They are based on the relational structure of the datasets.
Key Features:
- Verifies that values reported are consistent with each other.
- Addresses "non-applicable" values where relevant.
- Some checks are conditional and depend on the submission frequency or reference dates.
Changes in Version 1.1:
- Removed CN0380 due to inconsistency.
- Added CN0852, CN0865, CN0875, CN0876, CN0901, CN0913, CN0914 regarding "Non-applicable".
- Adjusted CN0540, CN0550, CN0701, CN0801, CN0805, CN0806, CN0807, CN0809, CN0827 for syntax improvements.
- Removed CN0592 due to redundancy.
- Adjusted CN0650, CN0802, CN0808, CN0812, CN0813 based on AnaCredit Q&As.
Key Definitions and Concepts
- Validation Identifier: A unique code for each check, used to identify and communicate the check.
- Logical Operators: Used to define the conditions and relationships between datasets and attributes (e.g., IF, THEN, WHERE).
- "EXISTS IN": Indicates that a record in one dataset must have a corresponding record in another dataset.
- "DOES NOT EXIST IN": Implies that a record is not present in the corresponding dataset.
- "UNION": Used to indicate that a record may exist in one of two datasets.
- "IN" and "NOT IN": Used to check for the presence or absence of specific values within a dataset.
- "IF AND ONLY IF": A bi-directional check that ensures both directions of a relationship are valid.
Conclusion
The AnaCredit Validation Checks document provides a comprehensive framework for ensuring data quality in AnaCredit reporting. It outlines the core validation categories (referential integrity, completeness, and consistency) and includes detailed definitions and examples. The checks are based on the AnaCredit data model and regulation, and they are subject to national derogations and potential updates. Reporting agents are encouraged to align their data quality systems with these checks to ensure compliance.
试读结束,高清完整版pdf/doc/ppt,请点下载