Prot. n. 119038/2016
Prot. n. 119038/2016
Disposizioni attuative del decreto del Ministro delle finanze del 6 agosto 2015 di attuazione della legge 18 giugno 2015, n. 95 di ratifica dell’Accordo tra il Governo degli Stati Uniti d’America e il Governo della Repubblica Italiana finalizzato a migliorare la compliance fiscale internazionale e ad applicare la normativa FATCA (Foreign Account Tax Compliance Act) e integrazione del provvedimento del Direttore dell’Agenzia n. 106541 del 7 agosto 2015. Modalità e termini per la correzione da parte degli istituti finanziari tenuti alla comunicazione (RIFI) di errori minori o amministrativi ovvero gravi non conformità notificati dall’Autorità fiscale degli Stati Uniti d’America. Aggiornamento degli allegati al provvedimento del Direttore dell’Agenzia n. 106541 del 7 agosto 2015.
IL DIRETTORE DELL’AGENZIA
In base alle attribuzioni conferitegli dalle norme riportate nel seguito del presente provvedimento,
Dispone
1. Comunicazione degli errori
1.1. Ai sensi dell’art. 5 dell’Accordo FATCA, ratificato con legge 18 giugno 0000, x. 00, x’Xxxxxxxx xxxxxxx xxxxx Xxxxx Xxxxx notifica all’Agenzia delle entrate eventuali errori minori e amministrativi ovvero gravi non conformità rilevati nelle comunicazioni ricevute.
1.2. L’Agenzia delle entrate, ricevuta la notifica di cui al punto 1.1 dall’Autorità fiscale degli Stati Uniti, comunica alla RIFI interessata la segnalazione di errore minore e amministrativo ovvero di grave non conformità.
1.3. La comunicazione di cui al punto 1.2 avviene mediante PEC.
2. Categorie di errori
2.1. Gli errori si distinguono in:
a) Errori minori e amministrativi. Tali errori, definiti dall’art. 5, comma 2, dell’Accordo FATCA, ratificato con legge 18 giugno 2015, n. 95, includono le
comunicazioni di informazioni inesatte o incomplete ovvero altre violazioni dell’Accordo medesimo.
b) Gravi non conformità. Tali errori, definiti dall’art. 5, comma 2, dell’Accordo FATCA, ratificato con legge 18 giugno 2015, n. 95, includono, a titolo esemplificativo:
i. l’omessa comunicazione;
ii. la mancata tempestiva correzione di errori minori e amministrativi a seguito di notifica dell’autorità statunitense;
iii. altre non conformità collegate alla mancata applicazione della ritenuta d’imposta, ove prevista, sui pagamenti di fonte statunitense effettuati nei confronti di Istituzioni finanziarie non partecipanti.
3. Correzione degli errori
3.1. Gli errori possono essere corretti:
a) a seguito delle comunicazioni di cui al punto 1 ovvero
b) su iniziativa spontanea della RIFI.
3.2. La correzione degli errori avviene mediante trasmissione di un file, utilizzando l’infrastruttura informatica SID e secondo le specifiche tecniche di cui agli allegati 1 e 2 del provvedimento 7 agosto 2015.
3.3. La trasmissione della comunicazione correttiva, da parte della RIFI, degli errori di cui al punto 3.1.a) avviene:
a) in caso di errore minore e amministrativo, entro 90 giorni dalla data di ricezione della PEC;
b) in caso di grave non conformità, entro 16 mesi dalla data di ricezione della PEC.
3.4. Ai fini della comunicazione correttiva, la RIFI può avvalersi di entità sponsor e di fornitori terzi di servizi, alle condizioni previste dall’articolo 8 del decreto del Ministro delle finanze del 6 agosto 2015.
4. Ricevute
4.1. L’Agenzia delle entrate certifica l’avvenuta presentazione della comunicazione, a fronte del risultato positivo dell’elaborazione di controllo formale, mediante una ricevuta nella quale sono indicati:
a) l’identificativo del file attribuito dal soggetto che effettua la comunicazione;
b) il protocollo attribuito in via automatica al file.
4.2. L’Agenzia delle entrate, mediante una ricevuta di scarto, notifica la mancata accettazione della comunicazione dovuta alla non adeguatezza alle regole di trasmissione o ad anomalie nella nomenclatura del file o a irregolarità nella struttura dei dati o a incongruenze tra i dati comunicati. In tal caso la comunicazione si considera non presentata e nella ricevuta sono indicati i seguenti dati:
a) l’identificativo del file attribuito dal soggetto che effettua la comunicazione;
b) il protocollo attribuito in via automatica al file;
c) il motivo dello scarto.
4.3. Salvo cause di forza maggiore, la ricevuta di cui al punto 4.1 è resa disponibile, tramite lo stesso canale adottato per la trasmissione, entro cinque giorni lavorativi successivi a quello di protocollazione del file.
4.4. Le ricevute sono predisposte secondo le specifiche tecniche pubblicate sul sito internet dell’Agenzia delle entrate, sul quale sarà inoltre data evidenza degli eventuali successivi aggiornamenti apportati a tali specifiche tecniche.
5. Trattamento dei dati
5.1. Le informazioni di cui al presente provvedimento sono trasmesse all’Agenzia delle entrate nell’osservanza della normativa in materia di riservatezza e protezione dei dati personali e sono raccolte nel rispetto dei diritti e delle libertà fondamentali dei contribuenti.
5.2. L’Agenzia delle entrate elabora i dati comunicati per la trasmissione all’Autorità fiscale degli Stati Uniti d’America secondo le modalità e i termini fissati dall’Accordo ratificato con la legge 18 giugno 2015, n. 95.
6. Consultazione del Garante per la protezione dei dati personali
6.1 Il Garante per la protezione dei dati personali ha reso parere favorevole con provvedimento n. 289 del 7 luglio 2016.
7. Aggiornamento degli allegati tecnici
7.1 L’allegato al presente Provvedimento sostituisce l’allegato n. 2 “Istruzioni per la compilazione e la trasmissione dei dati” al Provvedimento del Direttore dell’Agenzia n. 106541 del 7 agosto 2015.
7.2. Ove si renda necessario apportare tempestivamente delle modifiche o integrazioni all’allegato di cui al punto 7.1., al fine di migliorare le modalità di compilazione e di trasmissione dei dati da parte degli operatori finanziari italiani in attuazione della normativa FATCA, tali modifiche potranno essere adottate mediante pubblicazione della versione aggiornata nell’apposita sezione del sito internet dell’Agenzia delle Entrate.
Motivazioni
L’accordo intergovernativo FATCA, ratificato con legge 18 giugno 2015, n. 95 e operativo a partire dal 1° luglio 2014, è volto a contrastare l’evasione fiscale - realizzata da cittadini e residenti statunitensi mediante conti intrattenuti presso istituzioni finanziarie italiane e da residenti italiani mediante conti intrattenuti presso istituzioni finanziarie statunitensi - tramite lo scambio automatico di informazioni finanziarie.
Al fine di ottemperare agli adempimenti di trasmissione dei dati all’IRS (Internal Revenue Service) statunitense, le istituzioni finanziarie italiane tenute alla comunicazione (RIFI) trasmettono all’Agenzia delle entrate i dati sul titolare statunitense del conto e sul conto stesso, compresi gli importi dei pagamenti corrisposti a istituzioni finanziarie non partecipanti (NPFI).
Il presente provvedimento integra il precedente provvedimento del 7 agosto 2015 prot. n. 106541, sulla base di esplicito rinvio contenuto nel punto 5.6, per la gestione delle comunicazioni correttive.
Il punto 1 del presente provvedimento definisce termini e modalità di comunicazione degli errori ovvero gravi non conformità da parte dell’Agenzia delle entrate alle RIFI interessate, a seguito di notifica dell’Autorità fiscale statunitense.
Il punto 2 descrive le categorie di errori rilevabili dall’Autorità fiscale statunitense.
Il punto 3 definisce termini e modalità di comunicazione dei dati correttivi da parte delle RIFI all’Agenzia delle entrate.
Inoltre, il punto 7 dispone un aggiornamento nonché la pubblicazione sul sito internet di eventuali successivi aggiornamenti – i quali non comportino nuovi adempimenti o modifiche delle modalità di trasmissione – all’allegati tecnico al provvedimento 7 agosto 2015 prot. n. 106541. Tale modalità di aggiornamento ha il fine di accelerare il processo di messa a disposizione degli operatori finanziari della documentazione ausiliaria alla predisposizione e invio della comunicazione.
a) Attribuzioni del Direttore dell’Agenzia delle entrate.
Decreto legislativo 30 luglio 1999, n. 300, recante la riforma dell'organizzazione del Governo, a norma dell'articolo 11 della legge 15 marzo 1997, n. 59 (articolo 57;
articolo 62; articolo 66; articolo 67, comma 1, articolo 68, comma 1; articolo 71,
comma 3, lettera a); articolo 73, comma 4);
Statuto dell’Agenzia delle entrate, approvato con delibera del Comitato Direttivo n. 6 del 13 dicembre 2000, pubblicato nella Gazzetta Ufficiale n. 42 del 20 febbraio 2001
(articolo 5, comma 1; articolo 6, comma 1);
Regolamento di amministrazione dell’Agenzia delle entrate, approvato con delibera del Comitato Direttivo n. 4 del 30 novembre 2000, pubblicato nella Gazzetta Ufficiale
n. 36 del 13 febbraio 2001 (articolo 2, comma 1);
Decreto del Ministro delle Finanze 28 dicembre 2000, pubblicato nella Gazzetta Ufficiale n. 9 del 12 febbraio 2001, concernente disposizioni recanti le modalità di avvio delle Agenzie fiscali e l’istituzione del ruolo speciale provvisorio del personale dell’Amministrazione finanziaria, emanato a norma degli articoli 73 e 74 del decreto legislativo 30 luglio 1999, n. 300.
b) Disciplina normativa di riferimento:
Legge 18 giugno 2015, n. 95 di ratifica dell’accordo FATCA
Decreto del Ministero delle Finanze del 6 agosto 2015
Provvedimento del Direttore dell’Agenzia delle entrate del 7 agosto 2015, prot. n. 2015/106541
Provvedimento del Direttore dell’Agenzia delle entrate del 25 marzo 2013, prot. n. 2013/37561, approvato dal Garante per la protezione dei dati personali con provvedimento del 15 novembre 2012 e provvedimento del 31 gennaio 2013.
Competent Authority Arrangement between the Competent Authorities of the United States of America and the Republic of Italy (Accordo amministrativo tra Autorità competenti) in vigore dal 1/12/2015.
La pubblicazione del presente provvedimento sul sito internet dell’Agenzia delle entrate tiene luogo della pubblicazione nella Gazzetta Ufficiale, ai sensi dell’articolo 1, comma 361, della legge 24 dicembre 2007, n. 244.
Roma, 26/07/2016
IL DIRETTORE DELL’AGENZIA
Xxxxxxxx Xxxxxxx
Allegato:
1. Istruzioni per la compilazione e la trasmissione dei dati
MODALITA’ DI COMPILAZIONE E TRASFERIMENTO DEI DATI IN APPLICAZIONE DEGLI ACCORDI FATCA
Versione : 1.3
CRONOLOGIA DELLE REVISIONI
Versione | Data | Autore | Descrizione |
1.0 | 22/04/2015 | Sogei | Prima versione |
1.1 | 27/05/2015 | Sogei | Modificata specifica di compilazione dei valori del MessageRefId e dei DocRefID per recepire la richiesta pubblicata sul sito IRS |
1.2 | 14/07/2015 | AdE | Modifiche effettuate a seguito di consultazione pubblica |
1.3 | 23/06/2016 | Sogei | Modifiche per permettere indicazione di GIIN non italiani da parte degli Sponsor |
INDICE
1. INTRODUZIONE 5
1.1 OGGETTO DEL DOCUMENTO 5
1.2 TERMINOLOGIA 5
2. MODALITÀ DI COMUNICAZIONE DEI DATI 6
2.1 CONTROLLO FORMALE (CLIENT) 6
2.2 CONTROLLO IN FASE DI ACCOGLIENZA 7
2.3 DIAGNOSTICI E RICEVUTE 7
2.4 COMUNICAZIONI NEI TERMINI 8
2.5 COMUNICAZIONI OLTRE IL TERMINE DI SCADENZA 10
2.6 COMUNICAZIONI IN CASO DI OPERAZIONI STRAORDINARIE, CESSAZIONE E ALTRE VICENDE SOCIETARIE CHE COINVOLGONO LE RIFI 11
3. REGOLE DI COMPILAZIONE DELLA COMUNICAZIONE 13
3.1 CARATTERISTICHE TECNICHE DEI MESSAGGI XML 13
3.1.1 Notazioni adottate 13
3.2 SCHEMI DI RIFERIMENTO 15
3.3 STRUTTURA GENERALE DELLA COMUNICAZIONE FATCA 15
3.3.1 Il messaggio e il blocco di dati FATCA 16
3.3.2 Il messaggio e le informazioni tecniche di identificazione 18
3.4 STRUTTURA IN DETTAGLIO DEL MESSAGGIO FATCA_OECD 21
3.4.1 FATCA_OECD 21
3.4.2 FATCA_OECD / MessageSpec (sfa:MessageSpec_Type) 22
3.4.3 FATCA_OECD / FATCA (ftc:Fatca_Type) 25
3.4.4 FATCA_OECD / FATCA / ReportingFI 28
3.4.5 FATCA_OECD / FATCA / ReportingGroup/Sponsor 30
3.4.6 FATCA_OECD / FATCA / ReportingGroup/Intermediary 34
3.4.7 FATCA_OECD / FATCA / ReportingGroup/ AccountReport 36
3.4.8 FATCA_OECD / FATCA / ReportingGroup/ PoolReport 41
3.4.9 Blocco generico ftc:DocSpec_Type 42
3.4.10 Blocco generico sfa:PersonParty_Type 45
3.4.11 Blocco generico sfa:Address_Type 49
3.4.12 Blocco generico sfa: OrganisationParty_Type 52
3.5 CONTROLLI FORMALI ULTERIORI RISPETTO ALLA VALIDAZIONE CON LO SCHEMA XSD 54
3.6 CARATTERI AMMESSI NELLA COMPILAZIONE DELL’XML 59
3.7 VALORIZZAZIONE DEI SALDI FINALI E DELLE TIPOLOGIE DI RAPPORTO DEL BLOCCO “ACCOUNT REPORT” 60
3.7.1 Tabella di raffronto tra le tipologie di rapporto comunicate all’Archivio e le tipologie rilevanti per la normativa FATCA 60
3.7.2 Modalità di calcolo dei saldi 63
1. INTRODUZIONE
1.1 OGGETTO DEL DOCUMENTO
Dall’01.07.2014 è operativo l’Accordo FATCA (Foreign Account Tax Compliance Act) per la comunicazione dei conti statunitensi che risultano esistenti a partire dalla stessa data. Pertanto, i conti chiusi in data antecedente non sono oggetto di comunicazione all’Agenzia delle entrate.
Questo documento descrive le regole di compilazione e di trasmissione delle informazioni da parte degli operatori finanziari italiani in attuazione della normativa FATCA. .
1.2 TERMINOLOGIA
Abbreviazioni e Acronimi | Descrizione |
FATCA | Foreign Account Tax Compliance Act |
FI | Financial Istitution |
IRS | Internal Revenue Service (Agenzia governativa degli US) |
SID | Servizio Interscambio Dati |
GIIN | Global Intermediary Identifying Number |
TIN | Taxpayer Identification Number |
EIN | Employer Identification Number |
2. MODALITÀ DI COMUNICAZIONE DEI DATI
La piattaforma da utilizzare per la trasmissione dei dati previsti dagli accordi FATCA è il SID. Le FI o, nel caso di opzione per il sistema di sponsorizzazione, le entità Sponsor, se non già accreditate, sono tenute a registrarsi al servizio e ad attenersi alle regole individuate per lo scambio delle informazioni tramite SID.
L’Agenzia delle Entrate predispone un software finalizzato al controllo formale (controllo client) e alla preparazione dei file da trasmettere.
Secondo le regole del SID, il file potrà essere trasmesso tramite PEC, dichiarata nella fase di registrazione al SID, o avvalendosi di un nodo di interscambio.
Il file trasmesso subirà quindi un ulteriore controllo sui sistemi di accoglienza dell’Agenzia delle Entrate, a seguito del quale sarà prodotta una ricevuta di accettazione del file o di scarto completo dello stesso. I file il cui controllo produce una ricevuta di scarto si intendono non acquisiti e il file corretto deve essere ritrasmesso nei termini.
2.1 CONTROLLO FORMALE (CLIENT)
Il controllo client sarà finalizzato:
• alla verifica della validità del flusso XML rispetto all’ultima versione degli “schema xsd” rilasciati dall’IRS.
• alla verifica degli ulteriori vincoli previsti dagli accordi FATCA o riportati nella “User Guide” di riferimento (ad esempio, presenza di campi la cui obbligatorietà non è pervista dallo schema xsd di riferimento);
• alla verifica della correttezza formale rispetto agli ulteriori vincoli riportati nelle specifiche tecniche, esposte nel capitolo 3 di questo documento.
• alla verifica di correttezza formale di tutti i codici fiscali italiani presenti nel messaggio
Il riscontro di eventuali errori sarà esposto in un file di diagnostici.
La presenza di errori nel flusso interrompe il processo di elaborazione. Sarà pertanto necessario procedere alla rimozione delle anomalie e ripetere la procedura di controllo.
2.2 CONTROLLO IN FASE DI ACCOGLIENZA
In fase di accoglienza del file, saranno effettuati i seguenti ulteriori controlli:
• verifica di correttezza ed esistenza in Anagrafe tributaria del codice fiscale dell’FI inviante presente nel file xml nel campo TIN del Blocco Sponsor, se il blocco Sponsor è presente, altrimenti nel campo TIN del Blocco ReportingFI e verifica di corrispondenza di questo con il codice fiscale del soggetto firmatario e inviante
• verifica di conformità del flusso acquisito rispetto all’ultima versione del software di controllo pubblicata sul sito dell’Agenzia delle Entrate
• verifica del rispetto delle regole di invio in relazione alle scadenza (descritte di seguito ai paragrafi 2.4 e 2.5);
• verifica dell’univocità degli identificativi riportati nei campi MessageRefID, DocRefId e esistenza degli identificativi eventualmente riportati nei campi CorrMessageRefId e CorrDocRefId;
Le comunicazioni saranno ritenute acquisite esclusivamente nei casi in cui non siano evidenziati errori dai processi di controllo.
In presenza di errori sarà predisposta una ricevuta di scarto nella quale sarà riportato l’elenco degli errori. In questo caso, gli identificativi presenti nel file potranno essere ritrasmessi.
2.3 DIAGNOSTICI E RICEVUTE
L’esecuzione del controllo formale e l’attivazione dei controlli in fase di accoglienza, producono un esito – positivo o negativo - da notificare all’utente.
In dettaglio, nella fase di controllo client, a seconda dell’esito delle elaborazioni, possono verificarsi le seguenti condizioni:
• Esito positivo del controllo: viene fornita una segnalazione sintetica, e vengono attivate le successive fasi di lavorazione (compressione, cifratura e firma).
• Esito negativo del controllo: viene fornito l’elenco dettagliato delle anomalie riscontrate. Non sono attivate le successive fasi elaborative e pertanto è necessario correggere gli errori e rieseguire il controllo.
Nella fase di accoglienza, a prescindere dall’esito delle elaborazioni, è prodotto un file ricevuta nel quale è riportato il protocollo attribuito al file inviato. Inoltre in conseguenza dell’esito dei controlli, possono verificarsi le seguenti condizioni:
• Esito positivo: è fornita una ricevuta con una descrizione sintetica dei dati acquisiti.
• Esito negativo: è fornita una ricevuta con una descrizione analitica degli errori riscontrati. In questo caso tutta la fornitura si intende respinta.
2.4 COMUNICAZIONI NEI TERMINI
Dal 1 gennaio di ciascun anno, fino a 15 (quindici) giorni successivi al termine di scadenza previsto per la comunicazione annuale, è consentito effettuare esclusivamente comunicazioni di tipo “new data” - tutti gli elementi DocTypeIndic valorizzati con “FATCA1” - relative all’anno precedente.
L’FI dovrà produrre pertanto un file che contenga tutti gli elementi da inviare all’IRS.
Eventuali invii successivi al primo saranno ritenuti sostitutivi e non integrativi rispetto agli invii precedenti.
Per evitare errori nella cronologia delle acquisizioni, eventuali invii successivi al primo devono essere effettuati solo dopo la ricezione dell’esito (ricevuta) dell’invio precedente. Eventuali invii di tipo correttivo o annullamento (DocTypeIndic valorizzati con “FATCA2”, “FATCA3”, “FATCA4”) relativi all’annualità in scadenza saranno oggetto di scarto.
Per ciascun invio è in ogni caso verificata l’univocità degli identificativi (MessageRefId e DocRefId). Pertanto non potranno essere utilizzati gli stessi identificativi utilizzati in eventuali invii precedenti accolti con esito positivo.
L’Agenzia delle Entrate trasferirà all’IRS esclusivamente l’ultima comunicazione di tipo “new data” effettuata dall’operatore finanziario entro i 15 giorni successivi al termine di scadenza.
IN APPLICAZIONE DEGLI ACCORDI FATCA PAG. 9 DI 68
23 GIUGNO 2016
Le eventuali comunicazioni precedenti, anche nel caso in cui risultino acquisite, non saranno prese in considerazione nell’ambito dello scambio con l’IRS, e conseguentemente, non potranno essere oggetto di successive modifiche con invii di tipo “void data”, “amended data” e “corrected data”
L’FI che effettuerà per la prima volta un invio di tipo “new data” oltre la data di scadenza, ma comunque nei 15 giorni successivi, in caso di esito positivo dei controlli in fase di accoglienza, riceverà una segnalazione di tardività evidenziata nella ricevuta. Il file sarà comunque accolto e inviato dall’Agenzia delle Entrate all’IRS.
Es1:
Data di scadenza 30 aprile 2016 per comunicazioni relative al 2015 Messaggio1
Reporting FI = X
Anno di riferimento = 2015
Tipo comunicazione = New data Data invio = 15 aprile 2016 Ricevuta = Accolto
Messaggio2
Reporting FI = X
Anno di riferimento = 2015
Tipo comunicazione = New data Data invio = 27 aprile 2016 Ricevuta = Accolto
Alla IRS sarà inviato solo il Messaggio2. Es.2:
Messaggio1
Reporting FI = X
Anno di riferimento = 2015
Tipo comunicazione = New data Data invio = 15 aprile 2016 Ricevuta = Accolto
Messaggio2
Reporting FI = X
Anno di riferimento = 2015
Tipo comunicazione = New data Data invio = 8 maggio 2016 Ricevuta = Accolto
Alla IRS sarà inviato solo il Messaggio2.
Es3:
Messaggio1
Reporting FI = Y
Anno di riferimento = 2015
Tipo comunicazione = New data Data invio = 15 maggio 2016
Ricevuta = Accolto con segnalazione di tardività Messaggio2
Reporting FI = Y
Anno di riferimento = 2015
Tipo comunicazione = New data Data invio = 16 maggio 2016 Ricevuta = Accolto
Alla IRS sarà inviato il Messaggio1 nel primo invio completo. Il messaggio 2 si intende come integrativo del Messaggio1 e sarà inviato successivamente al primo invio completo dei dati all’IRS.
2.5 COMUNICAZIONI OLTRE IL TERMINE DI SCADENZA
Dal 16° giorno successivo alla scadenza fissata dal Provvedimento, è possibile trasmettere:
1. ulteriori comunicazioni ordinarie - DocTyipeIndic valorizzato con “FATCA1” che saranno ritenuti integrativi e non sostitutivi rispetto agli invii precedenti;
2. comunicazioni sostitutive scaturite da richieste dell’IRS - DocTyipeIndic
valorizzato con “FATCA2” (“Corrected Data”);
3. comunicazioni spontanee di annullamento - DocTyipeIndic valorizzato con “FATCA3” (“Void Data”); possono essere annullati esclusivamente i record contenenti i seguenti errori:
a. Assenza di TIN dell’Account Holder o del Substantial US Owner
b. Errato TIN dell’Account Holder o del Substantial US Owner
c. Nome errato dell’Account Holder o del Substantial US Owner
Nei casi sopra elencati, a seguito dell’annullamento deve essere trasmesso il dato corretto valorizzato con FATCA1 (new data)
4. comunicazioni correttive spontanee - DocTyipeIndic valorizzato con “FATCA4” (“Amended Data”);
In fase di accoglienza telematica, sono attivati i controlli specifici della tipologia di comunicazione. In dettaglio:
• Per comunicazioni con DocTyipeIndic = FATCA1, sarà verificata l’univocità degli identificativi comunicati. Saranno considerati, nella verifica dell’univocità, come già utilizzati, anche quelli inclusi in comunicazioni non trasmesse all’IRS per effetto delle modalità definite per le comunicazioni nei termini.
• Per le comunicazioni con DocTyipeIndic = FATCA2 o FATCA3 o FATCA4, sarà verificata sia l’univocità degli identificativi comunicati, sia la presenza e la validità degli identificativi (CorrMessageRefId e CorrDocRefId) che si intendono annullare (void data) o correggere (corrected data o amended data). La presenza di questi ultimi sarà verificata solo nei file effettivamente spediti all’IRS.
2.6 COMUNICAZIONI IN CASO DI OPERAZIONI STRAORDINARIE, CESSAZIONE E ALTRE VICENDE SOCIETARIE CHE COINVOLGONO LE RIFI
In caso di cessazione dell’attività finanziaria a seguito di fusione, incorporazione, scissione totale o cessione del ramo d’azienda, l’istituzione finanziaria di confluenza è tenuta a effettuare la comunicazione delle informazioni di propria competenza e di quelle relative all’operatore in essa confluito, anche con riferimento a periodi antecedenti l’anno in cui si è verificato l’evento societario.
In caso di cessione di dipendenze, ramo d’azienda e di scissione parziale che non comportino la cessazione dell’attività finanziaria della RIFI cedente, l’istituzione che subentra è tenuta ad effettuare la comunicazione dei conti finanziari acquisiti a partire dalla data di acquisizione in cui si è verificato l’evento, mentre per il periodo precedente la comunicazione è effettuata dalla RIFI cedente. Tale regola si applica a tutti i conti oggetto di reporting, inclusi quelli chiusi in corso d’anno.
Le RIFI che cessano l’attività finanziaria senza confluenza in altro operatore, sottoposte a procedure concorsuali o liquidazione volontaria mantengono attiva la propria utenza S.I.D. e trasmettono entro 90 giorni i dati relativi al periodo infrannuale in cui hanno svolto attività finanziaria (si rimanda alle regole previste
dai punti 4 e 5 del Provvedimento del Direttore dell’Agenzia entrate del 10 febbraio 2015 riguardante il canale S.I.D. per l’Archivio dei rapporti).
3. REGOLE DI COMPILAZIONE DELLA COMUNICAZIONE
3.1 CARATTERISTICHE TECNICHE DEI MESSAGGI XML
Questo capitolo descrive le modalità di compilazione dei file che le FI devono inviare all’Agenzia delle Entrate. Tali file devono essere:
- conformi alle regole definite dalle specifiche tecniche FATCA XML
- rispondenti alle esigenze dettate dagli accordi con l’IRS
- rispondenti alle esigenze stabilite dall’Agenzia delle Entrate
3.1.1 NOTAZIONI ADOTTATE
I blocchi di informazione dello schema XSD che descrive una comunicazione FATCA, sono di seguito presentati in forma tabellare.
Ogni informazione è caratterizzata come segue:
Intestazione colonna | Descrizione |
N° Area | N° area attribuito all’informazione. Questo numero è un identificativo interno di queste specifiche tecniche utilizzato per facilitare i riferimenti alle aree definite dallo schema xml. |
Or | Identifica la condizione di OR tra più elementi: 1° caso: L’annotazione {OR >> … OR} >> indica che una sola delle due aree dovrà essere riportata. 2° caso: L’annotazione {OR >> … |
OR} >> OR} >> indica che dovrà essere compilata in alternativa la prima area o la seconda e la terza area. | |
Livello | Simbolizzato dal carattere >, indica il livello di indentazione nello schema xml |
Oggetto | Indica il nome dell’elemento così come indicato nelle specifiche IRS |
TAG XML | Nome del tag XML |
Molteplicità | E’ indicata nella forma [x…y], dove: • ‘x’ rappresenta la caratteristica di obbligatorietà (valore 1) o opzionalità (valore 0) dell’informazione; • ‘y’ rappresenta il numero massimo di occorrenze dell’elemento accettate. |
Lunghezza | Precisa la lunghezza del dato. |
Tipo | Indica il tipo di dati, come specificato nello schema |
Requisito | Indica il livello di “requirement” dell’oggetto. Può assumere i seguenti valori: • V (Validation) = Obbligatorio per lo schema XSD • M (Mandatory) = Obbligatorio ma non controllato dallo schema XSD • O (Optional) = Opzionale, ma se l’informazione è disponibile deve essere fornita • N (Null) = Non richiesto |
Commento | Precisa il dato atteso e/o le regole di gestione associate a quell’elemento, compresi i controlli formali ulteriori rispetto alla validazione con lo schema xsd. |
3.2 SCHEMI DI RIFERIMENTO
Questi gli schemi xsd di riferimento per le specifiche tecniche:
• FatcaXML_v1.1.xsd
• isofatcatypes_v1.0.xsd
• oecdtypes_v4.1.xsd
• stffatcatypes_v1.1.xsd
Le condizioni per le quali è segnalato l’errore durante il controllo client delle comunicazioni FATCA, oltre a quelle formalizzate dallo schema xsd, sono trattate ai paragrafi 3.5 e 3.6.
3.3 STRUTTURA GENERALE DELLA COMUNICAZIONE FATCA
La comunicazione FATCA è costituita da più blocchi di informazioni strutturate ed organizzate, come schematizzato nella figura 1. Per ragioni di semplificazione, sono rappresentati esclusivamente i grandi blocchi di informazione dello schema.
Figura 1
Le informazioni contenute in testa al messaggio identificano la Sending Company, cioè l’istituzione finanziaria che invia il messaggio. Inoltre sono indicati la data di creazione del messaggio, l’anno di riferimento della comunicazione e la natura delle informazioni (nuovi dati o correttive), nonché un identificativo univoco del messaggio.
3.3.1 IL MESSAGGIO E IL BLOCCO DI DATI FATCA
A livello più alto, la comunicazione FATCA contiene il blocco FATCA_OECD, anche chiamato Messaggio FATCA_OECD.
Il messaggio FATCA_OECD è composto di un blocco MessageSpec e di uno o più blocchi FATCA.
Per i messaggi inviati da Istituzioni Finanziarie (FI) verso l’Agenzia delle Entrate è previsto che la molteplicità del blocco FATCA sia pari a 1.
Un blocco FATCA è composto da un blocco ReportingFI e uno o più blocchi
ReportingGroup.
Il blocco ReportingGroup, per i messaggi di tipo “new data” inviati da Istituzioni Finanziarie verso l’Agenzia delle Entrate, deve contenere almeno un blocco AccountReport.
Il blocco PoolReport non deve essere inserito nel messaggio.
Il blocco MessageSpec caratterizza il messaggio FATCA_OECD mentre il blocco FATCA identifica l’FI che detiene i conti o effettua i pagamenti e i relativi dati oggetto di comunicazione.
La struttura della comunicazione FATCA può essere rappresentata come nella figura seguente:
Livello 0 | Livello 1 | Livello 2 | Livello 3 | Livello 4 | Livello 5 | Livello 6 |
0 | FATCA_OECD | Version | ||||
1 | MessageSpec | |||||
1.1 | SendingCompanyIN | |||||
1.2 | TransmittingCountry | |||||
1.3 | ReceivingCountry | |||||
1.4 | MessageType | |||||
1.5 | Warning | |||||
1.6 | Contact | |||||
1.7 | MessageRefId | |||||
1.8 | CorrMessageRefId | |||||
1.9 | ReportingPeriod | |||||
1.10 | Timestamp | |||||
2 | FATCA | |||||
2.1 | ReportingFI | |||||
2.1.1 | ResCountryCode | |||||
2.1.2 | TIN | issuedBy | ||||
2.1.3 | Name | NameType | ||||
2.1.4 | Address | legalAddressType | ||||
2.1.4.1 | CountryCode | |||||
{OR | 2.1.4.2 | AddressFree | ||||
OR} | 2.1.4.3 | AddressFix | ||||
5.3.1 | Street | |||||
5.3.2 | BuildingIdentifier | |||||
5.3.3 | SuiteIdentifier | |||||
5.3.4 | FloorIdentifier | |||||
5.3.5 | DistrictName | |||||
5.3.6 | POB | |||||
5.3.7 | PostCode | |||||
5.3.8 | City | |||||
5.3.9 | CountrySubentity |
I blocchi sono dettagliati al paragrafo 3.4 Struttura in dettaglio del messaggio FATCA_OECD.
3.3.2 IL MESSAGGIO E LE INFORMAZIONI TECNICHE DI IDENTIFICAZIONE
Il messaggio FATCA_OECD contiene informazioni tecniche che servono a identificare, in modo univoco ed inequivocabile, i blocchi del messaggio FATCA_OECD.
Queste informazioni tecniche sono obbligatorie e si trovano:
• nel blocco MessageSpec (a livello del Messaggio)
• nel blocco generico DocSpec (a livello di blocco di informazioni).
I blocchi che possono essere corretti (Correctable) contengono tutti e soli la testata DocSpec.
I dati di dettaglio che consentono l’identificazione univoca dell’informazione sono:
MessageSpec
• MessageRefId
• CorrMessageRefId
DocSpec
• DocRefId
• CorrMessageRefId
• CorrDocRefId
Il dato MessageRefId deve essere univoco nel tempo e nello spazio. Pertanto si richiede che sia una stringa di 41 caratteri avente la seguente struttura:
19 caratteri corrispondenti al GIIN del ReportingFI seguiti dal carattere ‘.’
seguito da
11 caratteri numerici corrispondenti al codice fiscale del ReportingFI
seguiti da
10 caratteri alfanumerici identificanti un progressivo.
Il programma di controllo ne verificherà la correttezza formale secondo questa struttura, mentre l'univocità nello spazio e nel tempo sarà verificata al momento del ricevimento del file.
Il dato CorrMessageRefId è da riportare solo quando il messaggio è di tipo “correttivo” (corrected data o amended data) o “di annullamento” (void data) di un messaggio precedentemente inviato.
Il dato DocRefId, presente in ogni DocSpec dei blocchi di informazione, deve essere univoco nello spazio e nel tempo. Per questo si richiede che sia una stringa di 53 caratteri con la seguente struttura:
MessageRefId
seguito da
TipoBlocco (2 caratteri FI = ReportingFI, SP = Sponsor, IN = Intermediary, AR = AccountReport )
seguito da
progressivo del blocco dati all'interno del messaggio di 10 caratteri alfanumerici.
Il programma di controllo ne verificherà la correttezza formale secondo questa struttura e l’univocità all’interno di ogni file controllato, mentre l'univocità nello spazio e nel tempo sarà verificata al momento del ricevimento del file.
Il dato CorrDocRefId è da riportare solo quando il DocTypeIndic = FATCA2 o FATCA3 o FATCA4, cioè se il messaggio è di tipo “correttivo” (“corrected data” o “amended data”) o “di annullamento” (“void data”) di un messaggio precedentemente inviato. Questo dato specifica il blocco di informazioni da correggere o annullare. Deve pertanto fare riferimento al DocRefId del file originale e deve essere preceduto obbligatoriamente dal CorrMessageRefId.
Durante il controllo successivo all'invio del file all'Agenzia delle Entrate, è verificata l'esistenza di tale identificativo tra i dati precedentemente trasmessi.
3.4 STRUTTURA IN DETTAGLIO DEL MESSAGGIO FATCA_OECD
3.4.1 FATCA_OECD
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
FATCA_OECD | <ftc:FATCA_OECD> | [1..1] | V | Elemento Root | |||||
FATCA_OECD | version= | [0..1] | String | M | Deve contenere il valore della versione dello schema FATCA utilizzato | ||||
1 | > | MessageSpec | <ftc:MessageSpec> | [1..1] | sfa:MessageSpec_Type | V | |||
2 | > | FATCA | <ftc:FATCA> | [1..n] | ftc:Fatca_Type | V |
3.4.2 FATCA_OECD / MESSAGESPEC (SFA:MESSAGESPEC_TYPE)
N° Area | Or | Liv. | Oggetto | TAG XML | Moltepli cità | Lunghezza | Tipo | Requisito | Commento |
1 | MessageSpec | <ftc:MessageSpec> | [1..1] | sfa:MessageSpec_Type | V | È l'intestazione del messaggio. Caratterizza il messaggio. Specifica la data di creazione del messaggio, l'anno di riferimento della comunicazione e la natura della comunicazione | |||
1.1 | > | SendingCompanyIN | <sfa:SendingCompanyIN> | [0..1] | Unlimited | xsd:string | M | Identificativo GIIN dell' FI inviante (Reporting FI o Sponsor). Il GIIN è un identificativo di 19 caratteri alfanumerico. Deve essere impostato secondo la seguente struttura fissa per esempio: 98Q96B.00000.LE.380 E' previsto scarto del file se non impostato secondo la struttura succitata | |
1.2 | > | TransmittingCountry | <sfa:TransmittingCountry> | [1..1] | 2 digits | iso:CountryCode_Type | V | Paese di emissione Unico valore possibile = IT | |
1.3 | > | ReceivingCountry | <sfa:ReceivingCountry> | [1..1] | 2 digits | iso:CountryCode_Type | V | Destinatario del messaggio. = US |
1.4 | > | MessageType | <sfa:MessageType> | [1..1] | sfa:MessageType_Enu mType | V | Unico valore possibile = FATCA | ||
1.5 | > | Warning | <sfa:Warning> | [0..1] | Testo libero | xsd:string | O | Istruzioni specifiche sull'uso del file. Può essere lasciato vuoto. | |
1.6 | > | Contact | <sfa:Contact> | [0..1] | Testo libero | xsd:string | N | ||
1.7 | > | MessageRefID | <sfa:MessageRefId> | [1..1] | Testo libero | xsd:string | V | Numero di identificazione univoco del messaggio fornito dal FI inviante. Questo identificativo deve essere univoco nello spazio e nel tempo. Sarà utilizzato nell'area 1.8 CorrMessageRefID per designare il MessageRefID di un messaggio precedente da correggere. Si richiede che sia composto da una stringa di 41 caratteri con la seguente struttura: 19 caratteri corrispondenti al GIIN del ReportingFI seguiti da ‘.’ seguiti da 11 caratteri numerici corrispondenti al codice fiscale del ReportingFI seguiti da 10 caratteri alfanumerici che identificano un progressivo. La stringa non deve contenere spazi. Il programma di controllo ne verificherà la correttezza formale secondo questa struttura, mentre l'univocità nello spazio e nel tempo sarà verificata al momento del ricevimento del file |
1.8 | > | CorrMessageRefID | <sfa:CorrMessageRefId> | [0..n] | Testo libero | xsd:string | O | Numero di identificazione univoco che identifica il messaggio originale che si vuole correggere (obbligatorio per un messaggio di tipo correttivo) | |
1.9 | > | ReportingPeriod | <sfa:ReportingPeriod> | [1..1] | xsd:date | V | Questa data identifica l'anno cui si riferisce il messaggio. Deve essere impostata utilizzando il formato YYYY-MM-DD. Ad esempio, se le informazioni riportate riguardano conti o pagamenti relativi all'anno solare 2014, il campo deve essere impostato con il valore “2014-12- 31”. Il programma di controllo scarterà messaggi con date anteriori al 2014-12-31, che abbiano MM <>12 o GG <>31. | ||
1.10 | > | Timestamp | <sfa:Timestamp> | [1..1] | xsd:dateTime | V | Questo dato identifica la data e l'ora in cui il file è stato creato. Deve essere inserita automaticamente dal sistema host. Il formato da utilizzare è: AAAA- MM-GG'T'hh: mm: ss. Le frazioni di secondo non sono menzionate. Esempio: 2015-03-15T09:45:30 Queste informazioni sono assegnate dall’FI inviante |
3.4.3 FATCA_OECD / FATCA (FTC:FATCA_TYPE)
Questa tabella elenca la sequenza di blocchi di informazioni possibili. Ciascun blocco è dettagliato nelle tabelle successive.
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
2 | FATCA | <ftc:FATCA> | [1..n] | ftc:Fatca_Type | V | Anche se la molteplicità prevista dallo schema è [1…n], nel flusso prodotto dall’FI all'Agenzia delle Entrate la molteplicità di questo elemento è [1…1] | |||
2.1 | > | ReportingFI | <ftc:ReportingFI> | [1..1] | ftc:CorrectableOrganisationParty_Type | V | Identifica l'istituzione finanziaria che detiene i conti o effettua i pagamenti cf. Blocco generico OrganisationPar ty_Type | ||
2.2 | > | ReportingGroup | <ftc:ReportingGroup> | [1..n] | V | Dettagli specifici della comunicazione |
FATCA | |||||||||
2.2.1 | >> | Sponsor | <ftc:Sponsor> | [0..1] | ftc:CorrectableOrganisationParty_Type | O | Lo sponsor è l’entità che accetta di adempiere gli obblighi posti in capo all’ FI (DM, art. 8, co. 2). Non è ammessa la presenza di più di uno sponsor. In presenza di più occorrenze di ReportingGroup il blocco sponsor deve essere ripetuto in tutti i Reporting Group con gli stessi valori. Saranno confrontati esclusivamente i campi TIN cf. Blocco generico OrganisationPar ty_Type |
2.2.2 | >> | Intermediary | <ftc:Intermediary> | [0..1] | ftc:CorrectableOrganisationParty_Type | O | Informazioni che identificano un soggetto statunitense che, con riferimento a un pagamento ricevuto, agisce in qualità di custode, broker o agente per conto di un’altra persona indipendentem ente dalla qualifica di questa persona (beneficiario effettivo o meno) cf. Blocco generico OrganisationPar ty_Type | ||
2.2.3 | {OR | >> | AccountReport | <ftc:AccountReport> | [0..n] | ftc:CorrectableAccountReport_Type | O | Per le comunicazioni di tipo FATCA1 è obbligatoria la presenza di almeno una occorrenza di questo blocco |
2.2.3 | OR} | >> | PoolReport | <ftc:PoolReport> | [0..n] | ftc:CorrectablePoolReport_Type | O | Questo campo non deve essere impostato dalle FI italiane |
3.4.4 FATCA_OECD / FATCA / REPORTINGFI
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
2.1 | ReportingFI | <ftc:ReportingFI> | [1..1] | ftc:CorrectableOrganisationParty_Type | V | Identifica l’istituzione finanziaria che detiene i conti o effettua i pagamenti | |||
2.1.1 | > | ResCountryCode | <sfa:ResCountryCode> | [0..n] | 2 digit | iso:CountryCode_Type | O | Deve essere sempre impostato a IT | |
2.1.2 | > | TIN | <sfa:TIN> | [0..n] | Min 1 char | sfa:TIN_Type | M | La molteplicità è [2…2] per i messaggi inviati dagli FI italiani all’Agenzia delle Entrate. Nella prima occorrenza impostare il Codice Fiscale italiano; tale codice fiscale sarà controllato formalmente durante il controllo client e ne sarà verificata l’esistenza in A.T. dopo la trasmissione del file. |
In assenza del blocco Sponsor, il codice fiscale indicato deve coincidere con il codice fiscale accreditato alla piattaforma SID e con il codice fiscale dell’intestatario del certificato di firma. Nella seconda occorrenza deve contenere l’ Identificativo GIIN dell'FI o, se mancante per le comunicazioni relative al 2014, il GIIN dello Sponsor. Il GIIN è un identificativo di 19 caratteri alfanumerico. Deve essere impostato secondo la seguente struttura fissa. Per esempio: 98Q96B.00000.LE.380 o 98Q96B.00000.SP.380 (solo nel caso di presenza di sponsor e fino all’anno di riferimento 2014) E' previsto scarto del file se non impostato secondo la struttura succitata. In assenza del blocco Sponsor, il GIIN deve coincidere con quello riportato nel campo SendingCompanyIN del blocco MessageSpec |
2.1.2 | > | TIN | issuedBy | [0..1] | iso:CountryCode_Type | O | Codice del paese emittente il TIN. Impostare con IT nella prima occorrenza, non utilizzare nella seconda occorrenza | ||
2.1.3 | > | Name | <sfa:Name> | [1..n] | sfa:NameOrganisation_Type | V | Corrisponde alla ragione sociale dell'istituzione finanziaria che detiene i conti o effettua i pagamenti | ||
2.1.3 | > | Name | nameType | [0..1] | stf:OECDNameType_EnumType | N | |||
2.1.4 | > | Address | <sfa:Address> | [1..n] | sfa:Address_Type | V | cf. Blocco Generico Address_Type | ||
2.1.5 | > | DocSpec | <ftc:DocSpec> | [1..1] | ftc:DocSpec_Type | V | cf. Blocco Generico DocSpec_Type |
3.4.5 FATCA_OECD / FATCA / REPORTINGGROUP/SPONSOR
Se questo blocco è presente, deve essere identico in ogni ReportingGroup presente nel messaggio.
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
2.2.1 | Sponsor | <ftc:Sponsor> | [0..1] | ftc:CorrectableOrganisationParty_Type | O | Lo sponsor è l’entità che accetta di adempiere gli obblighi posti in capo al FI (DM, art. 8, co. 2). Non è ammessa la presenza di più di uno sponsor. In presenza di più occorrenze di ReportingGroup il blocco sponsor deve essere ripetuto in tutti i ReportingGroup con gli stessi valori. Saranno confrontati esclusivamente i campi TIN cf. Blocco generico OrganisationParty_Type | |||
2.2.1.1 | > | ResCountryCode | <sfa:ResCountryCode> | [0..n] | 2 digit | iso:CountryCode_Type | O | Codice del paese di residenza fiscale dello Sponsor. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE | |
2.2.1.2 | > | TIN | <sfa:TIN> | [0..n] | Min 1 char | sfa:TIN_Type | M | La molteplicità è [2…2] per i messaggi inviati dagli FI italiani all’Agenzia delle Entrate. Nella prima occorrenza impostare il Codice Fiscale italiano; tale codice fiscale sarà |
controllato formalmente durante il controllo client e ne sarà verificata l’esistenza in A.T. dopo la trasmissione del file. Il codice fiscale indicato deve coincidere con il codice fiscale accreditato alla piattaforma SID e con il codice fiscale dell’intestatario del certificato di firma. Nella seconda occorrenza deve contenere l’Identificativo GIIN ottenuto in qualità di Sponsoring Entity. Il GIIN è un identificativo di 19 caratteri alfanumerico. Deve essere impostato secondo la seguente struttura fissa per esempio: 98Q96B.00000.SP.380 E' previsto scarto del file se non impostato secondo la struttura succitata. Il GIIN deve coincidere con quello riportato nel campo SendingCompanyIN del blocco MessageSpec |
2.2.1.2 | > | TIN | issuedBy | [0..1] | iso:CountryCode_Type | O | Codice del paese emittente il TIN. Impostare con IT nella prima occorrenza, non utilizzare nella seconda occorrenza | ||
2.2.1.3 | > | Name | <sfa:Name> | [1..n] | sfa:NameOrganisation_Type | V | Corrisponde alla ragione sociale dello Sponsor | ||
2.2.1.3 | > | Name | nameType | [0..1] | stf:OECDNameType_EnumType | N | |||
2.2.1.4 | > | Address | <sfa:Address> | [1..n] | sfa:Address_Type | V | cf.Blocco Generico Address_Type | ||
2.2.1.5 | > | DocSpec | <ftc:DocSpec> | [1..1] | ftc:DocSpec_Type | V | cf.Blocco Generico DocSpec_Type |
3.4.6 FATCA_OECD / FATCA / REPORTINGGROUP/INTERMEDIARY
Questo blocco non è obbligatorio. Contiene informazioni relative a un soggetto statunitense che, con riferimento a un pagamento ricevuto, agisce in qualità di custode, broker o agente per conto di un altro soggetto, indipendentemente dalla qualifica di quest’ultimo (beneficiario effettivo o meno). Per ogni blocco di dati “Intermediary”, per comunicazioni di tipo FATCA1, devono essere comunicati i dati dei conti (“AccountReport”) riferiti all’intermediario indicato
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
2.2.2 | Intermediary | <ftc:Intermediary> | [0..1] | ftc:CorrectableOrganisationParty_Type | O | Informazioni che identificano un soggetto statunitense che, con riferimento a un pagamento ricevuto, agisce in qualità di custode, broker o agente per conto di un altro soggetto, indipendentemente dalla qualifica di quest’ultimo (beneficiario effettivo o meno) cf. Blocco generico OrganisationParty_Type | |||
2.2.2.1 | > | ResCountryCode | <sfa:ResCountryCode> | [0..n] | 2 digit | iso:CountryCode_Type | O | Codice del paese di residenza dell'Intermediary. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE |
2.2.2.2 | > | TIN | <sfa:TIN> | [0..n] | Min 1 char | sfa:TIN_Type | M | Indicare l’EIN statunitense, se al soggetto ne è stato rilasciato uno, altrimenti indicare l’EIN utilizzato dal territorio statunitense di pertinenza per identificare il soggetto. Indicare un solo TIN (molteplicità [1..1] | |
2.2.2.2 | > | TIN | issuedBy | [0..1] | iso:CountryCode_Type | O | Codice del paese emittente il numero di identificazione. Non utilizzare per indicare gli US come paese emittente | ||
2.2.2.3 | > | Name | <sfa:Name> | [1..n] | sfa:NameOrganisation_Type | V | Corrisponde alla ragione sociale dell'Intermediary | ||
2.2.2.3 | > | Name | nameType | [0..1] | stf:OECDNameType_EnumType | N | |||
2.2.2.4 | > | Address | <sfa:Address> | [1..n] | sfa:Address_Type | V | cf.Blocco Generico Address_Type | ||
2.2.2.5 | > | DocSpec | <ftc:DocSpec> | [1..1] | ftc:DocSpec_Type | V | cf.Blocco Generico DocSpec_Type |
3.4.7 FATCA_OECD / FATCA / REPORTINGGROUP/ ACCOUNTREPORT
Il blocco AccountReport è obbligatorio in tutte le comunicazioni di tipo “New data” (FATCA1)
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
2.2.3 | AccountReport | <ftc:AccountReport> | [0..n] | ftc:CorrectableAccountReport_Type | O | In caso di "New data" questo elemento è obbligatorio. | |||
2.2.3.1 | > | DocSpec | <ftc:DocSpec> | [1..1] | ftc:DocSpec_Type | V | cf. Blocco generico DocSpec_Type | ||
2.2.3.2 | > | AccountNumber | <ftc:AccountNumber> | [1..1] | ftc:FIAccountNumber_Type | V | |||
2.2.3.3 | > | AccountHolder | <ftc:AccountHolder> | [1..1] | ftc:AccountHolder_Type | V | |||
2.2.3.3.1 | {OR | >> | Individual | <ftc:Individual> | [1..1] | sfa:PersonParty_Type | O | cf. BLOCCO GENERICO PersonParty_Type (Persona Fisica comprese le ditte individuali) | |
2.2.3.3.2 | OR} | >> | Organisation | <ftc:Organisation> | [1..1] | sfa:OrganisationParty_Type | O | cf. BLOCCO GENERICO OrganisationParty_Type (Persona giuridica o diversa da persona fisica) |
2.2.3.3.3 | OR} | >> | AcctHolderType | <ftc:AcctHolderType> | [1..1] | ftc:FatcaAcctHolderType_EnumType | M | Elemento da compilare esclusivamente se il titolare del conto è una persona giuridica o diversa da persona fisica) . Lista dei possibili valori: • FATCA102 = Passive Non-Financial Entity with substantial US owner(s) • FATCA103 = Non- Participating FFI • FATCA104 = Specified US Person | |
2.5.4 | > | SubstantialOwner | <ftc:SubstantialOwner> | [0..n] | sfa:PersonParty_Type | M | Obbligatorio se AccHolderType = FATCA102 cf. BLOCCO GENERICO PersonParty_Type Tale campo riguarda le persone fisiche che esercitano il controllo (“Controlling persons”) su una NFFE passiva ai sensi dell’art. 1, par. 1, lett. mm), dell’IGA Italia. | ||
2.5.5 | > | AccountBalance | <ftc:AccountBalance> | [1..1] | sfa:MonAmnt_Type | V | Se il saldo del conto è negativo il valore da riportare è zero. |
Il saldo o valore del conto immediatamente prima della chiusura è dato dal maggiore tra il saldo contabile iniziale del giorno in cui è stato effettuato l’ultimo addebito prima della chiusura del rapporto e quello risultante al momento della estinzione (vedi par. 3.7) | |||||||||
2.5.5 | > | AccountBalance | currCode | [1..1] | 3 digits | iso:currCode_Type | V | Valuta La lista dei valori possibili è indicata nello schema ISOFATCATYPE | |
2.5.6 | > | Payment | <ftc:Payment> | [0..n] | ftc:Payment_Type | O | Tale elemento può essere presente a partire dalla comunicazione relativa all’anno 2015. |
2.5.6.1 | >> | Type | <ftc:Type> | [1..1] | ftc:FatcaPaymentType_EnumType | V | Scegliere il codice corretto tra i tipi di pagamento possibili: • FATCA501 = Dividendi • FATCA502 = Interessi • FATCA503 = Corrispettivi lordi per vendite, riscatti e rimborsi • FATCA504 = Altri proventi, compresi rendite, arretrati e pagamenti effettuati ad istituzioni finanziarie non partecipanti. | ||
2.5.6.2 | >> | PaymentAmnt | <ftc:PaymentAmnt> | [1..1] | sfa:MonAmnt_Type | V | Indicare zero se il rapporto in essere può in astratto comportare una tipologia di pagamento ma in concreto per l’anno di riferimento il pagamento non è stato effettuato (“conto azioni” che nell’anno di riferimento non hanno dato luogo a pagamenti di dividendi). Non compilare il campo se tale possibilità non è prefigurabile in astratto. L’importo va sempre indicato con 2 cifre decimali. La parte decimale è separata da |
quella intera dal . | |||||||||
2.5.6.2 | >> | PaymentAmnt | currCode | [1..1] | 3 digits | iso:currCode_Type | V | Valuta La lista dei valori possibili è indicata nello schema ISOFATCATYPE |
3.4.8 FATCA_OECD / FATCA / REPORTINGGROUP/ POOLREPORT
Questo blocco di dati non è da includere nel messaggio dalle istituzioni finanziarie italiane verso l’Agenzia delle Entrate.
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
2.2.3 | PoolReport | <ftc:PoolReport> | [0..n] | ftc:CorrectablePoolReport_Type | O | Questo elemento non deve essere compilato | |||
2.2.3.1 | > | DocSpec | <ftc:DocSpec> | [1..1] | ftc:DocSpec_Type | V | |||
2.2.3.2 | > | AccountCount | <ftc:AccountCount> | [1..1] | xsd:integer | V | |||
2.2.3.3 | > | AccountPoolReportType | <ftc:AccountPoolReportType> | [1..1] | ftc:FatcaAcctPoolReportType_EnumType | V | |||
2.2.3.4 | > | PoolBalance | <ftc:PoolBalance> | [1..1] | sfa:MonAmnt_Type | V | |||
2.2.3.4 | > | PoolBalance | currCode | [1..1] | 3 digits | iso:currCode_Type | V |
3.4.9 BLOCCO GENERICO FTC:DOCSPEC_TYPE
Questo blocco di dati viene riferito in vari punti dell'albero del messaggio XML FATCA.
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
3 | DocSpec | <ftc:DocSpec> | [1..1] | ftc:DocSpec_Type | V | Permette di individuare univocamente un particolare blocco di dati tra tutti quelli inviati. | |||
3.1 | > | DocTypeIndic | <ftc:DocTypeIndic> | [1..1] | ftc:FatcaDocTypeIndic_EnumType | V | Questo elemento specifica il tipo di comunicazione. Tutti gli elementi DocTypeIndic presenti in una comunicazione FATCA devono riportare lo stesso valore. I valori possibili sono: • FATCA1 = New Data (Nuovi Dati) • FATCA2 = Corrected Data (Dati corretti a seguito di una richiesta di correzione da parte degli US) • FATCA3 = Void Data (Dati da annullare) • FATCA4 = Amended Data (Dati corretti per errori rilevati autonomamente dall'FI) |
• FATCA11 = New Test Data • FATCA12 = Corrected Test Data • FATCA13 = Void Test Data • FATCA14 = Amended Test Data I codici da FATCA11 a 14 possono essere utilizzati solo in fase di test e non devono essere mai utilizzati in una comunicazione FATCA | |||||||||
3.2 | > | DocRefId | <ftc:DocRefId> | [1..1] | Min 1 char | xsd:string | V | Identificativo univoco del blocco di dati. Si richiede che sia composto con la seguente struttura: MessageRefId (vedi struttura del MessageRefId) + 2 caratteri per l’individuazione del blocco (FI = ReportingFI, SP = Sponsor, IN = Intermediary, AR = AccountReport)+ progressivo del blocco dati all'interno del messaggio di 10 caratteri. Il programma di controllo ne verificherà la correttezza formale secondo questa struttura, |
mentre l'univocità nello spazio e nel tempo sarà verificata al momento del ricevimento del file. Es: 98X96B.00000.LE.380.063 633910010000000001AR 0000000001 La stringa non deve contenere spazi | |||||||||
3.3 | > | CorrMessageRefId | <ftc:CorrMessageRefId> | [0..1] | Min 1 char | xsd:string | O | Identificativo univoco (come determinato dal mittente) per individuare il file originale che viene corretto. Deve essere impostato solo per un file di correzione o annullamento di dati precedentemente inviati. Deve fare riferimento al MessageRefId del file originale (Area 1.7 del file originale) e deve essere seguito obbligatoriamente dal CorrDocRefId. Durante il controllo successivo all'invio del file all'Agenzia delle Entrate, è verificata l'esistenza di tale identificativo tra i dati precedentemente trasmessi |
3.4 | > | CorrDocRefId | <ftc:CorrDocRefId> | [0..1] | Min 1 char | xsd:string | O | Identificativo univoco (come determinato dal mittente) per individuare il blocco dati originale che viene corretto. Deve essere impostato solo per un file di correzione o annullamento di dati precedentemente inviati. Deve fare riferimento al DocRefId del file originale e deve essere preceduto obbligatoriamente dal CorrMessageRefId. Durante il controllo successivo all'invio del file all'Agenzia delle Entrate, è verificata l'esistenza di tale identificativo tra i dati precedentemente trasmessi |
3.4.10 BLOCCO GENERICO SFA:PERSONPARTY_TYPE
Questo blocco di dati può essere utilizzato nel blocco AccountHolder (se il titolare del conto è una Persona Fisica incluse le ditte individuali) e nel blocco SubstantialOwner.
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
4 | PersonParty_Type | BLOCCO GENERICO PersonParty_Type Questo blocco deve essere compilato esclusivamente se il soggetto è una persona fisica | |||||||
4.1 | > | ResCountryCode | <sfa:ResCountryCode> | [0..n] | 2 digit | iso:CountryCode_Type | O | Codice del paese di residenza fiscale del soggetto. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE | |
4.2 | > | TIN | <sfa:TIN> | [0..n] | Min 1 char | sfa:TIN_Type | M* | In relazione ai conti esistenti al 30 giugno 2014 (pre-existing) e con riferimento ai periodi dal 2014 al 2016, le FI italiane non sono tenute a fornire il TIN statunitense se i loro archivi non contengono il dato. Obbligatorio per le comunicazioni dall’anno 2017. Se il soggetto possiede codice fiscale italiano, l’FI è tenuta ad inserirlo, anche come seconda occorrenza dopo quello statunitense. In questo caso ne sarà controllata la correttezza formale in fase di controllo client. |
4.2 | > | TIN | issuedBy | [0..1] | iso:CountryCode_Type | O | Codice del paese emittente il numero di identificazione. Non utilizzare solo quando il paese di emissione del TIN sono gli Stati Uniti. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE | ||
4.3 | > | Name | <sfa:Name> | [1..n] | sfa:NamePerson_Type | V | |||
4.3 | > | Name | nameType | [0..1] | stf:OECDNameType_EnumType | N | |||
4.3.1 | >> | PrecedingTitle | <sfa :PrecedingTitle> | [0..1] | xsd:string | N | |||
4.3.2 | >> | Title | <sfa:Title> | [0..n] | xsd:string | N | |||
4.3.3 | >> | FirstName | <sfa:FirstName> | [1..1] | xsd:string | V | |||
4.3.3 | >> | FirstName | xmlNameType | [0..1] | xsd:string | O | |||
4.3.4 | >> | MiddleName | <sfa:MiddleName> | [0..n] | xsd:string | O | |||
4.3.4 | >> | MiddleName | xmlNameType | [0..1] | xsd:string | N | |||
4.3.5 | >> | NamePrefix | <sfa:NamePrefix> | [0..1] | xsd:string | N | |||
4.3.5 | >> | NamePrefix | xmlNameType | [0..1] | xsd:string | N | |||
4.3.6 | >> | LastName | <sfa:LastName> | [1..1] | xsd:string | V | |||
4.3.6 | >> | LastName | xnlNameType | [0..1] | xsd:string | N | |||
4.3.7 | >> | GenerationIdentifier | <sfa:GenerationIdentifier> | [0..n] | xsd:string | N | |||
4.3.8 | >> | Suffix | <sfa:Suffix> | [0..n] | xsd:string | N |
4.3.9 | GeneralSuffix | <sfa:GeneralSuffix> | [0..1] | xsd:string | N | ||||
4.4 | > | Address | <sfa:Address> | [1..n] | sfa:Address_Type | V | cf. BLOCCO GENERICO Address_Type | ||
4.5 | > | Nationality | <sfa:Nationality> | [0..n] | 2-digit | iso:CountryCode_Type | N | ||
4.6 | > | BirthInfo | <sfa:BirthInfo> | [0..1] | M | Blocco dati di nascita del titolare del conto. | |||
4.6.1 | >> | BirthDate | <sfa:BirthDate> | [0..1] | xsd:date | O | Data di nascita del titolare del conto. Formato da utilizzare AAAA- MM-GG. Per i soggetti di cui non si è in possesso del TIN, tale dato deve essere fornito, se le FI ne sono in possesso. | ||
4.6.2 | >> | City | <sfa:City> | [0..1] | xsd:string | N | |||
4.6.3 | >> | CitySubentity | <sfa:CitySubentity> | [0..1] | xsd:string | N | |||
4.6.4 | >> | CountryInfo | <sfa:CountryInfo> | [0..1] | N | ||||
4.6.4.1 | {OR | >>> | CountryCode | <sfa:CountryCode> | [1..1] | 2-digit | iso:CountryCode_Type | N | |
4.6.4.2 | OR} | >>> | FormerCountryName | <sfa:FormerCountryName> | [1..1] | xsd:string | N |
3.4.11 BLOCCO GENERICO SFA:ADDRESS_TYPE
Questo blocco di dati viene riferito in vari punti dell'albero del messaggio XML FATCA.
N° Area | Or | Livello | Oggetto | TAG XML | Molteplicità | Lunghezza | Tipo | Requisito | Commento |
5 | Address_Type | Blocco generico Address_Type Ci sono due tipi di indirizzo nello schema: • indirizzo strutturato • indirizzo libero L'indirizzo in formato strutturato deve essere usato in ogni comunicazione FATCA, a meno che l'istituzione finanziaria non sia in grado di definire le varie parti dell'indirizzo. In tal caso va usato l’indirizzo libero. Deve essere comunicato l'indirizzo della sede legale o di residenza anagrafica del soggetto cui si riferisce. | |||||||
5 | Address_Type | legalAddressType | [0..1] | stf:OECDLegalAddressType_EnumType | N | ||||
5.1 | > | CountryCode | <sfa:CountryCode> | [1..1] | 2-digits | iso:CountryCode_Type | M | Codice del paese di residenza. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE |
5.2 | {OR | > | AddressFree | <sfa:AddressFree> | [1..1] | xsd:string | O* | Se l'utente sceglie l'opzione di inserire i dati richiesti in modo meno strutturato in 'AddressFree', tutti i dettagli dell'indirizzo disponibili devono essere presentati come una stringa di byte utilizzando il carattere "/" o il carattere di fine riga o il carattere spazio come delimitatore tra le varie parti dell'indirizzo. Questa opzione dovrà essere utilizzata solo se i dati non possono essere presentati nel formato AddressFix. NOTA: Se l'FI decide di utilizzare il formato AddressFix, avrà la possibilità di immettere l'indirizzo stradale completo del soggetto in AddressFree, aggiungendo tale elemento dopo l'AddressFix. In tal caso gli elementi City, CountrySubentity e PostCode presenti nell'elemento AddressFix devono essere obbligatoriamente compilati. | |
5.3 | OR} | > | AddressFix | <sfa:AddressFix> | [1..1] | sfa:AddressFix_Type | |||
5.3.1 | >> | Street | <sfa:Street> | [0..1] | xsd:string | O | Via | ||
5.3.2 | >> | BuildingIdentifier | <sfa:BuildingIdentifier> | [0..1] | xsd:string | O | Numero Civico | ||
5.3.3 | >> | SuiteIdentifier | <sfa:SuiteIdentifier> | [0..1] | xsd:string | O | Informazioni complementari. |
Ad es.interno | |||||||||
5.3.4 | >> | FloorIdentifier | <sfa:FloorIdentifier> | [0..1] | xsd:string | O | Piano | ||
5.3.5 | >> | DistrictName | <sfa:DistrictName> | [0..1] | xsd:string | O | |||
5.3.6 | >> | POB | <sfa:POB> | [0..1] | xsd:string | O | Casella Postale | ||
5.3.7 | >> | PostCode | <sfa:PostCode> | [0..1] | xsd:string | O | Codice d'avviamento postale | ||
5.3.8 | >> | City | <sfa:City> | [1..1] | xsd:string | V | Comune | ||
5.3.9 | >> | CountrySubentity | <sfa:CountrySubentity> | [0..1] | xsd:string | O | Provincia/Regione/Stato Federale | ||
5.3 | OR} | > | AddressFree | <sfa:AddressFree> | [0..1] | xsd:string | O |
3.4.12 BLOCCO GENERICO SFA: ORGANISATIONPARTY_TYPE
Questo blocco di dati viene riferito in vari punti dell'albero del messaggio XML FATCA.
N° Area | Or | Livello | Oggetto | TAG XML | Molte plicità | Lunghezz a | Tipo | Requisito | Commento |
6 | sfa:Organisation Party_Type | sfa:OrganisationParty_Type | Dato da riempire esclusivamente in caso il soggetto sia una persona giuridica o diversa da persona fisica | ||||||
6.1 | > | ResCountryCode | <sfa:ResCountryCode> | [0..n] | 2 digit | iso:CountryCode_Type | O | Codice del paese di residenza fiscale del soggetto. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE | |
6.2 | > | TIN | <sfa:TIN> | [0..n] | Min 1 char | sfa:TIN_Type | M | Numero di identificazione fiscale (vedi regole specifiche del soggetto cui è riferito). Se riferito ad account holder in possesso di C.F. italiano, l’FI è tenuta ad inserirlo, anche come seconda occorrenza dopo quello statunitense. In questo caso ne sarà controllata la correttezza formale in fase di controllo client. | |
6.2 | > | TIN | issuedBy | [0..1] | 2 digit | O | Codice del paese emittente il numero di identificazione. Non utilizzare solo quando il paese di emissione del TIN sono gli Stati Uniti. La lista dei valori possibili è fornita dallo schema ISOFATCATYPE | ||
6.3 | > | Name | <sfa:Name> | [1..n] | sfa:NameOrganisation_Type | V | |||
6.3 | > | Name | nameType | [0..1] | stf:OECDNameType_EnumType | N |
6.4 | > | Address | <sfa:Address> | [1..n] | sfa:Address_Type | V | cf. BLOCCO GENERICO Address_Type |
3.5 CONTROLLI FORMALI ULTERIORI RISPETTO ALLA VALIDAZIONE CON LO SCHEMA XSD
Il programma di controllo messo a disposizione dall’Agenzia delle Entrate, effettuerà, oltre alla validazione del file rispetto allo schema xsd, ulteriori controlli descritti qui di seguito:
BLOCCO FATCA_OECD
• Il blocco dati FATCA deve essere presente solo una volta nel messaggio.
BLOCCO MessageSpec
• Il campo SendingCompanyIN deve essere una stringa contenente il GIIN del soggetto inviante (ReportingFI o Sponsor), formata da 19 caratteri alfanumerici così composta:
XXXXXX.YYYYY.ZZ.NNN (nel caso in cui il soggetto inviante sia il ReportingFI gli ultimi 3 caratteri NNN devono valere 380 obbligatoriamente; la posizione dei “.” è fissa)
• Il campo TransmittingCountry deve contenere il valore IT
• Il campo ReceivingCountry deve contenere il valore US
• Il campo MessageRefID deve essere una stringa di 41 caratteri, così composta: i primi 19 caratteri corrispondenti al GIIN del ReportingFI seguiti dal carattere “.”, 11 corrispondenti al codice fiscale del Reporting FI, 10 caratteri alfanumerici che identificano un progressivo. La stringa non deve contenere spazi.
• Il campo CorrMessageRefId non deve essere presente se non per comunicazioni in cui tutti i DocTypeIndic presenti nel messaggio xml siano impostati con uno dei seguenti valori : FATCA2, FATCA3, FATCA4. Il campo deve avere la stessa struttura del MessageRefID
• Tutti e soli i valori presenti nei tag CorrMessageRefId del blocco MessageSpec devono essere presenti nei tag CorrMessageRefId di ogni singolo blocco DocSpec presente nella comunicazione
• Il campo ReportingPeriod deve contenere una data non inferiore a 2014- 12-31. Il mese deve essere sempre impostato a 12 e il giorno sempre a 31
BLOCCO FATCA
• Tutti i valori del campo DocTypeIndic presenti in ogni blocco DocSpec
devono avere lo stesso valore
• I valori di DocRefId presenti in tutto il file non devono essere mai duplicati. E’ controllata l’univocità dei DocRefId nel file.
• In presenza di più occorrenze del blocco ReportingGroup, sono effettuati i seguenti controlli:
o Se presente il blocco Sponsor, questo deve essere ripetuto con gli stessi valori in tutti i blocchi ReportingGroup. La verifica sarà effettuata tramite raffronto sui campi TIN;
o Verifica di esistenza del blocco Intermediary in un numero di blocchi pari ad almeno il numero di occorrenze del blocco ReportingGroup meno 1. In sostanza la molteplicità del blocco ReportingGroup è ammessa solo per comunicare gli AccountReport riferibili ad ogni Intermediary e, in un unico e distinto blocco ReportingGroup, gli AccountReport riferibili alla stessa ReportingFI.
BLOCCO ReportingFI
• Il campo TIN deve essere presente con molteplicità pari a 2
• Il primo campo TIN deve contenere il codice fiscale italiano dell’istituzione finanziaria
• Il primo attributo issuedBy deve contenere il valore IT
• Il codice fiscale presente deve essere formalmente corretto (l’esistenza in anagrafe tributaria è verificata all’accoglienza del file)
• Il secondo campo TIN deve contenere il GIIN dell’istituzione finanziaria
• Nel secondo campo TIN non deve esserci l’attributo issuedBy
• In assenza del blocco Sponsor, il GIIN presente nel secondo TIN deve essere uguale a quello inserito nel campo SendingCompanyIN del BLOCCO MessageSpec
BLOCCO ReportingGroup
• Il blocco PoolReport non deve essere presente
• Se DocTypeIndic = FATCA1, deve essere presente almeno un blocco
AccountReport
BLOCCO Sponsor
• Il campo TIN deve essere presente con molteplicità pari a 2
• Il primo campo TIN deve contenere il codice fiscale italiano dello sponsor
• Il primo attributo issuedBy deve contenere il valore IT
• Il codice fiscale presente deve essere formalmente corretto (l’esistenza in anagrafe tributaria è verificata all’accoglienza del file)
• Il secondo campo TIN deve contenere il GIIN ottenuto in qualità di
Sponsoring Entity
• Nel secondo campo TIN non deve esserci l’attributo issuedBy per indicare gli US come paese emittente
• Il GIIN presente nel secondo TIN deve essere uguale a quello inserito nel campo SendingCompanyIN del BLOCCO MessageSpec
BLOCCO Intermediary
• Il campo TIN deve essere presente una sola volta
• Nel campo TIN non deve esserci l’attributo issuedBy per indicare gli US come paese emittente
BLOCCO AccountReport
BLOCCO AccountHolder
• il TIN presente nel blocco Individual o Organisation deve contenere il TIN statunitense e deve essere presente obbligatoriamente a partire dalle comunicazioni relative all’anno 2017. Se l’FI è in possesso del codice fiscale italiano del soggetto, questo deve essere inserito, anche in aggiunta a quello statunitense. In presenza di codici fiscali italiani, sarà verificata la loro correttezza formale.
• Nel campo TIN non deve esserci l’attributo issuedBy per indicare gli US come paese emittente
BLOCCO SubstantialOwner
• Il blocco è obbligatorio se AccHolderType = FATCA102
• il TIN presente nel blocco deve contenere il TIN statunitense e deve essere presente obbligatoriamente a partire dalle comunicazioni relative all’anno 2017. Se l’FI è in possesso del codice fiscale italiano del soggetto, questo deve essere inserito, anche in aggiunta a quello statunitense. In presenza di codici fiscali italiani, sarà verificato che siano codici fiscali di persona fisica formalmente corretti.
Tag Account Balance
Il valore del campo AccountBalance non può essere negativo
BLOCCO Payment
• Il blocco Payment non deve essere presente per l’anno di riferimento 2014.
• Il valore di PaymentAmnt non può essere negativo
BLOCCO DocSpecType
• Il campo DocRefId è una stringa di 53 caratteri che deve seguire la sintassi indicata:
MessageRefID (41 caratteri) + TipoBlocco (2 caratteri) + Progressivo (10 caratteri)
dove TipoBlocco può valere:
FI = ReportingFI, SP= Sponsor,
IN = Intermediary, AR = AccountReport
TipoBlocco deve corrispondere alla tipologia del blocco cui fa riferimento il DocRefId.
La stringa non deve contenere spazi.
• CorrMessageRefId: vedi controlli per MessageRefID
• CorrDocRefId: vedi controlli per DocRefId. Il TipoBlocco deve essere coerente con il TipoBlocco del DocRefID.
• Se DocTypeIndic è = FATCA1 non devono essere presenti i campi
CorrMessageRefId e CorrDocRefId
• Se DocTypeIndic è = FATCA2 o FATCA3 o FATCA4 devono essere presenti i campi CorrMessageRefId e CorrDocRefId
• Tutti e soli gli identificativi presenti in CorrMessageRefId devono essere riportati nel campo CorrMessageRefId del blocco MessageSpec
BLOCCO AddressType
• L’attributo legalAddressType non deve essere presente.
• Se il primo tag indicato è AddressFree non possono seguire AddressFix
• Se il primo blocco indicato è AddressFix seguito dal blocco AddressFree, nel blocco AddressFix devono essere obbligatoriamente valorizzati gli elementi PostCode, City e CountrySubentity
3.6 CARATTERI AMMESSI NELLA COMPILAZIONE DELL’XML
Il file XML può contenere esclusivamente caratteri previsti dalla codifica ISO/IEC 8859-1.
Inoltre, i valori compresi nei campi non possono contenere i caratteri indicati nella tabella seguente nella colonna “caratteri non ammessi”.
Caratteri non ammessi | Descrizione |
' | Apostrophe |
- - | Double Dash |
# | Hash |
& | Ampersand |
< | Less Than |
" | Quotation Mark |
> | Greater Than |
3.7 VALORIZZAZIONE DEI SALDI FINALI E DELLE TIPOLOGIE DI RAPPORTO DEL BLOCCO
“ACCOUNT REPORT”
Al fine di semplificare e rendere omogenee le modalità di calcolo del saldo finale dei rapporti rilevanti ai fini FATCA, le RIFI applicano gli stessi criteri di cui alle “Istruzioni per la compilazione del tracciato record e dei dati contabili (provvedimento del 25 marzo 2013 recante “modalità per la comunicazione integrativa annuale all’archivio dei rapporti finanziari” pubblicate in data 8 agosto 2013 sul sito dell’Agenzia delle Entrate, che si riportano con opportuni necessari adattamenti. Per le tipologie di rapporto che, al contrario, devono essere valorizzate soltanto in base alla normativa FATCA il saldo sarà pari al valore indicato nel rendiconto predisposto per la clientela o in mancanza al valore di mercato ovvero se trattasi di strumento finanziario non quotato in mercato regolamentato sarà indicato il valore nominale, secondo quanto stabilito, per i saldi dei conti da trasmettere, dall’articolo 5, comma 1, lettera a), n. 4) del D.M.
3.7.1 TABELLA DI RAFFRONTO TRA LE TIPOLOGIE DI RAPPORTO COMUNICATE ALL’ARCHIVIO E LE TIPOLOGIE RILEVANTI PER LA NORMATIVA FATCA
La tabella che segue raffronta i rapporti finanziari già comunicati dalle RIFI ai sensi della normativa nazionale e la relativa qualificazione ai sensi della normativa FATCA e vengono riportate e opportunamente adattate le regole già richiamate per la valorizzazione dei saldi finali. Si precisa che la tabella non ha valore esaustivo delle tipologie di rapporto oggetto di comunicazione ai sensi della normativa FATCA ed è redatta al fine di semplificare gli adempimenti da parte delle RIFI.
Tipo rapporto ADRF | Descrizione | Natura rapporto FATCA | Valorizzazione del saldo |
1 | Conto corrente | Depository account | Saldo Contabile alla data di fine anno. Se il rapporto è chiuso nel corso dell’anno di riferimento il saldo di chiusura da comunicare è quello relativo al maggiore tra: - il saldo contabile iniziale del giorno in cui è stato effettuato l’ultimo addebito prima della chiusura del rapporto; - quello risultante al momento della estinzione (sommatoria del saldo alla chiusura e relativi addebiti e accrediti per competenze). Terzo e residuale criterio di valorizzazione |
del saldo del conto corrente, consistente nell’attribuzione del valore diverso da zero prima della movimentazione di azzeramento | |||
2 | Conto deposito titoli e/o obbligazioni | Custodial account | Controvalore dei titoli rilevato contabilmente alla data di fine anno o immediatamente prima della data di chiusura ovvero del valore risultante dall’ultima rendicontazione predisposta per la clientela prima della chiusura |
3 | Conto deposito a risparmio libero/vincolato | Depository account | Saldo Contabile alla data di fine anno o immediatamente prima della data di chiusura. Per i conti deposito nominativi e al portatore si applicano le stesse regole dei conti correnti. |
4 | Rapporto fiduciario ex legge n. 1966/1939 | Custodial account | Controvalore rilevato contabilmente alla data di fine anno o immediatamente prima della data di chiusura ovvero del valore risultante dall’ultima rendicontazione predisposta per la clientela prima della chiusura |
5 | Gestione collettiva del risparmio | Financial account | Ammontare del contratto di gestione alla data di fine anno o immediatamente prima della data di chiusura ovvero del valore risultante dall’ultima rendicontazione predisposta per la clientela prima della chiusura |
6 | Gestione patrimoniale | Custodial account | Valore globale del patrimonio alla data di fine anno o immediatamente prima della data di chiusura ovvero del valore risultante dall’ultima rendicontazione predisposta per la clientela prima della chiusura |
7 | Certificati di deposito e buoni fruttiferi | Depository account | Totale degli importi facciali dei certificati o dei buoni a fine anno o al momento dell’estinzione. |
8 | Portafoglio | Non previsto da normativa FATCA | |
9 | Conto terzi individuale / globale | Depository account | Stessi criteri del conto corrente |
10 | Dopo incasso | Non previsto da normativa FATCA | |
11 | Cessione indisponibile | Depository account | Saldo contabile alla data di fine anno o immediatamente prima della data di chiusura |
12 | Cassette di sicurezza | Non previsto da normativa FATCA | |
13 | Depositi chiusi | Non previsto da normativa FATCA | |
14 | Contratti derivati | Custodial account | Valore di mercato totale dei contratti accesi nell’anno di riferimento rendicontati al cliente |
15 | Carte di credito / debito | Depository account solo per la tipologia carte prepagate e le carte IBAN per le quali vale quanto detto per i conti correnti | Per le carte prepagate ricaricabili e le carte con IBAN valgono le stesse regole dei conti correnti. |
16 | Garanzie | Non previsto da normativa FATCA | |
17 | Crediti | Non previsto da normativa FATCA | |
18 | Finanziamenti | Non previsto da normativa FATCA | |
19 | Fondi pensione | FATCA Financial account | |
20 | Patto compensativo | Non previsto da normativa FATCA | |
21 | Finanziamento in pool | Non previsto da normativa FATCA | |
22 | Partecipazione | Financial account/Equity interest | Si fa riferimento ai soggetti che hanno sottoscritto capitale di rischio o di debito nella holding. Il valore è quello indicato nel rendiconto comunicato al cliente, o valore di |
mercato. Per i titoli non quotati il valore nominale | |||
23 | Prodotti finanziari emessi da imprese di assicurazione | Insurance contract/annuity contract/cash value insurance contract | Importo del valore maturato a fine anno o di riscatto totale in caso di cessazione |
24 | Acquisto e vendita di oro da investimento | Non previsto da normativa FATCA | |
98 | Operazione Extra- conto | Non previsto da normativa FATCA | |
99 | Altro rapporto | Non previsto da normativa FATCA |
3.7.2 MODALITÀ DI CALCOLO DEI SALDI
In linea generale ai fini della valorizzazione del saldo finale va considerato il dato risultante alle ore 24:00 del 31 dicembre dell’anno di riferimento.
Tale regola si applica a tutti i conti finanziari, anche se diversi dai rapporti di conto corrente, che siano chiusi nel corso dell’anno di riferimento della comunicazione.
Nel caso di conto finanziario chiuso nel corso dell’anno di riferimento della comunicazione, il saldo di chiusura da comunicare è quello relativo al maggiore tra:
- il saldo contabile iniziale del giorno in cui è stato effettuato l’ultimo addebito prima della chiusura del rapporto e
- quello risultante al momento della estinzione (sommatoria del saldo alla chiusura e relativi addebiti e accrediti per competenze).
Qualora i predetti criteri non siano applicabili, si utilizzerà il criterio residuale di valorizzazione del saldo consistente nell’attribuzione del valore prima della chiusura, ovvero del valore risultante dall’ultima rendicontazione predisposta per la clientela prima della chiusura.
CONTI CORRENTI E ALTRI RAPPORTI IN DIVISA ESTERA O MULTIDIVISA
Nel caso di rapporti in divisa estera deve essere indicata la divisa del conto. Se il conto è suddiviso in più valute allora bisogna valorizzare l’importo totale in euro o in dollari USA ai cambi ufficiali di fine anno o, se il conto si è estinto nell’anno, al valore dei cambi alla data di chiusura.
Il saldo da valorizzare è quello contabile alla data di riferimento e non quello disponibile per effetto di eventuali affidamenti.
L’attività di mera raccolta ordini, cui cioè non faccia seguito relativa attività di esecuzione sul mercato da parte dell’intermediario stesso (ma questi operi unicamente come collettore e trasmettitore di tali ordini ad altro operatore perché ne provveda all’esecuzione), non deve essere segnalata.
Per i rapporti in essere per l’intero periodo di riferimento attivi dal 1° gennaio al 31 dicembre dell’anno di riferimento della comunicazione va considerato il dato presente alle ore 24:00 del giorno di riferimento per il saldo finale. A titolo esemplificativo, se consideriamo il periodo 1° gennaio 2014 e 31 dicembre 2014, deve essere indicato come saldo finale il saldo contabile alle ore 24:00 del 31 dicembre 2014.
Per i rapporti chiusi nel corso dell’anno di riferimento della comunicazione il saldo di chiusura da comunicare è quello relativo al maggiore tra:
- il saldo contabile iniziale del giorno in cui è stato effettuato l’ultimo addebito prima della chiusura del rapporto e
- quello risultante al momento della estinzione (sommatoria del saldo alla chiusura e relativi addebiti e accrediti per competenze).
Terzo e residuale criterio di valorizzazione del saldo del conto corrente, consistente nell’attribuzione del valore diverso da zero prima della movimentazione di azzeramento.
CONTI DI PAGAMENTO
Ai fini delle segnalazioni dei saldi e dei movimenti detti rapporti sono equiparati ai rapporti codice 01.
Pertanto valgono le stesse considerazioni previste per i conti correnti.
CONTO DEPOSITO TITOLI E/O OBBLIGAZIONI - RAPPORTO CODICE 02
Per conto “deposito titoli e/o obbligazioni” si intende il dossier titoli.
In presenza di un conto di appoggio per operazioni in titoli, sul quale vengono registrati addebiti e accrediti per acquisti e vendite, questo deve essere segnalato come conto corrente - tipo rapporto 01 – e valorizzato in maniera autonoma rispetto al conto deposito e/o conto titoli.
Ai fini della valorizzazione dei titoli che compongono il dossier va indicato il valore come da estratto conto. Questo vale anche per i dossier titoli che non producono un estratto conto (ad esempio i dossier transitori, i dossier per operatività in Fondi e Sicav e per operatività pronti contro termine): si deve indicare il valore contenuto nella rendicontazione predisposta per la clientela.
In alcune tipologie di titoli, come ad esempio i titoli non quotati, non viene indicato alcun saldo (sull’estratto conto è riportata la dicitura ND): in questo caso bisogna indicare il valore nominale. Se l’estratto conto titoli indica due tipologie di controvalore - il fair value e il presumibile valore di realizzo – il valore da utilizzare è quello fair value alla data dell’operazione.
I depositi overnight, tom-next e spot-next non devono essere segnalati. Sono da segnalare i depositi intrattenuti con altri operatori finanziari. Nel caso di depositi con controparti estere, il deposito deve ugualmente essere segnalato.
Nel caso di prodotti finanziari non gestiti in un deposito titoli e comunicati come rapporti autonomi (ad esempio le operazioni di pronti contro termine, certificati di deposito, derivati quotati, fondi di investimento, ecc..) questi vanno classificati con gli appositi codici di rapporto e riferiti alla corrispondente natura FATCA.
CONTO DEPOSITO A RISPARMIO LIBERO/VINCOLATO - RAPPORTO CODICE 03
Con riferimento ai depositi di risparmio nominativi e al portatore - codice rapporto 03 - si applicano le stesse regole per la valorizzazione dei saldi infrannuali o annuali dei conti correnti.
RAPPORTO FIDUCIARIO - RAPPORTO CODICE 04
Come principio generale si precisa che il dato da comunicare relativo al rapporto di natura finanziaria deve essere sempre quello del resoconto contabile o di valorizzazione comunicato al cliente o che si avvicina il più possibile a tale valore.
Nel caso di rapporto fiduciario che gestisce valori mobiliari e polizze, il valore da indicare è quello dato dal gestore o dalla compagnia assicurativa.
Nel caso di gestione di quote di società non quotate, il valore da indicare è quello nominale.
Nel caso di gestione di mandati di amministrazione senza intestazione l’importo da indicare è quello dichiarato dal fiduciante.
GESTIONE COLLETTIVA DEL RISPARMIO - RAPPORTO CODICE 05
Rientrano in tale categoria le quote o azioni di OICR, diverse da quelle quotate o dematerializzate, ai sensi dell’art. 1, n. 14) del D. M. se sottoscritte in nome del cliente.
Per una corretta valorizzazione degli importi le quote o azioni detenute in OICR diversi o in comparti differenti del medesimo OICR sono considerate conti finanziari distinti.
Ai fini della valorizzazione del rapporto di “gestione collettiva del risparmio”, il dato del saldo da comunicare corrisponde al numero di quote detenute dal cliente valorizzate al valore unitario della quota (NAV – Net Asset Value) come risultante dall’ultimo prospetto contabile del fondo disponibile alla data di riferimento.
Ai fini della normativa FATCA non rientrano tra i rapporti di “gestione collettiva del risparmio” di cui alla presente sezione le quote o azioni sottoscritte tramite altra istituzione finanziaria che agisce in nome proprio e per conto del cliente, che è tenuta ad effettuare le comunicazioni previste dalla normativa FATCA secondo le modalità e i termini stabiliti per “custodial accounts”. Ai fini della valorizzazione degli importi da comunicare in relazione a tali “custodial accounts” è possibile considerare come unico rapporto le sottoscrizioni effettuate dall’investitore anche con OICR diversi.
Le segnalazioni relative alle quote o azioni di OICR quotate o dematerializzate sono effettuate dall’istituzione finanziaria presso cui l’investitore le detiene in deposito seguendo le regole previste per i “custodial accounts” (e specificamente quelle previste per i rapporti di deposito titoli).
GESTIONE PATRIMONIALE - RAPPORTO CODICE 06
I saldi del rapporto di gestione patrimoniale vanno comunicati tenendo conto del dato comunicato nel rendiconto di gestione predisposto per il cliente. In
particolare per i conti chiusi nel corso dell’anno deve farsi riferimento al saldo positivo esistente alle ore 00:00 del giorno in cui si verifica l’azzeramento del conto
Tenendo conto delle indicazioni fornite dalla Banca d’Italia nel Regolamento del 29 ottobre 2007, ai fini del deposito degli strumenti finanziari e della liquidità di pertinenza del cliente, il gestore può adottare due diverse modalità operative:
1. apertura, presso uno o più intermediari (ad esempio, una banca) diversi dal gestore (ad esempio, una SGR), di un conto liquidità e di un conto titoli a nome del cliente (“conti di appoggio”), dedicati esclusivamente al compimento delle operazioni relative alla gestione di portafogli, con conferimento al gestore di una delega a movimentare i suddetti conti nell’ambito del mandato di gestione. In questo caso le comunicazioni ai fini della normativa FATCA sono effettuate dagli intermediari diversi dal gestore presso cui risultano aperti i “conti di appoggio”, secondo le modalità previste per i “depository accounts” (relativamente al conto di liquidità) e per i “custodial accounts” (con riguardo al conto titoli). Nessuna segnalazione è, invece, dovuta dal gestore in relazione al rapporto di gestione patrimoniale;
2. deposito della liquidità e sub-deposito degli strumenti finanziari presso altro intermediario in conti intestati al gestore (“conti omnibus”, intestati ad esempio a una SGR), con indicazione che si tratta di beni di terzi: in questo caso la segnalazione del rapporto di gestione è effettuata dal soggetto gestore.
CERTIFICATI DI DEPOSITO - RAPPORTO CODICE 07
I certificati di deposito e altre forme di investimento, che sono incluse in un deposito titoli già comunicato con tipo rapporto 02, dovranno essere valorizzati insieme agli altri titoli e strumenti finanziari in portafoglio. Qualora l’operatore abbia comunicato i certificati di deposito come rapporto autonomo con codice 07, gli stessi saranno conseguentemente valorizzati autonomamente.
In questo caso, con riguardo al numero totale dei certificati dovranno essere indicati tutti i certificati in essere nel periodo di riferimento, anche se estinti prima del 31 dicembre o accesi prima del periodo in segnalazione.
CONTRATTI DERIVATI - RAPPORTO CODICE 14
Ai fini delle segnalazioni di questo rapporto va preso in considerazione il contratto quadro/principale o in alternativa i singoli specifici contratti. Gli importi da comunicare sono quelli dei contratti accesi durante l’anno (totale) e di quelli chiusi.
L’importo da indicare è quello corrispondente al valore di mercato totale dei contratti rendicontati al cliente.
Il contratto derivato va segnalato anche se nell’anno di riferimento non sono state effettuate operazioni (sottoscrizione nuovi contratti o incasso di quelli in corso).
Se all’interno di uno stesso derivato si opera con valute diverse, ai fini della valorizzazione dell’importo, è necessario convertire le valute in euro o dollari USA.
PRODOTTI FINANZIARI EMESSI DA IMPRESE DI ASSICURAZIONE ANCHE IN REGIME DI LIBERA PRESTAZIONE DI SERVIZI - RAPPORTO CODICE 23
Ai fini della indicazione dell’importo del saldo deve essere rilevato l’importo lordo relativo al valore maturato o di riscatto totale, per quanto riguarda le polizze unit- linked, index- linked e dei contratti di capitalizzazione.
Per quanto riguarda gli altri prodotti assicurativi si fa riferimento al Decreto Ministeriale, ovvero deve essere effettuata la segnalazione del solo valore di riscatto (il cash value - valore di riscatto) o, in mancanza, la riserva matematica.