Una guida ai sistemi e ai controlli per la rendicontazione FATCA CRS

FATCA e CRS reporting è la disciplina operativa di identificare, classificare e segnalare i conti finanziari detenuti da contribuenti residenti all'estero. Richiede sistemi robusti e verificabili per la due diligence, l'aggregazione dei dati e lo scambio sicuro di informazioni con le autorità fiscali.

La distinzione fondamentale è l'ambito: il Foreign Account Tax Compliance Act (FATCA) è una normativa unilaterale degli Stati Uniti rivolta alle U.S. persons, mentre il Common Reporting Standard (CRS) è un quadro multilaterale per la trasparenza fiscale tra oltre 100 giurisdizioni partecipanti. Per un istituto finanziario, la conformità è un problema di ingegneria: costruire un sistema che possa eseguire questi obblighi in modo coerente e verificabile.

Comprendere le basi di FATCA e CRS

Una rendicontazione FATCA e CRS efficace dipende da un sistema ben progettato, non da una checklist di conformità. Per i responsabili della compliance, del rischio e dell'IT, l'obiettivo è costruire un quadro di controllo dimostrabile che identifichi, classifichi e riporti coerentemente i conti finanziari corretti sotto la giurisdizione corretta.

Queste normative sono state stabilite per combattere l'evasione fiscale offshore creando uno standard globale per l'Automatic Exchange of Information (AEOI).

Gli Stati Uniti hanno avviato questo standard con FATCA, che obbliga le Foreign Financial Institutions (FFIs) a segnalare i conti finanziari detenuti dai contribuenti statunitensi. L'Organisation for Economic Co-operation and Development (OECD) ha quindi sviluppato il CRS come modello multilaterale per la condivisione delle informazioni tra tutte le nazioni partecipanti.

Distinguere l'ambito di FATCA e CRS

Sebbene l'obiettivo di entrambi i framework sia la trasparenza fiscale, le loro meccaniche operative differiscono significativamente. Comprendere queste distinzioni è il primo principio per progettare un sistema di conformità funzionale.

FATCA è un regime di rendicontazione unilaterale focalizzato sull'identificazione delle "U.S. Persons" basata su indizi di status statunitense, come la cittadinanza o la residenza fiscale. Al contrario, il CRS è multilaterale e richiede agli istituti finanziari di identificare qualsiasi intestatario di conto che sia residente fiscalmente in qualsiasi giurisdizione partecipante.

Questo ha implicazioni dirette per il design del sistema:

• I sistemi FATCA devono essere configurati per rilevare specifici indizi statunitensi, come luogo di nascita negli USA, indirizzo o numero di telefono statunitense.
• I sistemi CRS devono essere in grado di elaborare e convalidare le informazioni sulla residenza fiscale per dozzine di paesi, ciascuno con formati unici per i Tax Identification Numbers (TIN).

Alla base, la conformità è un problema di ingegneria. La sfida non è semplicemente inviare una segnalazione, ma costruire un sistema tracciabile e basato su evidenze che possa dimostrare la propria correttezza sotto scrutinio. Ciò significa che ogni classificazione, ogni dato e ogni invio deve essere collegato a un controllo definito e a un elemento di prova verificabile.

Definizioni chiave nella pratica

Le normative utilizzano definizioni funzionali precise. Una Financial Institution (FI) è definita dalle sue attività, non dal suo nome, e include istituti fiduciari, entità di investimento e alcune compagnie di assicurazione. Gli obblighi di un'entità sono determinati da ciò che fa.

Allo stesso modo, un Reportable Account è qualsiasi conto finanziario detenuto da una o più Reportable Persons. Questa definizione richiede che le FI incorporino una due diligence sistematica nei processi di onboarding dei clienti e nella gestione del ciclo di vita. Non è un controllo singolo ma una funzione di monitoraggio continuo, progettata per rilevare cambiamenti nella residenza fiscale di un intestatario di conto che potrebbero innescare un obbligo di segnalazione.

Definire il proprio ambito e gli obblighi di due diligence

Definire correttamente l'ambito per la rendicontazione FATCA e CRS è un processo sistematico, non una stima. Richiede di incorporare i controlli di due diligence direttamente nei flussi operativi, garantendo che ogni conto cliente sia classificato accuratamente fin dall'inizio.

Questo processo inizia con l'onboarding del cliente e persiste per tutto il ciclo di vita del conto. Un sistema difendibile deve mantenere una traccia chiara delle evidenze per ogni decisione di classificazione, collegando i moduli di autodichiarazione del cliente, i documenti d'identità e altri dati raccolti direttamente allo stato finale del conto come "Reportable Person" sotto uno dei due framework.

Identificare gli indizi segnalabili

Il processo di due diligence viene attivato dall'identificazione di specifici indicia—punti dati che indicano una potenziale residenza fiscale negli USA o all'estero. I sistemi devono essere configurati per rilevare questi indicatori in modo affidabile attraverso tutti i repository di dati dei clienti.

Per FATCA, il sistema deve identificare i collegamenti con gli USA. I principali indizi includono:

• Cittadinanza statunitense o status di lawful permanent resident (green card).
• Luogo di nascita negli USA.
• Residenza o indirizzo postale negli USA.
• Numero di telefono statunitense.
• Istruzioni permanenti per trasferire fondi su un conto negli USA.
• Procura concessa a una persona con indirizzo negli USA.

Per CRS, l'ambito è più ampio e copre la residenza fiscale in qualsiasi giurisdizione partecipante. L'indicatore principale è la dichiarazione del cliente sulla residenza fiscale in un paese diverso da quello in cui si trova l'istituto. Questo richiede un sistema capace di gestire e convalidare i tax identification numbers (TIN) e le dichiarazioni di residenza provenienti da oltre 100 paesi diversi.

Due diligence per conti nuovi e preesistenti

Le procedure di due diligence richieste differiscono in base al fatto che un conto sia nuovo o preesistente. Questa distinzione è critica per l'allocazione delle risorse e il design del sistema.

Per i conti nuovi, la due diligence viene eseguita in fase di onboarding. Il controllo principale è il modulo di autodichiarazione dove l'intestatario del conto dichiara le proprie residenze fiscali. Questo documento è un elemento fondamentale di prova. Il processo deve assicurare che questi moduli siano raccolti, convalidati per completezza e ragionevolezza, e archiviati in modo verificabile.

Per i conti preesistenti, agli istituti finanziari è stato richiesto di condurre una revisione retrospettiva della loro base clienti per identificare i conti segnalabili. Questo in genere comportava una ricerca elettronica degli indizi all'interno dei dati esistenti. Per i conti di alto valore, il processo era spesso più rigoroso, talvolta includendo una revisione manuale dei documenti cartacei e la consultazione con il relationship manager.

Un cambiamento di circostanza è un punto di controllo critico. Un evento come l'aggiornamento del numero di telefono del cliente con un numero statunitense o la modifica del suo indirizzo di residenza deve innescare automaticamente una revisione del loro stato FATCA e CRS. Questo trasforma la conformità da un controllo statico a una funzione di monitoraggio continuo.

Differenze chiave tra FATCA e CRS

Pur condividendo l'obiettivo di combattere l'evasione fiscale, FATCA e CRS presentano differenze operative che devono essere incorporate nel sistema di conformità. La mancata considerazione di queste può risultare in importanti lacune di conformità.

La tabella seguente delinea le principali distinzioni per le operazioni di rendicontazione.

Comprendere queste differenze influisce direttamente sul design dei moduli di onboarding, sulla configurazione dei sistemi di monitoraggio e sulla struttura dei report finali.

Costruire un sistema di classificazione difendibile

L'esito della due diligence è una classificazione: il conto è segnalabile o no? Questa decisione deve essere registrata nei sistemi core, collegata a tutte le evidenze a supporto.

Un revisore deve essere in grado di selezionare qualsiasi conto e tracciare un percorso chiaro e logico dai dati di origine del cliente e dal modulo di autodichiarazione alla sua classificazione finale per la rendicontazione. Questo richiede un sistema che connetta, non solo memorizzi, i dati. Un record cliente dovrebbe mostrare gli indici identificati, l'autodichiarazione ricevuta, qualsiasi documentazione aggiuntiva fornita per risolvere ambiguità e la classificazione finale, con timestamp, effettuata da un utente autorizzato. Questo costituisce la base di un framework di audit-ready fatca crs reporting, trasformando un obbligo normativo in un controllo operativo verificabile.

Raccolta dati e meccanica della rendicontazione

Una volta che un conto è classificato come segnalabile, l'attenzione si sposta sulla raccolta dei dati e sulla loro trasmissione. Questo è un processo tecnico che richiede precisione. Un fatca crs reporting di successo dipende dalla raccolta degli elementi di dato corretti, dal loro formattamento secondo schemi rigorosi e dal mantenimento di una lineage verificabile dei dati dai sistemi sorgente al report finale.

L'obiettivo è produrre un file di invio che sia tecnicamente valido e fattualmente accurato. Un singolo errore in un Tax Identification Number (TIN) o nel saldo di un conto può portare al rifiuto, a richieste di chiarimento da parte delle autorità e a un fallimento di conformità. L'intero processo deve essere progettato per garantire che ogni dato nel report finale sia tracciabile alla sua origine.

Campi dati principali per la rendicontazione

Sia FATCA che CRS impongono un set specifico di dati per ogni conto segnalabile. Sebbene esistano variazioni locali, i requisiti fondamentali sono coerenti tra le giurisdizioni. I sistemi devono essere configurati per aggregare questi campi in modo accurato.

Le autorità fiscali richiedono le seguenti informazioni:

• Informazioni sull'intestatario del conto: Nome completo, indirizzo, giurisdizione(i) di residenza fiscale e TIN. Per le entità è richiesto anche il tipo di entità.
• Dettagli del conto: Il numero di conto o un equivalente funzionale.
• Informazioni sull'istituto finanziario: Il nome e il numero identificativo dell'istituto che segnala.
• Saldo o valore del conto: Il saldo alla fine dell'anno civile o del periodo di rendicontazione appropriato. Se un conto è stato chiuso durante l'anno, tale fatto deve essere segnalato.
• Pagamenti di reddito: L'ammontare lordo di interessi, dividendi e altri redditi accreditati sul conto durante l'anno.

Questi dati sono spesso distribuiti su più sistemi, come una piattaforma core banking, un CRM e un sistema di gestione degli investimenti. Una sfida operativa primaria è aggregare queste informazioni senza introdurre errori. Ciò richiede una solida governance dei dati e riconciliazioni regolari per mantenere la coerenza.

Questo flusso illustra la progressione sistematica dall'identificazione del conto all'aggregazione dei dati per il report finale.

È un percorso strutturato dalla rilevazione degli indici all'evidenza documentata che costituisce la base per i dati segnalabili.

Generazione dei report e schemi di invio

Le autorità fiscali non accettano dati in formati arbitrari. Sia FATCA che CRS richiedono l'aderenza a specifici schemi XML (eXtensible Markup Language). Il report FATCA si basa sul IRS XML Schema v2.0, mentre il CRS usa il OECD’s CRS XML Schema.

Questi schemi definiscono la struttura precisa, gli elementi di dato e le regole di validazione per il file di rendicontazione. Il sistema di reporting deve essere in grado di trasformare i dati aggregati di clienti e conti in un file XML valido che sia conforme a tali specifiche tecniche.

Un sistema di reporting conforme è più di un aggregatore di dati; è un motore di validazione. Il sistema deve eseguire controlli per assicurare che i formati dei TIN siano corretti per la giurisdizione specificata, che i codici valuta siano validi e che tutti i campi obbligatori siano popolati prima che il file venga generato. Questo controllo preventivo minimizza il rischio di rifiuto dell'invio.

Il file XML generato viene tipicamente caricato all'autorità fiscale locale tramite un portale governativo sicuro. L'invio stesso è un punto di controllo critico. Le prove dell'invio, inclusi ricevute generate dal sistema e timestamp, devono essere conservate come prova dell'invio tempestivo. L'assenza di queste prove può creare notevoli difficoltà durante un audit, anche se il report era accurato e inviato in tempo. Un sistema che acquisisce e archivia automaticamente queste prove è essenziale per dimostrare la conformità end-to-end.

Gestire i tempi globali e le sfumature giurisdizionali

Un efficace fatca crs reporting richiede non solo accuratezza dei dati ma anche l'osservanza di un complesso calendario di scadenze giurisdizionali. Per un istituto finanziario multinazionale, questo rappresenta una significativa sfida di coordinamento.

Il ciclo di rendicontazione inizia molto prima della data di invio, coinvolgendo cut-off dei dati, processi di aggregazione e validazione e revisioni interne. Ogni fase è un punto di controllo progettato per rendere la conformità un processo prevedibile e gestito anziché uno sforzo reattivo dell'ultimo minuto.

Navigare il calendario globale di conformità

Una sfida operativa primaria è la variazione delle scadenze FATCA e CRS tra le giurisdizioni. Sebbene molti paesi allineino le loro scadenze, esistono differenze sufficienti da richiedere un calendario globale di conformità dinamico e gestito centralmente. Questo calendario serve come fonte unica della verità per il coordinamento delle attività tra team e sedi diverse.

Ad esempio, l'Ufficio Centrale Fiscale Federale tedesco (BZSt) fissa tipicamente la sua scadenza per 31 luglio. Al contrario, la scadenza in India può arrivare già a maggio. Maggiori dettagli su queste tempistiche giurisdizionali sono disponibili tramite risorse che analizzano international reporting deadlines from pplaw.com.

Gestire un calendario di rendicontazione globale è fondamentalmente una disciplina di project management. Il sistema di record non dovrebbe solo tracciare le scadenze ma anche assegnare la responsabilità per ogni fase del processo di invio, dall'estrazione dei dati alla conferma finale. Questo crea una chiara linea di responsabilità per la tempestività.

L'impatto dell'evoluzione dei portali di rendicontazione

Un'altra fonte di complessità operativa è l'evoluzione dei portali governativi di rendicontazione. Le autorità fiscali aggiornano o sostituiscono periodicamente i loro sistemi di invio per migliorare la sicurezza o le funzionalità. Questi cambiamenti, sebbene necessari, creano rischi operativi se non gestiti proattivamente.

Quando un regolatore annuncia una transizione del portale, come la sostituzione dell'ELSTER da parte del BZSt, i team di compliance e IT devono collaborare strettamente. La transizione richiede:

• Adattamento tecnico: Riconfigurare le esportazioni dei dati e le connessioni API per allinearsi alle specifiche del nuovo sistema.
• Ridisegno dei processi: Aggiornare le procedure interne e formare il personale sul nuovo flusso di invio.
• Validazione della sicurezza: Assicurarsi che il nuovo portale soddisfi gli standard dell'organizzazione per la trasmissione di dati sensibili.

La mancata pianificazione di questi cambiamenti può risultare in scadenze mancate o rifiuti di invio, indipendentemente dalla qualità dei dati. Questo richiede un monitoraggio continuo dell'ambiente e una manutenzione proattiva del sistema, principio che dettagliamo nella nostra guida su how to build a NIS2 demonstrable control system.

Presentare "nil report" e conservare le evidenze

Anche in assenza di conti segnalabili per un dato anno, gli obblighi di conformità potrebbero non essere completi. Molte giurisdizioni richiedono l'invio di un "nil report" per confermare che è stata effettuata la due diligence e che non sono stati identificati conti segnalabili. Questa è una dichiarazione obbligatoria; il mancato invio di un nil report richiesto è spesso trattato con la stessa gravità del mancato invio di conti effettivi.

Infine, la conservazione delle evidenze dell'invio tempestivo è una componente non negoziabile di un sistema pronto per l'audit. Queste evidenze devono includere:

• Il file XML finale che è stato inviato.
• La ricevuta ufficiale di invio o una cattura schermo di conferma.
• I log interni di sistema che mostrano il timestamp dell'invio e l'utente che ha effettuato l'azione.

Queste prove devono essere archiviate in modo sicuro e facilmente accessibili. Durante un audit, dimostrare che hai inviato in tempo è importante quanto dimostrare cosa hai inviato. Questo approccio sistematico alla conservazione delle evidenze chiude il ciclo del processo di rendicontazione, assicurando che ogni azione sia documentata e verificabile.

Costruire un sistema di conformità pronto per l'audit

La conformità FATCA e CRS dovrebbe essere il risultato di un sistema progettato per tracciabilità e verificabilità, non l'esito di aggregazioni di dati all'ultimo minuto e checklist manuali.

Un sistema pronto per l'audit trasforma un'ispezione in una verifica di routine dell'integrità operativa. L'obiettivo è stabilire una catena di evidenze ininterrotta da un requisito normativo a una procedura interna, al relativo controllo di governo e alla prova che il controllo è stato eseguito. Questo tratta la conformità come una disciplina di governance basata sui sistemi, non solo sulla documentazione.

Stabilire proprietà e responsabilità chiare

Un sistema difendibile si costruisce sull'accountability. Il primo passo è assegnare una proprietà inequivocabile per ogni componente del processo FATCA e CRS. Una responsibility assignment matrix (RACI) è lo strumento appropriato per questo.

Questa matrice mappa compiti di conformità specifici ai ruoli, chiarendo chi è Responsible per l'esecuzione del lavoro, chi è Accountable per l'esito, chi deve essere Consulted e chi deve essere Informed. Per esempio, un Relationship Manager può essere responsible per ottenere il modulo di autodichiarazione di un cliente, ma il Head of Compliance è accountable per l'integrità complessiva del processo di due diligence. Questa distinzione separa l'esecuzione del compito dalla proprietà del sistema. Un audit testerà entrambi.

Un sistema ben progettato rende l'accountability inevitabile. Registra quale utente ha eseguito un'azione, quale evidenza ha esaminato e quando è stata presa la decisione. Questo record immutabile è lo strumento più potente per dimostrare che i controlli non sono solo progettati, ma funzionano efficacemente.

Un approccio sistematico alla gestione delle evidenze

Un sistema pronto per l'audit è definito dalle sue evidenze. Queste evidenze sono un dataset strutturato, versionato e sicuro che dimostra che il programma di conformità funziona come progettato. Questo richiede di andare oltre cartelle condivise e fogli di calcolo verso un sistema appositamente progettato.

Tre pilastri supportano una gestione efficace delle evidenze:

1. Versioning della documentazione di controllo: Politiche e procedure evolvono. Un sistema robusto versione questi documenti, collegando ogni versione al suo periodo di applicabilità. Questo permette a un auditor di valutare il controllo esatto in vigore durante il periodo in esame.

2. Crittografia sicura dei dati: I dati FATCA e CRS contengono informazioni personali identificabili (PII) sensibili. Tutte le evidenze, dalle autodichiarazioni ai file di dati interni, devono essere crittografate sia in transito che a riposo. L'uso di standard forti come AES-256 è un requisito di base.

3. Generazione di audit pack sicuri: Per un audit, le evidenze devono essere fornite in modo efficiente e sicuro. Un audit pack dovrebbe essere un'esportazione autonoma e indicizzata di tutte le politiche rilevanti, procedure, log di esecuzione dei controlli e evidenze di supporto. Il sistema dovrebbe generare questo pacchetto come archivio sicuro e crittografato con un indice chiaro per la navigazione dell'auditor. Il nostro articolo sui fondamentali di un audit ISO 9001 fornisce ulteriore contesto sulla preparazione delle evidenze per le valutazioni formali.

Questo approccio sistematico al fatca crs reporting considera un audit come una verifica del design del sistema. Quando un auditor richiede prove, la risposta è un'esportazione predefinita, che dimostra controllo, preparazione e una postura di conformità matura.

Fallimenti comuni della conformità e come mitigarli

I sistemi efficaci per FATCA e CRS sono progettati per prevenire i fallimenti, non solo per rilevarli. La maggior parte dei cedimenti di conformità non sono eventi improvvisi ma il risultato di debolezze latenti nella due diligence, nella gestione dei dati o nei controlli interni. Comprendere questi punti di fallimento comuni è il primo passo verso la costruzione di un sistema resiliente.

La fonte di errore più frequente è la due diligence incompleta o inaccurata. Questo deriva da processi di onboarding difettosi in cui i moduli di autodichiarazione non sono raccolti o convalidati correttamente. Un Tax Identification Number (TIN) mancante o un cambiamento di circostanza non affrontato, come un nuovo indirizzo estero, è sufficiente per rendere un report errato e attirare l'attenzione normativa.

Un altro punto critico di fallimento è la scarsa qualità e integrità dei dati. Quando i dati finanziari sono aggregati da sistemi multipli e non sincronizzati, le incongruenze sono inevitabili. Questo porta alla segnalazione di saldi di conto o valori di reddito errati, minando l'integrità dell'intero invio. Senza una solida governance dei dati e controlli di riconciliazione, il rischio di presentare informazioni scorrette è elevato.

Affrontare le debolezze sistemiche

Mitigare questi rischi richiede di andare oltre i controlli manuali e concentrarsi su controlli sistemici. L'obiettivo è progettare processi che rendano difficile l'introduzione di errori.

Questo comporta l'incorporazione di controlli e bilanciamenti automatizzati lungo tutto il ciclo di rendicontazione:

• Ricerche automatizzate di indici: I sistemi dovrebbero scansionare automaticamente i dati dei clienti alla ricerca di indici segnalabili all'onboarding e ad ogni successivo aggiornamento delle informazioni del cliente.
• Validazione dei campi obbligatori: I workflow di onboarding devono impedire l'apertura del conto se un modulo di autodichiarazione richiesto è incompleto o non valido.
• Controlli di riconciliazione dei dati: Script automatizzati dovrebbero essere eseguiti a intervalli definiti per confrontare i dati tra i sistemi sorgente, segnalando discrepanze per indagine.

Un fallimento di conformità raramente è un singolo punto di errore. Tipicamente è una catena di piccole negligenze—un documento mancante, un campo dati non verificato, un controllo scaduto—che culmina in un invio non conforme. Rafforzare il sistema significa rinforzare ogni anello di quella catena.

Le conseguenze di un fallimento sistemico possono essere significative. Ad esempio, le revisioni del Comptroller and Auditor General (CAG) dell'India hanno rivelato deviazioni sostanziali nella conformità dell'amministrazione fiscale. Un audit GST ha riscontrato 741 deviazioni di conformità in 1.086 casi, mentre un altro ha identificato 549 casi in cui i registri dei contribuenti non erano disponibili. I risultati completi su questi gap di conformità dal rapporto CAG report-06943acb5ad7ae2.59486831.pdf) illustrano la scala del rischio.

L'unica mitigazione efficace è trattare il fatca crs reporting come un processo continuo, non come un progetto annuale. Puoi approfondire leggendo la nostra guida su implementing compliance as a continuous system. Questo approccio garantisce che i controlli siano sempre operativi, i dati siano costantemente convalidati e il sistema rimanga pronto per l'audit per progettazione.

Il futuro della rendicontazione fiscale internazionale

Il dominio della trasparenza fiscale internazionale non è statico. L'introduzione di framework come CRS 2.0 e il Crypto-Asset Reporting Framework (CARF) indica che l'ambito del FATCA CRS reporting continuerà ad espandersi.

Questi nuovi framework non sono aggiustamenti minori; sono progettati per incorporare nuove classi di attivi e punti dati più granulari nello scambio automatico di informazioni. Questo rappresenta un cambiamento fondamentale che richiede agli istituti finanziari di rivedere la loro architettura di rendicontazione. La sfida primaria, come sempre, è operativa.

Adattare i sistemi per nuove classi di attività

CARF, che prende di mira specificamente i crypto-asset, richiede alle imprese di sviluppare controlli per identificare, classificare e segnalare transazioni che potrebbero non coinvolgere intermediari finanziari tradizionali. Questo è un compito di ingegneria significativo, che richiede la cattura di nuovi tipi di dati e la loro integrazione nei workflow di conformità esistenti.

Parallelamente, CRS 2.0 dovrebbe ampliare le definizioni di asset finanziari ed entità di investimento. Questa espansione richiederà un aggiornamento completo delle procedure di due diligence e della logica di rendicontazione per assicurare che questi attivi ed entità recentemente inclusi siano identificati e segnalati correttamente.

L'evoluzione da CRS a CRS 2.0 e CARF dimostra un principio fondamentale: la conformità è una disciplina di ingegneria continua, non un progetto una tantum. I sistemi devono essere progettati per l'adattabilità, permettendo l'integrazione di nuove regole e requisiti di dato senza richiedere una ricostruzione completa.

Questa evoluzione è globale. L'adozione da parte dell'India del Multilateral Competent Authority Agreement (MCAA) dell'OECD il 3 giugno 2015 ha stabilito le basi per questo livello di trasparenza. Oggi, le sue oltre 4.000 Reporting Financial Institutions (RFIs) si stanno preparando per CRS 2.0, evidenziando la scala del lavoro necessario per mantenere sistemi FATCA CRS reporting conformi. L'impatto globale di questi standard di rendicontazione su neuronwealth.com fornisce ulteriore contesto.

La traiettoria della rendicontazione è chiara: più dati, in maggiore dettaglio, su più classi di attivi. Il successo dipende dalla costruzione di sistemi robusti e basati su evidenze capaci di evolvere in tandem con le richieste normative.