2017年-ECB欧洲央行_AnaCredit_Validation_Checks_-_Selected_validation_checks_performed_in_AnaCredit_datasets_Version_10_35页_507kb
报告摘要
AnaCredit Validation Checks Summary
1. Introduction
This document serves as a supplement to the AnaCredit Reporting Manual, explaining the main set of validation checks that ensure data quality for transmission to AnaCredit. It outlines the rules and methodologies for validating data against the AnaCredit data model and Regulation (EU) 2016/867. The validation checks are not legally binding but are essential for maintaining data completeness and consistency. The document also notes that NCBs (National Competent Bodies) may implement additional checks or apply national derogations as per the AnaCredit Regulation.
The validation checks are divided into three main categories:
- Referential integrity checks
- Completeness checks
- Consistency checks
These checks are based on the logical structure of the AnaCredit data model and are designed to ensure that all data reported is in line with the regulatory framework.
2. Main Validation Check Categories
2.1 Referential Integrity Checks
These checks ensure that the data reported to AnaCredit is consistent with the relationships defined in the AnaCredit data model. They are triggered based on the dataset being examined and are designed to confirm that necessary records exist across related datasets.
- Purpose: Ensure that the information reported is logically connected and consistent across datasets.
- Scope: Focus on the existence of records in related datasets (e.g., Financial, Instrument, Accounting, Counterparty-instrument, etc.).
- Key Features:
- Some checks are conditional and only executed if certain attributes are present.
- They are applied in a sequential manner rather than simultaneously.
- They ensure that a record in one dataset has a corresponding record in another.
2.2 Completeness Checks
These checks verify that all required attributes are reported for each element. They are divided into two subsets:
-
Counterparty reference dataset completeness checks
-
Credit relevant datasets completeness checks
-
Purpose: Ensure that all necessary attributes are reported for each element.
-
Scope: Based on scenarios defined in Annexes II and III of the AnaCredit Regulation.
-
Key Features:
- Some attributes may be exempt due to national derogations.
- Completeness is not checked for certain attributes where national discretion applies.
- The checks are structured to reflect the different roles and relationships of counterparties and instruments.
2.3 Consistency Checks
These checks ensure that the values of data attributes are logically consistent with one another and with the relationships defined in the AnaCredit data model.
- Purpose: Ensure that data values are internally consistent and align with the conceptual framework.
- Scope: Cover all attributes and their interrelationships across datasets.
- Key Features:
- They validate that values reported for one attribute do not contradict those for another.
- They consider different reference dates and submission frequencies.
- They address cases where certain concepts are not applicable to specific attributes.
3. Key Validation Check Details
3.1 Referential Integrity Examples
| Validation ID | Trigger Dataset | Referential Dataset | Description |
|---|---|---|---|
| RI0030 | Financial | Instrument | A financial record must have a corresponding instrument record. |
| RI0040 | Financial | Accounting | A financial record reported in the last quarter must have a corresponding accounting record. |
| RI0050 | Financial | Counterparty-instrument | A financial record must have a counterparty-instrument record for the creditor. |
| RI0060 | Financial | Counterparty-instrument | A financial record must have a counterparty-instrument record for the debtor. |
| RI0070 | Financial | Counterparty-instrument | A financial record must have a counterparty-instrument record for the 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, a reference record for it must exist. |
| RI0150 | Counterparty reference | Counterparty reference | If a counterparty has an immediate parent, a reference record for it must exist. |
| RI0160 | Counterparty reference | Counterparty reference | If a counterparty has an ultimate parent, a reference record for it must exist. |
| RI0180 | Counterparty-instrument | Counterparty reference | A counterparty-instrument record must have a corresponding counterparty reference record. |
| RI0190 | Counterparty default | Counterparty reference | A counterparty default record must have a corresponding counterparty reference record. |
| RI0191 | Counterparty default | Counterparty-instrument / Protection received | A counterparty default record must have a counterparty-instrument record for the debtor or a protection received record for the protection provider. |
| 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 the debtor or a protection received record for the protection provider. |
| RI0210 | Protection received | Counterparty reference | If a protection provider is reported, a counterparty reference record for that provider must exist. |
| RI0220 | Protection received | Instrument-protection received | A protection received record must have a corresponding instrument-protection received record. |
4. Summary of Key Concepts
- Validation identifier: A unique code for each check, used to identify and communicate validation rules.
- Triggering dataset: The dataset that initiates the validation check.
- Referential dataset: The dataset that must contain a corresponding record.
- Qualifier: Conditions that determine when a check is executed (e.g., based on specific attribute values).
- Logical operators: Used to define the relationships between datasets and attributes (e.g.,
EXISTS IN,NOT IN,IF,THEN,UNION). - Temporal variables: Used to reference different reporting periods (e.g.,
T,T-1,T-3). - Derogations: Certain data attributes may be exempt from validation checks based on national discretion or regulatory exceptions.
5. Conclusion
This document outlines the core validation checks for AnaCredit datasets, emphasizing the importance of referential integrity, completeness, and consistency. These checks are essential to ensure that data transmitted to AnaCredit is accurate, complete, and logically consistent. While the checks are based on the AnaCredit Regulation and Reporting Manual, NCBs may apply national derogations or implement additional checks. The structure and logic of the checks are designed to reflect the complex relationships between datasets and attributes, ensuring that all data aligns with the AnaCredit data model.
试读结束,高清完整版pdf/doc/ppt,请点下载