Common use of Validation of completeness Clause in Contracts

Validation of completeness. The metadata checksum file is part of the files to be submitted. For each entity type, the required type of checksum is listed. For now, only, a logical row count is requested for each entity type that is logically part of the reporting requirement. The entity types that are part of the reference data do not require a rowcount. All entity types whose rowcount is to be reported is marked with a rowcount reporting indicator value set to “entity type with reported rowcount”12. This rowcount indicates the number of instances of an entity type that is appropriate to this entity type in accordance with the logical data model. Please note that this concerns the entity types in the logical data model where the attribute ‘reporting reference date’ is part of the primary key, and not only those entity types in the physical data deliveries. The logical data model also requires a row count and checksum for those entity types that do not have a corresponding .csv file to be delivered. 2.6.6.1 Example of a check on a physical delivery E.g. the reporting agent must report on exactly 100,000 instruments. The instrument.csv file contains 100,000 rows, excluding the header. The row count for the logical entity is 100,000. The entity type delivery lists a row count of 100,000 for the "instrument" entity type. DNB checks that 100000 = 100000 and accepts the delivery. 2.6.6.2 Example of a check on a logical delivery The entity type "instrument not past due" does not have its own specific features or relations, and therefore does not require physical delivery. However, the logical checksum of all not past due instruments must be delivered. For example, the reporting agent must report on exactly 100,000 instruments (with 100,000 financial data), 10,000 of which are instrument past due and 90,000 are instrument not past due (100,000-10,000). These files must be reported: 1. instrument.csv with 100,000 records 2. financial_data.csv with 100,000 records 3. instrument_past_due.csv with 10,000 records These records must be reported in the entity type delivery: Instrument 100,000 financial data 100,000 instrument past due 10,000 instrument not past due 90,000 DNB checks that instrument.csv contains 100,000 rows, that financial_data.csv contains 100,000 rows, that instrument_past_due contains 10,000 rows and that 90,000 rows in instrument.csv logically consist of instruments not past due. 12 The rowcount reporting indicator for the entity types can be found in the ‘RRE business terms’, sheet ‘entity type’. 2.6.6.3 Check on primary key The LDM has entity types that allow DNB to ask for checks on combinations of attributes. This mechanism is primarily meant to check the integrity of primary keys of the entity types in the logical data model. Currently, no checks of these types are foreseen, since DNB will rely instead on the hashing of the csv files themselves, in combination of the checks on the referential integrity as specified in the logical data model. This entails that the file attribute_combination_delivery.csv must be reported as an empty file. Nevertheless, the header is mandatory.

Validation of completeness. The metadata checksum file is part of the files to be submitted. For each entity type, the required type of checksum is listed. For now, no checksum is requested, only, a logical row count is requested for each entity type that is logically part of the reporting requirement. The entity types that are part of the reference data do not require a rowcount. All entity types whose rowcount is to be reported is marked with a rowcount reporting indicator value set to “entity type with reported rowcount”12type. This rowcount count indicates the number of instances of an entity type that is appropriate to for this entity type in accordance with the logical data model. Please note that this concerns the entity types all entities in the logical data model where the attribute ‘reporting including reference date’ is part of the primary key, data and entity types like “entity type delivery” and not only those entity types in the physical data deliveries. The : the logical data model also requires a row count and checksum for those entity types that do not have a corresponding .csv file to be delivered. 2.6.6.1 2.7.6.1 Example of a check on a physical delivery E.g. the reporting agent must report on exactly 100,000 instruments. The instrument.csv file contains 100,000 rows, excluding the header. The row count for the logical entity is 100,000. The entity type delivery lists a row count of 100,000 for the "instrument" entity type. DNB checks that 100000 = 100000 and accepts the delivery. 2.6.6.2 2.7.6.2 Example of a check on a logical delivery The entity type "instrument not past due" does not have its own specific features or relations, and therefore does not require physical delivery. However, the logical checksum of all not past due instruments must be delivered. For example, the reporting agent must report on exactly 100,000 instruments (with 100,000 financial data), 10,000 of which are instrument past due and 90,000 are instrument not past due (100,000-10,000). These files must be reported: 1. instrument.csv with 100,000 records 2. financial_data.csv with 100,000 records 3. instrument_past_due.csv with 10,000 records These records must be reported in the entity type delivery: Instrument 100,000 financial data 100,000 instrument past due 10,000 instrument not past due 90,000 DNB checks that instrument.csv contains 100,000 rows, that financial_data.csv contains 100,000 rows, that instrument_past_due contains 10,000 rows and that 90,000 rows in instrument.csv logically consist of instruments not past due. 12 The rowcount reporting indicator for the entity types can be found in the ‘RRE business terms’, sheet ‘entity type’. 2.6.6.3 Check on primary key The LDM has entity types that allow DNB to ask for checks on combinations of attributes. This mechanism is primarily meant to check the integrity of primary keys of the entity types in the logical data model. Currently, no checks of these types are foreseen, since DNB will rely instead on the hashing of the csv files themselves, in combination of the checks on the referential integrity as specified in the logical data model. This entails that the file attribute_combination_delivery.csv must be reported as an empty file. Nevertheless, the header is mandatory.

Validation of completeness. The metadata checksum file is part of the files to be submitted. For each entity type, the required type of checksum is listed. For now, no checksum is requested, only, a logical row count is requested for each entity type that is logically part of the reporting requirement. The entity types that are part of the reference data do not require a rowcount. All entity types whose rowcount is to be reported is marked with a rowcount reporting indicator value set to “entity type with reported rowcount”12type. This rowcount count indicates the number of instances of an entity type that is appropriate to for this entity type in accordance with the logical data model. Please note that this concerns the entity types all entities in the logical data model where the attribute ‘reporting including reference date’ is part of the primary key, data and entity types like “entity type delivery” and not only those entity types in the physical data deliveries. The : the logical data model also requires a row count and checksum for those entity types that do not have a corresponding .csv file to be delivered. 2.6.6.1 2.7.6.1 Example of a check on a physical delivery E.g. the reporting agent must report on exactly 100,000 instruments. The instrument.csv file contains 100,000 rows, excluding the header. The row count for the logical entity is 100,000. The entity type delivery lists a row count of 100,000 for the "instrument" entity type. DNB checks that 100000 = 100000 and accepts the delivery. 2.6.6.2 2.7.6.2 Example of a check on a logical delivery The entity type "instrument not past due" does not have its own specific features or relations, and therefore does not require physical delivery. However, the logical checksum of all not past due instruments must be delivered. For example, the reporting agent must report on exactly 100,000 instruments (with 100,000 financial data), 10,000 of which are instrument past due and 90,000 are instrument not past due (100,000-10,000). These files must be reported: 1. instrument.csv with 100,000 records 2. financial_data.csv with 100,000 records 3. instrument_past_due.csv with 10,000 records These records must be reported in the entity type delivery: Instrument 100,000 financial data 100,000 instrument past due 10,000 instrument not past due 90,000 DNB checks that instrument.csv contains 100,000 rows, that financial_data.csv contains 100,000 rows, that instrument_past_due contains 10,000 rows and that 90,000 rows in instrument.csv logically consist of instruments not past due. 12 The rowcount reporting indicator for the entity types can be found in the ‘RRE business terms’, sheet ‘entity type’. 2.6.6.3 2.7.6.3 Check on primary key The LDM has entity types that allow DNB to ask for checks on combinations of attributes. This mechanism is primarily meant to check the integrity of primary keys of the entity types in the logical data model. Currently, no checks of these types are foreseen, since DNB will rely instead on the hashing of the csv files themselves, in combination of the checks on the referential integrity as specified in the logical data model. This entails that the file attribute_combination_delivery.csv must be reported as an empty file. Nevertheless, the header is mandatory.