Validation Guide

Before exporting, the register is validated by a four-layer engine that checks progressively more complex rules. Understanding these layers helps you fix issues efficiently.

Validation runs automatically when you open the Validate page (if register data exists). You can also re-run it manually at any time. Each error includes a severity (error or warning), the affected template, row, and column, plus guidance on how to fix it. Errors must be fixed before export. Warnings indicate potential issues that should be reviewed but do not block export. When validation passes with zero errors, an Export Register button appears for quick navigation to the export step.

Layer 1: Technical Validation

The technical layer checks low-level data quality — format correctness and field completeness. These are the most common errors and the easiest to fix.

Mandatory Fields

If a column is marked as mandatory in the DPM, it must have a non-empty value. An empty mandatory field produces an error.

LEI Format

Legal Entity Identifiers must be exactly 20 alphanumeric characters (uppercase letters A–Z and digits 0–9), conforming to ISO 17442. The last two characters are check digits calculated per ISO 7064 (Mod 97-10). Common mistakes include lowercase letters, spaces, or incorrect length.

Date Format

All dates must be in yyyy-mm-dd format with valid month (01–12) and day values. The special date 9999-12-31 is used for open-ended arrangements. Invalid date formats or impossible dates (e.g., 2025-13-01 or 2025-02-30) produce errors.

Country Codes

Country fields must contain a valid ISO 3166-1 alpha-2 code (e.g., DE, FR, LV, US). The validator checks against the full ISO code list.

Currency Codes

Currency fields must contain a valid ISO 4217 code (e.g., EUR, USD, GBP). Currency symbols (such as $) are not accepted.

Monetary Values

Monetary fields must be plain numbers without currency symbols, thousand separators, or letters. Use the separate currency column to indicate the currency. Examples: 150000, 1234567.89.

Numeric Fields

Number fields (e.g., notice periods, RTO/RPO, supply chain rank) must be valid numeric values. Commas used as thousand separators are stripped before validation.

Text Length

Text fields have maximum length constraints (typically 255 or 1000 characters). Exceeding the limit produces a warning.

Layer 2: DPM Validation

The Data Point Model layer enforces the structural rules defined by the EBA's DPM taxonomy. These checks ensure that the data conforms to the register's schema.

Closed-List Enforcement

Select (dropdown) fields only accept values from a predefined list of options. For example, the arrangement type field in B_02.01 only accepts CA_1, CA_2, or CA_3. Any value not in the allowed list produces an error.

Referential Integrity (Foreign Key Checks)

Many columns reference records in other templates. The DPM layer verifies that every referenced value actually exists. For example:

• B_02.02 column c0010 (arrangement ref) must match a c0010 value in B_02.01
• B_02.02 column c0030 (provider code) must match a c0010 value in B_05.01
• B_02.02 column c0050 (function ID) must match a c0010 value in B_06.01
• B_01.03 column c0020 (head office LEI) must match a c0010 value in B_01.02

A broken reference produces an error. The guidance text tells you which target template and column to check.

Key Uniqueness

Certain fields must have unique values across all rows:

• B_01.01 — For individual reporting (IND), this template must have at most 1 row.
• B_01.02 column c0010 — Each entity LEI must be unique. Duplicate LEIs produce an error.

Layer 3: Business Logic Validation

The business layer enforces DORA-specific rules that go beyond pure schema validation. These rules implement the regulatory intent of the ITS.

Arrangement Type Rules (B_02.01)

• CA_3 (Subsequent/Associated) — Column c0030 (overarching ref) must be populated. A subsequent agreement cannot exist without referencing its overarching/master agreement.
• CA_1 (Standalone) — Column c0030 should be empty or "Not Applicable." A standalone agreement has no overarching relationship. This produces a warning.

Date Range Consistency (B_02.02)

• Start date must be on or before end date — Column c0070 (start) must not be after column c0080 (end). This produces an error.
• Termination reason with open-ended date — If a termination reason (c0090) is set, the end date should not be 9999-12-31. This produces a warning.

Branch Nature Requires Branch Code (B_04.01)

If the nature of the entity using ICT services (c0030) is NE_2 (Branch), the branch identification code (c0040) is mandatory. This code must match a branch in B_01.03.

Supply Chain Rank (B_05.02)

The rank of a provider in the supply chain (c0050) must be at least 1. A rank of 1 indicates a direct provider; higher ranks indicate subcontractors further down the chain.

Layer 4: EBA Validation Rules

The EBA layer enforces the official validation rules published by the European Banking Authority as part of the DORA taxonomy. These rules are identified by alphanumeric codes and implement regulatory-grade data quality checks.

Existence Rules (e-series)

Rules prefixed with e (e.g., e23682) check that required fields contain non-empty values when the template row exists. These are similar to mandatory field checks but are defined at the EBA taxonomy level rather than the DPM schema level.

Conditional Mandatory Rules (v-series)

Rules prefixed with v and suffixed with _m (e.g., v8880_m) enforce fields that become mandatory based on the value of another field. For example:

• In B_06.01, if a function is classified as critical or important (CI_1 or CI_2), the date of last assessment (c0060), reasons for criticality (c0070), date of last identification (c0080), RTO (c0090), and RPO (c0100) become mandatory.
• In B_02.01, if the arrangement type is CA_3(subsequent), the overarching arrangement reference (c0030) becomes mandatory.
• In B_05.02, specific fields become mandatory based on the type of supply chain relationship.

Cross-Field Consistency Rules

Some EBA rules check logical consistency between multiple fields within the same row, such as date ordering, code type matching, and conditional exclusion of mutually exclusive values.

Cross-Template Validation

In addition to per-template rules, the engine runs cross-template checks to verify overall register consistency:

• Arrangement references exist — Every arrangement ref in B_02.02, B_03.01, B_03.02, B_03.03, B_04.01, B_05.02, and B_07.01 must correspond to an entry in B_02.01.
• Provider codes exist — Every provider code referenced in B_02.02 and B_05.02 must exist in B_05.01.
• Function IDs exist — Every function identifier in B_02.02 and B_07.01 must exist in B_06.01.
• Arrangements have signatories — Each arrangement in B_02.01 should have at least one signatory row in B_03.01 (entity signatories) or B_03.02 (provider signatories). Missing signatories produce a warning.

Common Errors and Fixes

Recommended Validation Workflow

1. Fill templates in dependency order — Start with entity information (B_01.xx), then providers (B_05.01) and functions (B_06.01), then contracts (B_02.xx), signatories (B_03.xx), usage (B_04.01), supply chain (B_05.02), assessments (B_07.01), and definitions (B_99.01).
2. Validate incrementally — Run validation after completing each group of templates. Fix errors before moving to the next group. This prevents cascading reference errors.
3. Fix errors first, then warnings — Errors block export. Warnings highlight potential issues but are not blocking. A warning about missing signatories, for example, may be intentional for arrangements still being formalized.
4. Use the error guidance — Each validation error includes a guidance message with the specific DPM column code and a suggestion for resolution. Follow the guidance to locate and fix the issue.