Maurice Müller
Senior Content Manager
Maurice Müller è giornalista e content strategist, con esperienza nella carta stampata e nei media digitali. In Formalize trasforma temi complessi di compliance e regolamentazione in contenuti chiari e pratici per i professionisti della compliance, del rischio e della sicurezza in tutta Europa.
Punti chiave:
Gli errori di validazione rientrano in quattro gruppi: il pacchetto, i singoli campi, le relazioni tra i modelli e la qualità dei dati. Dal gruppo dipende chi deve occuparsi della correzione.
Secondo l’AFM olandese, le violazioni di chiave esterna (errore 807) sono state la causa di rigetto più frequente nel ciclo 2026.
Correggi il record di origine ed esporta di nuovo. Se modifichi i file esportati, l’errore si ripresenterà nel ciclo successivo.
Superare i controlli tecnici non significa che i dati siano accettati. Ad aprile 2026 l’ABE ha effettuato ulteriori controlli di qualità dei dati.
Assegnare un responsabile preciso a ogni fornitore, contratto, servizio TIC e funzione commerciale mantiene il registro accurato tra un ciclo e l’altro.
Ai sensi del regolamento DORA, le entità finanziarie trasmettono una volta l’anno il proprio Registro delle Informazioni (RoI) all’autorità competente. Lo fanno utilizzando i 15 modelli previsti dal regolamento di esecuzione (UE) 2024/2956. Superare la validazione, però, si è rivelato più difficile che compilarli. Nel dry run del 2024 delle autorità europee di vigilanza (AEV), solo il 6,5 % dei registri ha superato tutti i controlli di qualità dei dati. Per il ciclo 2026, la CSSF lussemburghese ha avvertito che i controlli saranno applicati a un numero maggiore di campi. Ha anche avvertito che un registro accettato l’anno scorso potrebbe essere respinto quest’anno. La buona notizia è che gli errori di validazione del RoI DORA raramente sono un mistero. Quasi tutti dipendono da poche cause, e ogni causa ha un responsabile naturale all’interno dell’organizzazione.
Tipi di errori di validazione del Registro delle Informazioni DORA
Prima di modificare qualsiasi cosa, classifica l’errore. Il gruppo a cui appartiene indica se il problema è nel file o nei dati.
Errori del pacchetto ed errori tecnici. Il file ZIP, la struttura delle cartelle, i nomi dei file o i filing indicator non corrispondono alla specifica, quindi il file non può essere elaborato. Un caso tipico è il codice 808, “Missing filing indicators or case is wrong” (filing indicator mancanti o con maiuscole/minuscole errate). Tutti i 15 modelli devono essere segnalati, anche se vuoti. Secondo l’elenco dei problemi comuni delle AEV, questi errori comportano il rigetto.
Errori nei campi e nei dati. Manca un valore obbligatorio, oppure un identificativo o un formato non è valido. La regola v8826_m, ad esempio, verifica che un codice LEI (Legal Entity Identifier) sia composto da 20 caratteri e termini con due cifre. Di per sé, queste risultanze non comportano il rigetto del file. L’autorità competente può comunque chiedere di correggerle e di inviare di nuovo il registro.
Errori di relazione e di coerenza. Un record rimanda a qualcosa che non esiste in un altro modello. Il caso classico è il codice 807, “Foreign key constraint violated” (violazione del vincolo di chiave esterna). L’esempio fornito dalle stesse AEV è un riferimento contrattuale nel modello B_07.01 che non esiste nel modello B_02.01. Il file viene respinto.
Risultanze sulla qualità dei dati. Un registro può superare tutti i controlli tecnici e sollevare comunque dubbi. Ad aprile 2026, l’ABE ha sottoposto tutti i registri a ulteriori controlli di qualità dei dati. Tra gli esempi della Banca centrale d’Irlanda figurano un codice fittizio per la capogruppo ultima di un fornitore e la dicitura “non applicabile” come nome di un fornitore.
Qualunque sia il gruppo, annota il codice di errore, il modello (ad esempio B_02.01), la riga, la colonna (ad esempio c0010) e il valore che non ha superato il controllo. Il nostro RoI Validator gratuito mostra riga, colonna e valore della cella per ogni risultanza. Il feedback dell’autorità competente arriva invece tramite il suo portale e la sua procedura. Conserva quel messaggio come riferimento per un eventuale nuovo invio.
Ogni errore di validazione DORA comporta il rigetto?
No. La gravità di una risultanza dipende da tre fattori: la regola, le regole di validazione in vigore per quel ciclo e il modo in cui la tratta l’autorità competente. In linea di massima si distinguono tre livelli:
Errori bloccanti. I controlli su pacchetto, struttura e chiavi, come 103, 714, 720, 805, 807 e 808, comportano il rigetto dell’invio. Si correggono i dati e si invia un nuovo pacchetto.
Risultanze non bloccanti. Alcune regole non comportano di per sé il rigetto del file: v8886_m (valore obbligatorio mancante), v8826_m (formato del LEI) e i controlli VR_ sui dati GLEIF. La necessità di un nuovo invio dipende dall’autorità. La CSSF lussemburghese, ad esempio, si aspetta che le entità finanziarie correggano questi avvisi e inviino di nuovo il registro.
Feedback sulla qualità dei dati. Arriva dopo la validazione tecnica, spesso dall’autorità competente. Può tradursi nella richiesta di correggere e inviare di nuovo un registro già accettato.
Una regola può anche cambiare livello da un ciclo all’altro. Prima di decidere se una risultanza richiede un nuovo invio, verifica il tipo di messaggio nelle indicazioni aggiornate dell’autorità competente.
Errori comuni nel Registro delle Informazioni DORA: cause, responsabili e soluzioni
I codici riportati di seguito provengono dall’elenco dei problemi comuni delle AEV e dalle indicazioni delle autorità nazionali. Il validatore o l’autorità competente potrebbero formularli in modo diverso.
Errore o sintomo | Causa probabile da verificare | Chi contattare | Cosa fare |
|---|---|---|---|
File ZIP, nome del file o della cartella non validi (codici 714, 720) | Il nome o la struttura delle cartelle non rispettano la convenzione, oppure uno strumento di compressione ha aggiunto cartelle nascoste | Segnalazioni di vigilanza | Rigenerare il pacchetto dal sistema anziché ricomprimerlo manualmente |
Modelli o filing indicator mancanti (808) | Un modello è stato omesso invece di essere segnalato vuoto | Segnalazioni di vigilanza | Includere tutti i 15 modelli, con ogni filing indicator impostato su true |
Data di riferimento o versione di reporting errata | Pacchetto generato con le impostazioni dell’anno precedente | Segnalazioni di vigilanza | Usare il 31 dicembre dell’anno precedente e il pacchetto tecnico in vigore (DPM 4.0 dell’ABE nel 2026) |
Valore obbligatorio mancante (ad esempio v8886_m) | Record incompleto di un fornitore, un contratto, un servizio TIC, una funzione o un’entità | Responsabile del record interessato | Completare il campo nel record di origine ed esportare di nuovo |
LEI non valido (regola v8826_m, oppure non presente in GLEIF) | Un refuso, il LEI di un’altra entità del gruppo o un LEI scaduto | Acquisti, responsabile dei dati delle persone giuridiche | Verificare il codice nel database GLEIF e correggere il record |
Identificativo unico europeo (EUID) non trovato (VR_72) | Un LEI inserito come EUID, oppure un EUID privo del punto o del prefisso del paese | Acquisti, gestione dei fornitori | Usare l’EUID completo riportato nel registro delle imprese, compresi il punto e il codice paese dello Spazio economico europeo (SEE) |
Violazione di chiave esterna (807) | Un record rimanda a una chiave che non esiste nel modello a cui fa riferimento | Coordinatore del RoI, insieme al responsabile del record mancante | Creare il record mancante o correggere il riferimento |
Chiave primaria mancante (805) o chiavi duplicate | Una colonna chiave vuota o la stessa chiave usata due volte | Coordinatore del RoI | Assegnare a ogni riga una chiave univoca, come definito nel data model |
Valori generici o segnaposto (feedback sulla qualità dei dati) | “Non applicabile”, codici fittizi o valori copiati per compilare un campo obbligatorio | Responsabile del record interessato | Sostituirli con valori reali, oppure documentare perché il dato non è disponibile |
Gli identificativi richiedono particolare attenzione. Il regolamento di esecuzione richiede un LEI valido e attivo oppure un EUID, ed entrambi ove disponibili. L’obbligo vale per ogni fornitore di servizi TIC di terze parti che sia una persona giuridica. I fornitori stabiliti al di fuori dell’Unione europea possono essere identificati solo tramite LEI.
Come correggere gli errori di validazione DORA, passo dopo passo
Correggere il valore direttamente nel file esportato può sembrare la via più rapida. Così, però, si risolve solo l’invio in corso e l’errore resta nei dati di origine, pronto a ripresentarsi la volta successiva. Meglio procedere in questo ordine:
Annota il codice di errore, il modello, la riga, la colonna, il valore e la versione di reporting usata per l’esportazione.
Individua il record da cui deriva l’errore: fornitore, contratto, servizio TIC, funzione commerciale o entità.
Chiedi al responsabile del record di confermare il valore corretto. In caso di errore di chiave esterna, controlla sia il record che fa riferimento sia quello a cui dovrebbe rimandare.
Correggi il record nel sistema di origine, poi genera una nuova esportazione.
Valida il nuovo pacchetto e annota cosa è cambiato.
Se hai già effettuato l’invio, segui le istruzioni dell’autorità competente. Secondo le FAQ sul reporting delle AEV, un nuovo invio mantiene la stessa convenzione di denominazione, con una nuova marca temporale.
Se usi la piattaforma Formalize, apporta la correzione al suo interno ed esporta di nuovo il registro. La guida del nostro Help Center mostra dove va effettuata ogni correzione. Spiega anche perché non bisogna modificare il report generato: aprire e salvare i file può compromettere la struttura richiesta dalle AEV.
Checklist di validazione del Registro delle Informazioni DORA
Ripercorri questo elenco prima di ogni invio, non solo dopo un rigetto:
L’entità segnalante, il livello di segnalazione (individuale o consolidato) e la data di riferimento sono corretti.
Ogni entità finanziaria ha un LEI valido e ogni fornitore di servizi TIC di terze parti ha un LEI o un EUID valido.
I campi obbligatori relativi a fornitori, contratti, servizi TIC e funzioni commerciali sono completi.
Ogni riferimento tra modelli trova corrispondenza e ogni chiave è compilata e univoca.
I valori segnaposto e generici sono stati sostituiti o giustificati.
Il pacchetto rispetta il pacchetto tecnico in vigore e la convenzione di denominazione, e contiene tutti i 15 modelli.
Hai validato l’esportazione finale, esaminato ogni avviso e assegnato un responsabile a tutto ciò che è ancora in sospeso.
Conosci la finestra di invio, il portale e la procedura di nuovo invio della tua autorità.
Per controllare l’esportazione finale, caricala sul nostro RoI Validator gratuito. Esegue 294 controlli su tutti i 15 report nel formato ufficiale xBRL-CSV. Non richiede registrazione ed elimina i file dopo l’elaborazione.
Mantieni il registro accurato anche dopo l’invio
La maggior parte degli errori di validazione nasce mesi prima che qualcuno esegua una validazione. Un contratto viene rinnovato, il registro no. Un fornitore cambia entità giuridica. Un nuovo servizio TIC entra in produzione senza una funzione commerciale associata. Se ci si occupa del registro solo nel primo trimestre, ogni ciclo ricomincia con la stessa pulizia dei dati.
Per evitarlo serve una chiara attribuzione delle responsabilità. Assegna a ogni tipo di record un responsabile preciso: l’ufficio acquisti per i fornitori e i relativi identificativi, l’ufficio legale per i contratti, l’IT per i servizi TIC, le unità di business per le funzioni supportate da quei servizi. Saranno loro ad aggiornare il registro quando qualcosa cambia, non quando inizia il reporting. Una validazione trimestrale di un’esportazione di prova farà poi emergere i problemi quando chi conosce la risposta se la ricorda ancora.
In questo modo il registro diventa un insieme di dati operativi, non un file da sistemare una volta l’anno. È proprio lo scopo per cui è progettata una soluzione per il Registro delle Informazioni.
Come funziona nella piattaforma Formalize. Fornitori, contratti, servizi TIC e funzioni commerciali sono record collegati tra loro in un unico sistema. Prima dell’esportazione, una dashboard di controllo dei dati segnala i dati obbligatori mancanti e i collegamenti interrotti. Con un clic si arriva al punto esatto in cui si trova ogni problema. L’esportazione genera tutti i 15 report in un unico pacchetto, pronto per il RoI Validator.
Questo articolo ha finalità esclusivamente informative e non costituisce consulenza legale.
Individua gli errori del registro alla fonte
Porta il tuo ultimo report di validazione. Ti mostreremo come ricondurre ogni errore a un fornitore, a un contratto o a un servizio TIC, e come mantenere aggiornati quei record tra un ciclo e l’altro.
